Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[Brian E Carpenter <[e-mail]>]

On 19/05/2016 18:10, Lorenzo Colitti wrote:
> On Thu, May 19, 2016 at 2:19 PM, Alissa Cooper <[e-mail]> wrote:
> 
>> The draft makes just about a clear a statement in this vein as is possible:
>>
>> "By default, nodes SHOULD NOT employ IPv6 address generation schemes
>>    that embed the underlying link-layer address in the IID.”
>>
>> Note that this statement does not prohibit anything, nor does it make a
>> normative (in the moral sense) judgment. It just states the recommendation,
>> which is the point of the document.
>>
>> I appreciate that not everyone on the list agrees with this
>> recommendation. But I find the claim that this recommendation is unclear to
>> be difficult to understand. That is, I can’t think of a way to convey the
>> same recommendation that would be clearer. If you can, please suggest text.
>>
> 
> Alissa,
> 
> I don't think anybody is claiming that the recommendation itself is
> difficult to understand. What is difficult to understand is how the
> document justifies that claim.
> 
> It looks like the main argument used to justify this recommendation is
> major privacy risks. But embedding a link layer identifier into an IP
> address is not a major [1] privacy risk. It is only embedding a *STABLE*
> link-layer address that is a major privacy risk.
> 
> Recommending that link-layer address be embedded only if they are ephemeral
> would address the privacy concerns just as well as (or maybe even better)
> than the approach proposed in this document.
> 
> I think what people are do not understand is why this document recommends
> one but not the other. I certainly don't.
> 
> Cheers,
> Lorenzo
> 
> [1] I argue that cross-referencing IPX traffic to IP traffic is not a major
> privacy risk because IPX is so uncommon.

I only chose that example because it's an obvious one. Do we know all the contexts
in which a MAC address may appear in an off-link packet? I doubt it.

A privacy risk doesn't have to be "major" to be important. If we are concerned
about massive-scale surveillance, where the opponent is using Hadoop and machine
learning technologies to glean information, minor risks become significant. So
I support the draft as it stands: any case in which a layer 2 identifier is
embedded *in clear* in a higher layer identifier is a bad thing, even if it's
a temporary and pseudo-random bit string.

[I hadn't remembered that RFC1958 already said that ;-)]

I think this is completely orthogonal to whether stable IIDs should be used
by clients at all - that's an operational choice that we can only leave to site
operators.

Regards
   Brian