> > 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". > > > > Couldn't you also build a bot-net of machines that send legal fragments?
All fragments are equal and legal until they either (a) defragment to form complete packets, (b) get pushed out because the fragment cache is full, or (c) timeout of the fragment cache because of age. The change being talked about is when fragments purposefully overlap or collide. In that case, they are discarded. The problem is there is an RFC which says that fragments _received in the future -- after that collision event_ should also be discarded. That requirement is bogus; it cannot be supported without substantial storage. > I don't see the difference between a denial-of-service attack that fills up > your > state table with states that have empty fragment lists, versus a > denial-of-service > attack that fills up your state table with states that have non-empty > fragment lists. Ah. I can see you've not read the fragment cache code. > To put it another way, an attacker who consumes states by sending > overlapping > fragments that cause you to retain state (and discard fragments) until the > reassembly > timeout expires, is no worse than an attacker who consumes states by sending > non-overlapping fragments that cause you to retain state (and store > fragments) until > the reassembly timeout expires. Arguably, the latter case is even worse. The latter case is not worse, since it is unavoidable. Packets get lost. As it happens, the fragment cache is only 1000 entries in size. What the RFC was demanding is impossible with only 1000 entries. When loss or collisions happen, there is no justification for keeping "state of that event" or "doing more work".
