draft-ietf-6man-ipv6-address-generation-privacy-03.txt   draft-ietf-6man-ipv6-address-generation-privacy-04.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: July 19, 2015 Huawei Technologies Expires: August 27, 2015 Huawei Technologies
D. Thaler D. Thaler
Microsoft Microsoft
January 15, 2015 February 23, 2015
Privacy Considerations for IPv6 Address Generation Mechanisms Privacy Considerations for IPv6 Address Generation Mechanisms
draft-ietf-6man-ipv6-address-generation-privacy-03.txt draft-ietf-6man-ipv6-address-generation-privacy-04.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.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 19, 2015. This Internet-Draft will expire on August 27, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . . 6 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4
3.1. Correlation of activities over time . . . . . . . . . . . 6 3.1. Correlation of activities over time . . . . . . . . . . . 5
3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 7 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6
3.3. Address scanning . . . . . . . . . . . . . . . . . . . . . 7 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6
3.4. Device-specific vulnerability exploitation . . . . . . . . 8 3.4. Device-specific vulnerability exploitation . . . . . . . 7
4. Privacy and security properties of address generation 4. Privacy and security properties of address generation
mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 9 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . . 11 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9
4.2. Static, manually configured IIDs . . . . . . . . . . . . . 11 4.2. Static, manually configured IIDs . . . . . . . . . . . . 10
4.3. Constant, semantically opaque IIDs . . . . . . . . . . . . 11 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10
4.4. Cryptographically generated IIDs . . . . . . . . . . . . . 12 4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10
4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . . 12 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10
4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 13 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12
4.8. Transition/co-existence technologies . . . . . . . . . . . 13 4.8. Transition/co-existence technologies . . . . . . . . . . 12
5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 15 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12
5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 15 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 12
5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 15 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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
generate their own interface identifiers (IIDs) to complete their generate their own interface identifiers (IIDs) to complete their
skipping to change at page 6, line 38 skipping to change at page 5, line 25
the order of years, compared to days for DHCP. 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
special concern because addresses are a fundamental requirement of special concern because addresses are a fundamental requirement of
communication and cannot easily be hidden from eavesdroppers and communication and cannot easily be hidden from eavesdroppers and
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
skipping to change at page 8, line 15 skipping to change at page 7, line 8
value (0xff, 0xfe) used to form a Modified EUI-64 Interface value (0xff, 0xfe) used to form a Modified EUI-64 Interface
Identifier, greatly help to reduce the search space, making it easier Identifier, greatly help to reduce the search space, making it easier
for an attacker to scan for individual addresses using widely-known for an attacker to scan for individual addresses using widely-known
popular OUIs. This erases much of the protection against address popular OUIs. This erases much of the protection against address
scanning that the larger IPv6 address space was supposed to provide scanning that the larger IPv6 address space was supposed to provide
as compared to IPv4. as compared to IPv4.
3.4. Device-specific vulnerability exploitation 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 device (Network Interface Card vendor, or even Operating System and/
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.
4. Privacy and security properties of address generation mechanisms 4. Privacy and security properties of address generation mechanisms
Analysis of the extent to which a particular host is protected Analysis of the extent to which a particular host is protected
against the threats described in Section 3 depends on how each of a against the threats described in Section 3 depends on how each of a
host's addresses is generated and used. In some scenarios, a host host's addresses is generated and used. In some scenarios, a host
skipping to change at page 12, line 24 skipping to change at page 10, line 50
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 network, 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 a mechanism that generates a unique random IID [RFC7217] specifies an algorithm that generates, for each network
for each network. A host that stays connected to the same network interface, a unique random IID per network. The aforementioned
could therefore be tracked at length, whereas a mobile host's algorithm is employed not only for global unicast addresses, but also
activities could only be correlated for the duration of each network for unique local unicast addresses and link-local unicast addresses,
connection. Location tracking is not possible with these addresses. since these addresses may leak out via application protocols (e.g.,
They also do not allow device-specific exploitation or address IPv6 addresses embedded in email headers).
scanning attacks.
A host that stays connected to the same network could therefore be
tracked at length, whereas a mobile host's activities could only be
correlated for the duration of each network connection. Location
tracking is not possible with these addresses. They also do not
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
skipping to change at page 19, line 26 skipping to change at page 14, line 13
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", Generation Partnership Project (3GPP) Standards", RFC
RFC 3314, September 2002. 3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[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, Network Address Translations (NATs)", RFC 4380, February
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, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
skipping to change at page 20, line 22 skipping to change at page 15, line 8
[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.
9.2. Informative References 9.2. Informative References
[Broersma] [Broersma]
Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- Broersma, R., "IPv6 Everywhere: Living with a Fully
enabled environment", Australian IPv6 Summit 2010, IPv6-enabled environment", Australian IPv6 Summit 2010,
Melbourne, VIC Australia, October 2010, October 2010, <htt Melbourne, VIC Australia, October 2010, October 2010,
p://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf>. <http://www.ipv6.org.au/10ipv6summit/talks/
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)", Host Configuration Protocol for IPv6 (DHCPv6)", draft-
draft-ietf-dhc-stable-privacy-addresses-00 (work in ietf-dhc-stable-privacy-addresses-01 (work in progress),
progress), October 2014. February 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-04 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in
progress), June 2014. 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>.
[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, Considerations for Internet Protocols", RFC 6973, July
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
Alissa Cooper Alissa Cooper
Cisco Cisco
707 Tasman Drive 707 Tasman Drive
 End of changes. 16 change blocks. 
57 lines changed or deleted 63 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/