From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 01:16:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 983FC16A4CE for ; Tue, 6 Apr 2004 01:16:22 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3027143D4C for ; Tue, 6 Apr 2004 01:16:22 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 41584 invoked from network); 6 Apr 2004 08:15:52 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 6 Apr 2004 08:15:52 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 6 Apr 2004 03:15:51 -0500 (CDT) From: Mike Silbersack To: richard@wendland.org.uk In-Reply-To: <200404052309.AAA04582@starburst.demon.co.uk> Message-ID: <20040406025632.J40565@odysseus.silby.com> References: <200404052309.AAA04582@starburst.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Barney Wolff cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 08:16:22 -0000 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