Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt

From: [email-masked]
Date: Wed, 12 Jun 2013 10:45:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-6man-stable-privacy-addresses-10.txt
	Pages           : 29
	Date            : 2013-06-12

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.  This method is meant to be an
   alternative to generating Interface Identifiers based on hardware
   address (e.g., using IEEE identifiers), such that the benefits of
   stable addresses can be achieved without sacrificing the privacy of
   users.  The method specified in this document applies to all prefixes
   a host may be employing, including link-local, global, and unique-
   local addresses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-10

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Jun 2013 19:55:02 +0200

Folks,

This latest revision addresses the feedback sent by Alissa Cooper.

Should we progress this document now?

Thanks!
Fernando

On 06/12/2013 07:45 PM, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: SM <[email-masked]>
Date: Fri, 14 Jun 2013 03:18:37 -0700

>Should we progress this document now?

Yes. The proposal will be implemented.

Regards,
-sm

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jun 2013 07:11:51 +0200

ping?

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Jun 2013 10:20:11 +0200

Fernando,

> ping?

We are thinking that it would be good to have a separate draft that describes the current approaches to IID creation and how they effect privacy and tracking. Somewhat along the lines of the email and chart sent to the IPv6 list by Alissa Cooper.

The stable-privacy draft should then wait until that work has progressed.

Best regards,
Ole
(6man co-chair hat on)

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jun 2013 13:17:25 +0200

Ole,

On 06/18/2013 10:20 AM, Ole Troan wrote:
> 
>> ping?
> 
> We are thinking that it would be good to have a separate draft that
> describes the current approaches to IID creation and how they effect
> privacy and tracking. Somewhat along the lines of the email and chart
> sent to the IPv6 list by Alissa Cooper.
> 

I'm already working on such I-D.. but I disagree that progrees of this
document should depend on such document. Why should it?

We kind of beaten this issue to death.. and that's the reason for which
I ended up adding all the text that I added to the I-D.

There's people working on implementations of this document, so we should
progress it in a timely fashion. Besides, my personal sense of the wg is
that all of the comments I received were addressed, and that there's
general agreement to move the document forward.

So, procedurally-speaking, I don't understand the basis of stalling this
document.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jun 2013 10:32:29 +1200

Hi,

> document should depend on such document. Why should it?

I tend to agree with Fernando. The dependency is the other way round;
stable-privacy-addresses is a reference for the new draft.

I have the same question about draft-ietf-6man-ug. We responded to
all comments in the -01 version.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 09:48:23 +0200

Brian,

> stable-privacy-addresses is a reference for the new draft.

possibly; difficult to argue how dependencies should go for a yet-to-be written document. ;-)
we're looking at having a session on privacy/tracking and interface identifiers in Berlin.
my suggestion was to do the WGLC for stable-privacy-addresses after that.

> all comments in the -01 version.

we will initiate a last call on that ASAP.

cheers,
Ole

---

From: SM <[email-masked]>
Date: Wed, 19 Jun 2013 02:15:21 -0700

Hi Ole,
>yet-to-be written document. ;-)

There was a message asking Fernando to wait because of a 
yet-to-be-written draft.  :-)  In my opinion the dependency would be 
non-normative.  There doesn't seem to be much room for argument there.

Regards,
-sm

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Jun 2013 11:35:21 +0200

> my suggestion was to do the WGLC for stable-privacy-addresses after that.

Just to get a clear picture:

* We're stalling a wg item because you think that
draft-ietf-stable-privacy-addresses should have a (normative?) reference
to a document that the wg did not even express interest in?

* I went through the energy-consuming exercise of addressing all the
comments we had received. But now the document is stalled for other reason.

* Has the wg ever decided to wait till July/August (1.5 months from now)
to ship the document? -- So far, all comments I've seen (at least 5)
have argued in favor of shipping the document... so it looks like
there's consensus on shipping...

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 12:20:57 +0200

SM,

> There was a message asking Fernando to wait because of a yet-to-be-written draft.  :-)  In my opinion the dependency would be non-normative.  There doesn't seem to be much room for argument there.

the action is on the chairs to initiate the WGLC, and subsequently to review the document.
given the discussion on the list, we are planning a larger session on privacy, tracking and the interface identifier
in Berlin.

I thought it would make sense to do the last call on this document, after that discussion.

personally I would have preferred to scale back the stable-privacy document, and move some of the general
privacy and tracking discussion to a more general draft.
the other consideration is also, what's the sudden rush? given that interface-id generation is a local
implementation specific matter, there is nothing stopping someone who wants different interface-id's today
to go out and implement them.

cheers,
Ole

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 19 Jun 2013 13:07:55 +0200

Ole,

In my opinion, if you would prefer an absolute privacy, then changing the IP
address is not a complete solution and you need also to use an encryption
approach to protect users' data at least in higher layers. So all of the
current active drafts can provide privacy to some extend which highly
depends on some factors such as:
How they maintain the lifetime of the address, the security mechanisms in
used (firewalls, etc) , etc.

> > There was a message asking Fernando to wait because of a yet-to-be-
> written draft.  :-)  In my opinion the dependency would be non-
> normative.  There doesn't seem to be much room for argument there.
> 
> given the discussion on the list, we are planning a larger session on
> privacy, tracking and the interface identifier in Berlin.
> 
> personally I would have preferred to scale back the stable-privacy
> document, and move some of the general privacy and tracking discussion
> to a more general draft.
> the other consideration is also, what's the sudden rush? given that
> interface-id generation is a local implementation specific matter,
> there is nothing stopping someone who wants different interface-id's
> today to go out and implement them.

Regards,
Hosnieh,
Gesendet über MYMAIL für Android

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 13:18:18 +0200

Hosnieh,

> used (firewalls, etc) , etc.

I think we in this context only should focus on the effects interface-ids have
on privacy and tracking. the larger issue is out of scope for 6man. 

cheers,
Ole

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 19 Jun 2013 19:09:36 +0200

Ole,

> 
> I think we in this context only should focus on the effects interface-
> ids have on privacy and tracking. the larger issue is out of scope for
> 6man.

I am not sure about your response. What I understand here is that if you
cannot track a node means then the node has privacy and if you can track it,
then the privacy of the node is in doubt.

What is the purpose of scanning here? Why is tracking a node important? What
is to be gained from a users' IP addresses (location information) if you are
not going to use it to obtain the user's information and then carry out
other malicious endeavors? 

- I do think that it is because you want to obtain a user's information
which is in the upper layers. Or does one scan just for the purpose of
learning which ports are open which are not so that attacks can be initiated
against nodes via their open ports or attacks initiated against a particular
network?

In my opinion, if the purpose of your scan is the last one, then this is a
security issue. If it concerns users' information, then it is a privacy
issue. If you think that it is out of the scope of this group to deal with
the users' data, then it is probably not the right place to discuss users'
privacy issues too.

Thanks,
Hosnieh

---

From: Doug Barton <[email-masked]>
Date: Wed, 19 Jun 2013 10:44:36 -0700

Hosnieh,

It seems that you are combining too many things into the same category, 
and trying to make "all or nothing" judgments about them. If I'm right 
about that (and I very well might not be) then I think your perspective 
is wrong.

The original purpose of what became 4941 was to avoid the stable lower 
64 bits of an address being used by third parties to track a device/user 
as it moved from network to network. Referring to them as "privacy" 
addresses was a convenient shorthand that more or less accurately 
conveys their intended purpose.

However 3041 was published in 2001, and even though IP address related 
tracking was still the primary method of user tracking on the web (which 
was the primary, but not exclusive motivator for the privacy extensions 
in the first place) at the time 3041 was written it was already being 
replaced by other, more sophisticated methods. Now IP addresses are 
merely 1 data point in the vast ocean of data that is collected for a 
user on the web, and because of NAT and other reasons it is not even 
relied on that heavily. So at least in terms of web-related stuff, 4941, 
or other similar mechanisms, are of very limited utility for protecting 
users' privacy. One can make the argument that they are useful in other 
areas however, so to be clear I'm not suggesting that we remove them.

For what it's worth I am in agreement that the larger topics of 
communication security are outside the scope of this WG.

In relation to draft-ietf-6man-stable-privacy-addresses I remain 
unconvinced that it is necessary at all, and oppose its publication. 
There are 2 well-defined use cases, places where addresses need to be 
tracked (like businesses), and places where they don't. If addresses 
need to be tracked, turn off 4941. If they don't, you can turn it on. I 
have yet to see a convincing argument for a third use case that would be 
covered by the draft, and at this point any changes to the IPv6 spec 
need a VERY convincing use case.

Doug

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Jun 2013 14:40:38 -0700 (PDT)

<snip>

>unconvinced that it is necessary at all, and oppose its publication. 

I think what is proposed is a useful improvement.

Note that for publication to happen, rough consensus needs to be reached, not unanimity.  

>tracked (like businesses),

The problem is that this also allows tracking in the Internet. Business uses want to track devices internally, but would also want to minimise tracking on the Internet. This is the middle ground between existing L2 derived IIDs and RFC4941s. I generally don't agree with the idea of using layer 2 or layer 3 addresses to identify people because I don't think they're tightly coupled enough. However, I still think there is a useful benefit in not exposing globally unique link layer addresses beyond the scope of where they're necessary i.e. on the link itself. Minimising information disclosure is a good security and privacy principle.

> and places where they don't. If addresses 
>need to be tracked, turn off 4941. If they don't, you can turn it on.

The other benefit of this approach is that it breaks the coupling between layer 2 interface addresses and layer 3 addresses, such that changing the layer 2 interface would not change the layer 3 address. This has been a common complaint from some server and networking people. While static addressing can easily overcome that issue, it is useful to have defaults that don't create the issue in the first place.

My view is that, for devices that don't enable RFC4941 by default, this method should be the new default way of generating IPv6 IIDs.

> I 

I think it always depends on the cost of the changes verses the benefits. In this specific case, the costs of deploying this change are comparatively minor:

o it can be deployed in a piecemeal, device by device manner

o it only needs to be implemented on devices that care about the privacy of addresses (where RFC4941 are "too private") or those which would benefit from IIDs that are not as tightly coupled to the link-layer interface adresses (typically servers or routers)

o it doesn't require any changes to on-the-wire protocols 

o it can be implemented via user space processes, rather than requiring an OS upgrade, although an OS upgrade is probably preferable

One of the fundamental drawbacks of IPv6 is that it was designed in the early to mid 1990s. That was necessary because the primary problem it was dealing with was the running out of IPv4 addresses. Of course other techniques that came along that delayed that problem having a significant effect. However, in the mean time adoption of the Internet as exploded, and a lot of lessons have and are being learned about how it will be both used and abused. Ideally we could stop development and deployment of IPv6, and design and deploy IPv10 with the benefit of both IPv4 and IPv6 hindsight. That is unfortunately impractical, because we finally now need a solution to IPv4 addresses running out, rather than one in 5 to 10 or more years. Incremental improvement rather than radical change (requiring a version bump) to IPv6 is the only choice we have.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Jun 2013 09:13:44 +0200

> The problem is that this also allows tracking in the Internet. Business uses want to track devices internally, but would also want to minimise tracking on the Internet. This is the middle ground be…

wouldn't a business that require tracking devices internally use DHCP?
the DHCP server could use mechanisms similar to what we are discussing for SLAAC, or any other algorithm
to create addresses that have properties making them hard to track externally.

I also think it is a useful benefit of not exposing link-layer addresses in the IPv6 address.

> The other benefit of this approach is that it breaks the coupling between layer 2 interface addresses and layer 3 addresses, such that changing the layer 2 interface would not change the layer 3 ad…

even with the mechanisms discussed either the address needs to be stored in persistent storage, or one have to be very careful about the interface-id generation mechanism to make it independent of a change of L2 address.

> My view is that, for devices that don't enable RFC4941 by default, this method should be the new default way of generating IPv6 IIDs.

Fernando is making a good point that these addresses should be the default method even when RFC4941 is enabled by default.

the bigger question is how applications and the host stack should behave with regards to all these addresses?
should a host that isn't advertising any services even configure a public address?
I'm not sure the issue of how applications should deal with the plethora of addresses with varying lifetimes and
properties are in the scope of 6man, but it would certainly be interesting to hear the views of someone from the
apps area.

> o it can be implemented via user space processes, rather than requiring an OS upgrade, although an OS upgrade is probably preferable

indeed, and you can even argue over the need to standardize something that isn't on-the wire and cannot be
tested externally.

> One of the fundamental drawbacks of IPv6 is that it was designed in the early to mid 1990s. That was necessary because the primary problem it was dealing with was the running out of IPv4 addresses.…

hmmm... thats quickly going to become a rat-hole, but I'm not convinced that we would have designed IPv6 very differently if we had done it today.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Jun 2013 03:05:57 +0200

On 06/19/2013 12:20 PM, Ole Troan wrote:
>> yet-to-be-written draft.  :-)  In my opinion the dependency would
>> be non-normative.  There doesn't seem to be much room for argument
>> there.
> 
> the action is on the chairs to initiate the WGLC, and subsequently to
> review the document. given the discussion on the list, we are
> planning a larger session on privacy, tracking and the interface
> identifier in Berlin.

Why don't you want to ship this document, which seems to be what the wg
is supporting?

This document has been suffering from unnecessary delays for almost a
year now.

It's not very encouraging for people to contribute opinions to this wg
if, when most people seem to be arguing one way, but you decide to go
another.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: SM <[email-masked]>
Date: Thu, 20 Jun 2013 20:42:20 -0700

Hi Ole,
>the action is on the chairs to initiate the WGLC, and subsequently 

Ok.

>given the discussion on the list, we are planning a larger session 
>on privacy, tracking and the interface identifier
>in Berlin.

Ok.

>I thought it would make sense to do the last call on this document, 

I'll comment below.

>document, and move some of the general
>interface-id generation is a local

It's not a sudden rush. :-)  The specification is going to be 
implemented in an open source project.  The only proposed changed 
(see above) is the privacy and tracking discussion.  Nobody has 
submitted a more general draft.  It seems odd to have to wait for a 
session in Berlin when there isn't any concrete proposal being 
discussed on the mailing list.

Regards,
-sm

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Jun 2013 10:23:52 +0200

Fernando,

> Why don't you want to ship this document, which seems to be what the wg

have I said that? then please let me clarify.
I do think this document should be published.

> This document has been suffering from unnecessary delays for almost a

this document was returned to the working group by the AD, after the IETF last call.
to me that's a strong hint from the community that we didn't do a good enough job
in the working group. before re-sending the document, I want to make sure we have
dotted every i and crossed every t.

there are other interface-identifier mechanisms proposed, I want to make sure we go back and 
look at the bigger picture to ensure that we understand all the issues and that we are reasonably
confident that we are done.

> if, when most people seem to be arguing one way, but you decide to go

I think you have made your point, thank you.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Jun 2013 17:52:28 +0200

Ole,

My apologies if my coments cam across the wrong way. PLease find my
comments in-line...

On 06/21/2013 10:23 AM, Ole Troan wrote:
> in the working group. 

I never understood why the document came back to the wg. What we had to
address was, for the most part, the discussion fo the "NIC identifier"
we were using.

90% of the other text that was added was the product of later wg
discussions, and had nothing to do with the IETF LC.

> before re-sending the document, I want to make sure we have

Isn't that what reviews are for?

For instance, I polled every single guy that had provided comments since
IETF LC to double-check that their feedback had been addressed.

You mentioned that you planned to have a general discussion at the next
IETF. Yet everything that had to do with IETF LC had nothing to d with
"general issues", but rather with low level details (whether Interface
Indexes are constant or not, etc.).

Me, I personally think that if we rally want to make sure that the
document is ready, we just need reviews in that direction. If we're ging
to rewind back to WGLC, then, by itself, gives enough opportunities to
review and comment (there's still IETF LC, etc.).

> confident that we are done.

We have beaten this one to death, for more than a year. If having to
address low-level details in the I-D is going to be an opportunity to
rewind one year in the publication process, it becomes difficult to make
progress.

I don't think one anyone would think that "we need to make sure we
understand the bigger picture"... because the I-D was brought back to
the wg for a low-level detail, and not for the "bigger picture".

Just me trying to make progress.

Cheers,