From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 12:54:45 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 EC47A7D4; Sat, 4 Apr 2015 12:54:45 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id C32EC66D; Sat, 4 Apr 2015 12:54:45 +0000 (UTC) Received: from [10.0.1.22] (host81-157-243-31.range81-157.btcentralplus.com [81.157.243.31]) by cyrus.watson.org (Postfix) with ESMTPSA id CC94046B89; Sat, 4 Apr 2015 08:54:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information From: "Robert N. M. Watson" X-Mailer: iPhone Mail (12D508) In-Reply-To: <551FA37B.90609@selasky.org> Date: Sat, 4 Apr 2015 13:54:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> To: Hans Petter Selasky Cc: "freebsd-net@freebsd.org" 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 12:54:46 -0000 On 4 Apr 2015, at 09:40, Hans Petter Selasky wrote: >> On 04/03/15 23:36, Gleb Smirnoff wrote: >> The documentation on net.inet.ip.random_id is solid and doesn't need the >> text from your commit. >=20 > Let me detail a bit more. The old text describing "random_id" clearly give= s the wrong impression. It says that information is only leaking one way. It= is for sure very misleading. Information can leak both from the inside to t= he outside and from the outside to the inside. And also between two outsider= s or two insiders. That's what's scares me. >=20 > Try using my testapp if you don't believe me. >=20 > Given that the ICMP limit is 200 per second by default, I would guess that= 199 bits could at maximum be transferred per second in between two parties u= sing the proper algorithms. >=20 > If I myself was setting up a firewall, this is the kind of stuff I would l= ike to know about in advance. Covert and side channels are inherent to the design of contemporary processo= rs and operating systems -- via caches, memory bandwidth, OS scheduling, sta= tistics, clock drift due to temperature, protocol counters, rate limiters, e= tc. The inherent difficulty of addressing malicious information-leak mechani= sms means that our time is far better invested in trying to document and mit= igate side channels than covert channels, whose existence must be taken for g= ranted. And it's not just the IP ID field: almost any practical firewall con= figuration will be susceptible to lots of leaks of this sort. For example, r= ate limiting ICMP replies, TCP RST packets, etc, are all potential covert ch= annels. And that is before you start letting through application-level proto= cols like DNS. Instead, we simply need warning that the fundamental function of a firewall -= - of communication as much as blocking or it would be a dual-homed host not a= firewall -- makes it susceptible to covert channels by design. Firewalls ar= e about limiting overt communication -- if you want to limit covert communic= ation you need very different hardware and software designs. Robert=