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

From: Christian Huitema <[email-masked]>
Date: Tue, 4 Aug 2015 19:14:02 +0000

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 think it covers most of the feedback received in the WG.

-- Christian Huitema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 4, 2015 12:11 PM
To: Christian Huitema <[email-masked]>; Christian Huitema <[email-masked]>
Subject: New Version Notification for draft-huitema-6man-random-addresses-01.txt

A new version of I-D, draft-huitema-6man-random-addresses-01.txt
has been successfully submitted by Christian Huitema and posted to the IETF repository.

Name:		draft-huitema-6man-random-addresses
Revision:	01
Title:		Implications of Randomized Link Layers Addresses for IPv6 Address Assignment
Document date:	2015-08-04
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-huitema-6man-random-addresses-01.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-6man-random-addresses/
Htmlized:       https://tools.ietf.org/html/draft-huitema-6man-random-addresses-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-huitema-6man-random-addresses-01

Abstract:
   Hosts may assign random link-layer addresses to network interfaces in
   an attempt to increase privacy and reduce trackability.  Careless
   assignment of IPv6 addresses may negate the privacy advantages of
   random link-layer addresses.  We propose simple solutions to ensure
   that IPv6 addresses do change whenever the link layer addresses
   change.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Aug 2015 14:50:43 +0200

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.