From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 14:42:38 2003 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 38AAC37B401 for ; Wed, 30 Apr 2003 14:42:38 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 587E343F3F for ; Wed, 30 Apr 2003 14:42:37 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3ULgZVo056436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Apr 2003 17:42:36 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3ULgZ0i056433; Wed, 30 Apr 2003 17:42:35 -0400 (EDT) (envelope-from wollman) Date: Wed, 30 Apr 2003 17:42:35 -0400 (EDT) From: Garrett Wollman Message-Id: <200304302142.h3ULgZ0i056433@khavrinen.lcs.mit.edu> To: Mike Silbersack 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> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 21:42:38 -0000 < 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 (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