idnits 2.17.1 draft-ietf-dhc-dhcpv6-privacy-05.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 (February 24, 2016) is 2983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 7749 (Obsoleted by RFC 7991) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational T. Mrugalski 5 Expires: August 27, 2016 ISC 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 February 24, 2016 10 Privacy considerations for DHCPv6 11 draft-ietf-dhc-dhcpv6-privacy-05 13 Abstract 15 DHCPv6 is a protocol that is used to provide addressing and 16 configuration information to IPv6 hosts. This document describes the 17 privacy issues associated with the use of DHCPv6 by the Internet 18 users. It is intended to be an analysis of the present situation and 19 does not propose any solutions. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 27, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Identifiers in DHCPv6 options and fields . . . . . . . . . . 3 58 3.1. Source IPv6 address . . . . . . . . . . . . . . . . . . . 4 59 3.2. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Client Identifier Option . . . . . . . . . . . . . . . . 5 61 3.4. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options . . 5 62 3.5. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5 63 3.6. Client Link-layer Address Option . . . . . . . . . . . . 6 64 3.7. Option Request Option . . . . . . . . . . . . . . . . . . 6 65 3.8. Vendor Class and Vendor-specific Information Options . . 6 66 3.9. Civic Location Option . . . . . . . . . . . . . . . . . . 7 67 3.10. Coordinate-Based Location Option . . . . . . . . . . . . 7 68 3.11. Client System Architecture Type Option . . . . . . . . . 7 69 3.12. Relay Agent Options . . . . . . . . . . . . . . . . . . . 7 70 3.12.1. Subscriber ID Option . . . . . . . . . . . . . . . . 7 71 3.12.2. Interface ID Option . . . . . . . . . . . . . . . . 8 72 3.12.3. Remote ID Option . . . . . . . . . . . . . . . . . . 8 73 3.12.4. Relay-ID Option . . . . . . . . . . . . . . . . . . 8 74 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 8 75 4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 9 76 4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 9 78 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Device type discovery (fingerprinting) . . . . . . . . . 11 80 5.2. Operating system discovery (fingerprinting) . . . . . . . 11 81 5.3. Finding location information . . . . . . . . . . . . . . 11 82 5.4. Finding previously visited networks . . . . . . . . . . . 12 83 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 12 84 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 12 85 5.7. Finding client's IP address or hostname . . . . . . . . . 13 86 5.8. Correlation of activities over time . . . . . . . . . . . 13 87 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 13 88 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 14 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 95 10.2. Informative References . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 DHCPv6 [RFC3315] is a protocol that is used to provide addressing and 101 configuration information to IPv6 hosts. DHCPv6 uses several 102 identifiers that could become a source for gleaning information about 103 the IPv6 host. This information may include device type, operating 104 system information, location(s) that the device may have previously 105 visited, etc. This document discusses the various identifiers used 106 by DHCPv6 and the potential privacy issues [RFC6973]. In particular, 107 it also takes into consideration the problem of pervasive monitoring 108 [RFC7258]. 110 Future works may propose protocol changes to fix the privacy issues 111 that have been analyzed in this document. Protocol changes are out 112 of scope for this document. 114 The primary focus of this document is around privacy considerations 115 for clients to support client mobility and connection to random 116 networks. The privacy of DHCPv6 servers and relay agents are 117 considered less important as they are typically open for public 118 services. And, it is generally assumed that relay agent to server 119 communication is protected from casual snooping, as that 120 communication occurs in the provider's backbone. Nevertheless, the 121 topics involving relay agents and servers are explored to some 122 degree. However, future work may want to further explore privacy of 123 DHCPv6 servers and relay agents. 125 2. Terminology 127 Naming convention from [RFC3315] and related is used throughout this 128 document. In addition the following terminology is used: 130 Stable identifier - Any property disclosed by a DHCPv6 client that 131 does not change over time or changes very infrequently and is 132 unique for said client in a given context. Examples include 133 MAC address, client-id, and a hostname. Some identifiers may 134 be considered stable only under certain conditions, for 135 example one client implementation may keep its client-id 136 stored in stable storage while another may generate it on the 137 fly and use a different one after each boot. Stable 138 identifiers may or may not be globally unique. 140 3. Identifiers in DHCPv6 options and fields 142 In DHCPv6, there are many options that include identification 143 information or that can be used to extract identification information 144 about the client. This section enumerates various options or fields 145 and the identifiers conveyed in them, which can be used to disclose 146 client identification. The attacks that are enabled by such 147 disclosures are detailed in Section 5. 149 3.1. Source IPv6 address 151 Although IPv6 link-local address is technically not a part of DHCPv6, 152 it appears in the DHCPv6 transmissions, so it is mentioned here for 153 completeness. 155 If the client does not use privacy extensions (see [RFC4941]) or 156 similar solutions and its IPv6 link-local address is based on 157 physical link-layer address, this information is disclosed to the 158 DHCPv6 server and to anyone who manages to intercept this 159 transmission. 161 There are multiple cases where IPv6 link-local addresses are used in 162 DHCPv6. Initial client transmissions are always sent from the IPv6 163 link-local addresses even when the server unicast option (see 164 Sections 22.12 and 18 of [RFC3315] for details) is enabled. If there 165 are relay agents, they forward client's traffic wrapped in Relay- 166 forward and store original source IPv6 address in peer-address field. 168 3.2. DUID 170 Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID) 171 [RFC3315]. The DUID is designed to be unique across all DHCPv6 172 clients and servers, and to remain stable after it has been initially 173 generated. The DUID can be of different forms. Commonly used forms 174 are based on the link-layer address of one of the device's network 175 interfaces (with or without a timestamp), on the Universally Unique 176 IDentifier (UUID) [RFC6355]. The default type, defined in 177 Section 9.2 of [RFC3315] is DUID-LLT that is based on link-layer 178 address. It is commonly implemented in most popular clients. 180 It is important to understand DUID lifecycle. Clients and servers 181 are expected to generate their DUID once (during first operation) and 182 store it in a non-volatile storage or use the same deterministic 183 algorithm to generate the same DUID value again. This means that 184 most implementations will use the available link-layer address during 185 its first boot. Even if the administrator enables link-layer address 186 randomization, it is likely that it was not yet enabled during the 187 first device boot. Hence the original, unobfuscated link-layer 188 address will likely end up being announced as client DUID, even if 189 the link-layer address has changed (or even if being changed on a 190 periodic basis). The exposure of the original link-layer address in 191 DUID will also undermine other privacy extensions such as [RFC4941]. 193 3.3. Client Identifier Option 195 The Client Identifier Option (OPTION_CLIENTID) [RFC3315] is used to 196 carry the DUID of a DHCPv6 client between a client and a server. 197 There is an analogous Server Identifier Option but it is not as 198 interesting in the privacy context (unless a host can be convinced to 199 start acting as a server). See Section 3.2 for relevant discussion 200 about DUIDs. 202 3.4. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options 204 The Identity Association for Non-temporary Addresses (IA_NA) option 205 [RFC3315] is used to carry the parameters and any non-temporary 206 addresses associated with the given IA_NA. The Identity Association 207 for Temporary Addresses (IA_TA) option [RFC3315] is analogous to the 208 IA_NA option but for temporary addresses. The IA Address option 209 [RFC3315] is used to specify IPv6 addresses associated with an IA_NA 210 or an IA_TA and is encapsulated within the Options field of such an 211 IA_NA or IA_TA option. The Identity Association for Prefix 212 Delegation (IA_PD) [RFC3633] option is used to carry the prefixes 213 that are assigned to the requesting router. IA Prefix option 214 [RFC3633] is used to specify IPv6 prefixes associated with an IA_PD 215 and is encapsulated within the Options field of such an IA_PD option. 217 To differentiate between instances of the same type of IA containers 218 for a client, each IA_NA, IA_TA and IA_PD options have an IAID field 219 with a unique value for a given IA type. It is up to the client to 220 pick unique IAID values. At least one popular implementation uses 221 last four octets of the link-layer address. In most cases, that 222 means that merely two bytes are missing for a full link-layer address 223 reconstruction. However, the first three octets in a typical link- 224 layer address are vendor identifier. That can be determined with 225 high level of certainty using other means, thus allowing full link- 226 layer address discovery. 228 3.5. Client FQDN Option 230 The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is 231 used by DHCPv6 clients and servers to exchange information about the 232 client's fully qualified domain name and about who has the 233 responsibility for updating the DNS with the associated AAAA and PTR 234 RRs. 236 A client can use this option to convey all or part of its domain name 237 to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most 238 case a client sends its hostname as a hint for the server. The 239 DHCPv6 server may be configured to modify the supplied name or to 240 substitute a different name. The server should send its notion of 241 the complete FQDN for the client in the Domain Name field. 243 3.6. Client Link-layer Address Option 245 The Client link-layer address option [RFC6939] is used by first-hop 246 DHCPv6 relays to provide the client's link-layer address towards the 247 server. 249 DHCPv6 relay agents that receive messages originating from clients 250 may include the link-layer source address of the received DHCPv6 251 message in the Client Link-Layer Address option, in relayed DHCPv6 252 Relay-Forward messages. 254 3.7. Option Request Option 256 DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6 257 messages to inform the server about options the client wants the 258 server to send to the client. 260 The content of an Option Request option are the option codes for 261 options requested by the client. The client may additionally include 262 instances of those options that are identified in the Option Request 263 option, with data values as hints to the server about parameter 264 values the client would like to have returned. 266 3.8. Vendor Class and Vendor-specific Information Options 268 The Vendor Class option, defined in Section 22.16 of [RFC3315], is 269 used by a DHCPv6 client to identify the vendor that manufactured the 270 hardware on which the client is running. 272 The Vendor-specific Information option, defined in Section 22.17 of 273 [RFC3315], includes enterprise number, which identifies the client's 274 vendor and often includes a number of additional parameters that are 275 specific to a given vendor. That may include any type of information 276 the vendor deems useful. It should be noted that this information 277 may be present (and different) in both directions: client to server 278 and server to client communications. 280 The information contained in the data area of this option is 281 contained in one or more opaque fields that identify details of the 282 hardware configuration, for example, the version of the operating 283 system the client is running or the amount of memory installed on the 284 client. 286 3.9. Civic Location Option 288 DHCPv6 servers use the Civic Location option [RFC4776] to deliver 289 location information (the civic and postal addresses) from the DHCPv6 290 server to DHCPv6 clients. It may refer to three locations: the 291 location of the DHCPv6 server, the location of the network element 292 believed to be closest to the client, or the location of the client, 293 identified by the "what" element within the option. 295 3.10. Coordinate-Based Location Option 297 The GeoLoc options [RFC6225] are used by DHCPv6 server to provide 298 coordinate-based geographic location information to DHCPv6 clients. 299 They enable a DHCPv6 client to obtain its location. 301 3.11. Client System Architecture Type Option 303 The Client System Architecture Type option [RFC5970] is used by 304 DHCPv6 client to send a list of supported architecture types to the 305 DHCPv6 server. It is used by clients that must be booted using the 306 network rather than from local storage, so the server can decide 307 which boot file should be provided to the client. 309 3.12. Relay Agent Options 311 A DHCPv6 relay agent may include a number of options. Those option 312 contain information that can be used to identify the client. Those 313 options are almost exclusively exchanged between the relay agent and 314 the server, thus never leaving the operators network. In particular, 315 they're almost never present in the last wireless hop in case of WiFi 316 networks. The only exception to that rule is somewhat infrequently 317 used Relay Supplied Options option [RFC6422]. This fact implies that 318 the threat model related relay options is slightly different. 319 Traffic sniffing at the last hop and related class of attacks 320 typically do not apply. On the other hand, all attacks that involve 321 operator's intfrastructure (either willing or coerced cooperation or 322 infrastructure being compromised) usually apply. 324 The following subsections describe various options inserted by the 325 relay agents. 327 3.12.1. Subscriber ID Option 329 A DHCPv6 relay may include a Subscriber ID option [RFC4580] to 330 associate some provider-specific information with clients' DHCPv6 331 messages that is independent of the physical network configuration. 333 In many deployments, the relay agent that inserts this option is 334 configured to use client's link-layer address as Subscriber ID. 336 3.12.2. Interface ID Option 338 A DHCPv6 relay includes the Interface ID [RFC3315] option to identify 339 the interface on which it received the client message that is being 340 relayed. 342 Although in principle Interface ID can be arbitrarily long with 343 completely random values, it is sometimes a text string that includes 344 the relay agent name followed by interface name. This can be used 345 for fingerprinting the relay or determining client's point of 346 attachment. 348 3.12.3. Remote ID Option 350 A DHCPv6 relay includes a Remote ID option [RFC4649] to identify the 351 remote host end of the circuit. 353 The remote-id is vendor specific, for which the vendor is indicated 354 in the enterprise-number field. The remote-id field may encode the 355 information that identified DHCPv6 clients: 357 o a "caller ID" telephone number for dial-up connection 359 o a "user name" prompted for by a Remote Access Server 361 o a remote caller ATM address o a "modem ID" of a cable data modem 363 o the remote IP address of a point-to-point link 365 o an interface or port identifier 367 3.12.4. Relay-ID Option 369 Relay agent may include Relay-ID [RFC5460], which contains a unique 370 relay agent identifier. While its intended use is to provide 371 additional information for the server, so it would be able to respond 372 to leasequeries later, this information can be also used to identify 373 client's location within the network. 375 4. Existing Mechanisms That Affect Privacy 377 This section describes deployed DHCPv6 mechanisms that can affect 378 privacy. 380 4.1. Temporary addresses 382 [RFC3315] defines a mechanism for a client to request temporary 383 addresses. The idea behind temporary addresses is that a client can 384 request a temporary address for a specific purpose, use it, and then 385 never renew it. i.e. let it expire. 387 There are a number of serious issues, both related to protocol and 388 its implementations, that make temporary addresses nearly useless for 389 their original goal. First, [RFC3315] does not include T1 and T2 390 renewal timers in IA_TA (a container for temporary addresses). 391 However, in section 18.1.3 it explicitly mentions that temporary 392 addresses can be renewed. Client implementations may mistakenly 393 renew temporary addresses if they are not careful (i.e., by including 394 the IA_TA with the same IAID in Renew or Rebind requests, rather than 395 a new IAID - see [RFC3315] Section 22.5), thus forfeiting short 396 liveness. [RFC4704] does not explicitly prohibit servers to update 397 DNS for assigned temporary addresses and there are implementations 398 that can be configured to do that. However, this is not advised as 399 publishing a client's IPv6 address in DNS that is publicly available 400 is a major privacy breach. 402 4.2. DNS Updates 404 The Client FQDN Option[RFC4704] used along with DNS Update [RFC2136] 405 defines a mechanism that allows both clients and server to insert 406 into the DNS domain information about clients. Both forward (AAAA) 407 and reverse (PTR) resource records can be updated. This allows other 408 nodes to conveniently refer to a host, despite the fact that its IPv6 409 address may be changing. 411 This mechanism exposes two important pieces of information: current 412 address (which can be mapped to current location) and client's 413 hostname. The stable hostname can then by used to correlate the 414 client across different network attachments even when its IPv6 415 address keeps changing. 417 4.3. Allocation strategies 419 A DHCPv6 server running in typical, stateful mode is given a task of 420 managing one or more pools of IPv6 resources (currently non-temporary 421 addresses, temporary addresses and/or prefixes, but more resource 422 types may be defined in the future). When a client requests a 423 resource, server must pick a resource out of configured pool. 424 Depending on the server's implementation, various allocation 425 strategies are possible. Choices in this regard may have privacy 426 implications. 428 Iterative allocation - a server may choose to allocate addresses one 429 by one. That strategy has the benefit of being very fast, thus being 430 favored in deployments that prefer performance. However, it makes 431 the resources very predictable. Also, since the resources allocated 432 tend to be clustered at the beginning of an available pool, it makes 433 scanning attacks much easier. 435 Identifier-based allocation - some server implementations use a fixed 436 identifier for a specific client, seemingly taken from the client's 437 MAC address when available or some lower bits of client's source IPv6 438 address. This has a property of being convenient for converting IP 439 address to/from other identifiers, especially if the identifier is or 440 contains MAC address. It is also convenient, as a returning client 441 is very likely to get the same address, even if the server does not 442 retain previous client's address. Those properties are convenient 443 for system administrators, so DHCPv6 server implementors are 444 sometimes requested to implement it. There is at least one 445 implementation that supports it. The downside of such allocation is 446 that the client now discloses its identifier in its IPv6 address to 447 all services it connects to. That means that correlation of 448 activities over time, location tracking, address scanning and OS/ 449 vendor discovery attacks apply. 451 Hash allocation - it's an extension of identifier-based allocation. 452 Instead of using the identifier directly, it is hashed first. If the 453 hash is implemented correctly, it removes the flaw of disclosing the 454 identifier, a property that eliminates susceptibility to address 455 scanning and OS/vendor discovery. If the hash is poorly implemented 456 (e.g., can be reversed), it introduces no improvement over 457 identifier-based allocation. Even a well implemented hash does not 458 mitigate the threat of correlation over time. 460 Random allocation - a server can pick a resource pseudo-randomly out 461 of an available pool. This allocation scheme essentially prevents 462 returning clients from getting the same address or prefix again. On 463 the other hand, it is beneficial from privacy perspective as 464 addresses and prefixes generated that way are not susceptible to 465 correlation attacks, OS/vendor discovery attacks, or identity 466 discovery attacks. Note that even though the address or prefix 467 itself may be resilient to a given attack, the client may still be 468 susceptible if additional information is disclosed other way, e.g., 469 the client's address may be randomized, but it still can leak its MAC 470 address in the client-id option. 472 Other allocation strategies may be implemented. 474 5. Attacks 476 5.1. Device type discovery (fingerprinting) 478 The type of device used by the client can be guessed by the attacker 479 using the Vendor Class option, Vendor-specific Information option, 480 the Client Link-layer Address option, and by parsing the Client ID 481 option. All of those options may contain OUI (Organizationally 482 Unique Identifier) that represents the device's vendor. That 483 knowledge can be used for device-specific vulnerability exploitation 484 attacks. See Section 3.4 of 485 [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion 486 about this type of attack. 488 5.2. Operating system discovery (fingerprinting) 490 The operating system running on a client can be guessed using the 491 Vendor Class option, the Vendor-specific Information option, the 492 Client System Architecture Type option, or by using fingerprinting 493 techniques on the combination of options requested using the Option 494 Request option. See Section 3.4 of 495 [I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion 496 about this type of attack. 498 5.3. Finding location information 500 The physical location information can be obtained by the attacker by 501 many means. The most direct way to obtain this information is by 502 looking into a message originating from the server that contains the 503 Civic Location or GeoLoc option. It can also be indirectly inferred 504 using the Remote ID option, the Interface ID option (e.g., if an 505 access circuit on an Access Node corresponds to a civic location), or 506 the Subscriber ID option (if the attacker has access to subscriber 507 info). 509 Another way to discover client's physical location is to use 510 geolocation services. Those services typically map IP prefixes into 511 geographical locations. Those services are usually based on known 512 locations of the subnet, so they may reveal client's location as 513 precise as they can locate a network it is connected to. They 514 usually are not able to discover specific physical location within a 515 network. That is not awlays true and it depends on the quality of 516 the apriori information available in the geolocation services 517 databases. It should be noted that this threat is general to the 518 DHCPv6 mechanism. Regardless of the allocation strategy used by the 519 DHCPv6 server implementation, the addresses assigned will always 520 belong to the subnet the server is configured to manage. Cases of 521 using ULA (Unique Local Addresses) assigned by the DHCPv6 server are 522 out of scope for this document. 524 5.4. Finding previously visited networks 526 When DHCPv6 clients connect to a network, they attempt to obtain the 527 same address they had used before they attached to the network. They 528 do this by putting the previously assigned address(es) in the IA 529 Address option(s). [RFC3315] does not exclude IA_TA in such a case, 530 so it is possible that a client implementation includes an address 531 contained in an IA_TA for the Confirm message. By observing these 532 addresses, an attacker can identify the network the client had 533 previously visited. 535 5.5. Finding a stable identity 537 An attacker might use a stable identity gleaned from DHCPv6 messages 538 to correlate activities of a given client on unrelated networks. The 539 Client FQDN option, the Subscriber ID option, and the Client ID 540 option can serve as long-lived identifiers of DHCPv6 clients. The 541 Client FQDN option can also provide an identity that can easily be 542 correlated with web server activity logs. 544 It should be noted that in general case, the MAC addresses as such 545 are not available in the DHCPv6 packets. Therefore they cannot be 546 used directly in a reliable way. However, they may become indirectly 547 available using other mechanisms: client-id contains link-local 548 address if DUID-LL or DUID-LLT types are used, source IPv6 address 549 may use EUI-64 that contains MAC address, some access technologies 550 may specify MAC address in dedicated options (e.g., cable modems use 551 MAC addresses in DOCSIS options). Relay agents may insert additional 552 information that are used to help the server to identify the client. 553 This could be Remote-Id option, Subscriber-Id option, client link- 554 layer address option or vendor specific information options. Options 555 inserted by relay agents usually traverse only relay-server path, so 556 they typically can't be eavesdropped by intercepting client's 557 transmissions. This depends on the actual deployment model and used 558 access technologies. 560 5.6. Pervasive monitoring 562 Pervasive Monitoring (PM) is widespread (and often covert) 563 surveillance through intrusive gathering of protocol artefacts, 564 including application content, or protocol metadata such as headers. 565 Active or passive wiretaps and traffic analysis, (e.g., correlation, 566 timing or measuring packet sizes), or subverting the cryptographic 567 keys used to secure protocols can also be used as part of pervasive 568 monitoring. PM is distinguished by being indiscriminate and very 569 large scale, rather than by introducing new types of technical 570 compromise. See [RFC7258] for a discussion about PM. 572 In the DHCPv6 context, PM approach can be used to collect any 573 identifiers discussed in Section 3. DHCPv4 and DHCPv6 are especially 574 susceptible as the initial message sent (SOLICIT in case of DHCPv6) 575 is one of the very first packets sent when visiting a network. 576 Furthermore, in certain cases this packet can be logged even on 577 networks that do not support IPv6 (some implementations initiate 578 DHCPv6 even without receiving RA with M or O bits set). This may be 579 an easily overlooked attack vector when IPv6-capable device connects 580 to an IPv4 only network, gains only IPv4 connectivity, but still 581 leaks its stable identifiers over DHCPv6. 583 Using PM approach, attacks discussed in Sections 5.1, 5.2, 5.3, 5.4, 584 5.5, 5.7, 5.8 and possibly 5.9 apply. 586 5.7. Finding client's IP address or hostname 588 Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's 589 information (current IP address, client's hostname) into the DNS, 590 where it is easily accessible by anyone interested. Client ID is 591 also disclosed, albeit in not easily accessible form (SHA-256 digest 592 of the client-id). As SHA-256 is considered irreversible, DHCID 593 can't be converted back to client-id. However, SHA-256 digest can be 594 used as an unique identifier that is accessible by any host. 596 5.8. Correlation of activities over time 598 As with other identifiers, an IPv6 address can be used to correlate 599 the activities of a host for at least as long as the lifetime of the 600 address. If that address was generated from some other, stable 601 identifier and that generation scheme can be deduced by an attacker, 602 the duration of the correlation attack extends to that of the 603 identifier. In many cases, its lifetime is equal to the lifetime of 604 the device itself. See Section 3.1 of 605 [I-D.ietf-6man-ipv6-address-generation-privacy] for detailed 606 discussion. 608 5.9. Location tracking 610 If a stable identifier is used for assigning an address and such 611 mapping is discovered by an attacker (e.g., a server that uses IEEE- 612 identifier-based IID to generate IPv6 address), all scenarios 613 discussed in Section 3.2 of 614 [I-D.ietf-6man-ipv6-address-generation-privacy] apply. In particular 615 both passive (a service that the client connects to can log the 616 client's address and draw conclusions regarding its location and 617 movement patterns based on the prefix it is connecting from) and 618 active (an attacker can send ICMPv6 echo requests or other probe 619 packets to networks of suspected client locations) can be used. To 620 give specific example, by accessing a social portal from tomek- 621 laptop.coffee.somecity.com.example, tomek- 622 laptop.mycompany.com.example and tomek-laptop.myisp.example.com, the 623 portal administrator can draw conclusions about tomek-laptop's 624 owner's current location and his habits. 626 5.10. Leasequery & bulk leasequery 628 Attackers may masquerade to be an access concentrator, either as a 629 DHCPv6 relay agent or as a DHCPv6 client, to obtain location 630 information directly from the DHCPv6 server(s) using the DHCPv6 631 Leasequery [RFC5007] mechanism. 633 Location information is information needed by the access concentrator 634 to forward traffic to a broadband-accessible host. This information 635 includes knowledge of the host hardware address, the port or virtual 636 circuit that leads to the host, and/or the hardware address of the 637 intervening subscriber modem. 639 Furthermore, the attackers may use the DHCPv6 bulk leasequery 640 [RFC5460] mechanism to obtain bulk information about DHCPv6 bindings, 641 even without knowing the target bindings. 643 Additionally, active leasequery [RFC7653] is a mechanism for 644 subscribing to DHCPv6 lease update changes in near real-time. The 645 intent of this mechanism is to update an operator's database, but if 646 misused, an attacker could defeat the server's authentication 647 mechanisms and subscribe to all updates. He then could continue 648 receiving updates, without any need for local presence. 650 6. Security Considerations 652 In current practice, the client privacy and client authentication are 653 mutually exclusive. The client authentication procedure reveals 654 additional client information in their certificates/identifiers. 655 Full privacy for the clients may mean the clients are also anonymous 656 to the server and the network. 658 7. Privacy Considerations 660 This document in its entirety discusses privacy considerations in 661 DHCPv6. As such, no dedicated discussion is needed. 663 8. IANA Considerations 665 This draft does not request any IANA action. 667 9. Acknowledgements 669 The authors would like to thank Stephen Farrell, Ted Lemon, Ines 670 Robles, Russ White, Christian Schaefer, Jinmei Tatuya, Bernie Volz, 671 Marcin Siodelski, Christian Huitema, Brian Haberman, Robert Sparks, 672 Peter Yee, Ben Campbell and other members of DHC WG for their 673 valuable comments. 675 This document was produced using the xml2rfc tool [RFC7749]. 677 10. References 679 10.1. Normative References 681 [I-D.ietf-6man-ipv6-address-generation-privacy] 682 Cooper, A., Gont, F., and D. Thaler, "Privacy 683 Considerations for IPv6 Address Generation Mechanisms", 684 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 685 in progress), September 2015. 687 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 688 C., and M. Carney, "Dynamic Host Configuration Protocol 689 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 690 2003, . 692 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 693 Morris, J., Hansen, M., and R. Smith, "Privacy 694 Considerations for Internet Protocols", RFC 6973, 695 DOI 10.17487/RFC6973, July 2013, 696 . 698 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 699 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 700 2014, . 702 10.2. Informative References 704 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 705 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 706 RFC 2136, DOI 10.17487/RFC2136, April 1997, 707 . 709 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 710 Host Configuration Protocol (DHCP) version 6", RFC 3633, 711 DOI 10.17487/RFC3633, December 2003, 712 . 714 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 715 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 716 DOI 10.17487/RFC4580, June 2006, 717 . 719 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 720 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 721 DOI 10.17487/RFC4649, August 2006, 722 . 724 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 725 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 726 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 727 . 729 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 730 (DHCPv4 and DHCPv6) Option for Civic Addresses 731 Configuration Information", RFC 4776, 732 DOI 10.17487/RFC4776, November 2006, 733 . 735 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 736 Extensions for Stateless Address Autoconfiguration in 737 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 738 . 740 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 741 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 742 September 2007, . 744 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 745 DOI 10.17487/RFC5460, February 2009, 746 . 748 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 749 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, 750 September 2010, . 752 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed., 753 "Dynamic Host Configuration Protocol Options for 754 Coordinate-Based Location Configuration Information", 755 RFC 6225, DOI 10.17487/RFC6225, July 2011, 756 . 758 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 759 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 760 DOI 10.17487/RFC6355, August 2011, 761 . 763 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 764 RFC 6422, DOI 10.17487/RFC6422, December 2011, 765 . 767 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 768 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 769 May 2013, . 771 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 772 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 773 October 2015, . 775 [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", 776 RFC 7749, DOI 10.17487/RFC7749, February 2016, 777 . 779 Authors' Addresses 781 Suresh Krishnan 782 Ericsson 783 8400 Decarie Blvd. 784 Town of Mount Royal, QC 785 Canada 787 Phone: +1 514 345 7900 x42871 788 Email: suresh.krishnan@ericsson.com 790 Tomek Mrugalski 791 Internet Systems Consortium, Inc. 792 950 Charter Street 793 Redwood City, CA 94063 794 USA 796 Email: tomasz.mrugalski@gmail.com 797 Sheng Jiang 798 Huawei Technologies Co., Ltd 799 Q14, Huawei Campus, No.156 BeiQing Road 800 Hai-Dian District, Beijing 100095 801 P.R. China 803 Email: jiangsheng@huawei.com