On 04/27/2013 09:47 PM, Christian Huitema wrote: >> * second one: correlation of node activities within the same >> network. In many cases, no matter whether you change your >> addresses, it won't be solved. > > That's largely true, because hosts leak tons of information on the > network they connect to. The MAC address of course, but also things > like host names in DHCP requests, or even the DNS names queried by > the host. Solving that will require a significant effort.
That aside, if there's only one node active in a given network, then changing your address periodically (particularly when you're making that fact known) doesn't help much. >> * third one: leaking information about the IID, which could allow >> attackers to guess the addresses of other alive nodes. > > That one is solved by RFC 4941, by this draft, or even by DHCP. It *is* solved by DHCP, but not by RFC4941: RFC4941 addresses are generated *in addition* to SLAAC addresses. That's why, I'm told, Windows replaces traditional SLAAC addresses with a time-invariant version of RFC4941 - besides *additionally* implementing RFC4941 for temporary addresses. Here we're mitigating address-scanning attacks, while bringing other benefits such as privacy, by removing IIDs that are constant across networks. > I read Fernando's draft as engineering privacy with an exception. The > addresses are randomized and have many privacy features, but they > remain the same in a local context, and are thus very observable in > that local context. That's obviously a tradeoff. I see why IT > departments would like that feature -- but then, they could get the > same effect by just deploying a DHCP server. This document aims to improve the case for SLAAC: There are many scenarios in which SLAAC is desirable, without that meaning that you really want a super cookie in the IPv6 addresses of nodes. Or, put another way, from the pov of the user/host, you don't really want to be trivially traceable even if you connect to a network that uses SLAAC rather than DHCPv6. > However, in the case of > roaming the feature is highly debatable. If a host visits the same > network multiple times, should it always reuse the same ID, or should > it get a new identifier each time? It is very easy to argue that > "different each time" has better privacy properties. Agreed. For instance, draft-ietf-6man-stable-privacy-addresses-06.txt is not a replacement for RFC4941. If you're a roaming node, you probably want RFC4941 enabled (in addition to having draft-ietf-6man-stable-privacy-addresses-06.txt enabled). Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
