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

[Richard Wendland]

> 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?

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.

	Richard
-- 
Richard Wendland				richard at wendland.org.uk