Date: Wed, 30 Apr 2003 17:42:35 -0400 (EDT) From: Garrett Wollman <wollman@lcs.mit.edu> To: Mike Silbersack <silby@silby.com> Cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage Message-ID: <200304302142.h3ULgZ0i056433@khavrinen.lcs.mit.edu> In-Reply-To: <20030430162628.A3741@odysseus.silby.com> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> <20030430015609.M514@odysseus.silby.com> <200304302018.h3UKIpcF055535@khavrinen.lcs.mit.edu> <20030430162628.A3741@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 30 Apr 2003 16:35:24 -0500 (CDT), Mike Silbersack <silby@silby.com> said: > I think that even a trivial pseudo-random sequence would be good to > implement. With the standard ip_id++ sequence, you can precisely monitor > the number of packets sent and also determine if two IPs are shared by the > machine without any work. See Bellovin's paper for how to do it for any fixed increment without much work. The trouble is that we need sequences that are guaranteed not to repeat too fast -- and even then we'll still break on modern networks anyway, as I noted in my comment. Solaris apparently goes out of its way to create a different ip_id sequence for every combination of <s,d,protocol> (which is allowed), but this still doesn't buy you much if your system is capable of performing NFSv2 transactions at 100 Mbit/s. > I have this nagging feeling that taking most TCP sessions out of the > equation makes the obfuscation of the remaining ip_id'd packets more > important, but I can't figure out why exactly. I feel rather the opposite. > Do we set the DF flag on most UDP and ICMP packets? ping(8) can set it, but the kernel is not able to do so, since it can't predict the MTU in advance of sending the ICMP. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304302142.h3ULgZ0i056433>