On Wed, 20 Oct 2004, Suresh Krishnan wrote: > "Addresses generated using Stateless address autoconfiguration > [ADDRCONF]contain an embedded 64-bit interface identifier, which > remains constant over time. Anytime a fixed identifier is used in > multiple contexts, it becomes possible to correlate seemingly > unrelated activity using this identifier. > > The correlation can be performed by > o An attacker who is in the path between the node in question and > the peer(s) it is communicating to, and can view the IPv6 > addresses present in the datagrams. > o An attacker who can access the communication logs of the peers > with which the node has communicated.
In other words, this extension is not only aimed at protecting the privacy the outside observers (like the nodes you're communicating with), but also those who are able to perform on-the-path privacy violations (ISPs, FBI/NSA intercepting the packets, etc.). Has the protection from your ISPs and federal agencies etc. really been the requirement/goal from the start? I'd like to observe that anyone who will be able to do on-the-path analysis will be able to jeopardize the privacy of the user typically in any case. While I think privacy is pretty important, I fear that this mechanism is insufficient to provide privacy to the users if we're concerned about on-path analysis, and I'd be hesitant to include it in the problem statement without warnings. I'm interested if others have comments on this. > * I hope the problem statement above justifies the use of privacy > addresses for ULAs I'm not so sure: so, you'd assume that the evil enterprise administrator would be eavesdropping and correlating enterprise's internal traffic, or the enterprise's internal web servers would be correlating the behaviour? As far as I can see, it's exactly the opposite -- privacy extensions should not be enabled by default for ULAs. > * Added the following text specifying the conditions for DHCPv6 to be used > for privacy > > "One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > configured to hand out addresses that change over time. But DHCPv6 > will solve the privacy issue only if it frequently handed out > constantly changing addresses to the nodes. Since this does not > happen automatically, and is difficult to configure manually, DHCPv6 > is not really suited for solving the privacy issues addressed by this > document." This doesn't mention that DHCPv6 can hand out the temporary addresses, but that there is little benefit to do so compared to just doing RFC3041 (unless the site has disabled stateless address autoconf complately), but this is good enough for me now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
