idnits 2.17.1 draft-gont-6man-non-stable-iids-02.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 5, 2018) is 2244 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 284, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC5453' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC8064' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'FIPS-SHS' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'IANA-RESERVED-IID' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'OPEN-GROUP' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RAID2015' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC6059' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC6151' is defined on line 378, 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 6, 2018 Private Octopus Inc. 6 S. Krishnan 7 Ericsson Research 8 G. Gont 9 SI6 Networks 10 M. Garcia Corbo 11 SITRANS 12 March 5, 2018 14 Recommendation on Temporary IPv6 Interface Identifiers 15 draft-gont-6man-non-stable-iids-02 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 6, 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 . . . . . . . . . . . . . . . . . . . . . . 6 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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, which should be 172 different for different addresses. The lifetime of an address 173 essentially limits the extent to which network activity 174 correlation can be performed based on such address. 176 2. The lifetime of an address MUST be further reduced when privacy- 177 meaningful events (such as a node attaching to a new network) 178 takes place. 180 3. The resulting Interface Identifiers MUST be different when 181 addresses are configured for different prefixes. That is, if 182 different autoconfiguration prefixes are used to configure 183 addresses for the same network interface card, the resulting 184 Interface Identifiers must be (statistically) different. This 185 means that, given two addresses that employ different prefixes, 186 it must be difficult for an outside entity to tell whether the 187 addresses correspond to the same network interface or even 188 whether they have been generated by the same host. 190 4. The resulting interface identifiers MUST NOT embed layer-2 191 identifiers (e.g. MAC addresses). 193 5. It must be difficult for an outside entity to predict the 194 Interface Identifiers that will be generated by the algorithm, 195 even with knowledge of the Interface Identifiers generated for 196 configuring other addresses. 198 6. 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 do not have 203 have a limited lifetime. Having a variable maximum lifetime prevents 204 an observer from synchronizing with the temporary address 205 regeneration; that is, from being able to expect when address will be 206 regenerated, and thus infer that one newly observed addresses is the 207 result of regenerating a previously observed one. 209 The lifetime of an address should be further reduced by privacy- 210 meaningful events. For example, a host should not employ the same 211 address across network attachment events. That is, a host that de- 212 attaches from a network and subsequently re-attaches to a (possibly 213 different) network should regenerate all of its temporary addresses. 214 Similarly, a host that implements MAC address randomization should 215 regenerate all of its temporary addresses. Other events, such as 216 those discussed in Section 3.1 should also trigger the regeneration 217 of all temporary addresses. 219 The IIDs of addresses configured for different autoconfiguration 220 prefixes must be different, such that traffic for those addresses 221 cannot be correlated. 223 The reuse of identifiers that have their own semantics or properties 224 across different contexts or scopes can be detrimental for security 225 and privacy [I-D.gont-predictable-numeric-ids] [RFC6973] [RFC4941]. 226 For example, if two different layer-3 protocols generate their 227 addresses by embedding a layer-2 identifier (e.g., a MAC address), 228 then the traffic for such protocols could be correlated (irrespective 229 of whether the aforementioned layer-2 identifier has been randomized 230 or not). Besides, a node that generates an IPv6 address by embedding 231 a link-layer address in the IPv6 address will, when configuring 232 addresses for different prefixes, result in the same IID being used 233 for such prefixes, thus allowing the corresponding traffic to be 234 correlated. 236 For security and privacy reasons, the IIDs generated for temporary 237 addresses must not be predictable. Otherwise, the node may be 238 subject to many (if not all) of the security and privacy issues that 239 are meant to be mitigated (please see [RFC7721]. 241 Any semantics or patterns in an IID might be leveraged by an attacker 242 to e.g. reduce the search space when performing address-scanning 243 attacks, infer the identity of the node, etc. 245 6. Future Work 247 This document clarifies the requirements for stability requirements 248 for IPv6 addresses, and specifies requirements for temporary 249 addresses. A separate document 250 ([I-D.gont-taps-address-usage-problem-statement]) discusses the 251 tradeoffs involved when considering different stability properties of 252 IPv6 addresses. 254 7. IANA Considerations 256 There are no IANA registries within this document. The RFC-Editor 257 can remove this section before publication of this document as an 258 RFC. 260 8. Security Considerations 262 This document clarifies the stability requirements for IPv6 263 addresses, and specifies requirements for the generation of temporary 264 addresses. 266 The security and privacy properties of IPv6 addresses have been 267 discussed in detail in [RFC7721] and [RFC7707]. 269 9. Acknowledgements 271 The authors would like to thank (in alphabetical order) Brian 272 Carpenter and Lorenzo Colitti for providing valuable feedback on 273 earlier versions of this document. 275 10. References 277 10.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 285 "Randomness Requirements for Security", BCP 106, RFC 4086, 286 DOI 10.17487/RFC4086, June 2005, 287 . 289 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 290 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 291 2006, . 293 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 294 Address Autoconfiguration", RFC 4862, 295 DOI 10.17487/RFC4862, September 2007, 296 . 298 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 299 Extensions for Stateless Address Autoconfiguration in 300 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 301 . 303 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 304 RFC 5453, DOI 10.17487/RFC5453, February 2009, 305 . 307 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 308 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 309 February 2014, . 311 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 312 Interface Identifiers with IPv6 Stateless Address 313 Autoconfiguration (SLAAC)", RFC 7217, 314 DOI 10.17487/RFC7217, April 2014, 315 . 317 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 318 "Recommendation on Stable IPv6 Interface Identifiers", 319 RFC 8064, DOI 10.17487/RFC8064, February 2017, 320 . 322 10.2. Informative References 324 [FIPS-SHS] 325 NIST, "Secure Hash Standard (SHS)", FIPS 326 Publication 180-4, March 2012, 327 . 330 [I-D.gont-predictable-numeric-ids] 331 Gont, F. and I. Arce, "Security and Privacy Implications 332 of Numeric Identifiers Employed in Network Protocols", 333 draft-gont-predictable-numeric-ids-02 (work in progress), 334 February 2018. 336 [I-D.gont-taps-address-usage-problem-statement] 337 Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem 338 Statement Regarding IPv6 Address Usage", draft-gont-taps- 339 address-usage-problem-statement-00 (work in progress), 340 February 2018. 342 [IANA-RESERVED-IID] 343 IANA, "Reserved IPv6 Interface Identifiers", 344 . 346 [IETFMACRandom] 347 Zuniga, JC., "MAC Privacy", November 2014, 348 . 350 [OPEN-GROUP] 351 The Open Group, "The Open Group Base Specifications Issue 352 7 / IEEE Std 1003.1-2008, 2016 Edition", 353 Section 4.16 Seconds Since the Epoch, 2016, 354 . 357 [RAID2015] 358 Ullrich, J. and E. Weippl, "Privacy is Not an Option: 359 Attacking the IPv6 Privacy Extension", International 360 Symposium on Recent Advances in Intrusion Detection 361 (RAID), 2015, . 364 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 365 DOI 10.17487/RFC1321, April 1992, 366 . 368 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 369 Stateless Address Autoconfiguration in IPv6", RFC 3041, 370 DOI 10.17487/RFC3041, January 2001, 371 . 373 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 374 Detecting Network Attachment in IPv6", RFC 6059, 375 DOI 10.17487/RFC6059, November 2010, 376 . 378 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 379 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 380 RFC 6151, DOI 10.17487/RFC6151, March 2011, 381 . 383 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 384 Morris, J., Hansen, M., and R. Smith, "Privacy 385 Considerations for Internet Protocols", RFC 6973, 386 DOI 10.17487/RFC6973, July 2013, 387 . 389 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 390 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 391 2014, . 393 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 394 Trammell, B., Huitema, C., and D. Borkmann, 395 "Confidentiality in the Face of Pervasive Surveillance: A 396 Threat Model and Problem Statement", RFC 7624, 397 DOI 10.17487/RFC7624, August 2015, 398 . 400 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 401 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 402 . 404 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 405 Considerations for IPv6 Address Generation Mechanisms", 406 RFC 7721, DOI 10.17487/RFC7721, March 2016, 407 . 409 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 410 Profiles for DHCP Clients", RFC 7844, 411 DOI 10.17487/RFC7844, May 2016, 412 . 414 [RTB25] Interactive Advertising Bureau (IAB), "Real Time Bidding 415 (RTB) project, OpenRTB API Specification Version 2.5", 416 December 2016, . 420 Authors' Addresses 422 Fernando Gont 423 SI6 Networks / UTN-FRH 424 Evaristo Carriego 2644 425 Haedo, Provincia de Buenos Aires 1706 426 Argentina 428 Phone: +54 11 4650 8472 429 Email: fgont@si6networks.com 430 URI: http://www.si6networks.com 431 Christian Huitema 432 Private Octopus Inc. 433 Friday Harbor, WA 98250 434 U.S.A. 436 Email: huitema@huitema.net 437 URI: http://privateoctopus.com/ 439 Suresh Krishnan 440 Ericsson Research 441 8400 Decarie Blvd. 442 Town of Mount Royal, QC 443 Canada 445 Email: suresh.krishnan@ericsson.com 447 Guillermo Gont 448 SI6 Networks 449 Evaristo Carriego 2644 450 Haedo, Provincia de Buenos Aires 1706 451 Argentina 453 Phone: +54 11 4650 8472 454 Email: ggont@si6networks.com 455 URI: https://www.si6networks.com 457 Madeleine Garcia Corbo 458 Servicios de Informacion del Transporte 459 Neptuno 358 460 Havana City 10400 461 Cuba 463 Email: madelen.garcia16@gmail.com