Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Apr 2004 00:09:28 +0100 (BST)
From:      Richard Wendland <richard@starburst.demon.co.uk>
To:        silby@silby.com (Mike Silbersack)
Cc:        freebsd-net@freebsd.org
Subject:   Re: Fwd: [IPv4 fragmentation  --> The Rose Attack]
Message-ID:  <200404052309.AAA04582@starburst.demon.co.uk>
In-Reply-To: <20040404160909.D29958@odysseus.silby.com> from "Mike Silbersack" at Apr 04, 2004 04:18:05 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> 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@wendland.org.uk



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404052309.AAA04582>