draft-ietf-6man-ipv6-address-generation-privacy-00.txt   draft-ietf-6man-ipv6-address-generation-privacy-01.txt 
Network Working Group A. Cooper Network Working Group A. Cooper
Internet-Draft CDT Internet-Draft Cisco
Intended status: Informational F. Gont Intended status: Informational F. Gont
Expires: April 20, 2014 Huawei Technologies Expires: August 18, 2014 Huawei Technologies
D. Thaler D. Thaler
Microsoft Microsoft
October 17, 2013 February 14, 2014
Privacy Considerations for IPv6 Address Generation Mechanisms Privacy Considerations for IPv6 Address Generation Mechanisms
draft-ietf-6man-ipv6-address-generation-privacy-00.txt draft-ietf-6man-ipv6-address-generation-privacy-01.txt
Abstract Abstract
This document discusses privacy and security considerations for This document discusses privacy and security considerations for
several IPv6 address generation mechanisms, both standardized and several IPv6 address generation mechanisms, both standardized and
non-standardized. It evaluates how different mechanisms mitigate non-standardized. It evaluates how different mechanisms mitigate
different threats and the trade-offs that implementors, developers, different threats and the trade-offs that implementors, developers,
and users face in choosing different addresses or address generation and users face in choosing different addresses or address generation
mechanisms. mechanisms.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4
3.1. Correlation of activities over time . . . . . . . . . . . 5 3.1. Correlation of activities over time . . . . . . . . . . . 5
3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6
3.3. Device-specific vulnerability exploitation . . . . . . . 6 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6
3.4. Address scanning . . . . . . . . . . . . . . . . . . . . 6 3.4. Device-specific vulnerability exploitation . . . . . . . 6
4. Privacy and security properties of address generation 4. Privacy and security properties of address generation
mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9
4.2. Static, manually configured IIDs . . . . . . . . . . . . 9 4.2. Static, manually configured IIDs . . . . . . . . . . . . 10
4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10
4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10 4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10
4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10
4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 10 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 11 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12
4.8. Transition/co-existence technologies . . . . . . . . . . 11 4.8. Transition/co-existence technologies . . . . . . . . . . 12
5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12
5.1. Geographic Location . . . . . . . . . . . . . . . . . . . 12 5.1. Geographic Location . . . . . . . . . . . . . . . . . . . 12
5.2. Network Operation . . . . . . . . . . . . . . . . . . . . 12 5.2. Network Operation . . . . . . . . . . . . . . . . . . . . 12
5.3. Compliance . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Intellectual Property Rights (IPRs) . . . . . . . . . . . 12 5.4. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
IPv6 was designed to improve upon IPv4 in many respects, and IPv6 was designed to improve upon IPv4 in many respects, and
mechanisms for address assignment were one such area for improvement. mechanisms for address assignment were one such area for improvement.
In addition to static address assignment and DHCP, stateless address In addition to static address assignment and DHCP, stateless
autoconfiguration (SLAAC) was developed as a less intensive, fate- autoconfiguration was developed as a less intensive, fate-shared
shared means of performing address configuration. With stateless means of performing address assignment. With stateless
autoconfiguration, routers advertise on-link prefixes and hosts autoconfiguration, routers advertise on-link prefixes and hosts
generate their own interface identifiers (IIDs) to complete their generate their own interface identifiers (IIDs) to complete their
addresses. Over the years, many interface identifier generation addresses. Over the years, many interface identifier generation
techniques have been defined, both standardized and non-standardized: techniques have been defined, both standardized and non-standardized:
o Manual configuration o Manual configuration
* IPv4 address * IPv4 address
* Service port * Service port
skipping to change at page 3, line 41 skipping to change at page 3, line 41
* IPv4 address and port [RFC4380] * IPv4 address and port [RFC4380]
Deriving the IID from a globally unique IEEE identifier [RFC2462] was Deriving the IID from a globally unique IEEE identifier [RFC2462] was
one of the earliest mechanisms developed. A number of privacy and one of the earliest mechanisms developed. A number of privacy and
security issues related to the interface IDs derived from IEEE security issues related to the interface IDs derived from IEEE
identifiers were discovered after their standardization, and many of identifiers were discovered after their standardization, and many of
the mechanisms developed later aimed to mitigate some or all of these the mechanisms developed later aimed to mitigate some or all of these
weaknesses. This document identifies four types of threats against weaknesses. This document identifies four types of threats against
IEEE-identifier-based IIDs, and discusses how other existing IEEE-identifier-based IIDs, and discusses how other existing
techniques for generating IIDs do or do not mitigate those threats. techniques for generating IIDs do or do not mitigate those threats.
For simplicity sake, most of the discussion in this document assumes The discussion in this document is limited to global addresses and
that addresses have global scope. However, the scope of an address does not address link-local addresses. [Do we need to say something
just limits the number of potential nodes that might exploit such about unique-local being in or out of scope?]
address for different malicious purposes (host-tracking, device-
specific vulnerability exploitation, etc.). Additionally, we note
that even addresses with limited scopes (e.g. link-local) might leak
out as a result of, for example, application-layer protocols (e.g.,
consider email headers).
2. Terminology 2. Terminology
This section clarifies the terminology used throughout this document. This section clarifies the terminology used throughout this document.
Public address: Public address:
An address that has been published in a directory or other public An address that has been published in a directory or other public
location, such as the DNS, a SIP proxy, an application-specific location, such as the DNS, a SIP proxy, an application-specific
DHT, or a publicly available URI. A host's public addresses are DHT, or a publicly available URI. A host's public addresses are
intended to be discoverable by third parties. intended to be discoverable by third parties.
Stable address: Stable address:
An address that does not vary over time within the same network. An address that does not vary over time within the same network.
skipping to change at page 4, line 47 skipping to change at page 4, line 42
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. These words take their normative meanings only when they [RFC2119]. These words take their normative meanings only when they
are presented in ALL UPPERCASE. are presented in ALL UPPERCASE.
3. Weaknesses in IEEE-identifier-based IIDs 3. Weaknesses in IEEE-identifier-based IIDs
There are a number of privacy and security implications that exist There are a number of privacy and security implications that exist
for hosts that use IEEE-identifier-based IIDs. This section for hosts that use IEEE-identifier-based IIDs. This section
discusses four generic attack types: correlation of activities over discusses four generic attack types: correlation of activities over
time, location tracking, device-specific vulnerability exploitation, time, location tracking, address scanning, and device-specific
and address scanning. The first three of these rely on the attacker vulnerability exploitation. The first three of these rely on the
first gaining knowledge of the target host's IID. This can be attacker first gaining knowledge of the target host's IID. This can
achieved by different types of attackers: the operator of a server to be achieved by a number of different attackers: the operator of a
which the host connects, such as a web server or a peer-to-peer server to which the host connects, such as a web server or a peer-to-
server; an entity that connects to the same network as the target peer server; an entity that connects to the same network as the
(such as a conference network or any public network); or an entity target (such as a conference network or any public network); or an
that is on-path to the destinations with which the host communicates, entity that is on-path to the destinations with which the host
such as a network operator. communicates, such as a network operator.
3.1. Correlation of activities over time 3.1. Correlation of activities over time
As with other identifiers, an IPv6 address can be used to correlate As with other identifiers, an IPv6 address can be used to correlate
the activities of a host for at least as long as the lifetime of the the activities of a host for at least as long as the lifetime of the
address. The correlation made possible by IEEE-identifier-based IIDs address. The correlation made possible by IEEE-identifier-based IIDs
is of particular concern because MAC addresses are much more is of particular concern because MAC addresses are much more
permanent than, say, DHCP leases. MAC addresses tend to last roughly permanent than, say, DHCP leases. MAC addresses tend to last roughly
the lifetime of a device's network interface, allowing correlation on the lifetime of a device's network interface, allowing correlation on
the order of years, compared to days for DHCP. the order of years, compared to days for DHCP.
skipping to change at page 5, line 48 skipping to change at page 5, line 44
than these other identifiers, IIDs generated in other ways may have than these other identifiers, IIDs generated in other ways may have
shorter or longer lifetimes than these identifiers depending on how shorter or longer lifetimes than these identifiers depending on how
they are generated. Therefore, the extent to which a host's they are generated. Therefore, the extent to which a host's
activities can be correlated depends on whether the host uses activities can be correlated depends on whether the host uses
multiple identifiers together and the lifetimes of all of those multiple identifiers together and the lifetimes of all of those
identifiers. Frequently refreshing an IPv6 address may not mitigate identifiers. Frequently refreshing an IPv6 address may not mitigate
correlation if an attacker has access to other longer lived correlation if an attacker has access to other longer lived
identifiers for a particular host. This is an important caveat to identifiers for a particular host. This is an important caveat to
keep in mind throughout the discussion of correlation in this keep in mind throughout the discussion of correlation in this
document. For further discussion of correlation, see Section 5.2.1 document. For further discussion of correlation, see Section 5.2.1
of [I-D.iab-privacy-considerations]. of [RFC6973].
As noted in [RFC4941], in some cases correlation is just as feasible As noted in [RFC4941], in some cases correlation is just as feasible
for a host using an IPv4 address as for a host using an IEEE for a host using an IPv4 address as for a host using an IEEE
identifier to generate its IID in its IPv6 address. Hosts that use identifier to generate its IID in its IPv6 address. Hosts that use
static IPv4 addressing or who are consistently allocated the same static IPv4 addressing or who are consistently allocated the same
address via DHCPv4 can be tracked as described above. However, the address via DHCPv4 can be tracked as described above. However, the
widespread use of both NAT and DHCPv4 implementations that assign the widespread use of both NAT and DHCPv4 implementations that assign the
same host a different address upon lease expiration mitigates this same host a different address upon lease expiration mitigates this
threat in the IPv4 case as compared to the IEEE identifier case in threat in the IPv4 case as compared to the IEEE identifier case in
IPv6. IPv6.
skipping to change at page 6, line 29 skipping to change at page 6, line 24
host, a server that receives connections from the same host over time host, a server that receives connections from the same host over time
would be able to determine the host's movements as its prefix would be able to determine the host's movements as its prefix
changes. changes.
Active attacks are also possible. An attacker that first learns the Active attacks are also possible. An attacker that first learns the
host's interface identifier by being connected to the same network host's interface identifier by being connected to the same network
segment, running a server that the host connects to, or being on-path segment, running a server that the host connects to, or being on-path
to the host's communications could subsequently probe other networks to the host's communications could subsequently probe other networks
for the presence of the same interface identifier by sending a probe for the presence of the same interface identifier by sending a probe
packet (ICMPv6 Echo Request, or any other probe packet). Even if the packet (ICMPv6 Echo Request, or any other probe packet). Even if the
host does not respond (e.g. as a result of a personal firewall), the host does not respond, the first hop router will usually respond with
first hop router will usually respond with an ICMP Address an ICMP Address Unreachable when the host is not present, and be
Unreachable when the host is not present, and be silent when the host silent when the host is present.
is present.
Location tracking based on IP address is generally not possible in Location tracking based on IP address is generally not possible in
IPv4 since hosts get assigned wholly new addresses when they change IPv4 since hosts get assigned wholly new addresses when they change
networks. networks.
3.3. Device-specific vulnerability exploitation 3.3. Address scanning
IPv6 addresses that embed IEEE identifiers leak information about the
device (Network Interface Card vendor, or even Operating System and/
or software type), which could be leveraged by an attacker with
knowledge of device/software-specific vulnerabilities to quickly find
possible targets. Attackers can exploit vulnerabilities in hosts
whose IIDs they have previously obtained, or scan an address space to
find potential targets.
3.4. Address scanning
The structure of IEEE-based identifiers used for address generation The structure of IEEE-based identifiers used for address generation
can be leveraged by an attacker to reduce the target search space can be leveraged by an attacker to reduce the target search space
[I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally
Unique Identifier (OUI) of MAC addresses, together with the fixed Unique Identifier (OUI) of MAC addresses, together with the fixed
value (0xff, 0xfe) used to form a Modified EUI-64 Interface value (0xff, 0xfe) used to form a Modified EUI-64 Interface
Identifier, greatly help to reduce the search space, making it easier Identifier, greatly help to reduce the search space, making it easier
for an attacker to scan for individual addresses using widely-known for an attacker to scan for individual addresses using widely-known
popular OUIs. This erases much of the protection against address popular OUIs. This erases much of the protection against address
scanning that the larger IPv6 address space was supposed to provide scanning that the larger IPv6 address space was supposed to provide
as compared to IPv4. as compared to IPv4.
3.4. Device-specific vulnerability exploitation
IPv6 addresses that embed IEEE identifiers leak information about the
device (Network Interface Card vendor, or even Operating System and/
or software type), which could be leveraged by an attacker with
knowledge of device/software-specific vulnerabilities to quickly find
possible targets. Attackers can exploit vulnerabilities in hosts
whose IIDs they have previously obtained, or scan an address space to
find potential targets.
4. Privacy and security properties of address generation mechanisms 4. Privacy and security properties of address generation mechanisms
Analysis of the extent to which a particular host is protected Analysis of the extent to which a particular host is protected
against the threats described in Section 3 depends on how each of a against the threats described in Section 3 depends on how each of a
host's addresses is generated and used. In some scenarios, a host host's addresses is generated and used. In some scenarios, a host
configures a single global address and uses it for all configures a single global address and uses it for all
communications. In other scenarios, a host configures multiple communications. In other scenarios, a host configures multiple
addresses using different mechanisms and may use any or all of them. addresses using different mechanisms and may use any or all of them.
[RFC3041] (later obsoleted by [RFC4941]) sought to address some of [RFC3041] (later obsoleted by [RFC4941]) sought to address some of
skipping to change at page 8, line 29 skipping to change at page 8, line 23
This section compares the privacy and security properties of a This section compares the privacy and security properties of a
variety of IID generation mechanisms and their possible usage variety of IID generation mechanisms and their possible usage
scenarios, including scenarios in which a single mechanism is used to scenarios, including scenarios in which a single mechanism is used to
generate all of a host's IIDs and those in which temporary addresses generate all of a host's IIDs and those in which temporary addresses
are used together with addresses generated using a different IID are used together with addresses generated using a different IID
generation mechanism. The analysis of the exposure of each IID type generation mechanism. The analysis of the exposure of each IID type
to correlation assumes that IPv6 prefixes are shared by a reasonably to correlation assumes that IPv6 prefixes are shared by a reasonably
large number of nodes. As [RFC4941] notes, if a very small number of large number of nodes. As [RFC4941] notes, if a very small number of
nodes (say, only one) use a particular prefix for an extended period nodes (say, only one) use a particular prefix for an extended period
of time, the prefix itself can be used to correlate the host's of time, the prefix itself can be used to correlate the host's
activities regardless of how the IID is generated. activities regardless of how the IID is generated. For example,
[RFC3314] recommends that prefixes be uniquely assigned to mobile
handsets where IPv6 is used within GPRS. In cases where this advice
is followed and prefixes persist for extended periods of time (or get
reassigned to the same handsets whenever those handsets reconnect to
the same network router), hosts' activities could be correlatable for
longer periods than the analysis below would suggest.
The table below provides a summary of the whole analysis. The table below provides a summary of the whole analysis.
+--------------+-------------+------------+------------+------------+ +--------------+-------------+----------+-------------+-------------+
| Mechanism(s) | Correlation | Location | Address | Device | | Mechanism(s) | Correlation | Location | Address | Device |
| | | tracking | scanning | exploits | | | | tracking | scanning | exploits |
+--------------+-------------+------------+------------+------------+ +--------------+-------------+----------+-------------+-------------+
| IEEE | Possible | Possible | Possible | Possible | | IEEE | For device | For | Possible | Possible |
| identifier | (for device | (for | | | | identifier | lifetime | device | | |
| | lifetime) | device | | | | | | lifetime | | |
| | | lifetime) | | | | | | | | |
| | | | | | | Static | For address | For | Depends on | Depends on |
| Static | Possible | Depends on | Depends on | Depends on | | manual | lifetime | address | generation | generation |
| manual | (for | generation | generation | generation | | | | lifetime | mechanism | mechanism |
| | address | mechanism | mechanism | mechanism | | | | | | |
| | lifetime) | | | | | Constant, | For address | For | No | No |
| | | | | | | semantically | lifetime | address | | |
| Constant, | Possible | Possible | No | No | | opaque | | lifetime | | |
| semantically | (for OS | (for OS | | | | | | | | |
| opaque | lifetime) | lifetime) | | | | CGA | For | No | No | No |
| | | | | | | | lifetime of | | | |
| CGA | Typically | Typically | No | No | | | (public key | | | |
| | possible | possible | | | | | + modifier | | | |
| | (for public | (for | | | | | block) | | | |
| | key | public key | | | | | | | | |
| | lifetime) | lifetime) | | | | Stable, | Within | No | No | No |
| | | | | | | semantically | single | | | |
| Stable, | Possible | No | No | No | | opaque | network | | | |
| semantically | (for OS | | | | | | | | | |
| opaque | lifetime) | | | | | Temporary | For temp | No | No | No |
| | | | | | | | address | | | |
| Temporary | Only | No | No | No | | | lifetime | | | |
| | possible | | | | | | | | | |
| | for temp | | | | | DHCPv6 | For lease | No | Depends on | No |
| | address | | | | | | lifetime | | generation | |
| | lifetime | | | | | | | | mechanism | |
| | | | | | +--------------+-------------+----------+-------------+-------------+
| DHCPv6 | Possible | No | Depends on | No |
| | for lease | | DHCPv6 | |
| | lifetime | | server imp | |
| | (typically | | lementatio | |
| | hours) | | n | |
+--------------+-------------+------------+------------+------------+
Table 1: Privacy and security properties of IID generation mechanisms Table 1: Privacy and security properties of IID generation mechanisms
4.1. IEEE-identifier-based IIDs 4.1. IEEE-identifier-based IIDs
As discussed in Section 3, addresses that use IIDs based on IEEE As discussed in Section 3, addresses that use IIDs based on IEEE
identifiers are vulnerable to all four threats. They allow identifiers are vulnerable to all four threats. They allow
correlation and location tracking for the lifetime of the device correlation and location tracking for the lifetime of the device
since IEEE identifiers last that long and their structure makes since IEEE identifiers last that long and their structure makes
address scanning and device exploits possible. address scanning and device exploits possible.
skipping to change at page 10, line 7 skipping to change at page 10, line 20
The extent to which location tracking can be successfully performed The extent to which location tracking can be successfully performed
depends, to a some extent, on the uniqueness of the employed depends, to a some extent, on the uniqueness of the employed
Interface ID. For example, one would expect "low byte" Interface IDs Interface ID. For example, one would expect "low byte" Interface IDs
to be more widely reused than, for example, Interface IDs where the to be more widely reused than, for example, Interface IDs where the
whole 64-bits follow some pattern that is unique to a specific whole 64-bits follow some pattern that is unique to a specific
organization. Widely reused Interface IDs will typically lead to organization. Widely reused Interface IDs will typically lead to
false positives when performing location tracking. false positives when performing location tracking.
Whether manually configured addresses are vulnerable to address Whether manually configured addresses are vulnerable to address
scanning and device exploits depends on the specifics of how the IIDs scanning and device exploits depends on the specifics of how the IIDs
are generated. For example, low-byte and IPv4-embedded IIDs will are generated.
greatly reduce the search space when performing address scans.
4.3. Constant, semantically opaque IIDs 4.3. Constant, semantically opaque IIDs
Although a mechanism to generate a constant, semantically opaque IID Although a mechanism to generate a constant, semantically opaque IID
has not been standardized, it has been in wide use for many years on has not been standardized, it has been in wide use for many years on
at least one platform (Windows). Windows uses the [RFC4941] random at least one platform (Windows). Windows uses the [RFC4941] random
generation mechanism in lieu of generating an IEEE-identifier-based generation mechanism in lieu of generating an IEEE-identifier-based
IID. This mitigates the device-specific exploitation and address IID. This mitigates the device-specific exploitation and address
scanning attacks, but still allows correlation and location tracking scanning attacks, but still allows correlation and location tracking
because the IID is constant across networks and time. because the IID is constant across networks and time.
4.4. Cryptographically generated IIDs 4.4. Cryptographically generated IIDs
Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of
the host's public key to an IPv6 address in the SEcure Neighbor the host's public key to an IPv6 address in the SEcure Neighbor
Discovery (SEND) [RFC3971] protocol. CGAs may be regenerated for Discovery (SEND) [RFC3971] protocol. CGAs may be regenerated for
each subnet prefix, but this is not required given that they are each subnet prefix, but this is not required given that they are
computationally expensive to generate. A host using a CGA can be computationally expensive to generate. A host using a CGA can be
correlated for as long as the life of the public key. If the host correlated for as long as the lifetime of the combination of the
does not generate a new public key when it moves to a different public key and the chosen modifier block, since it is possible to
network, its location can also be tracked. CGAs do not allow device- rotate modifier blocks without generating new public keys. Because
the cryptographic hash of the host's public key uses the subnet
prefix as an input, even if the host does not generate a new public
key or modifier block when it moves to a different network, its
location cannot be tracked via the IID. CGAs do not allow device-
specific exploitation or address scanning attacks. specific exploitation or address scanning attacks.
4.5. Stable, semantically opaque IIDs 4.5. Stable, semantically opaque IIDs
[I-D.ietf-6man-stable-privacy-addresses] specifies a mechanism that [I-D.ietf-6man-stable-privacy-addresses] specifies a mechanism that
generates a unique random IID for each network. A host that stays generates a unique random IID for each network. A host that stays
connected to the same network could therefore be tracked at length, connected to the same network could therefore be tracked at length,
whereas a mobile host's activities could only be correlated for the whereas a mobile host's activities could only be correlated for the
duration of each network connection. Location tracking is not duration of each network connection. Location tracking is not
possible with these addresses. They also do not allow device- possible with these addresses. They also do not allow device-
skipping to change at page 11, line 10 skipping to change at page 11, line 26
temporary addresses makes the host vulnerable to the same attacks as temporary addresses makes the host vulnerable to the same attacks as
if temporary addresses were not in use, although the viability of if temporary addresses were not in use, although the viability of
some of them depends on how the host uses each address. An attacker some of them depends on how the host uses each address. An attacker
can correlate all of the host's activities for which it uses its can correlate all of the host's activities for which it uses its
IEEE-identifier-based IID. Once an attacker has obtained the IEEE- IEEE-identifier-based IID. Once an attacker has obtained the IEEE-
identifier-based IID, location tracking becomes possible on other identifier-based IID, location tracking becomes possible on other
networks even if the host only makes use of temporary addresses on networks even if the host only makes use of temporary addresses on
those other networks; the attacker can actively probe the other those other networks; the attacker can actively probe the other
networks for the presence of the IEEE-identifier-based IID. Device- networks for the presence of the IEEE-identifier-based IID. Device-
specific vulnerabilities can still be exploited. Address scanning is specific vulnerabilities can still be exploited. Address scanning is
also still possible because the IEEE-identifier-based address will also still possible because the IEEE-identifier-based address can be
result in predictable patterns. probed.
If the host instead generates a constant semantically-opaque IID to If the host instead generates a constant, semantically opaque IID to
use in a stable address for server-like connections together with use in a stable address for server-like connections together with
temporary addresses for outbound connections (as is the default in temporary addresses for outbound connections (as is the default in
Windows), it sees some improvements over the previous scenario. The Windows), it sees some improvements over the previous scenario. The
address scanning and device-specific exploitation attacks are no address scanning and device-specific exploitation attacks are no
longer possible because the OUI is no longer embedded in any of the longer possible because the OUI is no longer embedded in any of the
host's addresses. However, correlation of some activities across host's addresses. However, correlation of some activities across
time is still possible because the semantically opaque IID is time and location tracking are both still possible because the
constant. And once an attacker has obtained the host's semantically semantically opaque IID is constant. And once an attacker has
opaque IID, location tracking is possible on any network by probing obtained the host's semantically opaque IID, location tracking is
for that IID, even if the host only uses temporary addresses on those possible on any network by probing for that IID, even if the host
networks. only uses temporary addresses on those networks. However, if the
host generates but never uses a constant, semantically opaque IID, it
mitigates all four threats.
When used together with temporary addresses, the stable (per- When used together with temporary addresses, the stable, semantically
network), semantically opaque IID generation mechanism opaque IID generation mechanism
[I-D.ietf-6man-stable-privacy-addresses] improves upon the previous [I-D.ietf-6man-stable-privacy-addresses] improves upon the previous
scenario by eliminating the possibility for location tracking (since scenario by limiting the potential for correlation to the lifetime of
a different IID is generated for each subnet prefix). Correlation of the stable address (which may still be lengthy for hosts that are not
node activities within the same network will be typically possible mobile) and by eliminating the possibility for location tracking
for the lifetime of the stable address (which may still be lengthy (since a different IID is generated for each subnet prefix). As in
for hosts that are not mobile). the previous scenario, a host that configures but does not use a
stable, semantically opaque address mitigates all four threats.
4.7. DHCPv6 generation of IIDs 4.7. DHCPv6 generation of IIDs
The security/privacy implications of DHCPv6-based addresses will The security/privacy implications of DHCPv6-based addresses will
typically depend on the specific DHCPv6 server software being typically depend on the specific DHCPv6 server software being
employed. For example, some DHCPv6-server implementations lease low- employed. We note that recent releases of most popular DHCPv6 server
byte addresses, while others randomly select the IPv6 addresses they software typically lease random addresses with a similar lease time
lease from the entire IPv6 address space they manage. Thus, the as that of IPv4. Thus, these addresses can be considered to be
security/privacy implications of DHCPv6-addresses will essentially be "stable, semantically opaque."
those of the policy with which the leased addresses are selected.
On the other hand, some DHCPv6 software leases sequential addresses
(typically low-byte addresses). These addresses can be considered to
be stable addresses. The drawback of this address generation scheme
compared to "stable, semantically opaque" addresses is that, since
they follow specific patterns, they enable IPv6 address scans.
4.8. Transition/co-existence technologies 4.8. Transition/co-existence technologies
Addresses specified based on transition/co-existence technologies Addresses specified based on transition/co-existence technologies
that embed an IPv4 address within an IPv6 address are not included in that embed an IPv4 address within an IPv6 address are not included in
Table 1 because their privacy and security properties are inherited Table 1 because their privacy and security properties are inherited
from the embedded address. For example, Teredo [RFC4380] specifies a from the embedded address. For example, Teredo [RFC4380] specifies a
means to generate an IPv6 address from the underlying IPv4 address means to generate an IPv6 address from the underlying IPv4 address
and port, leaving many other bits set to zero. This makes it and port, leaving many other bits set to zero. This makes it
relatively easy for an attacker to scan for IPv6 addresses by relatively easy for an attacker to scan for IPv6 addresses by
skipping to change at page 13, line 11 skipping to change at page 13, line 36
This whole document concerns the privacy and security properties of This whole document concerns the privacy and security properties of
different IPv6 address generation mechanisms. different IPv6 address generation mechanisms.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Bernard Aboba and Rich Draves. The authors would like to thank Bernard Aboba, Rich Draves, and James
Woodyatt.
9. Informative References 9. Informative References
[Broersma] [Broersma]
Broersma, R., "IPv6 Everywhere: Living with a Fully Broersma, R., "IPv6 Everywhere: Living with a Fully
IPv6-enabled environment", Australian IPv6 Summit 2010, IPv6-enabled environment", Australian IPv6 Summit 2010,
Melbourne, VIC Australia, October 2010, October 2010, Melbourne, VIC Australia, October 2010, October 2010,
<http://www.ipv6.org.au/10ipv6summit/talks/ <http://www.ipv6.org.au/10ipv6summit/talks/
Ron_Broersma.pdf>. Ron_Broersma.pdf>.
[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.
[I-D.iab-privacy-considerations]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", draft-iab-privacy-
considerations-09 (work in progress), May 2013.
[I-D.ietf-6man-stable-privacy-addresses] [I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A Method for Generating Semantically Opaque Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", draft-ietf-6man-stable- Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
privacy-addresses-14 (work in progress), October 2013. privacy-addresses-17 (work in progress), January 2014.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-03 (work in
progress), July 2013. progress), January 2014.
[KAME-CGA] [KAME-CGA]
KAME, "The KAME IPR policy and concerns of some KAME, "The KAME IPR policy and concerns of some
technologies which have IPR claims", 2005. technologies which have IPR claims", 2005.
[Microsoft] [Microsoft]
Microsoft, "IPv6 interface identifiers", 2013. Microsoft, "IPv6 interface identifiers", 2013.
[Panopticlick] [Panopticlick]
Electronic Frontier Foundation, "Panopticlick", 2011. Electronic Frontier Foundation, "Panopticlick", 2011.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996. Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", RFC
3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
skipping to change at page 15, line 5 skipping to change at page 15, line 29
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
Security Updates", RFC 5991, September 2010. Security Updates", RFC 5991, September 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013.
Authors' Addresses Authors' Addresses
Alissa Cooper Alissa Cooper
CDT Cisco
1634 Eye St. NW, Suite 1100 707 Tasman Drive
Washington, DC 20006 Milpitas, CA 95035
US US
Phone: +1-202-637-9800 Phone: +1-408-902-3950
Email: acooper@cdt.org Email: alcoop@cisco.com
URI: http://www.cdt.org/ URI: https://www.cisco.com/
Fernando Gont Fernando Gont
Huawei Technologies Huawei Technologies
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
 End of changes. 38 change blocks. 
138 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/