draft-ietf-6man-ipv6-address-generation-privacy-07.txt   draft-ietf-6man-ipv6-address-generation-privacy-08.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: December 28, 2015 Huawei Technologies Expires: March 26, 2016 Huawei Technologies
D. Thaler D. Thaler
Microsoft Microsoft
June 26, 2015 September 23, 2015
Privacy Considerations for IPv6 Address Generation Mechanisms Privacy Considerations for IPv6 Address Generation Mechanisms
draft-ietf-6man-ipv6-address-generation-privacy-07.txt draft-ietf-6man-ipv6-address-generation-privacy-08.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 December 28, 2015. This Internet-Draft will expire on March 26, 2016.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . 6 3.4. Device-specific vulnerability exploitation . . . . . . . 7
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 . . . . . . . . . . 13 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 13
5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
generate their own interface identifiers (IIDs) to complete their generate their own interface identifiers (IIDs) to complete their
skipping to change at page 3, line 35 skipping to change at page 3, line 35
* Constant, semantically opaque (also known as random) * Constant, semantically opaque (also known as random)
[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] * Derived from an IPv4 address (e.g., [RFC5214], [RFC6052])
* Derived from an IPv4 address and port set ID (e.g., [RFC7596],
[RFC7597], [RFC7599])
* Derived from an IPv4 address and port (e.g., [RFC4380])
Deriving the IID from a globally unique IEEE identifier [RFC2464] Deriving the IID from a globally unique IEEE identifier [RFC2464]
[RFC4862] was one of the earliest mechanisms developed (and [RFC4862] was one of the earliest mechanisms developed (and
originally specified in [RFC1971] and [RFC1972]). A number of originally specified in [RFC1971] and [RFC1972]). A number of
privacy and security issues related to the IIDs derived from IEEE privacy and security issues related to the IIDs 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.
skipping to change at page 4, line 4 skipping to change at page 4, line 10
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.
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 [RFC3261], an application-
DHT, or a publicly available URI. A host's public addresses are specific DHT, or a publicly available URI. A host's public
intended to be discoverable by third parties. addresses are intended to be discoverable by third parties.
Stable address: Stable address:
An address that does not vary over time within the same IPv6 link. 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 IPv6 link. 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 IPv6 link 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 IPv6 link (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 IPv6 link, but may change when the node moves from one the same IPv6 link, but may change when the node moves from one
IPv6 link 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 attacker first gaining knowledge of the IID of the target host. This
could be achieved by a number of different entities: the operator of could be achieved by a number of different entities: the operator of
a server to which the host connects, such as a web server or a peer- a server to which the host connects, such as a web server or a peer-
to-peer server; an entity that connects to the same IPv6 link as the to-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); a
entity that is on-path to the destinations with which the host passive observer of traffic that the host broadcasts; or an entity
communicates, such as a network operator. that is on-path to the destinations with which the host 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 since they last roughly for the lifetime of is of particular concern since they last roughly for the lifetime of
a device's network interface, allowing correlation on the order of a device's network interface, allowing correlation on the order of
years. years.
skipping to change at page 5, line 37 skipping to change at page 5, line 42
other parties. Even when higher layers encrypt their payloads, other parties. Even when higher layers encrypt their payloads,
addresses in packet headers appear in the clear." addresses in packet headers appear in the clear."
IP addresses are just one example of information that can be used to IP addresses are just one example of information that can be used to
correlate activities over time. DNS names, cookies [RFC6265], correlate activities over time. DNS names, cookies [RFC6265],
browser fingerprints [Panopticlick], and application-layer usernames browser fingerprints [Panopticlick], and application-layer usernames
can all be used to link a host's activities together. Although IEEE- can all be used to link a host's activities together. Although IEEE-
identifier-based IIDs are likely to last at least as long or longer identifier-based IIDs are likely to last at least as long or longer
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 th ey 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 [RFC6973]. 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
skipping to change at page 6, line 40 skipping to change at page 6, line 46
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 could provide as compared scanning that the larger IPv6 address space could provide 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
skipping to change at page 7, line 51 skipping to change at page 8, line 8
concerns were minimal). [RFC6724] then obsoleted [RFC3484] and concerns were minimal). [RFC6724] then obsoleted [RFC3484] and
changed the default to match what implementations actually did. changed the default to match what implementations actually did.
The envisioned relationship in [RFC3484] between stability of an The envisioned relationship in [RFC3484] between stability of an
address and its use in "public" can be misleading when conducting address and its use in "public" can be misleading when conducting
privacy analysis. The stability of an address and the extent to privacy analysis. The stability of an address and the extent to
which it is linkable to some other public identifier are independent which it is linkable to some other public identifier are independent
of one another. For example, there is nothing that prevents a host of one another. For example, there is nothing that prevents a host
from publishing a temporary address in a public place, such as the from publishing a temporary address in a public place, such as the
DNS. Publishing both a stable address and a temporary address in the DNS. Publishing both a stable address and a temporary address in the
DNS or elsewhere where they can be linked together by a public DNS or elsewhere where t hey can be linked together by a public
identifier allows the host's activities when using either address to identifier allows the host's activities when using either address to
be correlated together. be correlated together.
Moreover, because temporary addresses were designed to supplement Moreover, because temporary addresses were designed to supplement
other addresses generated by a host, the host may still configure a other addresses generated by a host, the host may still configure a
more stable address even if it only ever intentionally uses temporary more stable address even if it only ever intentionally uses temporary
addresses (as source addresses) for communication to off-link addresses (as source addresses) for communication to off-link
destinations. An attacker can probe for the stable address even if destinations. An attacker can probe for the stable address even if
it is never used as such a source address or advertised (e.g., in DNS it is never used as such a source address or advertised (e.g., in DNS
or SIP) outside the link. or SIP) outside the link.
skipping to change at page 8, line 29 skipping to change at page 8, line 34
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. For example, activities regardless of how the IID is generated. For example,
[RFC3314] recommends that prefixes be uniquely assigned to mobile [RFC3314] recommends that prefixes be uniquely assigned to mobile
handsets where IPv6 is used within GPRS. In cases where this advice handsets where IPv6 is used within GPRS. In cases where this advice
is followed and prefixes persist for extended periods of time (or get is followed and prefixes persist for extended periods of time (or get
reassigned to the same handsets whenever those handsets reconnect to reassigned to the same handsets whenever those hand sets reconnect to
the same network router), hosts' activities could be correlatable for the same network router), hosts' activities could be correlatable for
longer periods than the analysis below would suggest. 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. A "No"
entry indicates that the attack is prevented from being carried out
on the basis of the IID, but the host may still be vulnerable
depending on how it employs other protocols.
+--------------+-------------+----------+-------------+-------------+ +--------------+-------------+----------+-------------+-------------+
| Mechanism(s) | Correlation | Location | Address | Device | | Mechanism(s) | Correlation | Location | Address | Device |
| | | tracking | scanning | exploits | | | | tracking | scanning | exploits |
+--------------+-------------+----------+-------------+-------------+ +--------------+-------------+----------+-------------+-------------+
| IEEE | For device | For | Possible | Possible | | IEEE | For device | For | Possible | Possible |
| identifier | lifetime | device | | | | identifier | lifetime | device | | |
| | | lifetime | | | | | | lifetime | | |
| | | | | | | | | | | |
| Static | For address | For | Depends on | Depends on | | Static | For address | For | Depends on | Depends on |
skipping to change at page 10, line 11 skipping to change at page 10, line 11
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.
4.2. Static, manually configured IIDs 4.2. Static, manually configured IIDs
Because static, manually configured IIDs are stable, both correlation Because static, manually configured IIDs are stable, both correlation
and location tracking are possible for the life of the address. and location tracking are possible for the life of the address.
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 IID.
Interface ID. For example, one would expect "low byte" Interface IDs For example, one would expect "low byte" IIDs to be more widely
to be more widely reused than, for example, Interface IDs where the reused than, for example, IIDs where the whole 64-bits follow some
whole 64-bits follow some pattern that is unique to a specific pattern that is unique to a specific organization. Widely reused
organization. Widely reused Interface IDs will typically lead to IIDs will typically lead to false positives when performing location
false positives when performing location tracking. 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. 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
skipping to change at page 11, line 41 skipping to change at page 11, line 41
scanning is also still possible because the IEEE-identifier-based scanning is also still possible because the IEEE-identifier-based
address can be 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 s till possible because the
semantically opaque IID is constant. And once an attacker has semantically opaque IID is constant. And once an attacker has
obtained the host's semantically opaque IID, location tracking is obtained the host's semantically opaque IID, location tracking is
possible on any network by probing for that IID, even if the host possible on any network by probing for that IID, even if the host
only uses temporary addresses on those networks. However, if the only uses temporary addresses on those networks. However, if the
host generates but never uses a constant, semantically opaque IID, it host generates but never uses a constant, semantically opaque IID, it
mitigates all four threats. mitigates all four threats.
When used together with temporary addresses, the stable, semantically When used together with temporary addresses, the stable, semantically
opaque IID generation mechanism [RFC7217] improves upon the previous opaque IID generation mechanism [RFC7217] improves upon the previous
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, semant ically 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 whether the client requests an IA_NA (Identity typically depend on whether the client requests an IA_NA (Identity
Association for Non-temporary Addresses) or an IA_TA ( Identity Association for Non-temporary Addresses) or an IA_TA ( Identity
Association for Temporary Addresses) [RFC3315] and the specific Association for Temporary Addresses) [RFC3315] and the specific
DHCPv6 server software being employed. DHCPv6 server software being employed.
DHCPv6 temporary addresses have the same properties as SLAAC DHCPv6 temporary addresses have the same properties as SLAAC
skipping to change at page 13, line 5 skipping to change at page 12, line 50
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
guessing the Teredo client's IPv4 address and port (which for many guessing the Teredo client's IPv4 address and port (which for many
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].
Some other transition technologies (e.g., [RFC5214], [RFC6052])
specify means to generate an IPv6 address from an underlying IPv4
address without a port. Such mechanisms thus make it much easier for
an attacker to conduct an address scan than for mechanisms that
require finding a port number as well.
Finally, still other mechanisms (e.g., [RFC7596], [RFC7597],
[RFC7599]) are somewhere in between, using an IPv4 address and a port
set ID (which for many NATs is not randomized). In general, such
mechanisms are thus typically as easy to scan as in the Teredo
example above without the 12-bit mitigation.
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 IPv6 link 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].
skipping to change at page 14, line 4 skipping to change at page 14, line 13
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 Hinden, Robert Moskowitz, Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz,
Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for
providing valuable comments on earlier 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
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[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,
2006. DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[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, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[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, DOI 10.17487/RFC5991,
September 2010, <http://www.rfc-editor.org/info/rfc5991>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., 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, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[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, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[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,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
9.2. Informative References 9.2. 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,
<https://datatracker.ietf.org/ipr/676/>. <https://datatracker.ietf.org/ipr/676/>.
[I-D.ietf-dhc-stable-privacy-addresses] [I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and S. LIU, "A Method for Generating Semantically Gont, F. and S. LIU, "A Method for Generating Semantically
Opaque Interface Identifiers with Dynamic Host Opaque Interface Identifiers with Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-
stable-privacy-addresses-02 (work in progress), April stable-privacy-addresses-02 (work in progress), April
2015. 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-07 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in
progress), April 2015. progress), August 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 [RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996. Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August
1996, <http://www.rfc-editor.org/info/rfc1971>.
[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,
DOI 10.17487/RFC1972, August 1996,
<http://www.rfc-editor.org/info/rfc1972>.
[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. DOI 10.17487/RFC3041, January 2001,
<http://www.rfc-editor.org/info/rfc3041>.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Generation Partnership Project (3GPP) Standards", RFC A., Peterson, J., Sparks, R., Handley, M., and E.
3314, September 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, DOI 10.17487/RFC3314, September 2002,
<http://www.rfc-editor.org/info/rfc3314>.
[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,
DOI 10.17487/RFC3484, February 2003,
<http://www.rfc-editor.org/info/rfc3484>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008,
<http://www.rfc-editor.org/info/rfc5214>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[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,
2013. DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
in IPv6 Addressing", RFC 7421, January 2015. Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
Authors' Addresses Authors' Addresses
Alissa Cooper Alissa Cooper
Cisco Cisco
707 Tasman Drive 707 Tasman Drive
Milpitas, CA 95035 Milpitas, CA 95035
US US
Phone: +1-408-902-3950 Phone: +1-408-902-3950
 End of changes. 49 change blocks. 
69 lines changed or deleted 149 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/