--- 1/draft-ietf-6man-rfc4941bis-08.txt 2020-04-06 12:13:05.196523788 -0700 +++ 2/draft-ietf-6man-rfc4941bis-09.txt 2020-04-06 12:13:05.248525100 -0700 @@ -1,24 +1,24 @@ 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: September 28, 2020 T. Narten +Expires: October 8, 2020 T. Narten IBM Corporation R. Draves Microsoft Research - March 27, 2020 + April 6, 2020 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 - draft-ietf-6man-rfc4941bis-08 + draft-ietf-6man-rfc4941bis-09 Abstract 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 limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network activity correlation when the same address is employed for multiple transactions by the same node. Additionally, it reduces the window @@ -33,21 +33,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 September 28, 2020. + This Internet-Draft will expire on October 8, 2020. Copyright Notice Copyright (c) 2020 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 @@ -73,26 +73,27 @@ 3.3.2. Hash-based Generation of Randomized Interface Identifiers . . . . . . . . . . . . . . . . . . . . . 9 3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12 3.7. Implementation Considerations . . . . . . . . . . . . . . 13 3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14 4. Implications of Changing Interface Identifiers . . . . . . . 15 5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 9.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Stateless address autoconfiguration (SLAAC) [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 detail in [RFC7721],[RFC7217], and RFC7707. This document specifies an extension for SLAAC to generate temporary addresses, that can help mitigate some of the aforementioned issues. This is a revision of @@ -743,21 +744,51 @@ protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when they become invalid [RFC4862], independent of whether or not upper layer protocols are still using them. For TCP connections, such information is available in control blocks. For UDP-based applications, it may be the case that only the applications have knowledge about what addresses are actually in use. Consequently, an implementation generally will need to use heuristics in deciding when an address is no longer in use. -7. Security Considerations +7. Implementation Status + + [The RFC-Editor should remove this section before publishing this + document as an RFC] + + The following are known implementations of this document: + + o FreeBSD kernel: There is a FreeBSD kernel implementation of this + document, albeit not yet committed. The implementation has been + done in April 2020 by Fernando Gont . The + corresponding patch can be found at: + + + o Linux kernel: There is a Linux kernel implementation of this + document for the net-next tree, albeit not yet committed. The + implementation has been done in April 2020 by Fernando Gont + . The corresponding patch can be found at: + + + o slaacd(8): slaacd(8) has traditionally used different randomized + interface identifiers for each prefix, and it has recently reduced + the Valid Lifetime of temporary addresses as specified in + Section 3.8, thus fully implementing this document. The + implementation has been done by Florian Obser + , with the update to the temporary address + Valid Lifetime applied in March 2020. The implementation can be + found at: + +8. Security Considerations If a very small number of nodes (say, only one) use a given prefix for extended periods of time, just changing the interface identifier part of the address may not be sufficient to mitigate address-based network activity correlation, since the prefix acts as a constant identifier. The procedures described in this document are most effective when the prefix is reasonably non static or is used by a fairly large number of nodes. Additionally, if a temporary address is used in a session where the user authenticates, any notion of "privacy" for that address is compromised. @@ -772,21 +803,21 @@ preventing the use of spoofed source addresses in Distributed Denial of Service (DDoS) attacks. In a network with a large number of nodes, new temporary addresses are created at a fairly high rate. This might make it difficult for ingress filtering mechanisms to distinguish between legitimately changing temporary addresses and spoofed source addresses, which are "in-prefix" (using a topologically correct prefix and non-existent interface ID). This can be addressed by using access control mechanisms on a per-address basis on the network egress point. -8. Acknowledgments +9. Acknowledgments The authors would like to thank (in alphabetical order) Fred Baker, Brian Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob Hinden, Christian Huitema, Erik Kline, Gyan Mishra, Dave Plonka, Michael Richardson, Mark Smith, Pascal Thubert, Ole Troan, Johanna Ullrich, and Timothy Winters, for providing valuable comments on earlier versions of this document. This document incorporates errata submitted for [RFC4941] by Jiri Bohac and Alfred Hoenes. @@ -796,23 +827,23 @@ 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, Allison Mankin, and Peter Bieringer. -9. References +10. References -9.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . @@ -856,21 +887,21 @@ [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, . -9.2. Informative References +10.2. Informative References [FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, August 2015, . [I-D.ietf-mboned-ieee802-mcast-problems] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless