Date: Thu, 8 Jan 2004 02:02:08 +0000 (GMT) From: Richard Wendland <richard@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 Message-ID: <200401080202.CAA20485@starburst.demon.co.uk> In-Reply-To: <3FFC97A1.4F397CC3@freebsd.org> from "Andre Oppermann" at Jan 08, 2004 12:34:57 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401080202.CAA20485>