Date: Thu, 1 May 2003 02:23:44 +0400 (MSD) From: "."@babolo.ru To: Garrett Wollman <wollman@lcs.mit.edu> Cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage Message-ID: <1051741424.259802.1572.nullmailer@cicuta.babolo.ru> In-Reply-To: <200304302142.h3ULgZ0i056433@khavrinen.lcs.mit.edu>
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. Why not to use 16 bit of 32 bit pseudorandom generator? > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1051741424.259802.1572.nullmailer>