Subject: draft-ietf-6man-stable-privacy-addresses: Document title

From: Fernando Gont <[email-masked]>
Date: Fri, 09 Aug 2013 18:59:20 -0300

Folks,

I has been suggested to me that we might want to change the title of
this document, and the chairs have suggested that I comment on this one
on-list.

The arguemtn, as far as I can tell, is that the current title might be
confusing (mostly because of the confusion there is with different
terminology on the subject).

The current title is:

* "A method for Generating Stable Privacy-Enhanced Addresses with IPv6
Stateless Address Autoconfiguration (SLAAC)"

It conveys this key information: that the addresses are stable, and that
they are privacy-friendly

And the titles that have so far been suggested are:

1) ""Stable Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)"

Me, I think this one is confusing -- for instance, IEEE-derived
addresses are stable, too.

2) "Stable Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC) not derived from EUI-64 identifiers"

This one doesn't convey the information that these addresses are
privacy-friendly. Besides, why whould we assume that every link layer
can generate addresses based on EUI-64 ientifiers? (some link layers
don't have those)

3) "Underived from EUI-64 Stable Addresses..."

Same as "3)".

4) "Amethod for generating stable random addresses"

This one is also confusing, since the current scheme used by Windows
provide addresses that are random, and stable across networks.

Given the above options I'd stick with the current title. Besides, the
community has become used to refer to this method as
"stable-privacy-addresses".. so changing the title at this point would,
IMHO, only contribute to confusion.

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Dave Thaler <[email-masked]>
Date: Fri, 9 Aug 2013 23:01:04 +0000

I will observe that Alissa's term "random per-network" isn't in any of the possibilities
below and the reasons given wouldn't apply if that term were used.  Perhaps that
could be used in a title?

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: Friday, August 9, 2013 2:59 PM
> To: [email-masked]
> Subject: draft-ietf-6man-stable-privacy-addresses: Document title
> 
> Folks,
> 
> I has been suggested to me that we might want to change the title of this
> document, and the chairs have suggested that I comment on this one on-list.
> 
> The arguemtn, as far as I can tell, is that the current title might be confusing
> (mostly because of the confusion there is with different terminology on the
> subject).
> 
> The current title is:
> 
> It conveys this key information: that the addresses are stable, and that they
> are privacy-friendly
> 
> 
> Me, I think this one is confusing -- for instance, IEEE-derived addresses are
> stable, too.
> 
> 
> This one doesn't convey the information that these addresses are privacy-
> friendly. Besides, why whould we assume that every link layer can generate
> addresses based on EUI-64 ientifiers? (some link layers don't have those)
> 
> 
> community has become used to refer to this method as "stable-privacy-
> addresses".. so changing the title at this point would, IMHO, only contribute to
> confusion.
> 
> Thoughts?
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Aug 2013 11:41:26 +1200

> could be used in a title?

Nah. Too complex for a title, and "random" is a bad word - you should always
say pseudo-random or (more pedantic) uniformly distributed.

IMHO the current title is clearest.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 12 Aug 2013 10:59:06 +0200

> IMHO the current title is clearest.

these addresses have the following properties:
 - stable per link
 - randomly generated as opposed to based on a MAC address.
   (making scanning attacks harder, makes tracking across links harder)
 - intended to replace existing EUI-64 identifiers

truth in advertising; given that these addresses are meant to be used 'in public', what is
"privacy enhanced" about them?

the use of "privacy" confuses it with RFC4941 addresses, which these addresses do not replace.

"Stable per-network Addresses for IPv6 Stateless Address Autoconfiguration (SPN-SLAAC)"?

no hat,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Aug 2013 06:11:59 -0300

Hi, Ole,

> "privacy enhanced" about them?

One thing is some node using an address to communicate with you. Another
thing is that other node being able to learn other information by means
of such address.

-- e.g, since the IID changes from one network to another, you cannot
track the device.

> the use of "privacy" confuses it with RFC4941 addresses, which these addresses do not replace.

Actually, RFC4941 are called "privacy extensions" (which isn't
incorrect), since those temporary addresses have interesting privacy
features. Probably, people assumed temporary == privacy because, before
stable-privacy-addresses you didn't have any other privacy-enhanced
addresses.

Both RFC4941 and stable-privacy-addreses are "privacy addresess" --
RFC4941 are temporary, while stable-privacy are stable.

> "Stable per-network Addresses for IPv6 Stateless Address Autoconfiguration (SPN-SLAAC)"?

An address could be "stable per network" without having any interesting
privacy/security features. For instance, traditional slaac addresses are
"stable per network", too.

Me, I don't care much about the title. However, given that folks have
become used to refer to this scheme as "stable-privacy addresses", and
that so far alternative titles don't seem to do a much better job, I'd
leave the title "as is".

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Mon, 12 Aug 2013 12:31:54 +0200

Fernando,

> -- e.g, since the IID changes from one network to another, you cannot

this brings us to the larger issue of how an application should choose an address type.
if I wanted "privacy" (assuming some suspension of disbelief (that choice of a particular address results in better privacy)),
I would use a temporary address.

this draft is about stable addresses. a use case for a stable address/public address, is to provide a service. that would typically mean it is published in DNS or available via some form of service discovery.
that is, an address I explicitly don't want to be private.

> RFC4941 are temporary, while stable-privacy are stable.

as soon as an address is used externally it isn't private anymore.

> "stable per network", too.

true.
any other suggestions that does not contain the word "privacy"?
I don't want to explain to my dad (substitute with your favourite family member), why he is still being
tracked across web-sites (AppNexus, Bluekai, Brightroll, Facebook Connect, Google Analytics, Google Adsense, OpenX, Taboola...) when he explicitly chose to use a privacy enhanced address for the communication.

> that so far alternative titles don't seem to do a much better job, I'd

"random Network Stable Addresses for IPv6 Stateless Address Autoconfiguration (NSA-SLAAC)"
:-)

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Aug 2013 07:53:00 -0300

On 08/12/2013 07:31 AM, Ole Troan wrote:
>> One thing is some node using an address to communicate with you.
>> Another thing is that other node being able to learn other
>> information by means of such address.
>> 
>> -- e.g, since the IID changes from one network to another, you
>> cannot track the device.
> 
> this brings us to the larger issue of how an application should
> choose an address type. if I wanted "privacy" (assuming some
> suspension of disbelief (that choice of a particular address results
> in better privacy)), I would use a temporary address.

That depends on a variety of factors, including (but not limited to):

* Whether you need stability for your address
* Whether temporary addresses are acceptable in your environment  (many
enterprises disable temporary-addresses, but would benefit from
stable-privacy)

> this draft is about stable addresses. a use case for a stable
> address/public address, is to provide a service. that would typically
> mean it is published in DNS or available via some form of service
> discovery. that is, an address I explicitly don't want to be
> private.

Please see above. Besides, receiving incoming connections does not man
many of the threats described in
<http://www.ietf.org/id/draft-cooper-6man-ipv6-address-generation-privacy-00.txt>
are acceptable.

>> incorrect), since those temporary addresses have interesting
>> privacy features. Probably, people assumed temporary == privacy
>> because, before stable-privacy-addresses you didn't have any other
>> privacy-enhanced addresses.
>> 
>> Both RFC4941 and stable-privacy-addreses are "privacy addresess"
>> -- RFC4941 are temporary, while stable-privacy are stable.
> 

"privacy" doesn't mean that your address is "unknown". It means that it
doesn't leak more info than necessary.

>> An address could be "stable per network" without having any
>> interesting privacy/security features. For instance, traditional
>> slaac addresses are "stable per network", too.
> 
> true. any other suggestions that does not contain the word
> "privacy"? I don't want to explain to my dad (substitute with your
> favourite family member), why he is still being tracked across
> web-sites (AppNexus, Bluekai, Brightroll, Facebook Connect, Google
> Analytics, Google Adsense, OpenX, Taboola...) when he explicitly
> chose to use a privacy enhanced address for the communication.

Because he didn't use a privacy-enhanced app? He'd be tracked based on
the app rather than based on the underlying address. Besides, tracking
is just one aspect (see the others in Alissa's document).

>> Me, I don't care much about the title. However, given that folks
>> have become used to refer to this scheme as "stable-privacy
>> addresses", and that so far alternative titles don't seem to do a
>> much better job, I'd leave the title "as is".
> 
> "random Network Stable Addresses for IPv6 Stateless Address
> Autoconfiguration (NSA-SLAAC)" :-)

That's a non-starter name, based on recent "events". ;-))

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 12 Aug 2013 05:57:07 -0700 (PDT)

Hi,

----- Original Message -----
> From: Ole Troan <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]>; Dave Thaler <[email-masked]>
> Sent: Monday, 12 August 2013 6:59 PM
> Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title
> 
>>> 

Why does this method have to be limited to SLAAC, or rather, wouldn't describing it as SLAAC related imply that this or a similar technique can't be used with DHCPv6 or any other address configuration methods?

While DHCPv6 assigned addresses are naturally per-subnet, I'd think the IID generation techniques described should be an option for DHCPv6 provided addresses e.g., different IIDs are generated for different subnets by the DHCPv6 server even when the client provides the same DUID.

It's starting to seem to me that more clearly separating address generation methods from address configuration methods would be worth while. If I statically configure an address that complies with this algorithm (perhaps because my host doesn't yet implement the SLAAC method of configuring them), is it a "stable privacy address" (or what ever name it ends up with)? In practice I'd probably still call it a "stable privacy address".

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 12 Aug 2013 12:59:07 -0700

Mark,

> It's starting to seem to me that more clearly separating address generation methods from address configuration methods would be worth while. If I statically configure an address that complies with…

That's a good point, the same issues apply to SLAAC and DHCPv6 generated addresses.  The next version of Privacy Considerations for IPv6 Address Generation Mechanisms will hopefully address the issues in DHCP.

Regarding the title, of this draft, how about:

  Stable Temporary Per-Subnet Interface Identifiers

My thinking behind this suggestion is that the draft is about a new type of Interface Identifiers, addresses are somewhat separate.  The are temporary as they are not tied to a hardware token like an IEEE MAC address.  They are stable as they intended to be used for a long while on the same subnet and don't change per connection/application.  It is a bit of an oxymoron :-)

Another choice:

  Pseudo-Random Per-Subnet Interface Identifiers

They are pseudo-random and intended to be used on a single subnet.

Personally, I would prefer something like these titles because "privacy" is once of several characteristics and the privacy characteristic depend a lot on how they are used and other factors like if they are put in the DNS, shared at the application layer, the prefix remains constant, etc.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Mon, 12 Aug 2013 18:04:34 -0300

Hi, Bob,

On 08/12/2013 04:59 PM, Bob Hinden wrote:
> Personally, I would prefer something like these titles because
> "privacy" is once of several characteristics and the privacy
> characteristic depend a lot on how they are used and other factors
> like if they are put in the DNS, shared at the application layer, the
> prefix remains constant, etc.

IMHO, I think we're over-..thinking(?) the title.

For instance, the same arguments that have been made about the use of
the term "privacy" could be done about terms such as "secret" (in
"secret key") -- we shouldn't not be able to say "secret key" because it
all depends on whether you disclose or publish the key.

In this case, theses addresses have the following properties:

* They don't leak information about the underlying NIC manufacturer
* They don't disclose information about node identity
* They don't disclose any information about patterns employed by IPv6
addresses in the local subnet

You might use this addresses for incoming connections without affecting
the above properties. And you might set up temporary names (and publish
the addresses there) without affecting any of some of the above
properties. In any case, if you hurt their privacy properties at any
other layer, it's a similar case of someone leaking a secret key above
(but we still call them "secret").

The best thing a reader of this document can do is read the I-D we're
co-authoring with Dave and Alissa. Whatever title we were to chose won't
help the reader avoid the ned to do that.

Cheers,

---

From: Dave Thaler <[email-masked]>
Date: Mon, 12 Aug 2013 21:33:24 +0000

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Monday, August 12, 2013 12:59 PM
> To: Mark ZZZ Smith
> Cc: Bob Hinden; Ole Troan; Brian Carpenter; IPv6 IPv6 List; Dave Thaler
> > Why does this method have to be limited to SLAAC, or rather, wouldn't
> describing it as SLAAC related imply that this or a similar technique can't be
> used with DHCPv6 or any other address configuration methods?
> >
> > While DHCPv6 assigned addresses are naturally per-subnet, I'd think the IID
> generation techniques described should be an option for DHCPv6 provided
> addresses e.g., different IIDs are generated for different subnets by the
> DHCPv6 server even when the client provides the same DUID.
> >
> > It's starting to seem to me that more clearly separating address generation
> methods from address configuration methods would be worth while. 

I agree with all of the above discussion.

> If I
> statically configure an address that complies with this algorithm (perhaps
> because my host doesn't yet implement the SLAAC method of configuring
> them), is it a "stable privacy address" (or what ever name it ends up with)? In
> practice I'd probably still call it a "stable privacy address".
> 
> That's a good point, the same issues apply to SLAAC and DHCPv6 generated
> addresses.  The next version of Privacy Considerations for IPv6 Address
> Generation Mechanisms will hopefully address the issues in DHCP.
> 

"Temporary" definitely doesn't belong in the title because they're not nearly
as temporary as the ones in RFC 4941.

> 
> My thinking behind this suggestion is that the draft is about a new type of
> Interface Identifiers, addresses are somewhat separate.  The are temporary
> as they are not tied to a hardware token like an IEEE MAC address.  They are
> stable as they intended to be used for a long while on the same subnet and
> don't change per connection/application.  It is a bit of an oxymoron :-)
> 
> Another choice:
> 

I have no problem with the above.

> Personally, I would prefer something like these titles because "privacy" is
> once of several characteristics and the privacy characteristic depend a lot on
> how they are used and other factors like if they are put in the DNS, shared at
> the application layer, the prefix remains constant, etc.

I agree it would be good to keep the word "Privacy" out of the name of
the type of interface identifiers.   It should only be in the title if used in
a way that doesn't modify the term "address" or "interface identifier".
(By comparison the title of RFC 4941 has Privacy used in a way that doesn't,
and is fine.)

-Dave

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Aug 2013 17:11:06 -0700

On Aug 9, 2013, at 14:59 , Fernando Gont <[email-masked]> wrote:
> The arguemtn, as far as I can tell, is that the current title might be confusing (mostly because of the confusion there is with different terminology on the subject).

Oh yay! Something I'm good at!

> Given the above options I'd stick with the current title. Besides, the community has become used to refer to this method as "stable-privacy-addresses".. so changing the title at this point would,

Count me in the group who would like to change the title.  I propose using the word "opaque" instead:

Long Title: "Stateless Automatic IPv6 Address Configuration (SLAAC) with Stable and Semantically Opaque Interface Identifiers"

Short Title: "SLAAC with Stable and Opaque IIDs"

I propose to use the word "opaque" here because the pseudo-random number generator is an implementation detail. The objective is to remove the semantic content of the EUI-64 formatted MAC address from all the IP addresses that a host needs to use.  The privacy consideration is only one of several goals that achieving that objective is meant to address.  Another goal is to reduce the likelihood of IID collision.

--
james woodyatt <[email-masked]>
core os networking

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Aug 2013 01:14:41 -0300

On 08/12/2013 09:11 PM, james woodyatt wrote:
>> Given the above options I'd stick with the current title. Besides,
>> the community has become used to refer to this method as
>> "stable-privacy-addresses".. so changing the title at this point
>> would, IMHO, only contribute to confusion.
> 
> Count me in the group who would like to change the title.

I knew that starting this thread was asking for trouble :-))

> I propose
> using the word "opaque" instead:
> 
> Long Title: "Stateless Automatic IPv6 Address Configuration (SLAAC)
> with Stable and Semantically Opaque Interface Identifiers"

How about "A method for generating Semantically Opaque Interface
Identifiers with Stateless Automatic IPv6 Address Configuration (SLAAC)"?

(otherwise it sounds like the Interface IDs are already there when you
do SLAAC).

> I propose to use the word "opaque" here because the pseudo-random
> number generator is an implementation detail. The objective is to
> remove the semantic content of the EUI-64 formatted MAC address from
> all the IP addresses that a host needs to use.

Not just that. Because if you were to replace the EUI-64 with some
constant number, the IID would be opaque, but you'd still be subject to
e.g. tracking attacks.

> The privacy
> consideration is only one of several goals that achieving that
> objective is meant to address.  Another goal is to reduce the
> likelihood of IID collision.

Me, I see "privacy" as not disclosing more than you're strictly required
to communicate. That is, not leak node identity, underlying NIC vendor,
etc., etc.

IMHO, I wouldn't personally opt for changing the title, since I think it
conveys the information it is meant to convey.

That say, if we (wg) want to go that path, something along the lines of
what I suggested above (essentially *your* suggestion, with a minor mod)
would seem to be the best alternative I have so far seen.

Thanks,

---

From: t.petch <[email-masked]>
Date: Tue, 13 Aug 2013 10:18:06 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Dave Thaler" <[email-masked]>
Cc: "Fernando Gont" <[email-masked]>; <[email-masked]>
Sent: Saturday, August 10, 2013 12:41 AM

> IMHO the current title is clearest.

I agree; it does the job.

I seem to have spent a lot of my working life disentangling identifiers
that have been overloaded with technical detail that adds nothing to
their use as identifiers and becomes plain misleading further down the
line.

The namespace here is that set by RFC4941
"Privacy Extensions for Stateless Address Autoconfiguration in IPv6"
to which this is an addition/enhancement/alternative and that is what
the title should convey, ie the title should be similar, to show that
the two are closely related, but different, to highlight what has
changed.

Adding "stable" does the job.

Tom Petch

> >> Me, I think this one is confusing -- for instance, IEEE-derived
addresses are
> >> This one doesn't convey the information that these addresses are
privacy-
> >> Given the above options I'd stick with the current title. Besides,
the
> >> community has become used to refer to this method as
"stable-privacy-

---

From: Christian Huitema <[email-masked]>
Date: Tue, 13 Aug 2013 19:44:38 +0000

> I propose to use the word "opaque" here because the pseudo-random number generator is an implementation detail. The objective is to remove the 
> semantic content of the EUI-64 formatted MAC address from all the IP addresses that a host needs to use.  The privacy consideration is only one of 
> several goals that achieving that objective is meant to address.  Another goal is to reduce the likelihood of IID collision.

I like this proposal: "SLAAC with Stable and Opaque IIDs"

-- Christian Huitema