Hello Darren, Please correct me if I'm wrong. So for a product which implements IP services and uses IPF internally to secure itself, the only way to correctly deal with fragmented udp traffic is to have IPF set up with smth like "pass all proto udp with frags", which now will pass all frags no matter which order they arrive, but loosen security on udp level (technically, it means no udp security).
Or, maybe there is a way to set up the following behaviour: pass all udp frags where offset > sizeof(udp header). For frags where offset=0 and size >= sizeof(udp header), run it through firewall rules to make a decision. This should give a better work-around for udp frags coming in wrong order, because all frags but first will sit in IP stack and not be reassembled and passed to application layer until first frag arrives, and first frag is contolled by firewall fules. I could not figure out by documentation if smth like this is possible. Also, I am talking UDP here, but does this problem exist for TCP frags? Thank you. -Alex Zhilyakov Network Manager, Accatel Inc. +1-212-3794000 On Sat, 13 Nov 2004, Darren Reed wrote: > In some email I received from Alex Zhilyakov, sie wrote: > > Hello Darren, > > > > Thanks for the answer. I tested same scenario vs FreeBSD - problem > > persists, so it is not only Linux behaviour. > > Generally speaking, frags are not required to come in order to > > destination box, and as such wrong order of arrival can not be an "excuse" > > to not process them properly. Normal IP stack reassembles them just fine. > > Is there any special reasoning why IPF must not do so as well? > > IP Filtre doesn't do fragment reassembly of any sort, including keeping > fragments on hold somewhere. > > The problem is this. > > You have UDP fragements that come in with no UDP header, so there is > no port information, and of course the packet cannot match any rule > that has a port number. > > The IP stack isn't necessarily concerned with providing security, > just the means to receive and defragment packets. > > Darren >
