Fwd: [IPv4 fragmentation --> The Rose Attack]

[Mike Silbersack]

On Tue, 6 Apr 2004, Richard Wendland wrote:

> > Per-protocol limits _could_ have some advantages; the 16 frags per packet
> > limit was chosen to account for NFS over UDP.  For TCP, we could drop that
> > to 3 frags per packet,
>
> The 16 frags per packet limit seems low to me for TCP already, blocking
> plausible RFC-compliant TCP connections, let alone a limit of 3 for TCP.
>
> Consider two endpoints using jumbo frames on gigE; MSS would be 9140.
> Say the remote TCP stack does not use/implement PMTUD (DF).  On the route
> a backup SLIP link has to be temporarily deployed with a MTU of 512,
> causing the jumbo segments to form 19 fragments.
>
> Is this so implausible that the default FreeBSD configuration with
> maxfragsperpacket=16 should block communication in this RFC-compliant
> situation?

Yes, a system using jumbo frames w/o PMTUD working is a stretch.  The
problems of DoS attacks using IP fragments are much more real and are what
the code needs to be tuned for.

> How about if the maxfragsperpacket limit was only enforced when FreeBSD
> perceived itself to be under reassembly 'stress' (possible DoS), so
> low-throughput heavily fragmented IP connections would generally work
> as specified in the RFCs?
>
> So for example there would be a tide mark count of waiting fragments
> below which the maxfragsperpacket limit wasn't enforced.  This tide mark
> could perhaps be half of net.inet.ip.maxfragpackets, or be an explicit
> sysctl value like net.inet.ip.highfragpackets.

That seems like a workable idea.  In order to ensure that a single packet
can not eat up all mbufs we'd still need some limit on the lower end, but
it could be relaxed.  Perhaps you could do:

---- 0 packets
frag limit = 32
---- maxfragpackets / 2
frag limit = 8
---- maxfragpackets

If there was no limit for the < maxfragpackets / 2 case, then we would
need to go back through and purge out the hyper-fragmented packets once we
hit the higher limits, which I would like to avoid doing.

NetBSD presently uses an approach whereby each fragment is counted, then
when the total fragment count reaches a threshold, random reassembly
queues are dropped.  Depending on the type of DoS, that may be more or
less successful, I haven't sat down to play with it.

If you'd like to code up the threshold idea above, I could look into
integrating it.

Mike "Silby" Silbersack