Fwd: [is this mbuf problem real?]

[Andre Oppermann]

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