Re: FW: New Version Notification for draft-huitema-6man-random-addresses-01.txt

[Philip Homburg <[e-mail]>]

In your letter dated Tue, 4 Aug 2015 19:14:02 +0000 you wrote:
>This is a new version of the draft that was discussed in Prague. I rewrote it 
>to focus on the "update to 7217," but also threw in an "update to 4941." I thi
>nk it covers most of the feedback received in the WG.

Hi Christian,

Here are a few comments.

In Section 2.2:

"These conditions will be considered equivalent to disconnecting and then
"reconnecting with a new link layer address.  The previously used IPv6
"addresses will be discarded, and a new set of addreses will be assigned.

Maybe you can put in a reference to an RFC if there is an RFC that describes
the desired behavior. 

I would say that in this case, a host MUST set all valid times of addresses
generated with the old IID to zero before connecting to the new link to make
sure that no packets with old IPv6 address go out. 

"4.1.  Update to RFC 4941"

The way I understand RFC 4941, you leave older address as deprecated when
generating a new one. Which means that older addresses may get used by
running application after the MAC address change.

I guess that when changing MAC addresses again all old address have to have
the lifetimes set to zero explicitly.

In Section 5.1:

"The correlation over time still be possible for the lifetime of the link
"layer address, and the location tracking will only be mitigated if link
"layer addresses do change with location.

I assumed that the premise of this draft is that MAC address will change.
I.e. that is the starting point for this draft.

"The practice will export the link-layer address value to all places where
"the IPv6 address is used.  This increase the potential "surface" for privacy
"attacks, and is not desirable.

Can you explain how such an attack would work? 

Just some random thoughts:

1)
Given that essentially we want random IIDs to go with random MAC addresses 
then maybe the best recommendation is to only configure RFC 4941. 

I'm not sure that a randomized RFC 7217 would add any benfits over RFC 4941.
The only thing is that RFC 7217 generates an IID whereas RFC 4941.

However, in the context of RFC 4941, the addresses derived from the EUI-64
IIDs are essentially unused except for link local.

2)
Alternatively, maybe add text to this draft to generate a new random IID
whenever the MAC address is changed while explicitly setting the lifetimes
of older addresses to zero.

By adding that text and then advising against using RFC-4941 or RFC-7217 the
draft becomes nicely self-contained.