idnits 2.17.1 draft-huitema-6man-random-addresses-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 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 (August 17, 2015) is 3174 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) == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-07 == Outdated reference: A later version (-08) exists of draft-ietf-dhc-anonymity-profile-01 Summary: 1 error (**), 0 flaws (~~), 4 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 August 17, 2015 5 Expires: February 18, 2016 7 Implications of Randomized Link Layers Addresses for IPv6 Address 8 Assignment 9 draft-huitema-6man-random-addresses-02.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 February 18, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . 4 60 3.1. Update to RFC 7217 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 8 68 5.5. Transition/co-existence technologies . . . . . . . . . . 8 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 in the process of approving a 80 recommending the use of [RFC7217] for the construction of stable IPv6 81 identifiers [I-D.ietf-6man-ipv6-address-generation-privacy]. The 82 mechanism is designed to prevent address scanning or device 83 identification through the use of "opaque" identifiers. It prevents 84 location tracking by making sure that the same device uses different 85 identifiers at different locations. However, a strict implementation 86 of [RFC7217] results in stable identifiers, which remain always the 87 same for a given device and a given location. This is in fact a 88 design goal of [RFC7217]. 90 Privacy conscious users will not agree with this design goal. 91 Suppose for example users who don't want being tracked when they 92 visit an public place at different times. They will configure their 93 device to use different link layer addresses on the different visits, 94 using a form of MAC Address Randomization. However, if their devices 95 implement a strict version of [RFC7217], the IPv6 addresses will 96 contain stable identifiers. The stable identifiers will re-enable 97 the tracking that MAC Address Randomization would have prevented. 99 Some systems also use temporary IPv6 addresses, as defined by 100 [RFC4941]. These randomized addresses are defined by generating a 101 randomized interface identifier at controlled intervals, and then 102 using this identifier in conjunction with prefixes advertised by 103 routers to construct addresses with limited life time. Even with 104 this short life time, the randomized interface identifier could 105 remain constant while the link layer addresses changes with MAC 106 Address Randomization. This would enable tracking between successive 107 network connections, even if the MAC Address changed. 109 The purpose of this document is to recommend specific guidelines for 110 the use of [RFC7217] and [RFC4941], in order to make it maintain the 111 privacy benefits of MAC Address Randomization. Section 2 presents 112 the address randomization mechanisms. Section 3 presents the 113 guidelines for use of [RFC7217]. Section 4 presents the guidelines 114 for use of [RFC4941]. Section 5 reviews the other address formats 115 commonly used, and their interaction with MAC Address Randomization. 117 1.1. Requirements 119 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 120 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 121 document, are to be interpreted as described in [RFC2119]. 123 2. Randomized link-layer addresses 125 Mobile nodes can be tracked using multiple identifiers, the most 126 prominent being the MAC addresses. For example, when devices use Wi- 127 Fi connectivity, they place the MAC address in the header of all the 128 packets that they transmit. Standard implementation of Wi-Fi use 129 unique 48 bit MAC addresses, assigned to the devices according to 130 procedures defined by IEEE 802. Even when the Wi-Fi packets are 131 encrypted, the portion of the header containing the addresses will be 132 sent in clear text. Tracking devices can "listen to the airwaves" to 133 find out what devices are transmitting near them. 135 The obvious solution is to "randomize" the MAC address. Before 136 connecting to a particular network, the device replaces the MAC 137 address with a randomly drawn 48 bit value. MAC address 138 randomization was successfully tried at the IETF in Honolulu in 139 November 2014 [IETFMACRandom]. However, we have to consider the 140 linkage between MAC addresses and IPv6 addresses. 142 From a privacy point of view, it is clear that MAC Addresses and IPv6 143 addresses and DHCP identifiers shall evolve in synchrony. For 144 example, if the MAC address changes and the IID portion of the IPv6 145 address stays constant, then it is really easy to correlate old and 146 new MAC address. Conversely, if the IID changes but the MAC address 147 remains constant, the old and new identifiers and addresses can be 148 correlated by listening to the link's traffic. 150 2.1. Randomized link-layer address format 152 At the time of this writing, there is no standard way to construct 153 randomized link layer addresses, but many implementations use the 154 following algorithm for IEEE 802 48 bit MACs: 156 Set the the "u" (universal/local) bit to 1 (local). 158 Set the the "g" (individual/group) bit to 0 (individual). 160 Pick random values for all the other bits. 162 2.2. Link-layer address life time 164 This document makes the hypothesis that randomized link layer 165 addresses are chosen just prior to the connection to a link. Hosts 166 are expected to maintain the same link-layer address for the duration 167 of the connection. 169 There are circumstances where a host may decide to reset its link 170 layer address while maintaining an attachment to a link. For 171 example, a host Ethernet interface may remain "plugged in" while the 172 interface driver is reset to use a new MAC address. These conditions 173 will be considered equivalent to disconnecting and then reconnecting 174 with a new link layer address. The previously used IPv6 addresses 175 will be discarded, and a new set of addreses will be assigned. 177 There are circonstances where a host may decide to reconnect to a 178 particular link using the same link-layer address as for a previous 179 attachment. In this case, the assignment algorithm will normally 180 result in assigning the same IPv6 address as in the previous session, 181 except under exceptional circumstances such as resetting the "secret 182 key" used in [RFC7217]. 184 3. Privacy respecting opaque identifiers 186 [RFC7217] specifies an algorithm that generates, for each network 187 interface, a unique random IID per IPv6 link. The privacy properties 188 of that algorithm depends on the specific source of the "Net_Iface" 189 chosen by the implementer. 191 Most sources for the Net_IFace parameter listed in Appendix A of 192 [RFC7217] will result in stable identifiers, independent of the link- 193 layer address. This will enable tracking over time of a host that 194 repeatedly visits the same location, despite any attempts by the host 195 to use different random link-layer address values. In fact, the 196 stable IIDs will enable correlation of different link-layer addresses 197 to the same host identity. 199 Tracking over time is prevented if the Net_IFace parameter is set to 200 the current link layer address. In that case, the stable addresses 201 will have exactly the same lifetime as the link-layer identifiers. 202 The IPv6 addresses will change whenever the link layer addresses 203 change. Hosts that return to the same network without changing their 204 link layer addresses will reuse the same IPv6 address. This SHOULD 205 be the default solution for hosts implementing Link-layer Address 206 Randomization. 208 Of course, this behavior could violate the statement regarding the 209 Net_Iface parameter selection in Section 5 of [RFC7217]: 211 It MUST be constant across system bootstrap sequences and other 212 network events (e.g., bringing another interface up or down). 214 Although [RFC7217] isn't very specific about "other network events", 215 it seems that it generally intends to not change for events like 216 changing a link-layer address. For example, there is a specific 217 statement about servers in section 5: 219 ... a server-oriented operating system might prefer Net_Iface 220 identifiers that are attached to system slots/ports, such that 221 replacement of a NIC does not result in an IPv6 address change. 223 This is indeed a fine recommendation for static servers, for which 224 [RFC7217] provides a reasonable tradeoff between stability and 225 privacy. But for mobile hosts, the tradeoff is a bit different. We 226 expect these mobile hosts to implement [RFC7217] as recommended by 227 the IETF, but to also require more privacy than static servers. It 228 turns out that a minimal update to [RFC7217] would make it suitable 229 for these mobile hosts. The will keep the full benefits of stable 230 opaque identifiers when the link-layer address is stable, and the 231 expected privacy when the link-layer address is randomized. This 232 simple update is proposed in the next section. 234 3.1. Update to RFC 7217 236 Section 5 of [RFC7217], Net_Iface selection, is modified as follow: 238 Replace "MUST" by "SHOULD" in the text: 240 It SHOULD be constant across system bootstrap sequences and other 241 network events (e.g., bringing another interface up or down). 243 Immediately after that, add: 245 It MAY change if the system administrator decides so explicitly, 246 e.g. by implementing Link Layer Address Randomization. This can 247 be achieved by selecting the Current Link Layer Address for Net- 248 Iface parameter. 250 The following text is added to Appendix A, section A.3, Link-Layer 251 Addresses: 253 Link-Layer addresses will change dynamically in systems that 254 implement Link Layer Address Randomization. This will cause IIDs 255 to change whenever the Link Address changes, which is very 256 desirable for privacy. 258 4. Privacy compatible Temporary Addresses 260 As stated in [I-D.ietf-6man-ipv6-address-generation-privacy], "a host 261 that uses only a temporary address mitigates all four threats. Its 262 activities may only be correlated for the lifetime a single temporary 263 address." There is however a condition. If the lifetime of the 264 temporary address exceeds the lifetime of the random link layer 265 address, then correlation of successive link-layer addresses becomes 266 possible, effectively enabling a form of tracking. 268 If a host uses both temporary and stable addresses, the privacy 269 properties are those of the particular stable addresses. This is 270 also true if a host uses temporary addresses and configures but 271 doen't use a stable address. The address configuration will require 272 performing duplicate address detection, generating at least a few 273 packets on the local links. Observing this packets, an on-link 274 attacker can correlate the link-layer address with the stable 275 address. If the stable address includes a constant identifier, then 276 the benefits of using random link-layer addresses will be negated. 278 This situation is anticipated somewhat in the specification of 279 temporary addresses. Section 3.5 of [RFC4941], specifies procedure 280 for the regeneration of interface identifiers. The last paragraph of 281 that section specifies: 283 ... when an interface connects to a new link, a new randomized 284 interface identifier SHOULD be generated immediately together with 285 a new set of temporary addresses. 287 That condition is however not sufficient to cover the case of a 288 device that re-connects to the same link with a new randomized link 289 local addresses. 291 4.1. Update to RFC 4941 293 The word "Finally" should be removed from the last paragraph of 294 section 3.5. 296 The following text should be added at the end of section 3.5: 298 Finally, when an interface is reconfigured to use a new link-layer 299 address, a new randomized interface identifier SHOULD be generated 300 immediately together with a new set of temporary addresses. The 301 previously assigned addresses SHOULD be marked as expired, not 302 just deprecated. This reconfiguration will happen for example as 303 a consequence of link-layer address randomization. 305 5. Other IPv6 Address Assigment methods 307 The previous sections reviewed the use of stable addresses [RFC7217] 308 and temporary addresses [RFC4941]. Several other IPv6 address 309 assignment methods have been defined over time. We review here these 310 methods in light of link layer address randomization, using the same 311 nomenclature as [I-D.ietf-6man-ipv6-address-generation-privacy]. 313 5.1. IEEE-identifier-based IIDs 315 IEEE-identifier-based IIDs could be derived from randomized link 316 layer ID, using the algorithm specified in Appendix A of [RFC4291]. 318 If the IIDs are constructed using the random link layer addresses, 319 and if the random link layer addresses are constructed using the 320 algorithm specified in Section 2.1, then the issues described in 321 section 3 of [I-D.ietf-6man-ipv6-address-generation-privacy] are 322 somewhat mitigated, but many concerns remain. The correlation over 323 time still be possible for the lifetime of the link layer address, 324 and the location tracking will only be mitigated if link layer 325 addresses do change with location. 327 In addition to the lifetime and location tracking concerns, there is 328 also a "scope" issue with IEEE-identifier-based IIDs. The practice 329 will export the link-layer address value to all places where the IPv6 330 address is used. This increase the potential "surface" for privacy 331 attacks, and is not desirable. 333 There is a small probability of collision between IIDs derived from 334 random link layer addresses and IIDs obtained through the sematically 335 opaque, cryptographically generated, or temporary assignment methods. 336 The "u" bit is set to global for globally assigned link layer 337 addresses, but set to "local" for both random link layer addresses 338 and for IIDs derived through some random process. The collision risk 339 is however very small, and may not be a practical concern. 341 5.2. Static, manually configured IIDs 343 Because static, manually configured IIDs are stable, both correlation 344 and location tracking are possible for the life of the address. 345 Using randomized link-layer addresses doesn't change that. 347 In practice, static assignment and link-layer address randomization 348 address different scenarios. Static assignments are typically used 349 for static hosts, while randomization is typically used for mobile 350 hosts. 352 5.3. Constant, semantically opaque IIDs 354 This address assignment method allows correlation and location 355 tracking because the IID is constant across IPv6 links and time. 356 Using randomized link-layer addresses doesn't change that. In fact, 357 the constant values allow for correlation between the random link- 358 layer address and the host's identity, removing most of privacy value 359 of random link-layer addresses. 361 Section 4.3 of [I-D.ietf-6man-ipv6-address-generation-privacy] 362 addresses the general case of systems generating constant IID using 363 the algorithms specified in [RFC4941], mentioning the implementation 364 of this algorithm in Windows. Tests on the Windows platform show 365 that the "constant" IIDs do in fact change if the link layer address 366 is changed to a random value, and thus do in fact preserve the 367 privacy value of random link-layer addresses. 369 5.4. DHCPv6 generation of IIDs 371 When using DHCPv6 in conjunction with random link layer addresses, 372 implementers SHOULD follow the recommendations of 373 [I-D.ietf-dhc-anonymity-profile]. 375 5.5. Transition/co-existence technologies 377 Transition technologies typically embed an IPv4 address in a 378 specifically formatted IPv6 address. Tracking over time becomes 379 possible if the IPv4 address has a longer lifetime than the random 380 link-layer address. 382 To mitigate the potential tracking issues with embedded IPv4 383 addresses, hosts using random link-layer addresses SHOULD implement 384 the DHCPv4 profile specified in [I-D.ietf-dhc-anonymity-profile]. 386 6. Security Considerations 388 This whole document concerns the privacy and security properties of 389 different IPv6 address generation mechanisms. 391 7. IANA Considerations 393 This draft does not require any IANA action. 395 8. Acknowledgments 397 The inspiration for this draft came from the authors of 398 [I-D.ietf-6man-ipv6-address-generation-privacy], Alissa Cooper, 399 Fernando Gont, and Dave Thaler. Philip Homburg, Jinmei Tatuya and 400 other members of the 6Man working group provided valuable comments. 402 9. References 404 9.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 412 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 413 2006, . 415 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 416 Extensions for Stateless Address Autoconfiguration in 417 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 418 . 420 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 421 Interface Identifiers with IPv6 Stateless Address 422 Autoconfiguration (SLAAC)", RFC 7217, 423 DOI 10.17487/RFC7217, April 2014, 424 . 426 9.2. Informative References 428 [I-D.ietf-6man-ipv6-address-generation-privacy] 429 Cooper, A., Gont, F., and D. Thaler, "Privacy 430 Considerations for IPv6 Address Generation Mechanisms", 431 draft-ietf-6man-ipv6-address-generation-privacy-07 (work 432 in progress), June 2015. 434 [I-D.ietf-dhc-anonymity-profile] 435 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 436 profile for DHCP clients", draft-ietf-dhc-anonymity- 437 profile-01 (work in progress), June 2015. 439 [IETFMACRandom] 440 Zuniga, JC., "MAC Privacy", November 2014, 441 . 443 Author's Address 445 Christian Huitema 446 Microsoft 447 Redmond, WA 98052 448 U.S.A. 450 Email: huitema@microsoft.com