idnits 2.17.1 draft-gont-6man-non-stable-iids-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2018) is 2224 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4086' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC5453' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC8064' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'FIPS-SHS' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'IANA-RESERVED-IID' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'OPEN-GROUP' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RAID2015' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC6059' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC6151' is defined on line 400, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-02 == Outdated reference: A later version (-01) exists of draft-gont-taps-address-usage-problem-statement-00 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Standards Track C. Huitema 5 Expires: September 25, 2018 Private Octopus Inc. 6 S. Krishnan 7 Ericsson Research 8 G. Gont 9 SI6 Networks 10 M. Garcia Corbo 11 SITRANS 12 March 24, 2018 14 Recommendation on Temporary IPv6 Interface Identifiers 15 draft-gont-6man-non-stable-iids-04 17 Abstract 19 This document specifies a set of requirements for generating 20 temporary addresses, and clarifies the stability requirements for 21 IPv6 addresses, allowing for the use of only temporary addresses. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 25, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Stability Requirements for IPv6 Addresses . . . . . . . . . . 4 61 5. Requirements for Temporary IPv6 Addresses . . . . . . . . . . 4 62 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 IPv6 StateLess Address AutoConfiguration (SLAAC) [RFC4862] has 72 traditionally resulted in stable addresses, since the Interface 73 Identifier (IID) has been generated by embedding a stable layer-2 74 numeric identifier (e.g., a MAC address). [RFC4941] originally 75 implied, throughout the specification, that temporary addresses are 76 generated and employed along with stable addresses. 78 While the use of stable addresses (only) or mixed stable and 79 temporary addresses can be desirable in a number of scenarios, there 80 are other scenarios in which, for security and privacy reasons, a 81 node may want to use only temporary address (e.g., a temporary 82 address). 84 On the other hand, the lack of a formal set of requirements for 85 temporary addresses led to a number of flaws in popular 86 implementations and in the protocol specification itself, such as 87 allowing for the correlation of network activity carried out with 88 different addresses, reusing randomized identifiers across different 89 networks, etc. 91 This document clarifies the requirements for stability of IPv6 92 addresses, such that nodes are not required to configure stable 93 addresses, and may instead employ only temporary addresses. It also 94 specifies a set of requirements for the generation of temporary 95 addresses. 97 2. Terminology 99 Statistically different: 100 When two values are required to be "statistically different", it 101 means that the equality of those values cannot be caused by 102 anything else other than random chance. 104 This document employs the definitions of "stable address" and 105 "temporary address" from [RFC7721]. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. Problem statement 113 When [RFC4941] was written, its authors wanted to prevent privacy and 114 security attacks enabled by addresses that contain "an embedded 115 interface identifier, which remains constant over time". They 116 observed that "Anytime a fixed identifier is used in multiple 117 contexts, it becomes possible to correlate seemingly unrelated 118 activity using this identifier." They were concerned with both on- 119 path attackers who would observe the IP addresses of packets observed 120 in transit, and attackers that would have access to the logs of 121 servers. 123 Since the publication of [RFC4941] in September 2007, our 124 understanding of threats and mitigations has evolved. The IETF is 125 now officially concerned with Pervasive Monitoring [RFC7258], as well 126 as the wide spread collection of information for advertising and 127 other purposes, for example through the Real Time Bidding protocol 128 used for advertising auctions [RTB25]. 130 3.1. Privacy requirements 132 The widespread deployment of encryption advocated in [RFC7624] is a 133 response to Pervasive Monitoring. Encryption of communication 134 reduces the amount of information that can be collected by monitoring 135 data links, but does not prevent monitoring of IPv6 addresses 136 embedded in clear text packet headers. Stable IPv6 addresses enable 137 the correlation of such data over time. 139 MAC Address Randomization [IETFMACRandom] is another response to 140 pervasive monitoring. In conjunction with DHCP Anonymity [RFC7844], 141 it ensures that devices cannot be tracked by their MAC Address or 142 their DHCP identifiers when they connect to "hot spots". However, 143 the privacy effects of MAC Address Randomization would be nullified 144 if a device kept using the same IPv6 address before and after a MAC- 145 address randomization event. 147 Many Web Browsers have options enabling browsing "in private". 148 However, if the web connections during the private mode use the same 149 IPv6 address as those in the public mode, web tracking systems 150 similar to [RTB25] will quickly find the correlation between the 151 public personna of the user and the supposedly private connection. 152 Similarly, many web browsers have options to "delete history", 153 including deleting "cookies" and other persistent data. Again, if 154 the same IPv6 address is used before and after the deletion of 155 cookies, web tracking systems will easily correlate the new activity 156 with the prior data collection. 158 Using temporary address alone may not be sufficient to prevent all 159 forms of tracking. It is however quite clear that some usage of 160 temporary addresses is necessary to provide user privacy. It is also 161 clear that the usage of temporary addresses needs to be synchronized 162 with other privacy defining event such as moving to a new network, 163 performing MAC Address Randomization, or changing the privacy posture 164 of a node. 166 4. Stability Requirements for IPv6 Addresses 168 Nodes are not required to generate addresses with any specific 169 stability properties. That is, the generation of stable addresses is 170 OPTIONAL. This means that a node may end up configuring only stable 171 addresses, only temporary, or both stable and temporary addresses. 173 5. Requirements for Temporary IPv6 Addresses 175 The requirements for temporary IPv6 addresses are as follows: 177 1. Temporary addresses MUST have a limited lifetime (limited "valid 178 lifetime" and "preferred lifetime" from [RFC4862]), that should 179 be statistically different for different addresses. The lifetime 180 of an address essentially limits the extent to which network 181 activity correlation can be performed for such address. 183 2. The lifetime of an address MUST be further reduced when privacy- 184 meaningful events (such as a node attaching to a new network) 185 takes place. 187 3. The resulting Interface Identifiers MUST be statistically 188 different when addresses are configured for different prefixes. 189 That is, when temporary addresses are generated for different 190 autoconfiguration prefixes for the same network interface, the 191 resulting Interface Identifiers must be statistically different. 193 This means that, given two addresses that employ different 194 prefixes, it must be difficult for an outside entity to tell 195 whether the addresses correspond to the same network interface or 196 even whether they have been generated by the same host. 198 4. It must be difficult for an outside entity to predict the 199 Interface Identifiers that will be employed for temporary 200 addresses, even with knowledge of the algorithm/method employed 201 to generate them and/or knowledge of the Interface Identifiers 202 previously employed for other temporary addresses. 204 5. The resulting Interface Identifiers MUST be semantically opaque 205 [RFC7136] and MUST NOT follow any specific patterns. 207 By definition, temporary addresses have a limited lifetime. This is 208 in contrast with e.g. stable addresses [RFC7217], that are not 209 expected to become invalid under normal circumstances. Employing 210 statistically different lifetimes for different addresses prevents an 211 observer from synchronizing with the temporary address regeneration; 212 that is, from being able to predict when a temporary address will 213 become invalid and a new one regenerated, and thus being able to 214 infer that one newly observed address is actually the result of 215 regenerating a previously observed one. 217 The lifetime of an address should be further reduced by privacy- 218 meaningful events. For example, a host must not employ the same 219 address across network attachment events. That is, a host that de- 220 attaches from a network and subsequently re-attaches to a (possibly 221 different) network should regenerate all of its temporary addresses. 222 Similarly, a host that implements MAC address randomization should 223 regenerate all of its temporary addresses. Failure to regenerate 224 temporary addresses upon such events would allow the correlation of 225 network activity across such events (e.g., correlation of network 226 activity as a host moves from one network to another). Other events, 227 such as those discussed in Section 3.1 should also trigger the 228 regeneration of all temporary addresses. 230 Temporary addresses configured for different prefixes should employ 231 statistically different interface identifiers. In general, the reuse 232 of identifiers across different contexts or scopes can be detrimental 233 for security and privacy [I-D.gont-predictable-numeric-ids] [RFC6973] 234 [RFC4941]. For example, a node that deterministically employs the 235 same interface identifier for generating temporary addresses for 236 different prefixes will allow the correlation of network activity. 238 For security and privacy reasons, the IIDs generated for temporary 239 addresses must be unpredictable by an outside entity. Otherwise, the 240 node may be subject to many (if not all) of the security and privacy 241 issues that temporary addresses are expected to mitigate (please see 242 [RFC7721]). 244 Any semantics or patterns in an IID might be leveraged by an attacker 245 to e.g. reduce the search space when performing address-scanning 246 attacks (see [RFC7707], infer the identity of the node, etc. 248 NOTE: 249 In the above text, where the "lifetime" of different addresses is 250 required to be statistically different, or where the interface 251 identifiers for different temporary addresses is required to be 252 statistically different, the goal is that an implementation must 253 not deterministically employ the same such values for different 254 addresses. For example, where interface identifiers for different 255 temporary addresses are required to be statistically different, 256 the goal is to e.g. prevent an implementation from computing a 257 single random interface identifier and employing such identifier 258 for the generation of temporary addresses for other prefixes for 259 the same network interface (as was the case with the algorithm 260 specified in [RFC4941]). Therefore, a node is neither required 261 nor expected to e.g. enforce that a newly-generated random 262 interface identifier is not currently employed by any other 263 temporary address configured by the node, or that such interface 264 identifier has not been previously employed for any other 265 temporary address configured by the node. 267 6. Future Work 269 This document clarifies the requirements for stability requirements 270 for IPv6 addresses, and specifies requirements for temporary 271 addresses. A separate document 272 ([I-D.gont-taps-address-usage-problem-statement]) discusses the 273 trade-offs involved when considering different stability properties 274 of IPv6 addresses. 276 7. IANA Considerations 278 There are no IANA registries within this document. The RFC-Editor 279 can remove this section before publication of this document as an 280 RFC. 282 8. Security Considerations 284 This document clarifies the stability requirements for IPv6 285 addresses, and specifies requirements for the generation of temporary 286 addresses. 288 The security and privacy properties of IPv6 addresses have been 289 discussed in detail in [RFC7721] and [RFC7707]. 291 9. Acknowledgements 293 The authors would like to thank (in alphabetical order) Brian 294 Carpenter, Lorenzo Colitti, and David Plonka, for providing valuable 295 feedback on earlier versions of this document. 297 10. References 299 10.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 307 "Randomness Requirements for Security", BCP 106, RFC 4086, 308 DOI 10.17487/RFC4086, June 2005, 309 . 311 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 312 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 313 2006, . 315 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 316 Address Autoconfiguration", RFC 4862, 317 DOI 10.17487/RFC4862, September 2007, 318 . 320 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 321 Extensions for Stateless Address Autoconfiguration in 322 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 323 . 325 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 326 RFC 5453, DOI 10.17487/RFC5453, February 2009, 327 . 329 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 330 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 331 February 2014, . 333 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 334 Interface Identifiers with IPv6 Stateless Address 335 Autoconfiguration (SLAAC)", RFC 7217, 336 DOI 10.17487/RFC7217, April 2014, 337 . 339 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 340 "Recommendation on Stable IPv6 Interface Identifiers", 341 RFC 8064, DOI 10.17487/RFC8064, February 2017, 342 . 344 10.2. Informative References 346 [FIPS-SHS] 347 NIST, "Secure Hash Standard (SHS)", FIPS 348 Publication 180-4, March 2012, 349 . 352 [I-D.gont-predictable-numeric-ids] 353 Gont, F. and I. Arce, "Security and Privacy Implications 354 of Numeric Identifiers Employed in Network Protocols", 355 draft-gont-predictable-numeric-ids-02 (work in progress), 356 February 2018. 358 [I-D.gont-taps-address-usage-problem-statement] 359 Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem 360 Statement Regarding IPv6 Address Usage", draft-gont-taps- 361 address-usage-problem-statement-00 (work in progress), 362 February 2018. 364 [IANA-RESERVED-IID] 365 IANA, "Reserved IPv6 Interface Identifiers", 366 . 368 [IETFMACRandom] 369 Zuniga, JC., "MAC Privacy", November 2014, 370 . 372 [OPEN-GROUP] 373 The Open Group, "The Open Group Base Specifications Issue 374 7 / IEEE Std 1003.1-2008, 2016 Edition", 375 Section 4.16 Seconds Since the Epoch, 2016, 376 . 379 [RAID2015] 380 Ullrich, J. and E. Weippl, "Privacy is Not an Option: 381 Attacking the IPv6 Privacy Extension", International 382 Symposium on Recent Advances in Intrusion Detection 383 (RAID), 2015, . 386 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 387 DOI 10.17487/RFC1321, April 1992, 388 . 390 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 391 Stateless Address Autoconfiguration in IPv6", RFC 3041, 392 DOI 10.17487/RFC3041, January 2001, 393 . 395 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 396 Detecting Network Attachment in IPv6", RFC 6059, 397 DOI 10.17487/RFC6059, November 2010, 398 . 400 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 401 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 402 RFC 6151, DOI 10.17487/RFC6151, March 2011, 403 . 405 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 406 Morris, J., Hansen, M., and R. Smith, "Privacy 407 Considerations for Internet Protocols", RFC 6973, 408 DOI 10.17487/RFC6973, July 2013, 409 . 411 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 412 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 413 2014, . 415 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 416 Trammell, B., Huitema, C., and D. Borkmann, 417 "Confidentiality in the Face of Pervasive Surveillance: A 418 Threat Model and Problem Statement", RFC 7624, 419 DOI 10.17487/RFC7624, August 2015, 420 . 422 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 423 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 424 . 426 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 427 Considerations for IPv6 Address Generation Mechanisms", 428 RFC 7721, DOI 10.17487/RFC7721, March 2016, 429 . 431 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 432 Profiles for DHCP Clients", RFC 7844, 433 DOI 10.17487/RFC7844, May 2016, 434 . 436 [RTB25] Interactive Advertising Bureau (IAB), "Real Time Bidding 437 (RTB) project, OpenRTB API Specification Version 2.5", 438 December 2016, . 442 Authors' Addresses 444 Fernando Gont 445 SI6 Networks / UTN-FRH 446 Evaristo Carriego 2644 447 Haedo, Provincia de Buenos Aires 1706 448 Argentina 450 Phone: +54 11 4650 8472 451 Email: fgont@si6networks.com 452 URI: http://www.si6networks.com 454 Christian Huitema 455 Private Octopus Inc. 456 Friday Harbor, WA 98250 457 U.S.A. 459 Email: huitema@huitema.net 460 URI: http://privateoctopus.com/ 462 Suresh Krishnan 463 Ericsson Research 464 8400 Decarie Blvd. 465 Town of Mount Royal, QC 466 Canada 468 Email: suresh.krishnan@ericsson.com 469 Guillermo Gont 470 SI6 Networks 471 Evaristo Carriego 2644 472 Haedo, Provincia de Buenos Aires 1706 473 Argentina 475 Phone: +54 11 4650 8472 476 Email: ggont@si6networks.com 477 URI: https://www.si6networks.com 479 Madeleine Garcia Corbo 480 Servicios de Informacion del Transporte 481 Neptuno 358 482 Havana City 10400 483 Cuba 485 Email: madelen.garcia16@gmail.com