On Fri, Jan 13, 2012 at 02:13:09PM -0300, Fernando Gont wrote: > If there was a fragment overlap, there was malicious activity, and > you're certainly not going to get any legitimate fragment reassembled. > Therefore, IMO, it doesn't make sense to tie resources (i.e., keep > state) for that. > > If you do not keep state, then. > 1) If you don't get any further fragments, you saved memory and other > resources, or, > 2) If you do get other fragments, they'll be queued, and since other > fragments were dropped, there won't be any reassembled datagram, and > after a "reassembly timeout" the fragments will get dropped anyway.
When I get 4 fragments overlapping like this: 1. |------| 2. |------| 3. |------| 4. |---| I have to drop them all, "including those not yet received". After framgent 2 I know there is an overlap, so drop 1 and 2. If I would not keep the state, I would not know that there was a problem and would reassemble 3 and 4 to the complete packet. My algoritm creates the state when 1 arrives, drops 1 and 2 when 2 arrives, drop 3 and 4 immediately when they arrive, finaly drop the state after timeout. An empty state is little memory compared to packet data. bluhm
