Andre Oppermann wrote: > > "Jacques A. Vidrine" wrote: > > > > Does anyone have time to investigate? I will try to get more > > information from iDEFENSE. > > Looking at the code there are indeed some problems. > > - there seems to be no boundary on how many segments we keep in the > tcp reassembly queue > - there seems to be no timeout of overaged fragments (we can drop > the segments after 1*msl because we don't have SACK and it has > to be retransmitted anyway since not ACK'ed which happens after > read from userland). Possibly it can be dropped earlier after > we've got x bytes or packets of more segments since it is un- > likely to receive the missing packet this late except for really > massive reordering > - this attack can be made with small packets which consume an mbuf > cluster anyway
- it uses MALLOC() to allocate its queue entry wheras it probably should use the zone allocator. The max limit on the zone than directly gives us a upper limit on the number of concatenated segments (not mbufs) - it uses LIST_FOREACH which is pretty inefficient. NetBSD has optimized this part quite a bit with a tail queue > For IP packet reassembly we have global and local limits: > > net.inet.ip.maxfragpackets: 800 > net.inet.ip.maxfragsperpacket: 16 > > Something like this is needed for TCP as well to cope with this kind > of resource exhaustion attack. > > I can fix this stuff but I won't be able to do that in emergency mode. > The first code can be ready after the weekend. If someone else wants > to takle it earlier/faster tell me. -- Andre _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
