idnits 2.17.1 draft-jiang-dhc-dhcp-privacy-00.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 (October 27, 2014) is 3462 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 informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track S. Krishnan 5 Expires: April 30, 2015 Ericsson 6 T. Mrugalski 7 ISC 8 October 27, 2014 10 Privacy considerations for DHCP 11 draft-jiang-dhc-dhcp-privacy-00 13 Abstract 15 DHCP is a protocol that is used to provide addressing and 16 configuration information to IPv4 hosts. This document discusses the 17 various identifiers used by DHCP and the potential privacy issues. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Identifiers in DHCP . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Client ID Option . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Address Fields & Options . . . . . . . . . . . . . . . . 4 58 3.3. Subscriber-ID Option . . . . . . . . . . . . . . . . . . 4 59 3.4. Relay Agent Information Option and Sub-options . . . . . 4 60 3.5. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5 61 3.6. Parameter Request List Option . . . . . . . . . . . . . . 5 62 3.7. Vendor Class and Vendor-Identifying Vendor Class Options 5 63 3.8. Civic Location Option . . . . . . . . . . . . . . . . . . 6 64 3.9. Coordinate-Based Location Option . . . . . . . . . . . . 6 65 3.10. Client System Architecture Type Option . . . . . . . . . 6 66 4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 6 67 4.1. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Allocation strategies . . . . . . . . . . . . . . . . . . 7 69 5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Device type discovery . . . . . . . . . . . . . . . . . . 8 71 5.2. Operating system discovery . . . . . . . . . . . . . . . 8 72 5.3. Finding location information . . . . . . . . . . . . . . 8 73 5.4. Finding previously visited networks . . . . . . . . . . . 9 74 5.5. Finding a stable identity . . . . . . . . . . . . . . . . 9 75 5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 9 76 5.7. Finding client's IP address or hostname . . . . . . . . . 9 77 5.8. Correlation of activities over time . . . . . . . . . . . 9 78 5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 9 79 5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 10.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Dynamic Host Configuration Protocol (DHCP) [RFC2131] is a protocol 92 that is used to provide addressing and configuration information to 93 IPv4 hosts. The DHCP protocol uses several identifiers that could 94 become a source for gleaning additional information about the IPv4 95 host. This information may include device type, operating system 96 information, location(s) that the device may have previously visited, 97 etc. This document discusses the various identifiers used by DHCP 98 and the potential privacy issues [RFC6973]. 100 Future works may propose protocol changes to fix the privacy issues 101 that have been analyzed in this document. It is out of scope for 102 this document. 104 Editor notes: for now, the document is mainly considering the privacy 105 of DHCP client. The privacy of DHCP server and relay agent are 106 considered less important because they are open for public services. 107 However, this may be a subject to change if further study shows 108 opposite result. 110 2. Terminology 112 This section clarifies the terminology used throughout this document. 114 Stable identifier - any property disclosed by a DHCP client that does 115 not change over time or changes very infrequently and is unique for 116 said client in a given context. Examples include MAC address, 117 client-id that does not change or a hostname. Stable identifier may 118 or may not be globally unique. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. When these 123 words are not in ALL CAPS (such as "should" or "Should"), they have 124 their usual English meanings, and are not to be interpreted as 125 [RFC2119] key words. 127 3. Identifiers in DHCP 129 There are several identifiers used in DHCP. This section provides an 130 introduction to the various options that will be used further in the 131 document. 133 3.1. Client ID Option 135 The Client Identifier Option [RFC2131] is used to pass an explicit 136 client identifier to a DHCP server. There is an analogous Server 137 Identifier Option but it is not as interesting in the privacy context 138 (unless a host can be convinced to start acting as a server). 140 The client identifier is an opaque key, which must be unique to that 141 client within the subnet to which the client is attached. It 142 typically remains stable after it has been initially generated. It 143 may contain a hardware address, identical to the contents of the 144 'chaddr' field, or another type of identifier, such as a DNS name. 145 It is recommended that client identifiers be generated by using the 146 permanent link-layer address of the network interface that the client 147 is trying to configure. [RFC4361] updates the recommendation of 148 Client Identifiers to be "consists of a type field whose value is 149 normally 255, followed by a four-byte IA_ID field, followed by the 150 DUID for the client as defined in RFC 3315, section 9". This does 151 not change the lifecycle of the Client Identifiers. Clients are 152 expected to generate their Client Identifiers once (during first 153 operation) and store it in a non-volatile storage or use the same 154 deterministic algorithm to generate the same Client Identifier values 155 again. 157 3.2. Address Fields & Options 159 The 'yiaddr' field [RFC2131] in DHCP message is used to allocate 160 address from the server to the client. 162 The DHCPv4 specification [RFC2131] provides a way to specify the 163 client link-layer address in the DHCPv4 message header. A DHCPv4 164 message header has 'htype' and 'chaddr' fields to specify the client 165 link-layer address type and the link-layer address, respectively. 166 The 'chaddr' field is used both as a hardware address for 167 transmission of reply messages and as a client identifier. 169 The 'requested IP address' option [RFC2131] is used by client to 170 suggest that a particular IP address be assigned. 172 3.3. Subscriber-ID Option 174 A DHCP relay includes a Subscriber-ID option [RFC3993] to associate 175 some provider-specific information with clients' DHCP messages that 176 is independent of the physical network configuration through which 177 the subscriber is connected. 179 The "subscriber-id" assigned by the provider is intended to be stable 180 as customers connect through different paths, and as network changes 181 occur. The Subscriber-ID is an ASCII string, which is assigned and 182 configured by the network provider. 184 3.4. Relay Agent Information Option and Sub-options 186 A DHCP relay agent includes a Relay Agent Information [RFC3046] to 187 identify the remote host end of the circuit. It contains a "circuit 188 ID" sub-option for the incoming circuit, which is an agent-local 189 identifier of the circuit from which a DHCP client-to-server packet 190 was received, and a "remote ID" sub-option which provides a trusted 191 identifier for the remote high-speed modem. 193 Possible encoding of "circuit ID" sub-option includes: router 194 interface number, switching hub port number, remote access server 195 port number, frame relay DLCI, ATM virtual circuit number, cable data 196 virtual circuit number, etc. 198 Possible encoding of the "remote ID" sub-option includes: a "caller 199 ID" telephone number for dial-up connection, a "user name" prompted 200 for by a remote access server, a remote caller ATM address, a "modem 201 ID" of a cable data modem, the remote IP address of a point-to-point 202 link, a remote X.25 address for X.25 connections, etc. 204 The link-selection sub-option [RFC3527] is used by any DHCP relay 205 agent that desires to specify a subnet/link for a DHCP client request 206 that it is relaying but needs the subnet/link specification to be 207 different from the IP address the DHCP server should use when 208 communicating with the relay agent. It contains an IP address, which 209 can identify the client's subnet/link. 211 3.5. Client FQDN Option 213 The Client Fully Qualified Domain Name (FQDN) option [RFC4702] is 214 used by DHCP clients and servers to exchange information about the 215 client's fully qualified domain name and about who has the 216 responsibility for updating the DNS with the associated AAAA and PTR 217 RRs. 219 A client can use this option to convey all or part of its domain name 220 to a DHCP server for the IP-address-to-FQDN mapping. In most case a 221 client sends its hostname as a hint for the server. The DHCP server 222 MAY be configured to modify the supplied name or to substitute a 223 different name. The server should send its notion of the complete 224 FQDN for the client in the Domain Name field. 226 3.6. Parameter Request List Option 228 The Parameter Request List option [RFC2131] is used to inform the 229 server about options the client wants the server to send to the 230 client. The content of a Parameter Request List option are the 231 option codes for an option requested by the client. 233 3.7. Vendor Class and Vendor-Identifying Vendor Class Options 235 The Vendor Class option [RFC2131] and the Vendor-Identifying Vendor 236 Class option [RFC3925] is used by a DHCP client to identify the 237 vendor that manufactured the hardware on which the client is running. 239 The information contained in the data area of this option is 240 contained in one or more opaque fields that identify the details of 241 the hardware configuration of the host on which the client is 242 running, or of industry consortium compliance, for example, the 243 version of the operating system the client is running or the amount 244 of memory installed on the client. 246 3.8. Civic Location Option 248 DHCP servers use the Civic Location Option [RFC4776] to delivery of 249 the location information (the civic and postal addresses) to the DHCP 250 clients. It may refer to three locations: the location of the DHCP 251 server, the location of the network element believed to be closest to 252 the client, or the location of the client, identified by the "what" 253 element within the option. 255 3.9. Coordinate-Based Location Option 257 The GeoConf and GeoLoc options [RFC6225] is used by DHCP server to 258 provide the coordinate-based geographic location information to the 259 DHCP clients. It enables a DHCP client to obtain its geographic 260 location. 262 After the relevant DHCP exchanges have taken place, the location 263 information is stored on the end device rather than somewhere else, 264 where retrieving it might be difficult in practice. 266 3.10. Client System Architecture Type Option 268 The Client System Architecture Type Option [RFC4578] is used by DHCP 269 client to send a list of supported architecture types to the DHCP 270 server. It is used to provide configuration information for a node 271 that must be booted using the network rather than from local storage. 273 4. Existing Mechanisms That Affect Privacy 275 This section describes available DHCP mechanisms that one can use to 276 protect or enhance one's privacy. 278 4.1. DNS Updates 280 DNS Updates [RFC4704] defines a mechanism that allows both clients 281 and server to insert into DNS domain information about clients. Both 282 forward (AAAA) and reverse (PTR) resource records can be updated. 283 This allows other nodes to conveniently refer to a host, despite the 284 fact that its IP address may be changing. 286 This mechanism exposes two important pieces of information: current 287 address (which can be mapped to current location) and client's 288 hostname. The stable hostname can then by used to correlate the 289 client across different network attachments even when its IP 290 addresses keep changing. 292 4.2. Allocation strategies 294 A DHCP server running in typical, stateful mode is given a task of 295 managing one or more pools of IP address resources. When a client 296 requests a resource, server must pick a resource out of configured 297 pool. Depending on the server's implementation, various allocation 298 strategies are possible. Choices in this regard may have privacy 299 implications. 301 Iterative allocation - a server may choose to allocate addresses one 302 by one. That strategy has the benefit of being very fast, thus can 303 be favored in deployments that prefer performance. However, it makes 304 the resources very predictable. Also, since the resources allocated 305 tend to be clustered at the beginning of available pool, it makes 306 scanning attacks much easier. 308 Identifier-based allocation - a server may choose to allocate an 309 address that is based on one of available identifiers, e.g. client 310 identifier or MAC address. It is also convenient, as returning 311 client is very likely to get the same address. Those properties are 312 convenient for system administrators, so DHCP server implementors are 313 often requested to implement it. On the other hand, the downside of 314 such allocation is that the client has a very stable IP address. 315 That means that correlation of activities over time, location 316 tracking, address scanning and OS/vendor discovery apply. 318 Hash allocation - it's an extension of identifier based allocation. 319 Instead of using the identifier directly, it is being hashed first. 320 If the hash is implemented correctly, it removes the flaw of 321 disclosing the identifier, a property that eliminates susceptibility 322 to address scanning and OS/vendor discovery. If the hash is poorly 323 implemented (e.g. can be reverted), it introduces no improvement over 324 identifier-based allocation. 326 Random allocation - a server can pick a resource randomly out of 327 available pool. That strategy works well in scenarios where pool 328 utilization is small, as the likelihood of collision (resulting in 329 the server needing to repeat randomization) is small. With the pool 330 allocation increasing, the collision is disproportionally large, due 331 to birthday paradox. With high pool utilization (e.g. when 90% of 332 available resources being allocated already), the server will use 333 most computational resources to repeatedly pick a random resource, 334 which will degrade its performance. This allocation scheme 335 essentially prevents returning clients from getting the same address 336 again. On the other hand, it is beneficial from privacy perspective 337 as addresses generated that way are not susceptible to correlation 338 attacks, OS/vendor discovery attacks or identity discovery attacks. 339 Note that even though the address itself may be resilient to a given 340 attack, the client may still be susceptible if additional information 341 is disclosed other way, e.g. client's address can be randomized, but 342 it still can leak its MAC address in client-id option. 344 Other allocation strategies may be implemented. 346 However, giving the limited resource of IPv4 public address pool, 347 allocation mechanism in IPv4 may not provide much protection, while 348 in IPv6, the network has very large address space to distribute the 349 address allocation. 351 5. Attacks 353 5.1. Device type discovery 355 The type of device used by the client can be guessed by the attacker 356 using the Vendor Class Option, the 'chaddr' field, and by parsing the 357 Client ID Option. All of those options may contain OUI 358 (Organizationally Unique Identifier) that represents the device's 359 vendor. That knowledge can be used for device-specific vulnerability 360 exploitation attacks. 362 5.2. Operating system discovery 364 The operating system running on a client can be guessed using the 365 Vendor Class option, the Client System Architecture Type option, or 366 by using fingerprinting techniques on the combination of options 367 requested using the Parameter Request List option. 369 5.3. Finding location information 371 The location information can be obtained by the attacker by many 372 means. The most direct way to obtain this information is by looking 373 into a server initiated message that contains the Civic Location, 374 GeoConf, or GeoLoc options. It can also be indirectly inferred using 375 the Relay Agent Information option, with the remote ID sub-option 376 (e.g. using a telephone number), the circuit ID option (e.g. if an 377 access circuit on an Access Node corresponds to a civic location), or 378 the Subscriber ID Option (if the attacker has access to subscriber 379 info). 381 5.4. Finding previously visited networks 383 When DHCP clients connect to a network, they attempt to obtain the 384 same address they had used before they attached to the network. They 385 do this by putting the previously assigned address in the requested 386 IP address option. By observing these addresses, an attacker can 387 identify the network the client had previously visited. 389 5.5. Finding a stable identity 391 An attacker might use a stable identity gleaned from DHCP messages to 392 correlate activities of a given client on unrelated networks. The 393 Client FQDN option, the Subscriber ID Option and the Client ID 394 options can serve as long lived identifiers of DHCP clients. The 395 Client FQDN option can also provide an identity that can easily be 396 correlated with web server activity logs. 398 5.6. Pervasive monitoring 400 This is an enhancement, or a combination of most aforementioned 401 mechanisms. Operator who controls non-trivial number of access 402 points or network segments, may use obtained information about a 403 single client and observer client's habits. 405 5.7. Finding client's IP address or hostname 407 Many DHCP deployments use DNS Updates [RFC4702] that put client's 408 information (current IP address, client's hostname). Client ID is 409 also disclosed, able it in not easily accessible form (SHA-256 digest 410 of the client-id). Although SHA-256 is irreversible, so DHCID can't 411 be converted back to client-id. However, SHA-256 digest can be used 412 as a unique identifier that is accessible by any host. 414 5.8. Correlation of activities over time 416 As with other identifiers, an IP address can be used to correlate the 417 activities of a host for at least as long as the lifetime of the 418 address. If that address was generated from some other, stable 419 identifier and that generation scheme can be deducted by an attacker, 420 the duration of correlation attack extends to that identifier. In 421 many cases, its lifetime is equal to the lifetime of the device 422 itself. 424 5.9. Location tracking 426 If a stable identifier is used for assigning an address and such 427 mapping is discovered by an attacker. In particular both passive (a 428 service that the client connects to can log client's address and draw 429 conclusions regarding its location and movement patterns based on 430 address it is connecting from) and active (attacker can send ICMP 431 echo requests or other probe packets to networks of suspected client 432 locations). 434 5.10. Leasequery & bulk leasequery 436 Attackers may pretend as an access concentrator, either DHCP relay 437 agent or DHCP client, to obtain location information directly from 438 the DHCP server(s) using the DHCP Leasequery [RFC4388], [RFC6148] 439 mechanism. 441 Location information is information needed by the access concentrator 442 to forward traffic to a broadband-accessible host. This information 443 includes knowledge of the host hardware address, the port or virtual 444 circuit that leads to the host, and/or the hardware address of the 445 intervening subscriber modem. 447 Furthermore, the attackers may use DHCP bulk leasequery [RFC6926] 448 mechanism to obtain bulk information about DHCP bindings, even 449 without knowing the target bindings. 451 6. Security Considerations 453 TBD 455 7. Privacy Considerations 457 This document at its entirety discusses privacy considerations in 458 DHCP. As such, no separate section about this is needed. 460 8. IANA Considerations 462 This draft does not request any IANA action. 464 9. Acknowledgements 466 The authors would like to thanks the valuable comments made by 467 Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian 468 Schaefer and other members of DHC WG. 470 This document was produced using the xml2rfc tool [RFC2629]. 472 10. References 473 10.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 479 2131, March 1997. 481 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 482 3046, January 2001. 484 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 485 "Link Selection sub-option for the Relay Agent Information 486 Option for DHCPv4", RFC 3527, April 2003. 488 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 489 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 490 RFC 3925, October 2004. 492 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 493 Suboption for the Dynamic Host Configuration Protocol 494 (DHCP) Relay Agent Option", RFC 3993, March 2005. 496 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 497 Identifiers for Dynamic Host Configuration Protocol 498 Version Four (DHCPv4)", RFC 4361, February 2006. 500 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 501 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 503 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 504 Configuration Protocol (DHCP) Client Fully Qualified 505 Domain Name (FQDN) Option", RFC 4702, October 2006. 507 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 508 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 509 Option", RFC 4704, October 2006. 511 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 512 (DHCPv4 and DHCPv6) Option for Civic Addresses 513 Configuration Information", RFC 4776, November 2006. 515 [RFC6148] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease 516 Query by Relay Agent Remote ID", RFC 6148, February 2011. 518 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 519 Host Configuration Protocol Options for Coordinate-Based 520 Location Configuration Information", RFC 6225, July 2011. 522 [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, 523 N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", 524 RFC 6926, April 2013. 526 10.2. Informative References 528 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 529 June 1999. 531 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 532 Protocol (DHCP) Options for the Intel Preboot eXecution 533 Environment (PXE)", RFC 4578, November 2006. 535 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 536 Morris, J., Hansen, M., and R. Smith, "Privacy 537 Considerations for Internet Protocols", RFC 6973, July 538 2013. 540 Authors' Addresses 542 Sheng Jiang 543 Huawei Technologies Co., Ltd 544 Q14, Huawei Campus, No.156 Beiqing Road 545 Hai-Dian District, Beijing, 100095 546 P.R. China 548 Email: jiangsheng@huawei.com 550 Suresh Krishnan 551 Ericsson 552 8400 Decarie Blvd. 553 Town of Mount Royal, QC 554 Canada 556 Phone: +1 514 345 7900 x42871 557 Email: suresh.krishnan@ericsson.com 559 Tomek Mrugalski 560 Internet Systems Consortium, Inc. 561 950 Charter Street 562 Redwood City, CA 94063 563 USA 565 Phone: +1 650 423 1345 566 Email: tomasz.mrugalski@gmail.com