--- 1/draft-ietf-6man-ipv6-address-generation-privacy-02.txt 2015-01-15 14:14:53.446836827 -0800 +++ 2/draft-ietf-6man-ipv6-address-generation-privacy-03.txt 2015-01-15 14:14:53.486837825 -0800 @@ -1,106 +1,112 @@ Network Working Group A. Cooper Internet-Draft Cisco Intended status: Informational F. Gont -Expires: April 13, 2015 Huawei Technologies +Expires: July 19, 2015 Huawei Technologies D. Thaler Microsoft - October 10, 2014 + January 15, 2015 Privacy Considerations for IPv6 Address Generation Mechanisms - draft-ietf-6man-ipv6-address-generation-privacy-02.txt + draft-ietf-6man-ipv6-address-generation-privacy-03.txt Abstract This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. -Status of This Memo +Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 13, 2015. + This Internet-Draft will expire on July 19, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4 - 3.1. Correlation of activities over time . . . . . . . . . . . 5 - 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6 - 3.4. Device-specific vulnerability exploitation . . . . . . . 6 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . . 6 + 3.1. Correlation of activities over time . . . . . . . . . . . 6 + 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Device-specific vulnerability exploitation . . . . . . . . 8 4. Privacy and security properties of address generation - mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9 - 4.2. Static, manually configured IIDs . . . . . . . . . . . . 10 - 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10 - 4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10 - 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10 - 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11 - 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12 - 4.8. Transition/co-existence technologies . . . . . . . . . . 12 - 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 - 5.1. Geographic Location . . . . . . . . . . . . . . . . . . . 12 - 5.2. Network Operation . . . . . . . . . . . . . . . . . . . . 12 - 5.3. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.4. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Informative References . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . . 11 + 4.2. Static, manually configured IIDs . . . . . . . . . . . . . 11 + 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . . 11 + 4.4. Cryptographically generated IIDs . . . . . . . . . . . . . 12 + 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . . 12 + 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . . 12 + 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 13 + 4.8. Transition/co-existence technologies . . . . . . . . . . . 13 + 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 15 + 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 15 + 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 15 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction IPv6 was designed to improve upon IPv4 in many respects, and mechanisms for address assignment were one such area for improvement. In addition to static address assignment and DHCP, stateless autoconfiguration was developed as a less intensive, fate-shared means of performing address assignment. With stateless autoconfiguration, routers advertise on-link prefixes and hosts generate their own interface identifiers (IIDs) to complete their - addresses. Over the years, many interface identifier generation - techniques have been defined, both standardized and non-standardized: + addresses. [RFC7136] clarifies that the IID should be treated as an + opaque value, while [RFC7421] provides an analysis of the 64-bit + boundary in IPv6 addressing (e.g. the implications of the IID length + on security and privacy). Over the years, many interface identifier + generation techniques have been defined, both standardized and non- + standardized: o Manual configuration + * IPv4 address * Service port * Wordy * Low-byte o Stateless Address Auto-Cofiguration (SLAAC) @@ -117,23 +123,23 @@ * Stable, semantically opaque [RFC7217] o DHCPv6-based [RFC3315] o Specified by transition/co-existence technologies * IPv4 address and port [RFC4380] Deriving the IID from a globally unique IEEE identifier [RFC2462] was one of the earliest mechanisms developed. A number of privacy and - security issues related to the interface IDs derived from IEEE - identifiers were discovered after their standardization, and many of - the mechanisms developed later aimed to mitigate some or all of these + security issues related to the IIDs derived from IEEE identifiers + were discovered after their standardization, and many of the + mechanisms developed later aimed to mitigate some or all of these weaknesses. This document identifies four types of threats against IEEE-identifier-based IIDs, and discusses how other existing techniques for generating IIDs do or do not mitigate those threats. 2. Terminology This section clarifies the terminology used throughout this document. Public address: An address that has been published in a directory or other public @@ -272,22 +277,22 @@ value (0xff, 0xfe) used to form a Modified EUI-64 Interface Identifier, greatly help to reduce the search space, making it easier for an attacker to scan for individual addresses using widely-known popular OUIs. This erases much of the protection against address scanning that the larger IPv6 address space was supposed to provide as compared to IPv4. 3.4. Device-specific vulnerability exploitation IPv6 addresses that embed IEEE identifiers leak information about the - device (Network Interface Card vendor, or even Operating System and/ - or software type), which could be leveraged by an attacker with + device (Network Interface Card vendor, or even Operating System + and/or software type), which could be leveraged by an attacker with knowledge of device/software-specific vulnerabilities to quickly find possible targets. Attackers can exploit vulnerabilities in hosts whose IIDs they have previously obtained, or scan an address space to find potential targets. 4. Privacy and security properties of address generation mechanisms Analysis of the extent to which a particular host is protected 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 @@ -502,21 +507,24 @@ the previous scenario, a host that configures but does not use a stable, semantically opaque address mitigates all four threats. 4.7. DHCPv6 generation of IIDs The security/privacy implications of DHCPv6-based addresses will typically depend on the specific DHCPv6 server software being employed. We note that 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." + "stable, semantically opaque". + [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that + can be employed by DHCP servers to generate "stable, semantically + opaque" addresses. On the other hand, some DHCPv6 software leases sequential addresses (typically low-byte addresses). These addresses can be considered to be stable addresses. The drawback of this address generation scheme compared to "stable, semantically opaque" addresses is that, since they follow specific patterns, they enable IPv6 address scans. 4.8. Transition/co-existence technologies Addresses specified based on transition/co-existence technologies @@ -527,152 +535,167 @@ and port, leaving many other bits set to zero. This makes it relatively easy for an attacker to scan for IPv6 addresses by guessing the Teredo client's IPv4 address and port (which for many NATs is not randomized). For this reason, popular implementations (e.g., Windows), began deviating from the standard by including 12 random bits in place of zero bits. This modification was later standardized in [RFC5991]. 5. Miscellaneous Issues with IPv6 addressing -5.1. Geographic Location - - Since IPv6 subnets have unique prefixes, they reveal some information - about the location of the subnet, just as IPv4 addresses do. Hiding - this information is one motivation for using NAT in IPv6 (see RFC - 5902 section 2.4). - -5.2. Network Operation +5.1. Network Operation It is generally agreed that IPv6 addresses that vary over time in a specific network tend to increase the complexity of event logging, trouble-shooting, enforcement of access controls and quality of service, etc. As a result, some organizations disable the use of temporary addresses [RFC4941] even at the expense of reduced privacy [Broersma]. -5.3. Compliance +5.2. Compliance Some IPv6 compliance testing suites required (and might still require) implementations to support MAC-derived suffixes in order to be approved as compliant. This document recommends that compliance testing suites be relaxed to allow other forms of address generation that are more amenable to privacy. -5.4. Intellectual Property Rights (IPRs) +5.3. Intellectual Property Rights (IPRs) Some IPv6 addressing techniques might be covered by Intellectual Property rights, which might limit their implementation in different Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on CGAs. 6. Security Considerations This whole document concerns the privacy and security properties of different IPv6 address generation mechanisms. 7. IANA Considerations This document does not require actions by IANA. 8. Acknowledgements - The authors would like to thank Bernard Aboba, Tim Chown, Rich - Draves, Robert Moskowitz, Erik Nordmark, and James Woodyatt for - providing valuable comments on earlier versions of this document. - -9. Informative References - - [Broersma] - Broersma, R., "IPv6 Everywhere: Living with a Fully - IPv6-enabled environment", Australian IPv6 Summit 2010, - Melbourne, VIC Australia, October 2010, October 2010, - . - - [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. - - [I-D.ietf-opsec-ipv6-host-scanning] - Gont, F. and T. Chown, "Network Reconnaissance in IPv6 - Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in - progress), June 2014. - - [KAME-CGA] - KAME, "The KAME IPR policy and concerns of some - technologies which have IPR claims", 2005. + The authors would like to thank Bernard Aboba, Brian Carpenter, Tim + Chown, Lorenzo Colitti, Rich Draves, Robert Moskowitz, Erik Nordmark, + and James Woodyatt for providing valuable comments on earlier + versions of this document. - [Microsoft] - Microsoft, "IPv6 interface identifiers", 2013. +9. References - [Panopticlick] - Electronic Frontier Foundation, "Panopticlick", 2011. +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 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 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. + Generation Partnership Project (3GPP) Standards", + RFC 3314, September 2002. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for 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 Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through - Network Address Translations (NATs)", RFC 4380, February - 2006. + Network Address Translations (NATs)", RFC 4380, + February 2006. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 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, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. - [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., - Morris, J., Hansen, M., and R. Smith, "Privacy - Considerations for Internet Protocols", RFC 6973, July - 2013. + [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 + Interface Identifiers", RFC 7136, February 2014. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014. +9.2. Informative References + + [Broersma] + Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- + enabled environment", Australian IPv6 Summit 2010, + Melbourne, VIC Australia, October 2010, October 2010, . + + [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. + + [I-D.ietf-dhc-stable-privacy-addresses] + Gont, F. and W. Will, "A Method for Generating + Semantically Opaque Interface Identifiers with Dynamic + Host Configuration Protocol for IPv6 (DHCPv6)", + draft-ietf-dhc-stable-privacy-addresses-00 (work in + progress), October 2014. + + [I-D.ietf-opsec-ipv6-host-scanning] + Gont, F. and T. Chown, "Network Reconnaissance in IPv6 + Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in + progress), June 2014. + + [KAME-CGA] + KAME, "The KAME IPR policy and concerns of some + technologies which have IPR claims", 2005, + . + + [Microsoft] + Microsoft, "IPv6 interface identifiers", 2013, . + + [Panopticlick] + Electronic Frontier Foundation, "Panopticlick", 2011, + . + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + July 2013. + + [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, + A., and A. Yourtchenko, "Analysis of the 64-bit Boundary + in IPv6 Addressing", RFC 7421, January 2015. + Authors' Addresses Alissa Cooper Cisco 707 Tasman Drive Milpitas, CA 95035 US Phone: +1-408-902-3950 Email: alcoop@cisco.com