Packet Fragementation

Packet Fragementation

[Sara Kostandy]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

We're developing an XML firewall application as part of our senior graduation project. We are using Linux 2.4 and queuing packets to be handled in user-space. However the packets arriving are fragmented, and so are more difficult to deal with. Is there a way to defragment them before they are queued to user-space?? 


---------------------------------
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

[-- Attachment #2: Type: text/html, Size: 496 bytes --]

Re: Packet Fragementation

[Pablo Neira]

Hi Sara,

Sara Kostandy wrote:

> We're developing an XML firewall application as part of our senior 
> graduation project. We are using Linux 2.4 and queuing packets to be 
> handled in user-space. However the packets arriving are fragmented, 
> and so are more difficult to deal with. Is there a way to defragment 
> them before they are queued to user-space??
>
In 2.4, the easiest way is loading the ip_conntrack module which will 
gather all the fragments and put them in a continuos memory area, this 
means that you won't need to deal with fragments anymore.

regards,
Pablo

Re: Packet Fragementation

[Scott MacKay]

Is the defragmented packet the thing passed up to the
userspace application?
If so, where in the whole netfilter process is the
packet re-fragmented? 
Oh, also, if a defragmented packet is passed up, then
I could see the buffer needs to be fairly large
(potentially).  Is there a way to tell how big an
incoming message awaiting delivery via ipq_read() is? 
Is there a way to keep conntrack from passing up a
de-fragmented packet (so still have conntrack make
it's session info, but not pass up defragmented data)?

Thanks!
-Scott

--- Pablo Neira <pablo@eurodev.net> wrote:
> Hi Sara,
> 
> Sara Kostandy wrote:
> 
> > We're developing an XML firewall application as
> part of our senior 
> > graduation project. We are using Linux 2.4 and
> queuing packets to be 
> > handled in user-space. However the packets
> arriving are fragmented, 
> > and so are more difficult to deal with. Is there a
> way to defragment 
> > them before they are queued to user-space??
> >
> In 2.4, the easiest way is loading the ip_conntrack
> module which will 
> gather all the fragments and put them in a continuos
> memory area, this 
> means that you won't need to deal with fragments
> anymore.
> 
> regards,
> Pablo
> 
> 

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Packet Fragementation

[Henrik Nordstrom]

On Tue, 30 Mar 2004, Scott MacKay wrote:

> Is the defragmented packet the thing passed up to the
> userspace application?

Yes.

> If so, where in the whole netfilter process is the
> packet re-fragmented? 

Just before it is sent out on the wire. Done by a conntrack hook running
very last at NF_IP_POST_ROUTING (search for ip_refrag).

> Oh, also, if a defragmented packet is passed up, then
> I could see the buffer needs to be fairly large
> (potentially).

Yes, or to be exact up to the maximum size of an IP packet (65535 octets).

> Is there a way to tell how big an
> incoming message awaiting delivery via ipq_read() is? 

libipq does not support this, but it should be possible to peek the size 
with a recvfrom using MSG_PEEK | MSG_TRUNC.

> Is there a way to keep conntrack from passing up a
> de-fragmented packet (so still have conntrack make
> it's session info, but not pass up defragmented data)?

Not yet. In the way things are designed the original fragments is 
completely lost. This is considered a design bug in how conntrack deals 
with fragmented packets bug unfortunately is how things work.

Regards
Henrik

Re: Packet Fragementation

[Scott MacKay]

--- Henrik Nordstrom <hno@marasystems.com> wrote:
> On Tue, 30 Mar 2004, Scott MacKay wrote:
> > If so, where in the whole netfilter process is the
> > packet re-fragmented? 
> 
> Just before it is sent out on the wire. Done by a
> conntrack hook running
> very last at NF_IP_POST_ROUTING (search for
> ip_refrag).
Hm, I would guess it is after the mangle table
processing but will check.

> > Is there a way to tell how big an
> > incoming message awaiting delivery via ipq_read()
> is? 
> 
> libipq does not support this, but it should be
> possible to peek the size 
> with a recvfrom using MSG_PEEK | MSG_TRUNC.
TY!  This will help alot.

> > Is there a way to keep conntrack from passing up a
> > de-fragmented packet (so still have conntrack make
> > it's session info, but not pass up defragmented
> data)?
> 
> Not yet. In the way things are designed the original
> fragments is 
> completely lost. This is considered a design bug in
> how conntrack deals 
> with fragmented packets bug unfortunately is how
> things work.
Then, as an option, is there any way to make a packet
re-enter the conntrack after mangle in PREROUTING? 
The problem I will be seeing is that I do some packet
mangling in mangle/POSTROUTING that I want to un-do
before the conntrack/PREROUTING get it.  I hoped to
use  raw/PREROUTING, but if mangle/POSTROUTING
generates a whole packet and raw/PREROUTING sees
fragments, then it just won't work.  If, in
mangle/PREROUTING (namely IP_QUEUE kicked off by
mangle/PREROUTING) I can do my un-mangling and make it
run thru conntrack again as a new packet then
everything is cool.  Thanks in advance!

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Packet Fragementation

[Henrik Nordstrom]

On Wed, 31 Mar 2004, Scott MacKay wrote:

> > Just before it is sent out on the wire. Done by a
> > conntrack hook running
> > very last at NF_IP_POST_ROUTING (search for
> > ip_refrag).
>
> Hm, I would guess it is after the mangle table
> processing but will check.

It is the very last thing in the netfilter hooks, well after mangle.

> > Not yet. In the way things are designed the original fragments is
> > completely lost. This is considered a design bug in how conntrack
> > deals with fragmented packets bug unfortunately is how things work.
>
> Then, as an option, is there any way to make a packet
> re-enter the conntrack after mangle in PREROUTING? 

What you mean?

> The problem I will be seeing is that I do some packet
> mangling in mangle/POSTROUTING that I want to un-do
> before the conntrack/PREROUTING get it.

Eh? You can not go back in time..

Regards
Henrik

Re: Packet Fragementation

[Scott MacKay]

--- Henrik Nordstrom <hno@marasystems.com> wrote:
> On Wed, 31 Mar 2004, Scott MacKay wrote:

> > Then, as an option, is there any way to make a
> packet
> > re-enter the conntrack after mangle in PREROUTING?
> 
> 
> What you mean?
Basically, incoming packets will be in a mangled
state, so conntrack likely will not make any useful
associations (data-aware type associations), though it
can provide the service of tying back together
fragments.  I need to de-mangle, but am limited to
mangle/PREROUTING (to get the de-fragmented data, the
same data I would be mangling in the sender's
mangle/POSTROUTING).  After I de-mangle the data, I
would like to generate proper conn track information. 
Basically, I was wondering if I could in any way make
it run the de-mangled packet back thru the conntrack
so it could establish it's data-aware conn tack
information.  If there is code I can add to ip_queue.c
to re-invoke the calls the system makes to hook in
conn track that would be good.  
For what I am doing, I am guessing it would be cleaner
to look at making a kernel level hook, but I am not as
well versed with that style of programming.



__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Packet Fragementation

[Henrik Nordstrom]

On Wed, 31 Mar 2004, Scott MacKay wrote:

> Basically, incoming packets will be in a mangled
> 
> --- Henrik Nordstrom <hno@marasystems.com> wrote:
> > On Wed, 31 Mar 2004, Scott MacKay wrote:
> 
> > > Then, as an option, is there any way to make a
> > packet
> > > re-enter the conntrack after mangle in PREROUTING?
> > 
> > 
> > What you mean?
>
> state, so conntrack likely will not make any useful
> associations (data-aware type associations), though it
> can provide the service of tying back together
> fragments.  I need to de-mangle, but am limited to
> mangle/PREROUTING (to get the de-fragmented data, the
> same data I would be mangling in the sender's
> mangle/POSTROUTING).


there is plenty of space inbetween defragmenting and conntrack..

defragmentation runs at a separate hook at 
priority NF_IP_PRI_CONNTRACK_DEFRAG (-400) while conntrack runs at 
NF_IP_PRI_CONNTRACK (-200). Anything you do between there will see 
defragmented packets before conntrack sees them. This applies to both 
NF_IP_PRE_ROUTING (input) and NF_IP_LOCAL_OUT (output).

In iptables you have the "raw" table which runs at NF_IP_PRI_RAW 
(-200). If you are writing your own netfilter module for the 
mangling/demangle then any priority -399 to -201 will place your module 
between defragmentation and connection tracking.

Then in NF_IP_POST_ROUTING there is two conntrack hooks running at the
very last prioritites, one which confirms sessions (makes the conntrack
"official"), immediately followed by the refragmenter. The first is not
involved in connection tracking as such, it only confirms the session
related to the packet in connection tracking as a valid session.

Regards
Henrik

Re: Packet Fragementation

[Scott MacKay]

--- Henrik Nordstrom <hno@marasystems.com> wrote:
> In iptables you have the "raw" table which runs at
> NF_IP_PRI_RAW 
> (-200). If you are writing your own netfilter module
> for the 
> mangling/demangle then any priority -399 to -201
> will place your module 
> between defragmentation and connection tracking.

You are the god!!!! TY so much :)
Actually, NF_IP_PRI_RAW is -300 (at least 2.4.25
kernel patch) , so I am golden.
I should be able to register at raw/PREROUTING and get
defragmented packets, fixing them prior to session
establishment. 

> Then in NF_IP_POST_ROUTING there is two conntrack
> hooks running at the
> very last prioritites, one which confirms sessions
> (makes the conntrack
> "official"), immediately followed by the
> refragmenter. The first is not
> involved in connection tracking as such, it only
> confirms the session
> related to the packet in connection tracking as a
> valid session.
Ah good.  So it sounds like I can add in my packet
altering code in mangle/POST_ROUTING (where I have
unfragmented packets ready to head out) and then my
packet de-altering code in raw/PRE_ROUTING (where I
will have de-fragmented packets that have not yet been
examined for session/conn track yet) and I will be a
Happy Camper.

I have a related question, but will make a new post
since it is OT from this thread.  Thanks again!!!!

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Packet Fragementation

[Henrik Nordstrom]

On Wed, 31 Mar 2004, Scott MacKay wrote:

> You are the god!!!! TY so much :)
> Actually, NF_IP_PRI_RAW is -300 (at least 2.4.25
> kernel patch) , so I am golden.

Just a copy-paste error on my part..

> Ah good.  So it sounds like I can add in my packet
> altering code in mangle/POST_ROUTING (where I have
> unfragmented packets ready to head out) and then my
> packet de-altering code in raw/PRE_ROUTING (where I
> will have de-fragmented packets that have not yet been
> examined for session/conn track yet) and I will be a
> Happy Camper.

>From what I can tell this should work yes.

Regards
Henrik