From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 19:06:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5943E17 for ; Sat, 4 Apr 2015 19:06:46 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 99407D4C for ; Sat, 4 Apr 2015 19:06:46 +0000 (UTC) Received: from [10.0.1.17] (host81-157-243-31.range81-157.btcentralplus.com [81.157.243.31]) by cyrus.watson.org (Postfix) with ESMTPSA id 3FEC246B97; Sat, 4 Apr 2015 15:06:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information From: "Robert N. M. Watson" In-Reply-To: <55202C4E.1010902@selasky.org> Date: Sat, 4 Apr 2015 20:06:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67C313E4-8B93-4B59-AC80-E4DEFFF8B15E@FreeBSD.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> <55202C4E.1010902@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2070.6) Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "freebsd-net@freebsd.org" , "Peter N. M. Hansteen" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-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: Sat, 04 Apr 2015 19:06:46 -0000 On 4 Apr 2015, at 19:24, Hans Petter Selasky 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