From owner-freebsd-net@FreeBSD.ORG Sat Apr 4 15:58:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA904779; Sat, 4 Apr 2015 15:58:33 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 546F88B0; Sat, 4 Apr 2015 15:58:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D20B91FE022; Sat, 4 Apr 2015 17:58:30 +0200 (CEST) Message-ID: <55200A51.3090008@selasky.org> Date: Sat, 04 Apr 2015 17:59:13 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Robert N. M. Watson" Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information 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> In-Reply-To: <551FF191.2090109@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" , "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 15:58:34 -0000 On 04/04/15 16:13, Hans Petter Selasky wrote: > Hi Robert, > > On 04/04/15 14:54, Robert N. M. Watson wrote: >> Covert and side channels are inherent to the design of >> contemporary processors and operating systems -- via caches, >> memory bandwidth, OS scheduling, statistics, clock drift due to >> temperature, protocol counters, rate limiters, etc. The inherent >> difficulty of addressing malicious information-leak mechanisms >> means that our time is far better invested in trying to document >> and mitigate side channels than covert channels, whose existence >> must be taken for granted. And it's not just the IP ID field: >> almost any practical firewall configuration will be susceptible >> to lots of leaks of this sort. For example, rate limiting ICMP >> replies, TCP RST packets, etc, are all potential covert >> channels. And that is before you start letting through >> application-level protocols 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 are about limiting overt >> communication -- if you want to limit covert communication you >> need very different hardware and software designs. > > I don't disagree that we can totally eliminate covert and side channels. > It's like you say a part of digital life. There is however a big > difference providing a 1 bit per hour statistically proven _unicast_ > side channel having X percent error and a 199 bit per second digital > _broadcast_ side channel having 0 percent error under good conditions > into a firewall or router subsystem. And I think you should agree about > that. > > I was curious enough to Google this topic a bit and I found that NMAP > can provide information about hosts which use incremental IPID generation. > > * OpenBSD always randomize IP ID > http://www.securityfocus.com/columnists/361/2 > > * MacOSX - incremental ? > http://forums.macnn.com/90/mac-os-x/119605/mac-os-x-portscan-results/ > > * All Windows versions - incremental ? > http://serverfault.com/questions/258790/changing-tcp-ip-ipid-sequence-generation-algorithm-on-windows-server > > > There are several mentions of using IPID for fingerprinting systems, but > no mentions of using it as a communication channel, or for that sake > covertly storing 16-bits of information at a remote host. Given the > large number of IP addresses in use, several GBytes can be stored this way. > > I think we should take OpenBSD's example in this case. Also we should > think about performance so that this feature can be default on, and not > have problems like mutex congestion and so on like Emeric mentioned. > > --HPS Hi Robert, I think you confuse what I'm trying to explain to you from the responses I get. I'm not talking about putting data into the IP ID field or other IP fields, which then someone at the receiving end picks out and stores. This is well known. I'm talking about sampling the IP ID value you get in return from a PING response. A firewall typically has multiple ports. If pinging the gateway from any of these ports cause an increment of a shared IP ID value, then anyone that can ping the common firewall will see the IP ID updates the other parties are doing. This can be used for RX and TX communication. Can you confirm that you understand? I have a feeling we are talking about completely different ways of side channel communication. --HPS