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

[Fernando Gont <[e-mail]>]

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?
> 
> Uh, storing 16 (or so) bytes per location is rather low-cost.

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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1