draft-ietf-6man-ipv6-address-generation-privacy-04.txt   draft-ietf-6man-ipv6-address-generation-privacy-05.txt 
Network Working Group A. Cooper Network Working Group A. Cooper
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational F. Gont Intended status: Informational F. Gont
Expires: August 27, 2015 Huawei Technologies Expires: October 29, 2015 Huawei Technologies
D. Thaler D. Thaler
Microsoft Microsoft
February 23, 2015 April 27, 2015
Privacy Considerations for IPv6 Address Generation Mechanisms Privacy Considerations for IPv6 Address Generation Mechanisms
draft-ietf-6man-ipv6-address-generation-privacy-04.txt draft-ietf-6man-ipv6-address-generation-privacy-05.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 August 27, 2015. This Internet-Draft will expire on October 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. Address scanning . . . . . . . . . . . . . . . . . . . . 6 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6
3.4. Device-specific vulnerability exploitation . . . . . . . 7 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 . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12
4.8. Transition/co-existence technologies . . . . . . . . . . 12 4.8. Transition/co-existence technologies . . . . . . . . . . 12
5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 13
5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 12 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13
5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 In addition to static address assignment and DHCP, stateless
autoconfiguration was developed as a less intensive, fate-shared autoconfiguration was developed as a less intensive, fate-shared
means of performing address assignment. 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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
[Microsoft] [Microsoft]
* Stable, semantically opaque [RFC7217] * Stable, semantically opaque [RFC7217]
o DHCPv6-based [RFC3315] o DHCPv6-based [RFC3315]
o Specified by transition/co-existence technologies o Specified by transition/co-existence technologies
* 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 [RFC1971] 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 IIDs derived from IEEE identifiers security issues related to the IIDs derived from IEEE identifiers
were discovered after their standardization, and many of the were discovered after their standardization, and many of the
mechanisms developed later aimed to mitigate some or all of these 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.
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 IPv6 link.
Note that [RFC4941] refers to these as "public" addresses, but Note that [RFC4941] refers to these as "public" addresses, but
"stable" is used here for reasons explained in Section 4. "stable" is used here for reasons explained in Section 4.
Temporary address: Temporary address:
An address that varies over time within the same network. An address that varies over time within the same IPv6 link.
Constant IID: Constant IID:
An IPv6 Interface Identifier that is globally stable. That is, An IPv6 Interface Identifier that is globally stable. That is,
the Interface ID will remain constant even if the node moves from the Interface ID will remain constant even if the node moves from
one network to another. one IPv6 link to another.
Stable IID: Stable IID:
An IPv6 Interface Identifier that is stable within some specified An IPv6 Interface Identifier that is stable within some specified
context. For example, an Interface ID can be globally stable context. For example, an Interface ID can be globally stable
(constant), or could be stable per network (meaning that the (constant), or could be stable per IPv6 link (meaning that the
Interface ID will remain unchanged as long as a the node stays on Interface ID will remain unchanged as long as a the node stays on
the same network, but may change when the node moves from one the same IPv6 link, but may change when the node moves from one
network to another). IPv6 link to another).
Temporary IID: Temporary IID:
An IPv6 Interface Identifier that varies over time. An IPv6 Interface Identifier that varies over time.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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, address scanning, and device-specific time, location tracking, address scanning, and device-specific
vulnerability exploitation. The first three of these rely on the vulnerability exploitation. The first three of these rely on the
attacker first gaining knowledge of the target host's IID. This can attacker first gaining knowledge of the target host's IID. This can
be achieved by a number of different attackers: the operator of a be achieved by a number of different attackers: the operator of a
server to which the host connects, such as a web server or a peer-to- server to which the host connects, such as a web server or a peer-to-
peer server; an entity that connects to the same network as the peer server; an entity that connects to the same IPv6 link as the
target (such as a conference network or any public network); or an target (such as a conference network or any public network); or an
entity that is on-path to the destinations with which the host entity that is on-path to the destinations with which the host
communicates, 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 since they last roughly for the lifetime of
permanent than, say, DHCP leases. MAC addresses tend to last roughly a device's network interface, allowing correlation on the order of
the lifetime of a device's network interface, allowing correlation on years.
the order of years, compared to days for DHCP.
As [RFC4941] explains, As [RFC4941] explains,
"[t]he use of a non-changing interface identifier to form "[t]he use of a non-changing interface identifier to form
addresses is a specific instance of the more general case where a addresses is a specific instance of the more general case where a
constant identifier is reused over an extended period of time and constant identifier is reused over an extended period of time and
in multiple independent activities. Anytime the same identifier in multiple independent activities. Anytime the same identifier
is used in multiple contexts, it becomes possible for that is used in multiple contexts, it becomes possible for that
identifier to be used to correlate seemingly unrelated activity. identifier to be used to correlate seemingly unrelated activity.
... The use of a constant identifier within an address is of ... The use of a constant identifier within an address is of
skipping to change at page 6, line 14 skipping to change at page 6, line 13
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.
3.2. Location tracking 3.2. Location tracking
Because the IPv6 address structure is divided between a topological Because the IPv6 address structure is divided between a topological
portion and an interface identifier portion, an interface identifier portion and an interface identifier portion, an interface identifier
that remains constant when a host connects to different networks (as that remains constant when a host connects to different IPv6 links
an IEEE-identifier-based IID does) provides a way for observers to (as an IEEE-identifier-based IID does) provides a way for observers
track the movements of that host. In a passive attack on a mobile to track the movements of that host. In a passive attack on a mobile
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 IPv6 link,
segment, running a server that the host connects to, or being on-path running a server that the host connects to, or being on-path to the
to the host's communications could subsequently probe other networks host's communications could subsequently probe other networks for the
for the presence of the same interface identifier by sending a probe presence of the same interface identifier by sending a probe packet
packet (ICMPv6 Echo Request, or any other probe packet). Even if the (ICMPv6 Echo Request, or any other probe packet). Even if the host
host does not respond, the first hop router will usually respond with does not respond, the first hop router will usually respond with an
an ICMP Address Unreachable when the host is not present, and be ICMP Destination Unreachable/Address Unreachable (type 1, code 3)
silent when the host is present. when the host is not present, and be silent when the host 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. Address scanning 3.3. 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 could provide as compared
as compared to IPv4. to IPv4.
3.4. Device-specific vulnerability exploitation 3.4. Device-specific vulnerability exploitation
IPv6 addresses that embed IEEE identifiers leak information about the IPv6 addresses that embed IEEE identifiers leak information about the
device (Network Interface Card vendor, or even Operating System and/ device (Network Interface Card vendor, or even Operating System and/
or software type), which could be leveraged by an attacker with or software type), which could be leveraged by an attacker with
knowledge of device/software-specific vulnerabilities to quickly find knowledge of device/software-specific vulnerabilities to quickly find
possible targets. Attackers can exploit vulnerabilities in hosts possible targets. Attackers can exploit vulnerabilities in hosts
whose IIDs they have previously obtained, or scan an address space to whose IIDs they have previously obtained, or scan an address space to
find potential targets. find potential targets.
skipping to change at page 7, line 32 skipping to change at page 7, line 26
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
the problems described in Section 3 by defining "temporary addresses" the problems described in Section 3 by defining "temporary addresses"
for outbound connections. Temporary addresses are meant to for outbound connections. Temporary addresses are meant to
supplement the other addresses that a device might use, not to supplement the other addresses that a device might use, not to
replace them. They use IIDs that are randomly generated and change replace them. They use IIDs that are randomly generated and change
daily by default. The idea was for temporary addresses to be used daily by default. The idea was for temporary addresses to be used
for outgoing connections (e.g., web browsing) while maintaining the for outgoing connections (e.g., web browsing) while maintaining the
ability to use a stable address when more address stability is ability to use a stable address when more address stability is
desired (e.g., in DNS advertisements). desired (e.g., for IPv6 addresses published in the DNS).
[RFC3484] originally specified that stable addresses be used for [RFC3484] originally specified that stable addresses be used for
outbound connections unless an application explicitly prefers outbound connections unless an application explicitly prefers
temporary addresses. The default preference for stable addresses was temporary addresses. The default preference for stable addresses was
established to avoid applications potentially failing due to the established to avoid applications potentially failing due to the
short lifetime of temporary addresses or the possibility of a reverse short lifetime of temporary addresses or the possibility of a reverse
look-up failure or error. However, [RFC3484] allowed that look-up failure or error. However, [RFC3484] allowed that
"implementations for which privacy considerations outweigh these "implementations for which privacy considerations outweigh these
application compatibility concerns MAY reverse the sense of this application compatibility concerns MAY reverse the sense of this
rule" and instead prefer by default temporary addresses rather than rule" and instead prefer by default temporary addresses rather than
skipping to change at page 9, line 28 skipping to change at page 9, line 28
| semantically | lifetime | address | | | | semantically | lifetime | address | | |
| opaque | | lifetime | | | | opaque | | lifetime | | |
| | | | | | | | | | | |
| CGA | For | No | No | No | | CGA | For | No | No | No |
| | lifetime of | | | | | | lifetime of | | | |
| | (modifier | | | | | | (modifier | | | |
| | block + | | | | | | block + | | | |
| | public key) | | | | | | public key) | | | |
| | | | | | | | | | | |
| Stable, | Within | No | No | No | | Stable, | Within | No | No | No |
| semantically | single | | | | | semantically | single IPv6 | | | |
| opaque | network | | | | | opaque | link | | | |
| | | | | | | | | | | |
| Temporary | For temp | No | No | No | | Temporary | For temp | No | No | No |
| | address | | | | | | address | | | |
| | lifetime | | | | | | lifetime | | | |
| | | | | | | | | | | |
| DHCPv6 | For lease | No | Depends on | No | | DHCPv6 | For lease | No | Depends on | No |
| | lifetime | | generation | | | | lifetime | | generation | |
| | | | mechanism | | | | | | mechanism | |
+--------------+-------------+----------+-------------+-------------+ +--------------+-------------+----------+-------------+-------------+
skipping to change at page 10, line 30 skipping to change at page 10, line 30
are generated. are generated.
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 IPv6 links 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 lifetime of the combination of the correlated for as long as the lifetime of the combination of the
public key and the chosen modifier block, since it is possible to public key and the chosen modifier block, since it is possible to
rotate modifier blocks without generating new public keys. Because rotate modifier blocks without generating new public keys. Because
the cryptographic hash of the host's public key uses the subnet 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 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 key or modifier block when it moves to a different IPv6 link, its
location cannot be tracked via the IID. CGAs do not allow device- 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
[RFC7217] specifies an algorithm that generates, for each network [RFC7217] specifies an algorithm that generates, for each network
interface, a unique random IID per network. The aforementioned interface, a unique random IID per IPv6 link. The aforementioned
algorithm is employed not only for global unicast addresses, but also algorithm is employed not only for global unicast addresses, but also
for unique local unicast addresses and link-local unicast addresses, for unique local unicast addresses and link-local unicast addresses,
since these addresses may leak out via application protocols (e.g., since these addresses may leak out via application protocols (e.g.,
IPv6 addresses embedded in email headers). IPv6 addresses embedded in email headers).
A host that stays connected to the same network could therefore be A host that stays connected to the same IPv6 link could therefore be
tracked at length, whereas a mobile host's activities could only be tracked at length, whereas a mobile host's activities could only be
correlated for the duration of each network connection. Location correlated for the duration of each network connection. Location
tracking is not possible with these addresses. They also do not tracking is not possible with these addresses. They also do not
allow device-specific exploitation or address scanning attacks. allow device-specific exploitation or address scanning attacks.
4.6. Temporary IIDs 4.6. Temporary IIDs
A host that uses only a temporary address mitigates all four threats. A host that uses only a temporary address mitigates all four threats.
Its activities may only be correlated for the lifetime a single Its activities may only be correlated for the lifetime a single
temporary address. temporary address.
A host that configures both an IEEE-identifier-based IID and A host that configures both an IEEE-identifier-based IID and
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 IPv6 links even if the host only makes use of temporary addresses on
those other networks; the attacker can actively probe the other those other IPv6 links; the attacker can actively probe the other
networks for the presence of the IEEE-identifier-based IID. Device- IPv6 links for the presence of the IEEE-identifier-based IID.
specific vulnerabilities can still be exploited. Address scanning is Device-specific vulnerabilities can still be exploited. Address
also still possible because the IEEE-identifier-based address can be scanning is also still possible because the IEEE-identifier-based
probed. address can be 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 and location tracking are both still possible because the time and location tracking are both still possible because the
semantically opaque IID is constant. And once an attacker has semantically opaque IID is constant. And once an attacker has
skipping to change at page 12, line 13 skipping to change at page 12, line 13
scenario by limiting the potential for correlation to the lifetime of scenario by limiting the potential for correlation to the lifetime of
the stable address (which may still be lengthy for hosts that are not the stable address (which may still be lengthy for hosts that are not
mobile) and by eliminating the possibility for location tracking mobile) and by eliminating the possibility for location tracking
(since a different IID is generated for each subnet prefix). As in (since a different IID is generated for each subnet prefix). As in
the previous scenario, a host that configures but does not use a the previous scenario, a host that configures but does not use a
stable, semantically opaque address mitigates all four threats. 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 whether the client requests an IA_NA (Identity
employed. We note that recent releases of most popular DHCPv6 server Association for Non-temporary Addresses) or an IA_TA ( Identity
software typically lease random addresses with a similar lease time Association for Temporary Addresses) [RFC3315] and the specific
as that of IPv4. Thus, these addresses can be considered to be DHCPv6 server software being employed.
"stable, semantically opaque".
DHCPv6 temporary addresses have the same properties as SLAAC
temporary addresses Section 4.6 [RFC4941]. On the other hand, the
properties of DHCPv6 non-temporary addresses typically depend on the
specific DHCPv6 server software being employed. Recent releases of
most popular DHCPv6 server software typically lease random addresses
with a similar lease time as that of IPv4. Thus, these addresses can
be considered to be "stable, semantically opaque".
[I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that
can be employed by DHCP servers to generate "stable, semantically can be employed by DHCPv6 servers to generate "stable, semantically
opaque" addresses. opaque" addresses.
On the other hand, some DHCPv6 software leases sequential addresses On the other hand, some DHCPv6 software leases sequential addresses
(typically low-byte addresses). These addresses can be considered to (typically low-byte addresses). These addresses can be considered to
be stable addresses. The drawback of this address generation scheme be stable addresses. The drawback of this address generation scheme
compared to "stable, semantically opaque" addresses is that, since compared to "stable, semantically opaque" addresses is that, since
they follow specific patterns, they enable IPv6 address scans. they follow specific patterns, they enable IPv6 address scans.
4.8. Transition/co-existence technologies 4.8. Transition/co-existence technologies
skipping to change at page 12, line 48 skipping to change at page 13, line 10
NATs is not randomized). For this reason, popular implementations NATs is not randomized). For this reason, popular implementations
(e.g., Windows), began deviating from the standard by including 12 (e.g., Windows), began deviating from the standard by including 12
random bits in place of zero bits. This modification was later random bits in place of zero bits. This modification was later
standardized in [RFC5991]. standardized in [RFC5991].
5. Miscellaneous Issues with IPv6 addressing 5. Miscellaneous Issues with IPv6 addressing
5.1. Network Operation 5.1. Network Operation
It is generally agreed that IPv6 addresses that vary over time in a It is generally agreed that IPv6 addresses that vary over time in a
specific network tend to increase the complexity of event logging, specific IPv6 link tend to increase the complexity of event logging,
trouble-shooting, enforcement of access controls and quality of trouble-shooting, enforcement of access controls and quality of
service, etc. As a result, some organizations disable the use of service, etc. As a result, some organizations disable the use of
temporary addresses [RFC4941] even at the expense of reduced privacy temporary addresses [RFC4941] even at the expense of reduced privacy
[Broersma]. [Broersma].
5.2. Compliance 5.2. Compliance
Some IPv6 compliance testing suites required (and might still Some IPv6 compliance testing suites required (and might still
require) implementations to support MAC-derived suffixes in order to require) implementations to support IEEE-identifier-based IIDS in
be approved as compliant. This document recommends that compliance order to be approved as compliant. This document recommends that
testing suites be relaxed to allow other forms of address generation compliance testing suites be relaxed to allow other forms of address
that are more amenable to privacy. generation that are more amenable to privacy.
5.3. Intellectual Property Rights (IPRs) 5.3. Intellectual Property Rights (IPRs)
Some IPv6 addressing techniques might be covered by Intellectual Some IPv6 addressing techniques might be covered by Intellectual
Property rights, which might limit their implementation in different Property rights, which might limit their implementation in different
Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on
CGAs. CGAs.
6. Security Considerations 6. Security Considerations
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, Brian Carpenter, Tim The authors would like to thank Bernard Aboba, Brian Carpenter, Tim
Chown, Lorenzo Colitti, Rich Draves, Robert Moskowitz, Erik Nordmark, Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz,
and James Woodyatt for providing valuable comments on earlier Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for
versions of this document. providing valuable comments on earlier versions of this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6
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
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
Stateless Address Autoconfiguration in IPv6", RFC 3041,
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
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.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February Network Address Translations (NATs)", RFC 4380, February
2006. 2006.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[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,
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.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, February 2014.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
skipping to change at page 15, line 20 skipping to change at page 15, line 11
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.ietf-dhc-stable-privacy-addresses] [I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and W. Will, "A Method for Generating Gont, F. and W. Will, "A Method for Generating
Semantically Opaque Interface Identifiers with Dynamic Semantically Opaque Interface Identifiers with Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", draft- Host Configuration Protocol for IPv6 (DHCPv6)", draft-
ietf-dhc-stable-privacy-addresses-01 (work in progress), ietf-dhc-stable-privacy-addresses-02 (work in progress),
February 2015. April 2015.
[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-06 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in
progress), February 2015. progress), February 2015.
[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,
<http://www.kame.net/newsletter/20040525/>. <http://www.kame.net/newsletter/20040525/>.
[Microsoft] [Microsoft]
Microsoft, "IPv6 interface identifiers", 2013, <target='ht Microsoft, "IPv6 interface identifiers", 2013, <target='ht
tp://www.microsoft.com/resources/documentation/windows/xp/ tp://www.microsoft.com/resources/documentation/windows/xp/
all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true>. all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true>.
[Panopticlick] [Panopticlick]
Electronic Frontier Foundation, "Panopticlick", 2011, Electronic Frontier Foundation, "Panopticlick", 2011,
<http://panopticlick.eff.org>. <http://panopticlick.eff.org>.
[RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", RFC
3314, September 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July Considerations for Internet Protocols", RFC 6973, July
2013. 2013.
[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", RFC 7421, January 2015. in IPv6 Addressing", RFC 7421, January 2015.
Authors' Addresses Authors' Addresses
 End of changes. 38 change blocks. 
84 lines changed or deleted 89 lines changed or added

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