Stable privacy addresses (upcoming rev)
Fernando Gont <fgont@si6networks.com> Wed, 28 March 2012 15:53 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36CC21E8234 for <ipv6@ietfa.amsl.com>; Wed, 28 Mar 2012 08:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKgKLSpMVDNd for <ipv6@ietfa.amsl.com>; Wed, 28 Mar 2012 08:53:34 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC621E80B8 for <ipv6@ietf.org>; Wed, 28 Mar 2012 08:53:33 -0700 (PDT)
Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SCvBd-00031t-1T; Wed, 28 Mar 2012 17:53:25 +0200
Message-ID: <4F7333F9.9090007@si6networks.com>
Date: Wed, 28 Mar 2012 17:53:29 +0200
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Stable privacy addresses (upcoming rev)
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 15:53:35 -0000
Folks, Probably the only objection that I got for draft-gont-6man-stable-privacy-addresses is that the prefix shouldn't be included in F() (the hash function). I'd like to clarify the motivation for that, and also trigger some discussion on the topic such that I can produce a revision of this docuement that addresses any remaining concerns. * Motivation for including the SLAAC Prefix in F() (the hash function) The essential rationale for including the prefix in the hash function is that, if we don't, then we'd be leaking more information than we should. If we don't include the prefix as part of the data to be hashed, then the Interface-ID will be exactly the same no matter whether the devices moves from one network to another, and hence the node could be tracked, even if it implements RFC 4941. For example, think about the following scenario: Attack scenario #1 A host configures the stable addresses without including the Prefix in the hash function. Let's say the host employs any application that needs to perform a server-like function (P2P, or whatever). As a result of that, an attacker attacker participating in that application (e.g., P2P) would learn the Interface-ID used for the stable address. Now the same host moves to a completely different network, and uses the same P2P application, probably even with a different user. The attacker now interacts with the same node again, and hence can learn the "new" stable address. Since the interface ID is the same as the one above, he can infer that it is communicating with the same device as before. Had the host included the Prefix when computing the Interface-ID (with the hash function F()), the Interface-ID would have been different, and this wouldn't have been made possible. This is just *one* possible attack scenario, which should remind us that one shouldn't disclose more than it is really needed (and a static Interface-ID across many different networks does exactly that). * Use of draft-gont-6man-stable-privacy-addresses without RFC 4941 Temporary addresses are painful to manage. They make painful to correlate the activities of your own nodes. FOr example, one host gets infeceted will malware, you logged the IPv6 address, but then you don't know which node was using that address at that point in time. This is the reason for which in many deployments temporary addresses (RFC 4941) are disabled (e.g., look at any presentation by Ron Broersma). When you disable temporary addresses, all you're left with is whatever stable addresses your host uses. If you don't include the Prefix in F() (the hash function) then, while you may be resistant to host scanning attacks (your addresses is not predictable anymore), you're still trackable, since your interface ID doesn't change as you move from one network to another. So yes, there are cases in which you may want privacy, without necessarily be willing to deal with the burden of temporary addresses. And if you're just going to have stable addresses, you do not really want the Interface ID to be constant across networks. * Concerns about CPU impact Other folks have expressed concerns (in corridor meetings) that if the Prefix is included in the hash function, they may need to recompute the hash every time they attach to a network (assuming the SLAAC prefix changes), and that would be expensive. I personally think this shouldn't be an issue for most implementations (for instance, we do MD5 for every single new TCP connection! -- see RFC 6528). And, in any case, we do not really specify which hash function to use. -- If you're concerned about CPU, you may want to use a (CPU-wise) cheaper function. That said, I'd have no problem with making the inclusion of the Prefix a SHOULD (i.e., do it, unless you have very good reasons not to do so (such as CPU-constraints)), or even a MAY (if inclusion of the Prefix in the hash function turns out to be the show-stopper here). If you have any feedback/comments, I'd be glad to hear. I'm planning to rev the document asap, clarifying and incorporating many of the things explained throughout this e-mail. So if you send your feedback shortly, the next rev could reflect your comments. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- Stable privacy addresses (upcoming rev) Fernando Gont
- Re: Stable privacy addresses (upcoming rev) Tassos Chatzithomaoglou
- Re: Stable privacy addresses (upcoming rev) Fernando Gont
- Re: [6man] Stable privacy addresses (upcoming rev) Ray Hunter
- Re: [6man] Stable privacy addresses (upcoming rev) Brian E Carpenter
- Re: [6man] Stable privacy addresses (upcoming rev) Fernando Gont
- Re: [6man] Stable privacy addresses (upcoming rev) Ray Hunter
- RE: [6man] Stable privacy addresses (upcoming rev) Christian Huitema
- Re: [6man] Stable privacy addresses (upcoming rev) Fernando Gont
- Re: [6man] Stable privacy addresses (upcoming rev) Fred Baker
- Re: [6man] Stable privacy addresses (upcoming rev) Fernando Gont