Subject: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)

From: "Brian Haberman" <[email-masked]>
Date: Wed, 22 Jan 2014 12:24:34 -0800

Brian Haberman has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am taking the somewhat curious route of raising a DISCUSS on a document
that I am shepherding.  I will return to a Yes when these issues are
resolved.  Thomas Narten raised a good point that this document does not
mention the work published in RFCs 4436 and 6059 (from the concluded DNA
WG).  Two of the points he raised are worth addressing in this document
prior to publication.

1. If you have stable storage (and many devices do), it makes sense to
just cache the addresses instead of
regenerating them. DNA does this. Seems like that option should be
allowed. (the current document suggests saving the number of DAD
iterations in stable storage... why do that if you can just save the
address itself?)

2. DNA also has recommendations for detecting when you (re)connect to a
network you visited before. That is pretty much the same thing this spec
needs to do in order to generate the same addresses when connecting to a
previously visited network (i.e., the Network_ID paramater). For the
wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal
address pair of routers to identify a link. This document might suggest
doing the same thing.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2014 17:48:45 -0300

On 01/22/2014 05:24 PM, Brian Haberman wrote:
> regenerating them.

1) Recording the addresses a node has visited during its lifetime would
somehow be ironic for a document aiming at privacy. Just get the
document compromised, and you get a list of where the node has been
since it was first installed.

2) Recording the addresses seems like a waste of resources. How many
networks you connect to only once in your lifetime?

> DNA does this. Seems like that option should be

The current document allows that to happen for cases where you find a
colission -- which would be close to nil, given that subnets are /64 and
the IIDs are essentially random.

That said, as an author, I don't expect implementations to record the
dad counter ever, even in the presence of collisions.  I'd argue that
that paragraph is there with this rationale "if you're picky and you're
going to argue that this spec doesn't guarantee a stable IID, you can do
this if you want".

> address pair of routers to identify a link. This document might suggest

IMHO, using the linklayer/linklocal address of the router is not a good
idea. Thing about a replaced NIC,  or a backup router that kicks in in
the event of failuer of the main one.

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Jan 2014 16:44:13 -0500

> since it was first installed.

I think I can get a list of where a device has been from any number of
places.  So, I don't buy that argument at all.

> networks you connect to only once in your lifetime?

Uh, storing 16 (or so) bytes per location is rather low-cost.

> going to argue that this spec doesn't guarantee a stable IID, you can do

Now you are getting into specifying implementation details and that is
not good.  All this point is making is that there are a variety of ways
of getting this behavior and DNA provided guidance on one way to do
that.  The simple solution is to refer to those RFCs (informatively) and
point out that they describe one way to track which addresses are
associated with particular networks.  This has the benefit of not
forcing re-calculation of the hash on every (re-)connect.

> the event of failuer of the main one.

We have had this discussion before.  The Network_ID variable really
should be used to whatever extent possible.  For a wired network, the
DNA approach of caching a router's link-local address seems like a good
approach.  Yes, it will not work if the router's interface changes, but
that should be rather infrequent.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2014 19:13:12 -0300

Hi, Brian,

Comments in-line... (important bit at the bottom :-) )..

On 01/22/2014 06:44 PM, Brian Haberman wrote:
>> 
>> 1) Recording the addresses a node has visited during its lifetime
>> would somehow be ironic for a document aiming at privacy. Just
>> get the document compromised, and you get a list of where the
>> node has been since it was first installed.
> 
> I think I can get a list of where a device has been from any number
> of places.

I guess you might. However, I don't think that means one should add
yet another one.

>> 2) Recording the addresses seems like a waste of resources. How
>> many networks you connect to only once in your lifetime?
> 

Firstly, you might not have such stable storage. Secondly, where do
you stop? 10 addresses? 100 addresses? 1000 addresses? Why should we
rely on such stable storage when we need not? Thirdly, recording the
addresses seems to be a different scheme than this one, which aims at
producing stable addresses stateless-ly.

>>> DNA does this. Seems like that option should be allowed. (the
>>> current document suggests saving the number of DAD iterations
>>> in stable storage... why do that if you can just save the 
>>> address itself?)
>> 
>> The current document allows that to happen for cases where you
>> find a colission -- which would be close to nil, given that
>> subnets are /64 and the IIDs are essentially random.
>> 
>> That said, as an author, I don't expect implementations to record
>> the dad counter ever, even in the presence of collisions.  I'd
>> argue that that paragraph is there with this rationale "if you're
>> picky and you're going to argue that this spec doesn't guarantee
>> a stable IID, you can do this if you want".
> 
> Now you are getting into specifying implementation details and that
> is not good.

I was just clarifying that while the document says you MAY do
something that requires stable storage, the mechanism does not really
depend on it.

> All this point is making is that there are a variety of ways of
> getting this behavior and DNA provided guidance on one way to do 
> that.  The simple solution is to refer to those RFCs
> (informatively) and point out that they describe one way to track
> which addresses are associated with particular networks.  This has
> the benefit of not forcing re-calculation of the hash on every
> (re-)connect.

I have no issues with that (I misinterpreted where you were going, it
seems).

So I guess one could add something along the lines of:
"A node may use Simple DNA [RFC6059] to reuse a previously-configured
address for this network without the need to recompute the
Interface-ID with the scheme specified in this document."

?

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Jan 2014 22:31:12 +0000

On 01/22/2014 09:44 PM, Brian Haberman wrote:
>>> 1) Recording the addresses a node has visited during its
>>> lifetime would somehow be ironic for a document aiming at
>>> privacy. Just get the document compromised, and you get a list
>>> of where the node has been since it was first installed.
> of places.  So, I don't buy that argument at all.
> 

I buy the argument. Some vendors have been beaten up for
it now and then. Making that worse while trying to make
privacy better would be a shame, no?

S.

[1]
http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 Jan 2014 06:37:14 -0500

> http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears

Duly noted.  If that is a concern, then it should be noted in the draft
that storing the address is a bad idea.  That way, people won't be
tempted to implement this feature in that way.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 Jan 2014 06:39:08 -0500

> Interface-ID with the scheme specified in this document."

That would work for me.  We can wait to see if any of AD has an issue
with this text.

Regards,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jan 2014 11:45:08 +0000

On 01/23/2014 11:37 AM, Brian Haberman wrote:
>>>>> privacy. Just get the document compromised, and you get a
>>>>> list of where the node has been since it was first
>>>>> installed.
>>> I think I can get a list of where a device has been from any
>>> number of places.  So, I don't buy that argument at all.
>> 
>> 
>> I buy the argument. Some vendors have been beaten up for it now
>> and then. Making that worse while trying to make privacy better
>> would be a shame, no?
>> 
>> S.
>> 
>> [1] 
> Duly noted.  If that is a concern, then it should be noted in the
> draft that storing the address is a bad idea.  That way, people
> won't be tempted to implement this feature in that way.

That'd work for me.
Thanks,
S.

> Regards, Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2014 08:47:31 -0300

On 01/23/2014 08:39 AM, Brian Haberman wrote:
>>> All this point is making is that there are a variety of ways
>>> of getting this behavior and DNA provided guidance on one way
>>> to do that.  The simple solution is to refer to those RFCs 
>>> (informatively) and point out that they describe one way to
>>> track which addresses are associated with particular networks.
>>> This has the benefit of not forcing re-calculation of the hash
>>> on every (re-)connect.
>> 
>> I have no issues with that (I misinterpreted where you were
>> going, it seems).
>> 
>> So I guess one could add something along the lines of: "A node
>> may use Simple DNA [RFC6059] to reuse a previously-configured 
> That would work for me.  We can wait to see if any of AD has an
> issue with this text.

My understanding of the discussion with Thomas is that one could
rather use the SDNA stuff as a possible source for the Network_ID
parameter. That' be great. (I proposed some text to Thomas, and I'm
waiting for his response).

Regarding use of DNA as proposed in the suggested paragraph above, I
have no issues with it, although it seems orthogonal and out of scope
*here*. -- i.e., such note might make more sense for the other
document that has just been adopted. This one is about what to do when
you have already "decided" that you cannot reuse the
previously-assigned address.

Thoughts?

Thanks,
- -- 
Fernando Gont
SI6 Networks

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 Jan 2014 07:01:40 -0500

> previously-assigned address.

Given the concerns raised by Stephen about storing addresses, I can see
where employing the DNA approach for the Network_ID is a reasonable
compromise.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2014 09:04:39 -0300

On 01/23/2014 09:01 AM, Brian Haberman wrote:
>> 
>> Regarding use of DNA as proposed in the suggested paragraph
>> above, I have no issues with it, although it seems orthogonal and
>> out of scope *here*. -- i.e., such note might make more sense for
>> the other document that has just been adopted. This one is about
>> what to do when you have already "decided" that you cannot reuse
>> the previously-assigned address.
>> 
>> Thoughts?
> 
> Given the concerns raised by Stephen about storing addresses, I can
> see where employing the DNA approach for the Network_ID is a
> reasonable compromise.

Great.

Should I wait for Thomas response, and then rev to address all the
comments received so far? (Tim's, Stephen's, yours, Thomas', etc.)?

Thanks!
- -- 
Fernando Gont

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 Jan 2014 08:19:51 -0500

> comments received so far? (Tim's, Stephen's, yours, Thomas', etc.)?

Yes, let's wait on a revision until we have all the needed updates
identified.

Regards,
Brian