Date: Tue, 6 Apr 2004 03:15:51 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: richard@wendland.org.uk Cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] Message-ID: <20040406025632.J40565@odysseus.silby.com> In-Reply-To: <200404052309.AAA04582@starburst.demon.co.uk> References: <200404052309.AAA04582@starburst.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040406025632.J40565>