Hi, Alissa! Thanks so much for your feedback! -- Please find my comments in-line... On 04/25/2013 06:32 PM, Alissa Cooper wrote: > > There are two places where it is implied that the algorithm in this > spec mitigates most of the privacy issues associated with embedding > IEEE identifiers in addresses. The first is in section 1: > > For nodes that currently disable "Privacy extensions" [RFC4941] for > some of the reasons stated above, this mechanism provides stable > privacy-enhanced addresses which may already address most of the > privacy concerns related to addresses that embed IEEE identifiers > [RFC4291]. On the other hand, in scenarios in which "Privacy > Extensions" are employed, implementation of the mechanism described > in this document would mitigate host-scanning attacks and also > mitigate correlation of host activities. > > And the second is in section 6: > > Finally, we note that the method described in this document may > mitigate most of the privacy concerns arising from the use of IPv6 > addresses that embed IEEE identifiers, without the use of temporary > addresses, thus possibly offering an interesting trade-off for those > scenarios in which the use of temporary addresses is not feasible. > > This implication seems misguided. Providing the ability to track and > correlate the communications of a device that never leaves a single > network is a significant concern. In some scenarios, that's impossible. Trivial example: If you have a network with a single host attached to it, no matter whether you change your address periodically (*), it will be possible to correlate the hosts' activities. (*) That of changing your addresses *periodically* actually helps correlation. > It is one concern among several > that the IEEE-identifier-based mechanism raises, but it is a big one > IMO. This algorithm does not appear to mitigate that concern, so any > implication that it does should be avoided. What the text implicitly means is "This algorithm mitigates all concerns except correlation of a nde's activity within the same network... but in some scenarios that's impossible to mitigate, then, in those scenarios, this algorithm mitigates as much as *can* be mitigated". > I would suggest using > "some of the privacy concerns" in place of "most of the privacy > concerns" in the two sections above. Is there any other one left to be mitigated other than the one I mentioned above? > > Nit: > > This link in the [Broersma] reference is broken: > http://www.ipv6.org.au/summit/talks/Ron_Broersma.pdf Will fix this. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492