Subject: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt

From: [email-masked]
Date: Fri, 14 Feb 2014 10:43:35 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Privacy Considerations for IPv6 Address Generation Mechanisms
        Authors         : Alissa Cooper
                          Fernando Gont
                          Dave Thaler
	Filename        : draft-ietf-6man-ipv6-address-generation-privacy-01.txt
	Pages           : 16
	Date            : 2014-02-14

Abstract:
   This document discusses privacy and security considerations for
   several IPv6 address generation mechanisms, both standardized and
   non-standardized.  It evaluates how different mechanisms mitigate
   different threats and the trade-offs that implementors, developers,
   and users face in choosing different addresses or address generation
   mechanisms.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-address-generation-privacy/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-address-generation-privacy-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 14 Feb 2014 10:53:41 -0800

Summary of changes:

Additional text about unique prefix assignment in Sec 4

Updated table entries in Sec 4 to reflect discussion at IETF 88

Corrected Sec 4.4 text on CGAs

Added detail to Sec 4.7 to reflect common DHCPv6 practices

Alissa

On 2/14/14 10:43 AM, "[email-masked]" <[email-masked]>
wrote:

>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Christian Huitema <[email-masked]>
Date: Fri, 14 Feb 2014 21:43:36 +0000

> Added detail to Sec 4.7 to reflect common DHCPv6 practices

I read this draft, and while I generally agree with the discussion, I feel that a particular angle is missing, the relation between IPv6 address and MAC address tracking.

There are tracking systems that can record and correlate the MAC addresses of mobile nodes as they connect to various networks. The obvious countermeasure is to randomize the MAC address. On a Wi-Fi network, it could be done by passively listening to the advertisement from the access point, and then making an explicit decision to use a stable MAC address if the location is trusted, and a randomized one if it is not.

The question then is whether the IPv6 would remain constant even if the MAC address changed. There are generation schemes where the address would remain constant. CGA for example only depends of the IPv6 header and the public key. Stable IID would remain constant if the network interface parameter used in the generation (Net_Iface) remained constant, e.g. was based on the interface name. It would obviously change if the interface was identified by the MAC address.

Can we add a discussion of the issue to this address privacy draft?

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Feb 2014 19:17:17 -0300

Hi, Christian,

On 02/14/2014 06:43 PM, Christian Huitema wrote:
> I read this draft, and while I generally agree with the discussion, I
> feel that a particular angle is missing, the relation between IPv6
> address and MAC address tracking.
> 
> There are tracking systems that can record and correlate the MAC
> addresses of mobile nodes as they connect to various networks.

Yes, as e.g.:
<http://www.ftc.gov/news-events/blogs/techftc/2014/02/my-phone-your-service>.

> The
> obvious countermeasure is to randomize the MAC address.

This has issues. Do you randomize the the whole six bytes of the
address? Not that MAC addresses are guaranteed to be unique (MAC address
duplication is well-known) -- but if you do randomize the MAC address,
the collisions are of course more likely.

Besides do you randomize it each time you connect to a network? If you
do, you might end up with a different IPv6 address each time (this will
be guaranteed if your doing traditional SLAAC, but may be the case with
stable-privacy if you employ the mac address as the interface_id).

While this wouldn't be an issue for the roam around cyber-cafes
scenario, it is probably not desirable for e.g. enterprises.
Also, what if I want to keep my TCP connections open in the presence of
a temporal link disconnection?

So it looks like you'd want to implement some sort of stable-privacy but
for the MAC address...

> The question then is whether the IPv6 would remain constant even if
> the MAC address changed. There are generation schemes where the
> address would remain constant. CGA for example only depends of the
> IPv6 header and the public key. Stable IID would remain constant if
> the network interface parameter used in the generation (Net_Iface)
> remained constant, e.g. was based on the interface name. It would
> obviously change if the interface was identified by the MAC address.

(Apologies for responding before reading your whole message :-) )

> Can we add a discussion of the issue to this address privacy draft?

I personally have no issues. My only "concern" is that if we start
discussing IDs other than the IPv6 addresses, we might later discuss
e.g. layer-7 stuff. Not that layer-2 and layer-7 privacy issues are
uninteresting.. but rather than the more focused we stay, the more
tractable the problem is.

Thanks!

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 15 Feb 2014 00:23:54 +0000

> I personally have no issues. My only "concern" is that if we start discussing IDs other than the IPv6 addresses, we might later discuss e.g. layer-7 stuff. Not that layer-2 and layer-7 privacy issues are uninteresting.. but rather than the more focused we stay, the more tractable the problem is.

I would not want to discuss in an IPv6 draft the precise mechanics of changing MAC addresses, or the policy controls to make avoid nasty side effects. I would like to see a simple issue debated: "assuming that the host administrator has programmed the host to change its MAC address before visiting network X, can we guarantee that the IPv6 IID does not leak information about the identity of the host."

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Feb 2014 21:42:02 -0300

Hi, Christian,

On 02/14/2014 09:23 PM, Christian Huitema wrote:
>> discussing IDs other than the IPv6 addresses, we might later
>> discuss e.g. layer-7 stuff. Not that layer-2 and layer-7 privacy
>> issues are uninteresting.. but rather than the more focused we
>> stay, the more tractable the problem is.
> 
> I would not want to discuss in an IPv6 draft the precise mechanics of
> changing MAC addresses, or the policy controls to make avoid nasty
> side effects. I would like to see a simple issue debated: "assuming
> that the host administrator has programmed the host to change its MAC
> address before visiting network X, can we guarantee that the IPv6 IID
> does not leak information about the identity of the host."

My simple answer would be "Depends on the algorithm employed to
generated the IID".

For example, if you do the traditional SLAAC IIDs, "randomizing the MAC
adress" would essentially mitigate the privacy/security issues related
with IPv6 addressing.

OTOH, if the node implements Microsoft's scheme (randomized but constant
IIDs along the life of the node), then I'd expect to randomized MACs to
just mitigate the MAC-tracking issue. (I don't think they regenerate the
IID when the NIC is replaced.. buy I might be wrong).

P.S.: While we won't be able to commit any of these before the IETF
meeting, I will craft some text and post it here for discussion asap.

Thanks!

Cheers,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Feb 2014 19:37:24 -0800 (PST)

Hi,

I think it would be useful to not specifically couple address configuration methods (SLAAC, DHCPv6, static/manual) with address generation methods (MAC derived, RFC4941, cryptographically generated etc.). I think what is being discussed about addresses equally applies regardless of the address configuration method used to configure the resulting IPv6 address on an interface.

So, for example, dropping the address configuration method:

"Over the years, many interface identifier generation  techniques have been defined, both standardized and non-standardized:

      *  IPv4 address

      *  Service port

      *  Wordy

      *  Low-byte

      *  IEEE 802 48-bit MAC or IEEE EUI-64 identifier
         [RFC1972][RFC2464]

      *  Cryptographically generated [RFC3972]

      *  Temporary (also known as "privacy addresses") [RFC4941]

      *  Constant, semantically opaque (also known as random)
         [Microsoft]

      *  Stable, semantically opaque
         [I-D.ietf-6man-stable-privacy-addresses]

      *  IPv4 address and port [RFC4380]"

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Feb 2014 14:58:06 -0300

On 02/15/2014 12:37 AM, Mark ZZZ Smith wrote:
> 
> I think it would be useful to not specifically couple address
> configuration methods (SLAAC, DHCPv6, static/manual) with address
> generation methods (MAC derived, RFC4941, cryptographically generated
> etc.). I think what is being discussed about addresses equally
> applies regardless of the address configuration method used to
> configure the resulting IPv6 address on an interface.

Makes sense -- although for the most part, they do seem to be coupled in
practice.

e.g., how do you do CGAs with DHCPv6, etc.?

It seems to me that while there's a distinction between the mechanism
used for address configuration and the resulting IID, for most cases
there's a 1 to 1 mapping... and it's valuable how such IIDs are
typically generated.

Thoughts?

Thanks,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 22 Feb 2014 16:29:31 -0800 (PST)

Hi Fernando,

----- Original Message -----
> From: Fernando Gont <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Wednesday, 19 February 2014 4:58 AM
> Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt
> 

I think that has been a coupling of "convenience" more than a necessity. I think it is also the origin of the issues where when DHCPv6 or SLAAC is switched off on a link, the DHCPv6 or SLAAC configured addresses have been removed from the hosts' interfaces, even though the addresses still had valid lifetimes. I've come to the belief that the only address expiry mechanism is their lifetimes, and the lifetimes, while set by the address configuration method used, are the only determinant of whether the address should be expired or not.

> there's a 1 to 1 mapping... and it's valuable how such IIDs are

I'm not sure there is a 1:1 mapping very often, though it might be implied by the various RFCs that have coupled them together. However, if you go through a variety of examples of IID generation methods, and think of the methods that can or could be used to configure them, most of the time they aren't very exclusive.

For example, privacy addresses can be configured via SLAAC or via DHCPv6 (IA_TA option). The could also be configured manually, by generating the address and then setting non-infinite lifetimes. So the privacy address generation mechanism isn't coupled to a single address configuration method.

As another example, consider EUI-64 derived. Used by SLAAC, however I don't think there is any technical reason why a DHCPv6 server couldn't generate addresses based on the EUI-64 form of the link-layer source address the host used, and then dole them out to the hosts. They could be configured manually too.

I thought the same for your Opaque IDs address generation method, which is why I suggested the text to say that this method isn't exclusively tied to SLAAC. DHCPv6 servers could use the opaque IID address generation method, and it could also be used to generate addresses that are then manually configured on the host (perhaps via a boot script).

I agree there are some cases where the address generation and address configuration methods are tightly coupled, such as your CGA with DHCPv6 example. However I think they're the exception rather than the rule, which is why I think there is value in treating address generation as a distinct function that is usually separate from address configuration. (In summary, I think there are 3 distinct addressing related functions - address generation (privacy, opaque, EUI-64), address configuration (SLAAC, DHCPv6, static/manual) and address expiry (valid lifetime)). 

Regards,
Mark.