RE: a question on marking packets

RE: a question on marking packets

[Shipman, Jeffrey E]

The incoming packets will fit a particular criteria
as in what port it is connecting to, what options
and flags are set, etc. The outgoing packet really
depends on what was incoming. We see what pattern
we matched as, and then we have a hash table of modifications
for the packet (just about anything can be modified)
that we'll need to perform. The trouble is making sure
we're modifying the correct outgoing packet which
is in response to the packet that came in.

Jeff Shipman - CCD
Sandia National Laboratories
(505) 844-1158 / MS-1372


-----Original Message-----
From: Henrik Nordstrom [mailto:hno@marasystems.com]
Sent: Tuesday, July 09, 2002 4:04 PM
To: Shipman, Jeffrey E; 'netfilter-devel@lists.samba.org'
Subject: Re: a question on marking packets


mark values are unique per packet. the response packet will get a new mark 
value, initially 0..

but there is help. See the CONNMARK pactch in patch-o-matic. Adds a similar 
mark value to conntrack, allowing you to mark a connection rather than 
individual packets.

Why do you need mark values to know which packets to modify? How are you 
modifying packets, and why? Perhaps there is a better way if you describe a 
little of what you are up to doing.

Regards
Henrik Nordström
MARA Systems AB, Sweden




Shipman, Jeffrey E wrote:
> I have a situation where I need to be able to
> mark packets on the NF_IP_LOCAL_IN hook that
> match certain patterns we will be watching
> for. This because after accept the packet and
> the response packet is generated (NF_IP_LOCAL_OUT),
> we must be able to know how to modify this packet
> depending on the results from that incoming
> packet. Does anyone have some advice how to properly
> mark these packets so we can do this? Any tips
> or direction on where to look would be most
> appreciated.
>
> TIA,
>
> Jeff Shipman - CCD
> Sandia National Laboratories
> (505) 844-1158 / MS-1372

Re: a question on marking packets

[Henrik Nordstrom]

I assume you by incoming/outgoing packets refer to incoming and response 
packets.. not single packets coming in to a router on one interface and going 
out on another after possibly having some kind of transformation applied to 
them..

Will be damn hard...

a) As you seem to be messing around with the packets outside of the netfilter 
NAT framework you cannot use conntrack.. (I assume these modifications may 
include addressing/port modifications).

b) As incoming packets has not yet been processed by the TCP/IP stack you 
don't know which socket these will get accepted by, so your cannot base any 
desisions on the local socket..

c) You cannot use nfmark, as nfmark is per-packet, not at all connection 
related.. A response pakcket is a new packet, and will have a new nfmark 
value, not related to the incoming packet..

d) You cannot use ToS, as this is not reflected by the TCP/IP kernel.. and is 
generally to small for this kind of things anyway, indended for other uses.

Basically you would need to implement your own connection tracking based on 
the packets you have sent to the TCP/IP kernel, and invert the tuple to match 
possible response packets.


It is a little bit hard to theorise on this on a packet level without knowing 
what kind of packets we are talking about here or the application/purpose on 
why you are modifying the packets. Does this involve TCP/UDP/whatever? Do you 
have control of the application that generates the response packets? And many 
other similar questions..

Regards
Henrik Nordström
MARA Systems AB, Sweden


Shipman, Jeffrey E wrote:
> The incoming packets will fit a particular criteria
> as in what port it is connecting to, what options
> and flags are set, etc. The outgoing packet really
> depends on what was incoming. We see what pattern
> we matched as, and then we have a hash table of modifications
> for the packet (just about anything can be modified)
> that we'll need to perform. The trouble is making sure
> we're modifying the correct outgoing packet which
> is in response to the packet that came in.
>
> Jeff Shipman - CCD
> Sandia National Laboratories
> (505) 844-1158 / MS-1372

RE: a question on marking packets

[Shipman, Jeffrey E]

You are correct in saying that the packets will be coming
in and leaving on the same interface. I am dealing with TCP/UDP
packets and the addresses/ports will not be changed. The things
I will be changing are possibly:

Sequence Numbers, Flags, Options, Don't Fragment bit,
window sizes, Type of Service, UDP data, etc.

Pretty much anything in the IP/TCP/UDP layers that don't
involve changing the source or destination addresses/ports. :)

Essentially what we are doing are emulating the behavior
of other OSs based on signatures we've already gathered.
This requires modifying or dropping the outgoing packets
that are in response to particular incoming packets.

I don't have control of the applications while my
module is being used inside the kernel.

I was thinking we'd probably have to come up with our
own solution, but I was hoping Netfilter had something
to support this situation. 

Either way, thank you so much for your help!

Jeff Shipman - CCD
Sandia National Laboratories
(505) 844-1158 / MS-1372


-----Original Message-----
From: Henrik Nordstrom [mailto:hno@marasystems.com]
Sent: Tuesday, July 09, 2002 4:42 PM
To: Shipman, Jeffrey E; 'netfilter-devel@lists.samba.org'
Subject: Re: a question on marking packets


I assume you by incoming/outgoing packets refer to incoming and response 
packets.. not single packets coming in to a router on one interface and
going 
out on another after possibly having some kind of transformation applied to 
them..

Will be damn hard...

a) As you seem to be messing around with the packets outside of the
netfilter 
NAT framework you cannot use conntrack.. (I assume these modifications may 
include addressing/port modifications).

b) As incoming packets has not yet been processed by the TCP/IP stack you 
don't know which socket these will get accepted by, so your cannot base any 
desisions on the local socket..

c) You cannot use nfmark, as nfmark is per-packet, not at all connection 
related.. A response pakcket is a new packet, and will have a new nfmark 
value, not related to the incoming packet..

d) You cannot use ToS, as this is not reflected by the TCP/IP kernel.. and
is 
generally to small for this kind of things anyway, indended for other uses.

Basically you would need to implement your own connection tracking based on 
the packets you have sent to the TCP/IP kernel, and invert the tuple to
match 
possible response packets.


It is a little bit hard to theorise on this on a packet level without
knowing 
what kind of packets we are talking about here or the application/purpose on

why you are modifying the packets. Does this involve TCP/UDP/whatever? Do
you 
have control of the application that generates the response packets? And
many 
other similar questions..

Regards
Henrik Nordström
MARA Systems AB, Sweden


Shipman, Jeffrey E wrote:
> The incoming packets will fit a particular criteria
> as in what port it is connecting to, what options
> and flags are set, etc. The outgoing packet really
> depends on what was incoming. We see what pattern
> we matched as, and then we have a hash table of modifications
> for the packet (just about anything can be modified)
> that we'll need to perform. The trouble is making sure
> we're modifying the correct outgoing packet which
> is in response to the packet that came in.
>
> Jeff Shipman - CCD
> Sandia National Laboratories
> (505) 844-1158 / MS-1372

Re: a question on marking packets

[Henrik Nordstrom]

mark values are unique per packet. the response packet will get a new mark 
value, initially 0..

but there is help. See the CONNMARK pactch in patch-o-matic. Adds a similar 
mark value to conntrack, allowing you to mark a connection rather than 
individual packets.

Why do you need mark values to know which packets to modify? How are you 
modifying packets, and why? Perhaps there is a better way if you describe a 
little of what you are up to doing.

Regards
Henrik Nordström
MARA Systems AB, Sweden




Shipman, Jeffrey E wrote:
> I have a situation where I need to be able to
> mark packets on the NF_IP_LOCAL_IN hook that
> match certain patterns we will be watching
> for. This because after accept the packet and
> the response packet is generated (NF_IP_LOCAL_OUT),
> we must be able to know how to modify this packet
> depending on the results from that incoming
> packet. Does anyone have some advice how to properly
> mark these packets so we can do this? Any tips
> or direction on where to look would be most
> appreciated.
>
> TIA,
>
> Jeff Shipman - CCD
> Sandia National Laboratories
> (505) 844-1158 / MS-1372

a question on marking packets

[Shipman, Jeffrey E]

I have a situation where I need to be able to
mark packets on the NF_IP_LOCAL_IN hook that
match certain patterns we will be watching
for. This because after accept the packet and 
the response packet is generated (NF_IP_LOCAL_OUT),
we must be able to know how to modify this packet
depending on the results from that incoming
packet. Does anyone have some advice how to properly
mark these packets so we can do this? Any tips
or direction on where to look would be most
appreciated.

TIA, 

Jeff Shipman - CCD
Sandia National Laboratories
(505) 844-1158 / MS-1372