idnits 2.17.1 draft-huitema-6man-random-addresses-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 2, 2016) is 2974 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) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Microsoft 4 Intended status: Standards Track March 2, 2016 5 Expires: September 3, 2016 7 Implications of Randomized Link Layers Addresses for IPv6 Address 8 Assignment 9 draft-huitema-6man-random-addresses-03.txt 11 Abstract 13 Hosts may assign random link-layer addresses to network interfaces in 14 an attempt to increase privacy and reduce trackability. Careless 15 assignment of IPv6 addresses may negate the privacy advantages of 16 random link-layer addresses. We propose simple solutions to ensure 17 that IPv6 addresses do change whenever the link layer addresses 18 change. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 3, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Randomized link-layer addresses . . . . . . . . . . . . . . . 3 57 2.1. Randomized link-layer address format . . . . . . . . . . 4 58 2.2. Link-layer address life time . . . . . . . . . . . . . . 4 59 3. Privacy respecting opaque identifiers . . . . . . . . . . . . 5 60 3.1. Update to RFC 7217 . . . . . . . . . . . . . . . . . . . 6 61 4. Privacy compatible Temporary Addresses . . . . . . . . . . . 6 62 4.1. Update to RFC 4941 . . . . . . . . . . . . . . . . . . . 7 63 5. Other IPv6 Address Assigment methods . . . . . . . . . . . . 7 64 5.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 7 65 5.2. Static, manually configured IIDs . . . . . . . . . . . . 8 66 5.3. Constant, semantically opaque IIDs . . . . . . . . . . . 8 67 5.4. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 9 68 5.5. Transition/co-existence technologies . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The IPv6 Maintenance Working Group is reviewing the privacy 80 properties of various IPv6 address generation mechanisms 81 [I-D.ietf-6man-ipv6-address-generation-privacy]. At the same time, 82 this working group has proposed in [RFC7217] a method for the 83 construction of stable IPv6 identifiers. The method defined in 84 [RFC7217] is designed to prevent address scanning or device 85 identification through the use of "opaque" identifiers. It prevents 86 location tracking by making sure that the same device uses different 87 identifiers at different locations. However, a strict implementation 88 of [RFC7217] results in stable identifiers, which remain always the 89 same for a given device and a given location. This is in fact a 90 design goal of [RFC7217]. 92 Privacy conscious users will not agree with this design goal. 93 Suppose for example users who don't want being tracked when they 94 visit an public place at different times. They will configure their 95 device to use different link layer addresses on the different visits, 96 using a form of MAC Address Randomization, as discussed in Section 2. 98 However, if their devices implement a strict version of [RFC7217], 99 the IPv6 addresses will contain stable identifiers. The stable 100 identifiers will re-enable the tracking that MAC Address 101 Randomization would have prevented. 103 Some systems also use temporary IPv6 addresses, as defined by 104 [RFC4941]. These randomized addresses are defined by generating a 105 randomized interface identifier at controlled intervals, and then 106 using this identifier in conjunction with prefixes advertised by 107 routers to construct addresses with limited life time. Even with 108 this short life time, the randomized interface identifier could 109 remain constant while the link layer addresses changes with MAC 110 Address Randomization. This would enable tracking between successive 111 network connections, even if the MAC Address changed. 113 The purpose of this document is to recommend specific guidelines for 114 the use of [RFC7217] and [RFC4941], in order to make it maintain the 115 privacy benefits of MAC Address Randomization. Section 2 presents 116 the address randomization mechanisms. Section 3 presents the 117 guidelines for use of [RFC7217]. Section 4 presents the guidelines 118 for use of [RFC4941]. Section 5 reviews the other address formats 119 commonly used, and their interaction with MAC Address Randomization. 121 1.1. Requirements 123 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 124 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 125 document, are to be interpreted as described in [RFC2119]. 127 2. Randomized link-layer addresses 129 Mobile nodes can be tracked using multiple identifiers, the most 130 prominent being the MAC addresses. For example, when devices use Wi- 131 Fi connectivity, they place the MAC address in the header of all the 132 packets that they transmit. Standard implementation of Wi-Fi use 133 unique 48 bit MAC addresses, assigned to the devices according to 134 procedures defined by IEEE 802. Even when the Wi-Fi packets are 135 encrypted, the portion of the header containing the addresses will be 136 sent in clear text. Tracking devices can "listen to the airwaves" to 137 find out what devices are transmitting near them. 139 The obvious solution is to "randomize" the MAC address. Before 140 connecting to a particular network, the device replaces the MAC 141 address with a randomly drawn 48 bit value. MAC address 142 randomization was successfully tried at the IETF in Honolulu in 143 November 2014, and in several other lcation since that, as reported 144 in [IETFMACRandom], and is also studied in [IEEE802PRSG]. MAC 145 Address Randomization will defend against trackers that just "listen 146 to the airwaves," but tracking can be re-enabled if the trackers can 147 obtain other device identifiers. We are concerned here with the use 148 of IPv6 addresses for such tracking. 150 From a privacy point of view, it is clear that MAC Addresses and IPv6 151 addresses and DHCP identifiers shall evolve in synchrony. For 152 example, if the MAC address changes and the IID portion of the IPv6 153 address stays constant, then it is really easy to correlate old and 154 new MAC address. Conversely, if the IID changes but the MAC address 155 remains constant, the old and new identifiers and addresses can be 156 correlated by listening to the link's traffic. 158 2.1. Randomized link-layer address format 160 At the time of this writing, there is no standard way to construct 161 randomized link layer addresses, but many implementations use the 162 following algorithm for IEEE 802 48 bit MACs: 164 Set the the "u" (universal/local) bit to 1 (local). 166 Set the the "g" (individual/group) bit to 0 (individual). 168 Pick random values for all the other bits. 170 2.2. Link-layer address life time 172 This document makes the hypothesis that randomized link layer 173 addresses are chosen just prior to the connection to a link. Hosts 174 are expected to maintain the same link-layer address for the duration 175 of the connection. 177 There are circumstances where a host may decide to reset its link 178 layer address while maintaining an attachment to a link. For 179 example, a host Ethernet interface may remain "plugged in" while the 180 interface driver is reset to use a new MAC address. These conditions 181 will be considered equivalent to disconnecting and then reconnecting 182 with a new link layer address. The previously used IPv6 addresses 183 will be discarded, and a new set of addreses will be assigned. 185 There are circonstances where a host may decide to reconnect to a 186 particular link using the same link-layer address as for a previous 187 attachment. In this case, the assignment algorithm will normally 188 result in assigning the same IPv6 address as in the previous session, 189 except under exceptional circumstances such as resetting the "secret 190 key" used in [RFC7217]. 192 3. Privacy respecting opaque identifiers 194 [RFC7217] specifies an algorithm that generates, for each network 195 interface, a unique random IID per IPv6 link. The privacy properties 196 of that algorithm depends on the specific source of the "Net_Iface" 197 chosen by the implementer. 199 Most sources for the Net_IFace parameter listed in Appendix A of 200 [RFC7217] will result in stable identifiers, independent of the link- 201 layer address. This is useful in some deployment cases. For 202 example, if the network interface card of a server is swapped, the 203 specified algorithm will ensure that the server's IPv6 address do not 204 change. However, applying the same algorithm for mobile devices 205 enable tracking over time of a device that repeatedly visits the same 206 location, despite attempts by the host to use different random link- 207 layer address values. 209 Tracking over time is prevented if the Net_IFace parameter is set to 210 the current link layer address. In that case, the stable addresses 211 will have exactly the same lifetime as the link-layer identifiers. 212 The IPv6 addresses will change whenever the link layer addresses 213 change. Hosts that return to the same network without changing their 214 link layer addresses will reuse the same IPv6 address. This SHOULD 215 be the default solution for hosts implementing Link-layer Address 216 Randomization. 218 Of course, this behavior could violate the statement regarding the 219 Net_Iface parameter selection in Section 5 of [RFC7217]: 221 It MUST be constant across system bootstrap sequences and other 222 network events (e.g., bringing another interface up or down). 224 Although [RFC7217] isn't very specific about "other network events", 225 it seems that it generally intends to not change for events like 226 changing a link-layer address. For example, there is a specific 227 statement about servers in section 5: 229 ... a server-oriented operating system might prefer Net_Iface 230 identifiers that are attached to system slots/ports, such that 231 replacement of a NIC does not result in an IPv6 address change. 233 This is indeed a fine recommendation for static servers, for which 234 [RFC7217] provides a reasonable tradeoff between stability and 235 privacy. But for mobile hosts, the tradeoff is a bit different. We 236 expect these mobile hosts to implement [RFC7217] as recommended by 237 the IETF, but to also require more privacy than static servers. It 238 turns out that a minimal update to [RFC7217] would make it suitable 239 for these mobile hosts. The will keep the full benefits of stable 240 opaque identifiers when the link-layer address is stable, and the 241 expected privacy when the link-layer address is randomized. This 242 simple update is proposed in the next section. 244 3.1. Update to RFC 7217 246 Section 5 of [RFC7217], Net_Iface selection, is modified as follow: 248 Replace "MUST" by "SHOULD" in the text: 250 It SHOULD be constant across system bootstrap sequences and other 251 network events (e.g., bringing another interface up or down). 253 Immediately after that, add: 255 It MAY change if the system administrator decides so explicitly, 256 e.g. by implementing Link Layer Address Randomization. This can 257 be achieved by selecting the Current Link Layer Address for Net- 258 Iface parameter. 260 The following text is added to Appendix A, section A.3, Link-Layer 261 Addresses: 263 Link-Layer addresses will change dynamically in systems that 264 implement Link Layer Address Randomization. This will cause IIDs 265 to change whenever the Link Address changes, which is very 266 desirable for privacy. 268 4. Privacy compatible Temporary Addresses 270 As stated in [I-D.ietf-6man-ipv6-address-generation-privacy], "a host 271 that uses only a temporary address mitigates all four threats. Its 272 activities may only be correlated for the lifetime a single temporary 273 address." There is however a condition. If the lifetime of the 274 temporary address exceeds the lifetime of the random link layer 275 address, then correlation of successive link-layer addresses becomes 276 possible, effectively enabling a form of tracking. 278 If a host uses both temporary and stable addresses, the privacy 279 properties are those of the particular stable addresses. This is 280 also true is a host uses temporary addresses and configure but doen't 281 use a stable address. The address configuration will require 282 performing duplicate address detection, generating at least a few 283 packets on the local links. Observing this packets, an on-link 284 attacker can correlate the link-layer address with the stable 285 address. If the stable address includes a constant identifier, then 286 the benefits of using random link-local addresses will be negated. 288 This situation is anticipated somewhat in the specification of 289 temporary addresses. Section 3.5 of [RFC4941] specifies procedure 290 for the regeneration of interface identifiers. The last paragraph of 291 that section specifies: 293 ... when an interface connects to a new link, a new randomized 294 interface identifier SHOULD be generated immediately together with 295 a new set of temporary addresses. 297 That condition is however not sufficient to cover the case of a 298 device that re-connects to the same link with a new randomized link 299 local addresses. 301 4.1. Update to RFC 4941 303 The word "Finally" should be removed from the last paragraph of 304 section 3.5. 306 The following text should be added at the end of section 3.5: 308 Finally, when an interface is reconfigured to use a new link-layer 309 address, a new randomized interface identifier SHOULD be generated 310 immediately together with a new set of temporary addresses. The 311 previously assigned addresses SHOULD be marked as expired, not 312 just deprecated. This reconfiguration will happen for example as 313 a consequence of link-layer address randomization. 315 5. Other IPv6 Address Assigment methods 317 The previous sections reviewed the use of stable addresses [RFC7217] 318 and temporary addresses [RFC4941]. Several other IPv6 address 319 assignment methods have been defined over time. We review here these 320 methods in light of link layer address randomization, using the same 321 nomenclature as [I-D.ietf-6man-ipv6-address-generation-privacy]. 322 Several IPv6 address assignment methods have been defined over time. 323 We review here these methods in light of link layer address 324 randomization, using the same nomenclature as 325 [I-D.ietf-6man-ipv6-address-generation-privacy]. 327 5.1. IEEE-identifier-based IIDs 329 IEEE-identifier-based IIDs could be derived from randomized link 330 layer ID, using the algorithm specified in Appendix A of [RFC4291]. 332 If the IIDs are constructed using the random link layer addresses, 333 and if the random link layer addresses are constructed using the 334 algorithm specified in Section 2.1, then the issues described in 335 section 3 of [I-D.ietf-6man-ipv6-address-generation-privacy] are 336 somewhat mitigated, but many concerns remain. The correlation over 337 time still be possible for the lifetime of the link layer address, 338 and the location tracking will only be mitigated if link layer 339 addresses do change with location. 341 In addition to the lifetime and location tracking concerns, there is 342 also a "scope" issue with IEEE-identifier-based IIDs. The practice 343 will export the link-layer address value to all places where the IPv6 344 address is used. This increase the potential "surface" for privacy 345 attacks, and is not desirable. 347 There is a small probability of collision between IIDs derived from 348 random link layer addresses and IIDs obtained through the sematically 349 opaque, cryptographically generated, or temporary assignment methods. 350 The "u" bit is set to global for globally assigned link layer 351 addresses, but set to "local" for both random link layer addresses 352 and for IIDs derived through some random process. The collision risk 353 is however very small, and may not be a practical concern. 355 5.2. Static, manually configured IIDs 357 Because static, manually configured IIDs are stable, both correlation 358 and location tracking are possible for the life of the address. 359 Using randomized link-local addresses doesn't change that. 361 In practice, static assignment and link-layer address randomization 362 address different scenarios. Static assignments are typically used 363 for static hosts, while randomization is typically used for mobile 364 hosts. 366 5.3. Constant, semantically opaque IIDs 368 This address assignment method allows correlation and location 369 tracking because the IID is constant across IPv6 links and time. 370 Using randomized link-local addresses doesn't change that. In fact, 371 the constant values allow for correlation between the random link- 372 local address and the host's identity, removing most of privacy value 373 of random link-layer addresses. 375 Section 4.3 of [I-D.ietf-6man-ipv6-address-generation-privacy] 376 addresses the general case of systems generating constant IID using 377 the algorithms specified in [RFC4941], mentioning the implementation 378 of this algorithm in Windows. Tests on the Windows platform show 379 that the "constant" IIDs do in fact change if the link layer address 380 is changed to a random value, and thus do in fact preserve the 381 privacy value of random link-layer addresses. 383 5.4. DHCPv6 generation of IIDs 385 When using DHCPv6 in conjunction with random link layer addresses, 386 implementers SHOULD follow the recommendations of 387 [I-D.ietf-dhc-anonymity-profile]. 389 5.5. Transition/co-existence technologies 391 Transition technologies typically embed an IPv4 address in a 392 specifically formatted IPv6 address. Tracking over time becomes 393 possible if the IPv4 address has a longer lifetime than the random 394 link-layer address. 396 To mitigate the potential tracking issues with embedded IPv4 397 addresses, hosts using random link-local addresses SHOULD implement 398 the DHCPv4 profile specified in [I-D.ietf-dhc-anonymity-profile]. 400 6. Security Considerations 402 This whole document concerns the privacy and security properties of 403 different IPv6 address generation mechanisms. 405 7. IANA Considerations 407 This draft does not require any IANA action. 409 8. Acknowledgments 411 The inspiration for this draft came from the authors of 412 [I-D.ietf-6man-ipv6-address-generation-privacy], Alissa Cooper, 413 Fernando Gont, and Dave Thaler. Philip Homburg and other members of 414 the 6Man working group provided valuable comments. 416 9. References 418 9.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 426 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 427 2006, . 429 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 430 Extensions for Stateless Address Autoconfiguration in 431 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 432 . 434 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 435 Interface Identifiers with IPv6 Stateless Address 436 Autoconfiguration (SLAAC)", RFC 7217, 437 DOI 10.17487/RFC7217, April 2014, 438 . 440 9.2. Informative References 442 [I-D.ietf-6man-ipv6-address-generation-privacy] 443 Cooper, A., Gont, F., and D. Thaler, "Privacy 444 Considerations for IPv6 Address Generation Mechanisms", 445 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 446 in progress), September 2015. 448 [I-D.ietf-dhc-anonymity-profile] 449 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 450 profile for DHCP clients", draft-ietf-dhc-anonymity- 451 profile-08 (work in progress), February 2016. 453 [IEEE802PRSG] 454 IEEE 802 EC PRSG, "IEEE 802 EC Privacy Recommendation 455 Study Group", Dec 2015, 456 . 458 [IETFMACRandom] 459 Bernardos, CJ., Zuniga, JC., and P. O'Hanlon, "Wi-Fi 460 Internet connectivity and privacy: hiding your tracks on 461 the wireless Internet", October 2015, 462 . 465 Author's Address 467 Christian Huitema 468 Microsoft 469 Redmond, WA 98052 470 U.S.A. 472 Email: huitema@microsoft.com