From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 16:07:41 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 8AA5716A4CE for ; Mon, 5 Apr 2004 16:07:41 -0700 (PDT) Received: from starburst.demon.co.uk (adsl-02-198.abel.net.uk [193.109.51.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3734843D48 for ; Mon, 5 Apr 2004 16:07:40 -0700 (PDT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id AAA04582; Tue, 6 Apr 2004 00:09:29 +0100 From: Richard Wendland Message-Id: <200404052309.AAA04582@starburst.demon.co.uk> To: silby@silby.com (Mike Silbersack) Date: Tue, 6 Apr 2004 00:09:28 +0100 (BST) In-Reply-To: <20040404160909.D29958@odysseus.silby.com> from "Mike Silbersack" at Apr 04, 2004 04:18:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Reply-To: richard@wendland.org.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 23:07:41 -0000 > 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