barry, fragment != misordered packet.
fragments are a result of a size mismatch between the IP layer and the underlying physical layer. if you ask Fed-Ex to ship something that is bigger than a 747 they must chop it into pieces that fit into a 747. at the other end they get out the glue and put it back together again. this is not one of the things that ipf does -- it doesn't glue the fragments together -- nor do i think that it should. but ipf does include the capability to deal with the fragmented IP packets by passing them when they are indeed part of a valid connection; that's what the directive "keep frags" does for you. misordered packets are really just a case of dropped packets. in other words, take the misordering to the boundary condition: i.e., the misordered packet is arriving at T=infinity. in either case (misordered aka dropped) this situation is generally result of insufficient equipment capacity, network overload, or the result of a route or network which is in a transient state (e.g. a BGP update is in progress due to a new topology). while it would be nice for ipf to "know" that a misordered packet is part of a connection (i.e. it's "in the window"), in practice this is cumbersome to implement. it somewhat depends on a priori knowledge that the receiver is in fact receiving ALL of the packets which the firewall is passing. this may not be the case in a large internetwork. moreover the so-called "misordered packet" could be the result of someone who is trying to hijack a connection by guessing sequence numbers, or via other methods. the "how should ipf deal with misordered packets" subject has been discussed at length in the past few months. try a search and see what pops up. as always, the implementation of a security tool has to make a tradeoff between usability and protection. the key for your car is inexpensive, easily fits in your pocket, and provides "good enough" security against car theives. but that same key can be easily duplicated (man in the middle attack), the mating lockset can be picked (remote root exploit) or just reduced to useless rubble with acid (DoS attack). engineering, whether software or hardware, is about balance and compromise. engineering for security is no different. jim barryc wrote: >>Thank you - that seems to have fixed the problem . Or worked around it, >>depending on whether it's a feature or a bug that misordered packets are >>rejected by IP Filter - surely, since they're a legitimate/expected part of >>normal TCP operation they should be allowed through if associated with an >>established stateful connection ...? >> > >In this event, the errant packat is called a 'fragment' in ipf terminology >to allow fragmented packets, add a "keep frags" clause to your rules along with >the "keep state" > >see: > >http://www.obfuscation.org/ipf/ipf-howto.html#TOC_23 >
