idnits 2.17.1 draft-gont-6man-non-stable-iids-03.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 21, 2018) is 2228 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 301, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC5453' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC8064' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'FIPS-SHS' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'IANA-RESERVED-IID' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'OPEN-GROUP' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RAID2015' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC6059' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC6151' is defined on line 395, 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 22, 2018 Private Octopus Inc. 6 S. Krishnan 7 Ericsson Research 8 G. Gont 9 SI6 Networks 10 M. Garcia Corbo 11 SITRANS 12 March 21, 2018 14 Recommendation on Temporary IPv6 Interface Identifiers 15 draft-gont-6man-non-stable-iids-03 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 22, 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 This document employs the terms defined in [RFC7721]. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. Problem statement 107 When [RFC4941] was written, its authors wanted to prevent privacy and 108 security attacks enabled by addresses that contain "an embedded 109 interface identifier, which remains constant over time". They 110 observed that "Anytime a fixed identifier is used in multiple 111 contexts, it becomes possible to correlate seemingly unrelated 112 activity using this identifier." They were concerned with both on- 113 path attackers who would observe the IP addresses of packets observed 114 in transit, and attackers that would have access to the logs of 115 servers. 117 Since the publication of [RFC4941] in September 2007, our 118 understanding of threats and mitigations has evolved. The IETF is 119 now officially concerned with Pervasive Monitoring [RFC7258], as well 120 as the wide spread collection of information for advertising and 121 other purposes, for example through the Real Time Bidding protocol 122 used for advertising auctions [RTB25]. 124 3.1. Privacy requirements 126 The widespread deployment of encryption advocated in [RFC7624] is a 127 response to Pervasive Monitoring. Encryption of communication 128 reduces the amount of information that can be collected by monitoring 129 data links, but does not prevent monitoring of IPv6 addresses 130 embedded in clear text packet headers. Stable IPv6 addresses enable 131 the correlation of such data over time. 133 MAC Address Randomization [IETFMACRandom] is another response to 134 pervasive monitoring. In conjunction with DHCP Anonymity [RFC7844], 135 it ensures that devices cannot be tracked by their MAC Address or 136 their DHCP identifiers when they connect to "hot spots". However, 137 the privacy effects of MAC Address Randomization would be nullified 138 if a device kept using the same IPv6 address before and after a MAC- 139 address randomization event. 141 Many Web Browsers have options enabling browsing "in private". 142 However, if the web connections during the private mode use the same 143 IPv6 address as those in the public mode, web tracking systems 144 similar to [RTB25] will quickly find the correlation between the 145 public personna of the user and the supposedly private connection. 146 Similarly, many web browsers have options to "delete history", 147 including deleting "cookies" and other persistent data. Again, if 148 the same IPv6 address is used before and after the deletion of 149 cookies, web tracking systems will easily correlate the new activity 150 with the prior data collection. 152 Using temporary address alone may not be sufficient to prevent all 153 forms of tracking. It is however quite clear that some usage of 154 temporary addresses is necessary to provide user privacy. It is also 155 clear that the usage of temporary addresses needs to be synchronized 156 with other privacy defining event such as moving to a new network, 157 performing MAC Address Randomization, or changing the privacy posture 158 of a node. 160 4. Stability Requirements for IPv6 Addresses 162 Nodes are not required to generate addresses with any specific 163 stability properties. That is, the generation of stable addresses is 164 OPTIONAL. This means that a node may end up configuring only stable 165 addresses, only Temporary, or both stable and temporary addresses. 167 5. Requirements for Temporary IPv6 Addresses 169 The requirements for temporary IPv6 addresses are as follows: 171 1. Temporary addresses MUST have a limited lifetime (limited "valid 172 lifetime" and "preferred lifetime" from [RFC4862]), that should 173 be (statistically) different for different addresses. The 174 lifetime of an address essentially limits the extent to which 175 network activity correlation can be performed for such address. 177 2. The lifetime of an address MUST be further reduced when privacy- 178 meaningful events (such as a node attaching to a new network) 179 takes place. 181 3. The resulting Interface Identifiers MUST be statistically 182 different when addresses are configured for different prefixes. 183 That is, when temporary addresses are generated for different 184 autoconfiguration prefixes for the same network interface, the 185 resulting Interface Identifiers must be (statistically) 186 different. This means that, given two addresses that employ 187 different prefixes, it must be difficult for an outside entity to 188 tell whether the addresses correspond to the same network 189 interface or even whether they have been generated by the same 190 host. 192 4. It must be difficult for an outside entity to predict the 193 Interface Identifiers that will be employed for temporary 194 addresses, even with knowledge of the algorithm/method employed 195 to generate them and/or knowledge of the Interface Identifiers 196 previously employed for other temporary addresses. 198 5. The resulting Interface Identifiers MUST be semantically opaque 199 [RFC7136] and MUST NOT follow any specific patterns. 201 By definition, temporary addresses have a limited lifetime. This is 202 in contrast with e.g. stable addresses [RFC7217], that are not 203 expected to become invalid under normal circumstances. Employing 204 (statistically) different lifetimes for different addresses prevents 205 an observer from synchronizing with the temporary address 206 regeneration; that is, from being able to predict when a temporary 207 address will become invalid and a new one regenerated, and thus being 208 able to infer that one newly observed address is actually the result 209 of regenerating a previously observed one. 211 The lifetime of an address should be further reduced by privacy- 212 meaningful events. For example, a host must not employ the same 213 address across network attachment events. That is, a host that de- 214 attaches from a network and subsequently re-attaches to a (possibly 215 different) network should regenerate all of its temporary addresses. 216 Similarly, a host that implements MAC address randomization should 217 regenerate all of its temporary addresses. Failure to regenerate 218 temporary addresses upon such events would allow the correlation of 219 network activity across such events (e.g., correlation of network 220 activity as a host moves from one network to another). Other events, 221 such as those discussed in Section 3.1 should also trigger the 222 regeneration of all temporary addresses. 224 Temporary addresses configured for different prefixes should employ 225 (statistically) different interface identifiers. In general, the 226 reuse of identifiers across different contexts or scopes can be 227 detrimental for security and privacy 228 [I-D.gont-predictable-numeric-ids] [RFC6973] [RFC4941]. For example, 229 a node that deterministically employs the same interface identifier 230 for generating temporary addresses for different prefixes will allow 231 the correlation of network activity. 233 For security and privacy reasons, the IIDs generated for temporary 234 addresses must be unpredictable by an outside entity. Otherwise, the 235 node may be subject to many (if not all) of the security and privacy 236 issues that temporary addresses are expected to mitigate (please see 237 [RFC7721]). 239 Any semantics or patterns in an IID might be leveraged by an attacker 240 to e.g. reduce the search space when performing address-scanning 241 attacks (see [RFC7707], infer the identity of the node, etc. 243 NOTE: 244 In the above text, where the "lifetime" of different addresses is 245 required to be (statistically) different, or where the interface 246 identifiers for different temporary addresses is required to be 247 (statistically) different, the goal is that an implementation must 248 not deterministically employ the same such values for different 249 addresses. For example, where interface identifiers for different 250 temporary addresses are required to be (statistically) different, 251 the goal is to e.g. prevent an implementation from computing a 252 single random interface identifier and employing such identifier 253 for the generation of temporary addresses for other prefixes for 254 the same network interface (as was the case with the algorithm 255 specified in [RFC4941]). Therefore, a node is neither required 256 nor expected to e.g. enforce that a newly-generated random 257 interface identifier is not currently employed by any other 258 temporary address configured by the node, or that such interface 259 identifier has not been previously employed for any other 260 temporary address configured by the node. 262 6. Future Work 264 This document clarifies the requirements for stability requirements 265 for IPv6 addresses, and specifies requirements for temporary 266 addresses. A separate document 267 ([I-D.gont-taps-address-usage-problem-statement]) discusses the 268 tradeoffs involved when considering different stability properties of 269 IPv6 addresses. 271 7. IANA Considerations 273 There are no IANA registries within this document. The RFC-Editor 274 can remove this section before publication of this document as an 275 RFC. 277 8. Security Considerations 279 This document clarifies the stability requirements for IPv6 280 addresses, and specifies requirements for the generation of temporary 281 addresses. 283 The security and privacy properties of IPv6 addresses have been 284 discussed in detail in [RFC7721] and [RFC7707]. 286 9. Acknowledgements 288 The authors would like to thank (in alphabetical order) Brian 289 Carpenter, Lorenzo Colitti, and David Plonka, for providing valuable 290 feedback on earlier versions of this document. 292 10. References 294 10.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 302 "Randomness Requirements for Security", BCP 106, RFC 4086, 303 DOI 10.17487/RFC4086, June 2005, 304 . 306 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 307 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 308 2006, . 310 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 311 Address Autoconfiguration", RFC 4862, 312 DOI 10.17487/RFC4862, September 2007, 313 . 315 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 316 Extensions for Stateless Address Autoconfiguration in 317 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 318 . 320 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 321 RFC 5453, DOI 10.17487/RFC5453, February 2009, 322 . 324 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 325 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 326 February 2014, . 328 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 329 Interface Identifiers with IPv6 Stateless Address 330 Autoconfiguration (SLAAC)", RFC 7217, 331 DOI 10.17487/RFC7217, April 2014, 332 . 334 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 335 "Recommendation on Stable IPv6 Interface Identifiers", 336 RFC 8064, DOI 10.17487/RFC8064, February 2017, 337 . 339 10.2. Informative References 341 [FIPS-SHS] 342 NIST, "Secure Hash Standard (SHS)", FIPS 343 Publication 180-4, March 2012, 344 . 347 [I-D.gont-predictable-numeric-ids] 348 Gont, F. and I. Arce, "Security and Privacy Implications 349 of Numeric Identifiers Employed in Network Protocols", 350 draft-gont-predictable-numeric-ids-02 (work in progress), 351 February 2018. 353 [I-D.gont-taps-address-usage-problem-statement] 354 Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem 355 Statement Regarding IPv6 Address Usage", draft-gont-taps- 356 address-usage-problem-statement-00 (work in progress), 357 February 2018. 359 [IANA-RESERVED-IID] 360 IANA, "Reserved IPv6 Interface Identifiers", 361 . 363 [IETFMACRandom] 364 Zuniga, JC., "MAC Privacy", November 2014, 365 . 367 [OPEN-GROUP] 368 The Open Group, "The Open Group Base Specifications Issue 369 7 / IEEE Std 1003.1-2008, 2016 Edition", 370 Section 4.16 Seconds Since the Epoch, 2016, 371 . 374 [RAID2015] 375 Ullrich, J. and E. Weippl, "Privacy is Not an Option: 376 Attacking the IPv6 Privacy Extension", International 377 Symposium on Recent Advances in Intrusion Detection 378 (RAID), 2015, . 381 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 382 DOI 10.17487/RFC1321, April 1992, 383 . 385 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 386 Stateless Address Autoconfiguration in IPv6", RFC 3041, 387 DOI 10.17487/RFC3041, January 2001, 388 . 390 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 391 Detecting Network Attachment in IPv6", RFC 6059, 392 DOI 10.17487/RFC6059, November 2010, 393 . 395 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 396 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 397 RFC 6151, DOI 10.17487/RFC6151, March 2011, 398 . 400 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 401 Morris, J., Hansen, M., and R. Smith, "Privacy 402 Considerations for Internet Protocols", RFC 6973, 403 DOI 10.17487/RFC6973, July 2013, 404 . 406 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 407 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 408 2014, . 410 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 411 Trammell, B., Huitema, C., and D. Borkmann, 412 "Confidentiality in the Face of Pervasive Surveillance: A 413 Threat Model and Problem Statement", RFC 7624, 414 DOI 10.17487/RFC7624, August 2015, 415 . 417 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 418 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 419 . 421 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 422 Considerations for IPv6 Address Generation Mechanisms", 423 RFC 7721, DOI 10.17487/RFC7721, March 2016, 424 . 426 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 427 Profiles for DHCP Clients", RFC 7844, 428 DOI 10.17487/RFC7844, May 2016, 429 . 431 [RTB25] Interactive Advertising Bureau (IAB), "Real Time Bidding 432 (RTB) project, OpenRTB API Specification Version 2.5", 433 December 2016, . 437 Authors' Addresses 439 Fernando Gont 440 SI6 Networks / UTN-FRH 441 Evaristo Carriego 2644 442 Haedo, Provincia de Buenos Aires 1706 443 Argentina 445 Phone: +54 11 4650 8472 446 Email: fgont@si6networks.com 447 URI: http://www.si6networks.com 449 Christian Huitema 450 Private Octopus Inc. 451 Friday Harbor, WA 98250 452 U.S.A. 454 Email: huitema@huitema.net 455 URI: http://privateoctopus.com/ 457 Suresh Krishnan 458 Ericsson Research 459 8400 Decarie Blvd. 460 Town of Mount Royal, QC 461 Canada 463 Email: suresh.krishnan@ericsson.com 464 Guillermo Gont 465 SI6 Networks 466 Evaristo Carriego 2644 467 Haedo, Provincia de Buenos Aires 1706 468 Argentina 470 Phone: +54 11 4650 8472 471 Email: ggont@si6networks.com 472 URI: https://www.si6networks.com 474 Madeleine Garcia Corbo 475 Servicios de Informacion del Transporte 476 Neptuno 358 477 Havana City 10400 478 Cuba 480 Email: madelen.garcia16@gmail.com