Date: Mon, 16 Apr 2001 16:01:32 -0400 From: Barney Wolff <barney@databus.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Barney Wolff <barney@databus.com>, "E.B. Dreger" <eddy+public+spam@noc.everquick.net>, Wes Peters <wes@softweyr.com>, freebsd-security@FreeBSD.ORG, net@FreeBSD.ORG, provos@OpenBSD.org Subject: Re: non-random IP IDs Message-ID: <20010416160132.A49963@mx.databus.com> In-Reply-To: <20010416125053.A11446@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Apr 16, 2001 at 12:50:53PM -0700 References: <20010416121019.D10023@xor.obsecurity.org> <Pine.LNX.4.20.0104161919390.26335-100000@www.everquick.net> <20010416154249.A49858@mx.databus.com> <20010416125053.A11446@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
No - the ip_id is used only to collect the fragments of a single packet - so all that counts is that each fragment has the same value, and that the value not collide with that in other packets/fragments that can be in flight at the same time. (I think you're confusing ip_id with the TCP sequence number.) Barney On Mon, Apr 16, 2001 at 12:50:53PM -0700, Kris Kennaway wrote: > On Mon, Apr 16, 2001 at 03:42:49PM -0400, Barney Wolff wrote: > > If ip_randomid() is an asm rather than C code, I have sometimes > > seen problems with an asm func calling another asm func. That > > was long ago and far away, but is the only reason I can think of > > for that change. > > > > But whether the id is random or a counter, there is no reason to > > htons it, as long as it's treated consistently, with externals > > never compared with internals. > > Surely that can't work since the purpose of that field is for received > packet ordering (unless I'm wrong, I'm not an IPv4 guru and only > skimmed the RFC), and what's ordered in network order isn't ordered in > host order. > > Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010416160132.A49963>