Subject: Re: Last Call: <draft-ietf-6man-stable-privacy-addresses-06.txt> (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard

From: Alissa Cooper <[email-masked]>
Date: Thu, 25 Apr 2013 17:32:44 -0400

One comment and one nit below.

Comment:

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. 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. I would suggest using "some of the privacy concerns" in place of "most of the privacy concerns" in the two sections above.

Nit:

This link in the [Broersma] reference is broken: http://www.ipv6.org.au/summit/talks/Ron_Broersma.pdf

Alissa

On Apr 12, 2013, at 11:34 AM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'A method for Generating Stable Privacy-Enhanced Addresses with IPv6
>   Stateless Address Autoconfiguration (SLAAC)'
>  <draft-ietf-6man-stable-privacy-addresses-06.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-04-26. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document specifies a method for generating IPv6 Interface
>   Identifiers to be used with IPv6 Stateless Address Autoconfiguration
>   (SLAAC), such that addresses configured using this method are stable
>   within each subnet, but the Interface Identifier changes when hosts
>   move from one network to another.  The aforementioned method is meant
>   to be an alternative to generating Interface Identifiers based on
>   IEEE identifiers, such that the benefits of stable addresses can be
>   achieved without sacrificing the privacy of users.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Apr 2013 16:13:53 -0300

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:
> 
> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492