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

[Alissa Cooper <[e-mail]>]

> On Mar 24, 2016, at 6:10 PM, Christian Huitema <[e-mail]> wrote:
> 
>>> What concerns me the most is that platforms that are already
>>> implementing MAC address randomization, and that have strong privacy
>>> requirements, should not be forced to implement RFC 7217, which from a
>>> privacy perspective is inferior to EUI-64 with MAC address randomization.
>> 
>> That has nothing to do with this document. If that's your concern, then
>> you're calling for an update to RFC4941, such that you do both random link-
>> layer addresses and temporary addresses with no stable addresses.
>> 
>> However, I'd say that you can probably get away with what you want, while
>> doing RFC7217, even without doing RFC4941: use your randomized MAC
>> address as the Net_Iface parameter, and your address will change as often
>> as your MAC address. From the point of view of achiving a stable address, I'd
>> say you chose the wrong surce of Net_Iface ;-), but it'll get what you want...
> 
> I am reading this discussion just now. I think that the issue is with the requirements stated in section, or precisely with what is not stated there. The first requirement stated is about stability, "The resulting Interface Identifiers remain stable for each prefix used with SLAAC within each subnet for the same network interface." That requires that when a mobile node visits a particular subnet, it should obtain exactly the same IID. 
> 
> Well, the practice of MAC Address Randomization goes against that. When a user decides to randomize the MAC address used on a particular link, the user expects that during the next visit to the link, after randomization, the interface will obtain a different address. Failing that would allow tracking through IID, and negate the privacy value of the randomization.
> 
> As Lorenzo points out, the simple solution is to use the randomized MAC address as the Net_Iface parameter specified for RFC7217. As far as I can tell, at least one stack is doing exactly that today.
> 
> 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. 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.

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.

Alissa


> 
> -- Christian Huitema
> 
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------