--- 1/draft-ietf-6man-ipv6-address-generation-privacy-05.txt 2015-06-25 18:14:56.146462074 -0700 +++ 2/draft-ietf-6man-ipv6-address-generation-privacy-06.txt 2015-06-25 18:14:56.182462939 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Cooper Internet-Draft Cisco Intended status: Informational F. Gont -Expires: October 29, 2015 Huawei Technologies +Expires: December 27, 2015 Huawei Technologies D. Thaler Microsoft - April 27, 2015 + June 25, 2015 Privacy Considerations for IPv6 Address Generation Mechanisms - draft-ietf-6man-ipv6-address-generation-privacy-05.txt + draft-ietf-6man-ipv6-address-generation-privacy-06.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,21 +27,21 @@ 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 October 29, 2015. + This Internet-Draft will expire on December 27, 2015. 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 @@ -103,43 +103,43 @@ * IPv4 address * Service port * Wordy * Low-byte o Stateless Address Auto-Cofiguration (SLAAC) - * IEEE 802 48-bit MAC or IEEE EUI-64 identifier - [RFC1972][RFC2464] + * IEEE 802 48-bit MAC or IEEE EUI-64 identifier [RFC2464] * Cryptographically generated [RFC3972] * Temporary (also known as "privacy addresses") [RFC4941] * 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] - Deriving the IID from a globally unique IEEE identifier [RFC1971] was - one of the earliest mechanisms developed. 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 + 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. 2. Terminology This section clarifies the terminology used throughout this document. Public address: @@ -178,24 +178,24 @@ [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 can - be achieved by a number of different attackers: the operator of a - server to which the host connects, such as a web server or a peer-to- - peer server; an entity that connects to the same IPv6 link as the + attacker first gaining knowledge of the target host's IID. 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. 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 @@ -610,20 +610,23 @@ [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. + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + [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. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. @@ -640,30 +643,30 @@ [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-02 (work in progress), - April 2015. + 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-06 (work in - progress), February 2015. + Networks", draft-ietf-opsec-ipv6-host-scanning-07 (work in + progress), April 2015. [KAME-CGA] KAME, "The KAME IPR policy and concerns of some technologies which have IPR claims", 2005, . [Microsoft] Microsoft, "IPv6 interface identifiers", 2013, .