Hi Pekka, Thanks for the quick review. See comments inline Regards Suresh
On Wed, 20 Oct 2004, Pekka Savola wrote: >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.). Yes. > >Has the protection from your ISPs and federal agencies etc. really >been the requirement/goal from the start? On-path does not have to be FBI/NSA or ISPs. It can be anyone on an upstream network (even in the same organization as the user). I would assume if the FBI/NSA or the ISPs wanted to intercept they could do so at the layer 2 connection to the provider. Do you want me to add a statement about lawful intercept still being possible? > >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. This is already the case. Privacy extensions are disabled by default for ALL types of global addresses (including the ULA). > >> * 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. OK. That was the reason I left it out. I will leave it as is. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
