Date: Sat, 4 Apr 2015 20:06:47 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Hans Petter Selasky <hps@selasky.org> Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" <emeric.poupon@stormshield.eu>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "Peter N. M. Hansteen" <peter@bsdly.net> Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information Message-ID: <67C313E4-8B93-4B59-AC80-E4DEFFF8B15E@FreeBSD.org> In-Reply-To: <55202C4E.1010902@selasky.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org> <55200A51.3090008@selasky.org> <C936160B-4959-42F9-9433-226AA5CC7591@FreeBSD.org> <55202C4E.1010902@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Apr 2015, at 19:24, Hans Petter Selasky <hps@selasky.org> wrote: > The IPv4 protocol was intentionally designed to be such, that in any = ways trying to make it more secure, will require additional CPU = overhead, like keeping track of 2-tuples for generating per-stream IP = IDs, that it will not be feasible in practice and then vendors will do = insecure implementations instead of secure implementations to get the = needed performance. The IP ID field was then intentionally designed to = be too small, 16-bit. If Snowden leaks documents on this, would for sure = confirm this claim. Remember that TCP/IP is a product of 1980s computer architecture and = communication technologies. While it's true that a number of the key = design decisions from that period are suited for very different problems = than we face today (e.g., a real concern with global passive = adversaries), they were also working with far more limited = communications speeds, processor speeds, and memory sizes. Although I = wasn't there myself, you have to suspect that some folk involved felt = that 16 bits was far too much when prevailing communication speeds were = <9,600bps. More generally, though, the covert channel problem is actually a = fundamental one to the design of computer systems, and in the territory = of "we just don't know how to engineer solutions to this problem in a = scalable way" still. Maybe another 10-20 years will fix that, especially = with formal techniques becoming more viable. In the end, I think that = does need to the approach due to weakest-link concerns in security. The = good news is that formal methods are starting to become viable at scale, = so there is real hope in that regard (I believe, anyway). I think there is real, interesting, and immediate work to do in = improving our IP ID implementation though, which will have substantial = performance and functionality benefits, along with the side effect of = reducing the impact of the covert channel you've raised, though. = Hopefully that's something we can sort out in the next few months since = it will help with contention issues such as the one raised. Robert >=20 > OK, Robert, I fully understand and will not touch this issue any more = before my head gets cut off :-) I appreciate your openness and = willingness to share information on this issue. You know the IPv4 = history even before I came to this world. >=20 > --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67C313E4-8B93-4B59-AC80-E4DEFFF8B15E>