From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 18:02:01 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 518D116A4CE; Wed, 7 Jan 2004 18:02:01 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-230.abel.net.uk [193.109.51.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FC943D2F; Wed, 7 Jan 2004 18:01:52 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id CAA20485; Thu, 8 Jan 2004 02:02:09 GMT From: Richard Wendland Message-Id: <200401080202.CAA20485@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Thu, 8 Jan 2004 02:02:08 +0000 (GMT) In-Reply-To: <3FFC97A1.4F397CC3@freebsd.org> from "Andre Oppermann" at Jan 08, 2004 12:34:57 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rw@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 02:02:01 -0000 > 4. After reading the pf.conf man page from OpenBSD (where it talks about > scrubbing IP packets) I don't think it's a good idea to set the ip_id > to zero in the DF case. It seems to cause various kinds of problems > when for some reason DF is removed along the path (which it shouldn't > but whatever). I think it is clearly better to put a ip_id into every > packet no matter what. Yes, I think we're both now agreed that zero ip_id for DF is a bad idea because of what middle-boxes might do to DF. > Although the ip_randomid() function doesn't > look really cheap to run... but then security comes at a cost. > > 5. Random ip_id is already a kernel option but it is *not* enabled by > default in 5.2RC2 GENERIC or -current. I don't think random ip_id should be enabled by default. The reduction in ip_id cycle from 64k is a real re-assembly risk on modern high-speed networks. Random ip_id brings debatable benefits. There was a good discussion about this on tech-net@NetBSD.org last November, where they rejected random ip_id as default. One issue is that they (claim to have) discovered the OpenBSD random ip_id code has a 12k cycle rather than the advertised 30k: http://mail-index.netbsd.org/tech-net/2003/11/26/0005.html http://mail-index.netbsd.org/tech-net/2003/11/27/0007.html The other is a consideration of what the maximum safe data transfer rate is for a given ip_id cycle. You want long ip_id cycle times for non-DF gigabit networking, like NFS. I buy into these arguments by Robert Elz and Jonathan Stone: http://mail-index.netbsd.org/tech-net/2003/11/26/0013.html http://mail-index.netbsd.org/tech-net/2003/11/26/0015.html though a good contrary view is: http://mail-index.netbsd.org/tech-net/2003/11/26/0021.html It's important to remember that if fragmentation takes place, and a fragment is lost, the other fragment(s) will wait for quite some time in a re-assembly buffer (maybe up to 63 seconds). While they are waiting they are at quite some risk of being joined onto a fragment from the next ip_id cycle if a lot of packets are flowing: http://mail-index.netbsd.org/tech-net/2003/11/26/0022.html http://mail-index.netbsd.org/tech-net/2003/11/26/0023.html Remember a 64k cycle is consumed by 64MB of transfer if average datagram size is 1024 bytes. Thats not a lot on a gigabit network. The better solution in my opinion is to do similar to Solaris, have per-destination ip_id counters (or at least a hash of destination IP to one of N ip_id counters). You typically get longer cycle times and improved privacy, with a method that is faster than random ip_id. > On the other hand the code > *does* zero the ip_id when DF is set in any case which is troublesome > as we just found out. Yes. Richard -- Richard Wendland richard@wendland.org.uk