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(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492