--- 1/draft-ietf-6man-rfc4941bis-02.txt 2019-09-05 06:13:28.107799648 -0700 +++ 2/draft-ietf-6man-rfc4941bis-03.txt 2019-09-05 06:13:28.155800855 -0700 @@ -1,53 +1,54 @@ IPv6 Maintenance (6man) Working Group F. Gont Internet-Draft SI6 Networks / UTN-FRH Obsoletes: rfc4941 (if approved) S. Krishnan Intended status: Standards Track Ericsson Research -Expires: January 9, 2020 T. Narten +Expires: March 8, 2020 T. Narten IBM Corporation R. Draves Microsoft Research - July 8, 2019 + September 5, 2019 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 - draft-ietf-6man-rfc4941bis-02 + draft-ietf-6man-rfc4941bis-03 Abstract Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. This document describes an extension that causes nodes to generate global scope - addresses from interface identifiers that change over time. Changing - the interface identifier (and the global scope addresses generated - from it) over time makes it more difficult for eavesdroppers and - other information collectors to identify when different addresses - used in different transactions actually correspond to the same node. + addresses with randomized interface identifiers that change over + time. Changing global scope addresses over time makes it more + difficult for eavesdroppers and other information collectors to + identify when different addresses used in different transactions + actually correspond to the same node. This document formally + obsoletes RFC4941. 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 https://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 January 9, 2020. + This Internet-Draft will expire on March 8, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,41 +58,41 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Extended Use of the Same Identifier . . . . . . . . . . . 4 - 2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 5 + 2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 6 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Generation of Randomized Interface Identifiers . . . . . 7 + 3.2. Generation of Randomized Interface Identifiers . . . . . 8 3.2.1. Simple Randomized Interface Identifiers . . . . . . . 8 3.2.2. Hash-based Generation of Randomized Interface - Identifiers . . . . . . . . . . . . . . . . . . . . . 8 + Identifiers . . . . . . . . . . . . . . . . . . . . . 9 3.3. Generating Temporary Addresses . . . . . . . . . . . . . 10 - 3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 11 + 3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.5. Regeneration of Randomized Interface Identifiers . . . . 12 3.6. Deployment Considerations . . . . . . . . . . . . . . . . 13 4. Implications of Changing Interface Identifiers . . . . . . . 14 - 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 14 + 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Stateless address autoconfiguration [RFC4862] defines how an IPv6 node generates addresses without the need for a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server. The security and privacy implications of such addresses have been discussed in great detail in [RFC7721],[RFC7217], and RFC7707. This document specifies an extension for SLAAC to generate temporary addresses, such that the aforementioned issues are mitigated. @@ -147,21 +148,22 @@ interface identifiers that vary over time. Note that an attacker, who is on path, may be able to perform significant correlation based on o The payload contents of the packets on the wire o The characteristics of the packets such as packet size and timing Use of temporary addresses will not prevent such payload-based - correlation. + correlation, which can only be addressed by widespread deployment of + encryption as advocated in [RFC7624]. 2. Background This section discusses the problem in more detail, provides context for evaluating the significance of the concerns in specific environments and makes comparisons with existing practices. 2.1. Extended Use of the Same Identifier The use of a non-changing interface identifier to form addresses is a @@ -211,27 +213,31 @@ The use of a constant identifier within an address is of special concern because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear. Consequently, if a mobile host (e.g., laptop) accessed the network from several different locations, an eavesdropper might be able to track the movement of that mobile host from place to place, even if the upper layer payloads were encrypted. + Using temporary address alone may not be sufficient to prevent all + forms of tracking. It is however quite clear that some usage of + temporary addresses is necessary to improve user privacy. + The security and privacy implications of IPv6 addresses are discussed in detail in [RFC7721], [RFC7707], and [RFC7217]. 2.2. Possible Approaches One way to avoid having a stable non-changing address is to use - DHCPv6 [RFC3315] for obtaining addresses. Section 12 of [RFC3315] + DHCPv6 [RFC8415] for obtaining addresses. Section 12 of [RFC8415] discusses the use of DHCPv6 for the assignment and management of "temporary addresses", which are never renewed and provide the same property of temporary addresses described in this document with regards to the privacy concern. Another approach, compatible with the stateless address autoconfiguration architecture, would be to change the interface identifier portion of an address over time. Changing the interface identifier can make it more difficult to look at the IP addresses in independent transactions and identify which ones actually correspond @@ -255,54 +261,63 @@ On the other hand, a machine that functions only as a client may want to employ only temporary addresses for public communication. To make it difficult to make educated guesses as to whether two different interface identifiers belong to the same node, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entities that are collecting information. - [I-D.gont-6man-non-stable-iids] specifies requirements for temporary - addresses. This document specifies a number of algorithms for - generating temporary addresses that comply with the aforementioned - requirements. - 3. Protocol Description - The goal of this section is to define procedures that: + The goal of this section is to define procedures that can generate + IPv6 addresses with the following properties: - 1. Do not result in any changes to the basic behavior of addresses - generated via stateless address autoconfiguration [RFC4862]. + 1. Temporary addresses can be employed for initiating outgoing + sessions. - 2. Create temporary addresses based on an unpredictable interface - identifier for the purpose of initiating outgoing sessions. - These temporary addresses would be used for a short period of - time (hours to days) and would then be deprecated. Deprecated - addresses can continue to be used for already established - connections, but are not used to initiate new connections. New - temporary addresses are generated periodically to replace - temporary addresses that expire, with the exact time between - address generation a matter of local policy. + 2. Temporary addresses are used for a short period of time + (typically hours to days) and are subsequently deprecated. + Deprecated addresses can continue to be used for already + established connections, but are not used to initiate new + connections. - 3. Produce a sequence of temporary global scope addresses from a - sequence of interface identifiers that appear to be random in the - sense that it is difficult for an outside observer to predict a - future address (or identifier) based on a current one and it is - difficult to determine previous addresses (or identifiers) - knowing only the present one. + 3. New temporary addresses are generated periodically to replace + temporary addresses that expire. - 4. By default, generate one address for each prefix advertised for - stateless address autoconfiguration. The interface identifier - generated for each of those prefixes should be (statistically) - different. That is, a new interface identifier should be - computed for each temporary address that is to be generated. + 4. Temporary addresses must have a limited lifetime (limited "valid + lifetime" and "preferred lifetime" from [RFC4862]), that should + be statistically different for different addresses. The lifetime + of an address should be further reduced when privacy-meaningful + events (such as a node attaching to a different network, or the + regeneration of a new randomized MAC address) takes place. + + 5. By default, one address is generated for each prefix advertised + for stateless address autoconfiguration. The resulting Interface + Identifiers must be statistically different when addresses are + configured for different prefixes. That is, when temporary + addresses are generated for different autoconfiguration prefixes + for the same network interface, the resulting Interface + Identifiers must be statistically different. This means that, + given two addresses that employ different prefixes, it must be + difficult for an outside entity to tell whether the addresses + correspond to the same network interface or even whether they + have been generated by the same host. + + 6. It must be difficult for an outside entity to predict the + Interface Identifiers that will be employed for temporary + addresses, even with knowledge of the algorithm/method employed + to generate them and/or knowledge of the Interface Identifiers + previously employed for other temporary addresses. These + Interface Identifiers must be semantically opaque [RFC7136] and + must not follow any specific patterns. 3.1. Assumptions The following algorithm assumes that for a given temporary address, an implementation can determine the prefix from which it was generated. When a temporary address is deprecated, a new temporary address is generated. The specific valid and preferred lifetimes for the new address are dependent on the corresponding lifetime values set for the prefix from which it was generated. @@ -315,26 +330,26 @@ implementation to prefer temporary addresses by default, so that the connections initiated by the node can use temporary addresses without requiring application-specific enablement. This document also assumes that an API will exist that allows individual applications to indicate whether they prefer to use temporary or stable addresses and override the system defaults. 3.2. Generation of Randomized Interface Identifiers The following subsections specify some possible algorithms for - generating temporary interface identifiers that comply with the - requirements in [I-D.gont-6man-non-stable-iids]. The algorithm - specified in Section 3.2.1 benefits from a Pseudo-Random Number - Generator (PRNG) available on the system. On the other hand, the - algorithm specified in Section 3.2.2 allows for code reuse by nodes - that implement [RFC7217]. + generating temporary interface identifiers that follow the guidelines + in Section 3 of this document. The algorithm specified in + Section 3.2.1 benefits from a Pseudo-Random Number Generator (PRNG) + available on the system. On the other hand, the algorithm specified + in Section 3.2.2 allows for code reuse by nodes that implement + [RFC7217]. 3.2.1. Simple Randomized Interface Identifiers One possible approach would be to select a pseudorandom number of the appropriate length. A node employing this algorithm should generate IIDs as follows: 1. Obtain a random number (see [RFC4086] for randomness requirements for security) @@ -796,70 +812,63 @@ [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . + [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 + 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, DOI 10.17487/RFC7217, April 2014, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . 10.2. Informative References [FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, March 2012, . - [I-D.gont-6man-non-stable-iids] - Gont, F., Huitema, C., Krishnan, S., Gont, G., and M. - Corbo, "Recommendation on Temporary IPv6 Interface - Identifiers", draft-gont-6man-non-stable-iids-04 (work in - progress), March 2018. - [IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", . [ONION] Reed, MGR., Syverson, PFS., and DMG. Goldschlag, "Proxies for Anonymous Routing", Proceedings of the 12th Annual Computer Security Applications Conference, San Diego, CA, December 1996. [OPEN-GROUP] The Open Group, "The Open Group Base Specifications Issue 7 / IEEE Std 1003.1-2008, 2016 Edition", Section 4.16 Seconds Since the Epoch, 2016, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . - [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, . - [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, . @@ -870,30 +879,44 @@ [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . + [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., + Trammell, B., Huitema, C., and D. Borkmann, + "Confidentiality in the Face of Pervasive Surveillance: A + Threat Model and Problem Statement", RFC 7624, + DOI 10.17487/RFC7624, August 2015, + . + [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + . + Authors' Addresses + Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com