> 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".
That last bit is crazy. You cannot maintain state until the potential packets fall out of the fragment cache. > 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. Actually, an empty state is a big deal, since it is way more important and persistant in memory than packet data. mbufs can be dropped if there is no room, time, etc to handle them. But the state table requires some pretty nasty code to handle expiration and it is bad when it fills up. The state table exists to map legit traffic. It is not there to maintain a cache of "the bad guys". There could be a lot of bad guys. >From remote I could build a bot-net of machines that send you illegal fragments and, if you create a state of the bad mappings, you'd run your state table out. When the state table gets full, it will eject other stuff which is more important. Like ssh sessions and such. We allocate resources (ie. states) to create a mapping of the 'good sessions'. It is impossible to allocate sufficient resources to "keep a list of the bad traffic/sessions/guys". If rfc 5722 is truly saying you must drop packets in the future, then the only answer is to flush the entire ipv6 fragment cache. Then the new fragments won't map an existing fragment. It is a new fragment set...
