--- 1/draft-ietf-6man-rfc4941bis-03.txt 2019-11-04 00:14:03.059281917 -0800 +++ 2/draft-ietf-6man-rfc4941bis-04.txt 2019-11-04 00:14:03.103283030 -0800 @@ -1,23 +1,23 @@ 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: March 8, 2020 T. Narten +Expires: May 6, 2020 T. Narten IBM Corporation R. Draves Microsoft Research - September 5, 2019 + November 3, 2019 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 - draft-ietf-6man-rfc4941bis-03 + draft-ietf-6man-rfc4941bis-04 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 with randomized interface identifiers that change over time. Changing global scope addresses over time makes it more @@ -34,21 +34,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 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 March 8, 2020. + This Internet-Draft will expire on May 6, 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 @@ -67,21 +67,21 @@ 2.1. Extended Use of the Same Identifier . . . . . . . . . . . 4 2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 6 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 9 3.3. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 12 - 3.5. Regeneration of Randomized Interface Identifiers . . . . 12 + 3.5. Regeneration of Temporary Addresses . . . . . . . . . . . 12 3.6. Deployment Considerations . . . . . . . . . . . . . . . . 13 4. Implications of Changing Interface Identifiers . . . . . . . 14 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 @@ -108,30 +108,33 @@ temporary addresses. Section 2 provides background information on the issue. Section 3 describes a procedure for generating temporary interface identifiers and global scope addresses. Section 4 discusses implications of changing interface identifiers. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. The terms "public address", "stable address", "temporary address", "constant IID", "stable IID", and "temporary IID" are to be interpreted as specified in [RFC7721]. The term "global scope addresses" is used in this document to collectively refer to "Global unicast addresses" as defined in - [RFC4291] and "Unique local addresses" as defined in [RFC4193]. + [RFC4291] and "Unique local addresses" as defined in [RFC4193], and + not to "globally reachable" as defined in [RFC8190]. 1.2. Problem Statement Addresses generated using stateless address autoconfiguration [RFC4862] contain an embedded interface identifier, which remains stable over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. The correlation can be performed by @@ -247,24 +251,21 @@ Many machines function as both clients and servers. In such cases, the machine would need a DNS name for its use as a server. Whether the address stays fixed or changes has little privacy implication since the DNS name remains constant and serves as a constant identifier. When acting as a client (e.g., initiating communication), however, such a machine may want to vary the addresses it uses. In such environments, one may need multiple addresses: a stable address registered in the DNS, that is used to accept incoming connection requests from other machines, and a temporary address used to shield the identity of the client when it - initiates communication. These two cases are roughly analogous to - telephone numbers and caller ID, where a user may list their - telephone number in the public phone book, but disable the display of - its number via caller ID when initiating calls. + initiates communication. 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. @@ -348,21 +350,22 @@ 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) 2. The Interface Identifier is obtained by taking as many bits from the aforementioned random number (obtained in the previous step) - as necessary. + as necessary. Note: there are no special bits in an Interface + Identifier [RFC7136]. We note that [RFC4291] requires that the Interface IDs of all unicast addresses (except those that start with the binary value 000) be 64 bits long. However, the method discussed in this document could be employed for generating Interface IDs of any arbitrary length, albeit at the expense of reduced entropy (when employing Interface IDs smaller than 64 bits). 3. The resulting Interface Identifier SHOULD be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] @@ -487,21 +490,21 @@ corresponding prefix, the node SHOULD create a new temporary address for such prefix. 4. When creating a temporary address, the lifetime values MUST be derived from the corresponding prefix as follows: * Its Valid Lifetime is the lower of the Valid Lifetime of the prefix and TEMP_VALID_LIFETIME * Its Preferred Lifetime is the lower of the Preferred Lifetime - of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR. + of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR. 5. A temporary address is created only if this calculated Preferred Lifetime is greater than REGEN_ADVANCE time units. In particular, an implementation MUST NOT create a temporary address with a zero Preferred Lifetime. 6. New temporary addresses MUST be created by appending a randomized interface identifier (generates as described in Section 3.2 of this document) to the prefix that was received. @@ -533,21 +536,21 @@ race conditions in the case where generating a new temporary address is not instantaneous, such as when duplicate address detection must be run. The node SHOULD start the address regeneration process REGEN_ADVANCE time units before a temporary address would actually be deprecated. As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or upper layers as detailed in Section 6. -3.5. Regeneration of Randomized Interface Identifiers +3.5. Regeneration of Temporary Addresses The frequency at which temporary addresses change depends on how a device is being used (e.g., how frequently it initiates new communication) and the concerns of the end user. The most egregious privacy concerns appear to involve addresses used for long periods of time (weeks to months to years). The more frequently an address changes, the less feasible collecting or coordinating information keyed on interface identifiers becomes. Moreover, the cost of collecting information and attempting to correlate it based on interface identifiers will only be justified if enough addresses @@ -555,32 +558,31 @@ large numbers of clients change their address on a daily or weekly basis is likely to be sufficient to alleviate most privacy concerns. There are also client costs associated with having a large number of addresses associated with a node (e.g., in doing address lookups, the need to join many multicast groups, etc.). Thus, changing addresses frequently (e.g., every few minutes) may have performance implications. Nodes following this specification SHOULD generate new temporary - addresses on a periodic basis. This can be achieved automatically by - generating a new randomized interface identifier at least once every - (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units. - As described above, generating a new temporary address REGEN_ADVANCE - time units before a temporary address becomes deprecated produces - addresses with a preferred lifetime no larger than - TEMP_PREFERRED_LIFETIME. The value DESYNC_FACTOR is a random value - (different for each client) that ensures that clients don't - synchronize with each other and generate new addresses at exactly the - same time. When the preferred lifetime expires, a new temporary - address MUST be generated using the new randomized interface - identifier. + addresses on a periodic basis. This can be achieved by generating a + new temporary address at least once every (TEMP_PREFERRED_LIFETIME - + REGEN_ADVANCE - DESYNC_FACTOR) time units. As described above, + generating a new temporary address REGEN_ADVANCE time units before a + temporary address becomes deprecated produces addresses with a + preferred lifetime no larger than TEMP_PREFERRED_LIFETIME. The value + DESYNC_FACTOR is a random value (different for each client) that + ensures that clients don't synchronize with each other and generate + new addresses at exactly the same time. When the preferred lifetime + expires, a new temporary address MUST be generated using the new + randomized interface identifier. Because the precise frequency at which it is appropriate to generate new addresses varies from one environment to another, implementations SHOULD provide end users with the ability to change the frequency at which addresses are regenerated. The default value is given in TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time at which to invalidate a temporary address depends on how applications are used by end users. Thus, the suggested default value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all environments. Implementations SHOULD provide end users with the @@ -680,21 +681,21 @@ TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be able to override the default value. REGEN_ADVANCE -- 5 seconds MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR. It is computed once at system start (rather than each time it is used) and must never be greater than - (TEMP_VALID_LIFETIME - REGEN_ADVANCE). + (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE). TEMP_IDGEN_RETRIES -- Default value: 3 6. Future Work An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when @@ -735,44 +736,44 @@ 4941 that an implementer of RFC 4941 should be aware of. 1. Discussion of IEEE-based IIDs has been removed, since the current recommendation ([RFC8064]) is to employ [RFC7217]). 2. The document employs the terminology from [RFC7721]. 3. Sections 2.2 and 2.3 of [RFC4941] have been removed since the topic has been discussed in more detail in e.g. [RFC7721]. - 4. The algorithm to generate randomized interface identifiers was - replaced by two possible alternative algorithms. + 4. The algorithm specified in Section 3.2.1 and 3.2.2 of [RFC4941] + was replaced by two possible alternative algorithms. 5. Generation of stable addresses is not implied or required by this document. 6. Temporary addresses are *not* disabled by default. - 7. Section 3.2.1 and 3.2.2 from [RFC4941] were replaced with - alternative algorithms. - - 8. Section 3.2.3 from [RFC4941] was removed, based on the + 7. Section 3.2.3 from [RFC4941] was removed, based on the explanation of that very section of RFC4941. - 9. All the verified errata for [RFC4941] has been incorporated. + 8. All the verified errata for [RFC4941] has been incorporated. 9. Acknowledgments The authors would like to thank (in alphabetical order) Brian Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob Hinden, Christian Huitema, Dave Plonka, Michael Richardson, Mark Smith, and Johanna Ullrich for providing valuable comments on earlier versions of this document. + This document incoporates errata submitted for [RFC4941] by (in + alphabetical order) Jiri Bohac and Alfred Hoenes. + This document is based on [RFC4941] (a revision of RFC3041). Suresh Krishnan was the sole author of RFC4941. He would like to acknowledge the contributions of the ipv6 working group and, in particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont, Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their detailed comments. Rich Draves and Thomas Narten were the authors of RFC 3041. They would like to acknowledge the contributions of the ipv6 working group and, in particular, Ran Atkinson, Matt Crawford, Steve Deering, @@ -827,27 +828,36 @@ 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, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, + "Updates to the Special-Purpose IP Address Registries", + BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, + . + 10.2. Informative References [FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, March 2012, - . + . [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.