Date: Sat, 4 Apr 2015 13:54:42 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Hans Petter Selasky <hps@selasky.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information Message-ID: <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> In-Reply-To: <551FA37B.90609@selasky.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Apr 2015, at 09:40, Hans Petter Selasky <hps@selasky.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35F9F267-EDB3-45FC-95E0-4573556BD736>