Date: Mon, 16 Apr 2001 13:15:48 -0700 From: "Crist Clark" <crist.clark@globalstar.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: <3ADB52F4.1A7058B9@globalstar.com> 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
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. The IP ID and the Fragment Offset are different fields within the IPv4 header. At least that's what I think you are saying. As far as the whole thread goes, no, I cannot visualize a situation where the IP ID would need to be htons()'ed. The machine generating a datagram creates a "unique" IP ID for each outgoing datagram (actually the IP ID only needs to be unique for each source host, destination host, and protocol). No routers in between ever change it; the receiving machine just uses it to figure out what fragmented datagrams go together to assemble the original datagram. The only question that arises is a non-htons'ed field any less "unique" than the htons'ed one. People have mentioned that we might have a problem with wrap-around. However, preventing wrap around from happening too quickly is just a simple minded way to ensure pseudo-uniqueness of IDs. There are no requirements about wrap around in and of itself. Even if you do use an algorithm that wraps the in-kernel value slowly to prevent wrap around, the IDs on the wire in the reversed byte-order will be just as unique because if it. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com 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?3ADB52F4.1A7058B9>