Subject: Re: default-iids ready for WGLC? (Re: I-D Action: draft-ietf-6man-default-iids-10.txt)

From: Fernando Gont <[email-masked]>
Date: Sun, 3 Apr 2016 10:29:41 -0300

Hi, Alissa,

On 03/25/2016 04:32 PM, Alissa Cooper wrote:
>> Note that this is unrelated to whether IT admins allow randomized
>> addresses, or whether a specific hardware supports it. If
>> randomization is forbidden or unavailable, of course it will not be
>> used and the address will not change. And the users will be easy to
>> track.
> 
> 
> Thinking this through, I think part of the difficulty with this kind
> of document is the gap between what is standardized and what is
> implemented. What we have today, from a standards perspective is:
> 
> (1) a bunch of specs that normatively specify embedding in an IID a
> MAC address as presently specified by IEEE 802
> 
> (2) RFC 4941 which specifies a method for temporary address
> generation but indicates that such addresses can/should be generated
> alongside a MAC-based address
> 
> (3) RFC 7217 which specifies a method for generating a random address
> that stays stable per-subnet
> 
> Aside from what has been standardized, it sounds like what we also
> have are MAC addresses getting randomized more commonly, use of the
> method in 7217 to generate addresses that do not necessarily remain
> stable per subnet, and perhaps use of 4941 temporary addresses in
> isolation, without a stable address also configured.
> 
> If we want to replace (1) with something better from a
> security/privacy perspective, we have limited choices if we want to
> point to an existing standard. 

This was the whole point of this I-D.

> If we do not care about pointing to an
> existing standard, we could just list what the requirements are, and
> have all the specs that fall under (1) be updated to use some
> (unspecified) mechanisms that meet those requirements. Or we could
> first standardize mechanisms to cover all the cases that the
> requirements would cover, and then point to those mechanisms.

What we're doing there is replacing the default mechanism for generating
stable addresses. ANything else is orthogonal. e..g, if you want to use
RFC4941-only, that has, IMO, nothing to do with replacing the MAC-based
stable addresses with RFC7217.

> Personally I think requirements 2-4 in Sec. 3 of default-iids
> represent the minimum change that is worth updating all the specs
> that fall under (1). Adding a requirement or changing requirement 2
> to speak to an address change per network connection/disconnection
> rather than per subnet would be reasonable if we decide to ditch
> requirement 1. From this discussion it sounds like adding a
> requirement against direct embedding of a link layer address in an
> IID may also be a good addition.

Isn't it there, already?

Thanks!

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