Carson wrote... > No, it isn't. The problem is that ipfilter cannot handle out-of-order > fragments.
Yes it can. The requirement for a rule like this: pass in proto udp from any to any port = 2049 keep state keep frags to work is that the firewall must be able to match all parts of the "packet matching" for the result to happen. So if the out of order fragment delivery means that the 1st fragment has no port information in it, then it is not possible to match that rule. If the 1st packet seen has the port information in it, then the rest of the fragments can arrive in any order they choose, but it works best when they're all in sequential order. > It happens that Linux always emits fragments out-of-order, but To be technically pedantic, certain versions of Linux emit fragments in the reverse order. This was done to benefit a specific optimisation in reassembly - by getting the last packet first, you know how big to make the holding buffer for the later fragments. > Whether you consider this a bug or a RFE is up to you, but it's ipfilter's > problem. It's a tough call. It would be nice if fragment reassembly was a bit more like TCP and you could issue a selective ACK and cause parts of the fragmented packet to be resent but IP doesn't (and can't) work like that. > That doesn't mean that emitting fragments backward wasn't a > monumentally stupid idea on the part of the Linux developers. See above but :-) > There are at least 2 ways to fix this: > > - Pass all non-initial IP fragments with an offset > x (where x is > sufficiently large to not overwrite the header). Optionally, verify that it > is _possible_ for the fragment to be valid (without the protocol/port info, > all you have to go on is src IP / dst IP). I believe that Darren already > posted a patch that does something like this. Yes. I made it possible to do with 4.1next: pass in ... with frag-body > - Buffer fragments until enough information exists to make a pass/drop > decision. This is much harder to do correctly, but is worth it in some > environments. I'll give this one some thought, too. Darren
