--- 1/draft-ietf-6man-ipv6-address-generation-privacy-07.txt 2015-09-23 12:15:03.594215135 -0700 +++ 2/draft-ietf-6man-ipv6-address-generation-privacy-08.txt 2015-09-23 12:15:03.634216103 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Cooper Internet-Draft Cisco Intended status: Informational F. Gont -Expires: December 28, 2015 Huawei Technologies +Expires: March 26, 2016 Huawei Technologies D. Thaler Microsoft - June 26, 2015 + September 23, 2015 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 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. @@ -27,67 +27,67 @@ 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 December 28, 2015. + This Internet-Draft will expire on March 26, 2016. Copyright Notice 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 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 + 3.4. Device-specific vulnerability exploitation . . . . . . . 7 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 . . . . . . . . . . 13 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.2. Informative References . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 @@ -118,21 +118,26 @@ * Constant, semantically opaque (also known as random) [Microsoft] * Stable, semantically opaque [RFC7217] o DHCPv6-based [RFC3315] 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] [RFC4862] was one of the earliest mechanisms developed (and originally specified in [RFC1971] and [RFC1972]). A number of privacy and 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. @@ -135,70 +140,70 @@ 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 - location, such as the DNS, a SIP proxy, an application-specific - DHT, or a publicly available URI. A host's public addresses are - intended to be discoverable by third parties. + location, such as the DNS, a SIP proxy [RFC3261], an application- + specific DHT, or a publicly available URI. A host's public + addresses are intended to be discoverable by third parties. Stable address: An address that does not vary over time within the same IPv6 link. Note that [RFC4941] refers to these as "public" addresses, but "stable" is used here for reasons explained in Section 4. Temporary address: An address that varies over time within the same IPv6 link. 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 one IPv6 link to another. 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 (constant), or could be stable per IPv6 link (meaning that the 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 IPv6 link to another). 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE. 3. Weaknesses in IEEE-identifier-based IIDs There are a number of privacy and security implications that exist for hosts that use IEEE-identifier-based IIDs. This section discusses four generic attack types: correlation of activities over time, location tracking, address scanning, and device-specific 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 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 - target (such as a conference network or any public network); or an - entity that is on-path to the destinations with which the host - communicates, such as a network operator. + target (such as a conference network or any public network); a + passive observer of traffic that the host broadcasts; or an entity + that is on-path to the destinations with which the host communicates, + such as a network operator. 3.1. Correlation of activities over time 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 address. The correlation made possible by IEEE-identifier-based IIDs is of particular concern since they last roughly for the lifetime of a device's network interface, allowing correlation on the order of years. @@ -267,22 +272,22 @@ Location tracking based on IP address is generally not possible in IPv4 since hosts get assigned wholly new addresses when they change networks. 3.3. Address scanning The structure of IEEE-based identifiers used for address generation can be leveraged by an attacker to reduce the target search space [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally Unique Identifier (OUI) of MAC addresses, together with the fixed - value (0xff, 0xfe) used to form a Modified EUI-64 Interface - Identifier, greatly help to reduce the search space, making it easier + 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 could 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 @@ -356,21 +361,24 @@ 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 activities regardless of how the IID is generated. For example, [RFC3314] recommends that prefixes be uniquely assigned to mobile handsets where IPv6 is used within GPRS. In cases where this advice is followed and prefixes persist for extended periods of time (or get reassigned to the same handsets whenever those handsets reconnect to the same network router), hosts' activities could be correlatable for longer periods than the analysis below would suggest. - The table below provides a summary of the whole analysis. + The table below provides a summary of the whole analysis. 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 | | | | tracking | scanning | exploits | +--------------+-------------+----------+-------------+-------------+ | IEEE | For device | For | Possible | Possible | | identifier | lifetime | device | | | | | | lifetime | | | | | | | | | | Static | For address | For | Depends on | Depends on | @@ -409,26 +417,26 @@ correlation and location tracking for the lifetime of the device since IEEE identifiers last that long and their structure makes address scanning and device exploits possible. 4.2. Static, manually configured IIDs Because static, manually configured IIDs are stable, both correlation and location tracking are possible for the life of the address. The extent to which location tracking can be successfully performed - depends, to a some extent, on the uniqueness of the employed - Interface ID. For example, one would expect "low byte" Interface IDs - to be more widely reused than, for example, Interface IDs where the - whole 64-bits follow some pattern that is unique to a specific - organization. Widely reused Interface IDs will typically lead to - false positives when performing location tracking. + depends, to a some extent, on the uniqueness of the employed IID. + For example, one would expect "low byte" IIDs to be more widely + reused than, for example, IIDs where the whole 64-bits follow some + pattern that is unique to a specific organization. Widely reused + IIDs will typically lead to false positives when performing location + tracking. Whether manually configured addresses are vulnerable to address scanning and device exploits depends on the specifics of how the IIDs are generated. 4.3. Constant, semantically opaque IIDs Although a mechanism to generate a constant, semantically opaque IID has not been standardized, it has been in wide use for many years on at least one platform (Windows). Windows uses the [RFC4941] random @@ -545,20 +553,32 @@ from the embedded address. For example, Teredo [RFC4380] specifies a means to generate an IPv6 address from the underlying IPv4 address 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]. + 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.1. Network Operation It is generally agreed that IPv6 addresses that vary over time in a specific IPv6 link 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]. @@ -588,62 +608,79 @@ This document does not require actions by IANA. 8. Acknowledgements The authors would like to thank Bernard Aboba, Brian Carpenter, Tim Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz, Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for providing valuable comments on earlier versions of this document. 9. References + 9.1. Normative References [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, + . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", RFC 2464, December 1998. + Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, + . - [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. + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, . - [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure - Neighbor Discovery (SEND)", RFC 3971, March 2005. + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + DOI 10.17487/RFC3971, March 2005, + . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", - RFC 3972, March 2005. + RFC 3972, DOI 10.17487/RFC3972, 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, + DOI 10.17487/RFC4380, February 2006, + . [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, + . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in - IPv6", RFC 4941, September 2007. + IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, + . [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, . - [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 - (IPv6)", RFC 6724, September 2012. + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + . [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, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address - Autoconfiguration (SLAAC)", RFC 7217, April 2014. + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, 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, . @@ -652,65 +689,108 @@ [I-D.ietf-dhc-stable-privacy-addresses] Gont, F. and S. LIU, "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- stable-privacy-addresses-02 (work in progress), April 2015. [I-D.ietf-opsec-ipv6-host-scanning] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 - Networks", draft-ietf-opsec-ipv6-host-scanning-07 (work in - progress), April 2015. + Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in + progress), August 2015. [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, . [RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 1971, August 1996. + Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August + 1996, . [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, + . [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. + DOI 10.17487/RFC3041, January 2001, + . - [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third - Generation Partnership Project (3GPP) Standards", RFC - 3314, September 2002. + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + . + + [RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third + Generation Partnership Project (3GPP) Standards", + RFC 3314, DOI 10.17487/RFC3314, September 2002, + . [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, + . + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, + DOI 10.17487/RFC5214, March 2008, + . + + [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, + . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, - April 2011. + DOI 10.17487/RFC6265, April 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. + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, 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. + [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., + Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit + Boundary in IPv6 Addressing", RFC 7421, + DOI 10.17487/RFC7421, January 2015, + . + + [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, . + + [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, + . + + [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, . Authors' Addresses Alissa Cooper Cisco 707 Tasman Drive Milpitas, CA 95035 US Phone: +1-408-902-3950