idnits 2.17.1 draft-mrugalski-dhc-dhcpv6-privacy-mitigation-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3315, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: PROPOSAL: Clients interested in their privacy SHOULD not use IA_TA. They should simply send an IA_NA with a randomized IAID. This, along with the mitigation technique discussed in Section 3.2, will ensure that a client will get a new address that can be renewed and can be used as long as needed. To get a new address, it can send Request message with a new randomized IAID before releasing the other one. This will cause the server to assign a new address, as it still has a valid lease for the old IAID value. Once a new address is assigned, the address obtained using the older IAID value can be released safely, using the Release message or it may simply be allowed to time out. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: PROPOSAL: Clients SHOULD avoid disclosing their hostnames, as the hostnames may contain personally identifying information (e.g. "Tomek's laptop"). Even if the hostname does not contain personally identifying information, it can still be used as a stable identifier for tracking. Therefore a client SHOULD not send FQDN option at all. This ensures that the host does not expose a stable identifier, but also implies that the host will not have a resolvable DNS name. Should DNS name be useful, a client SHOULD send a randomly generated hostname, consisting of a single label. The server is expected to append the domain name and return FQDN to the client. Client can then use this FQDN as its temporary hostname that will be discarded once its location changes or the client chooses to assume a new identity. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: PROPOSAL: When using stateless DHCPv6, clients wanting to protect their privacy SHOULD not include client identifiers in their Information-Request messages. This will prevent the server from specifying client-specific options if it is configured to do so, but the need for anonymity precludes such options anyway. (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-6man-ipv6-address-generation-privacy' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC4580' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC4649' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC4776' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC5007' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC5460' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC5970' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC6225' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC6939' is defined on line 357, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-privacy-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dhc-dhcpv6-privacy (ref. 'I-D.ietf-dhc-dhcpv6-privacy') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc T. Mrugalski 3 Internet-Draft ISC 4 Updates: 3315 (if approved) S. Krishnan 5 Intended status: Standards Track Ericsson 6 Expires: September 10, 2015 March 9, 2015 8 Mitigation of Privacy Concerns in DHCPv6 9 draft-mrugalski-dhc-dhcpv6-privacy-mitigation-00 11 Abstract 13 There is work ongoing in the dhc working group that discusses the 14 various identifiers used by DHCPv6 and the potential privacy 15 implications. This draft explores several migitation techniques that 16 could be used to address the privacy issues in DHCPv6. This draft is 17 expected to evolve significantly over time, but the ultimate goal is 18 to standardize mitigation techniques the DHC working group considers 19 useful. 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 September 10, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Client Mitigation Techniques . . . . . . . . . . . . . . . . 3 58 3.1. Not disclose the desire for privacy . . . . . . . . . . . 3 59 3.2. Use randomized DUIDs . . . . . . . . . . . . . . . . . . 3 60 3.3. Do not send Confirm messages . . . . . . . . . . . . . . 4 61 3.4. Obtain temporary addresses . . . . . . . . . . . . . . . 4 62 3.5. Do not request the FQDN Option . . . . . . . . . . . . . 5 63 3.6. Randomize ordering of Options in messages and in the ORO 5 64 3.7. Anonymous Information-Request . . . . . . . . . . . . . . 6 65 4. Server Mitigation Techniques . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 DHCPv6 [RFC3315] is a protocol that is used to provide addressing and 78 configuration information to IPv6 hosts. The DHCPv6 protocol uses 79 several identifiers that could become a source for gleaning 80 additional information about the IPv6 host. This information may 81 include device type, operating system information, location(s) that 82 the device may have previously visited, etc. 83 [I-D.ietf-dhc-dhcpv6-privacy] discusses the various identifiers used 84 by DHCPv6 and the potential privacy issues [RFC6973]. This document 85 proposes 87 2. Terminology 89 This document uses the term "Stable identifier" as defined in 90 [I-D.ietf-dhc-dhcpv6-privacy] 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. When these 94 words are not in ALL CAPS (such as "should" or "Should"), they have 95 their usual English meanings, and are not to be interpreted as 96 [RFC2119] key words. 98 3. Client Mitigation Techniques 100 3.1. Not disclose the desire for privacy 102 A naive approach to privacy would be to simply disclose the desire to 103 protect one's privacy, e.g. by sending requests for temporary 104 addresses or defining a new type of temporary DUID that would be 105 changing over time. This is not workable in a large number of cases 106 as it is possible that the network operator (or other entities that 107 have access to the operator's network) might be actively 108 participating in surveillance and anti-privacy, willingly or not. 109 Simply revealing the desire for privacy, could cause the attacker to 110 react by triggering additional surveillance or monitoring mechanisms. 111 Therefore we feel that it is preferable to not disclose one's desire 112 for privacy. This preference leads to some important implications. 113 In particular, we make an effort to make the mitigation techniques 114 difficult to distinguish from regular client behaviors, if at all 115 possible. 117 3.2. Use randomized DUIDs 119 One of the primary privacy concerns is that a client is disclosing a 120 stable identifier (the DUID) that can be use for tracking and 121 profiling. The most common way of disclosing client's MAC/hardware 122 address in DHCPv6 is to use DUID type LLT (link-layer with time) or 123 LL (link-layer). Another DUID of type UUID is also bad in this 124 regard, as its the UUID may contain additional information about the 125 device it is tied to. 127 Discussion: As stated in Section 3.1, the desire for privacy should 128 not be explicitly advertised. Therefore a new DUID type is not 129 recommended here. 131 PROPOSAL: The clients that want to protect their privacy SHOULD 132 generate a new randomized DUID-LLT every time they attach to a new 133 link or detect a possible link change event. The exact details are 134 left up to implementors, but there are several factors should be 135 taken into consideration. The DUID type SHOULD be set to 1 (DUID- 136 LLT). Hardware type SHOULD be set appropriately to the hardware 137 type. Time MAY be set to current time, but this will reveal the fact 138 that the DUID is newly generated. Implementors interested in hiding 139 this fact MAY use a time stamp from the past. e.g. a random timestamp 140 from the previous year could be a good value. In the most common 141 cases the link-layer address is based on MAC. The first three octets 142 are composed of the OUI (Organizationally Unique Identifier) that is 143 expected to have a value assigned to a real organization. See 144 [IEEE-OUI] for currently assigned values. Using a value that is 145 unassigned may disclose the fact that a DUID is randomized. Using a 146 value that belongs to a third party may have legal implications. 148 3.3. Do not send Confirm messages 150 The [RFC3315] requires clients to send a Confirm message when they 151 attach to a new link to verify whether the addressing and 152 configuration information they previously received is still valid. 153 When these clients send Confirm messages, they include any IAs 154 assigned to the interface that may have moved to a new link, along 155 with the addresses associated with those IAs. By examining the 156 addresses in the Confirm message an attacker can trivially identify 157 the previous point(s) of attachment. 159 PROPOSAL: Clients interested in protecting their privacy SHOULD NOT 160 send Confirm messages and instead directly try to acquire addresses 161 on the new link. 163 3.4. Obtain temporary addresses 165 [RFC3315] defines a special container (IA_TA) for requesting 166 temporary addresses. This is a good mechanism in principle, but 167 there are a number of issues associated with it. First, this is not 168 widely used feature, so clients depending solely on temporary 169 addresses may lock themselves out of service. Secondly, [RFC3315] 170 does not specify any renewal mechanisms for temporary addresses. 171 Therefore support for renewing temporary addresses may vary between 172 server implementations, including not being supported at all. 173 Finally, by requesting temporary addresses a client reveals its 174 desire for privacy and potentially risks countermeasures as described 175 in Section 3.1. 177 PROPOSAL: Clients interested in their privacy SHOULD not use IA_TA. 178 They should simply send an IA_NA with a randomized IAID. This, along 179 with the mitigation technique discussed in Section 3.2, will ensure 180 that a client will get a new address that can be renewed and can be 181 used as long as needed. To get a new address, it can send Request 182 message with a new randomized IAID before releasing the other one. 183 This will cause the server to assign a new address, as it still has a 184 valid lease for the old IAID value. Once a new address is assigned, 185 the address obtained using the older IAID value can be released 186 safely, using the Release message or it may simply be allowed to time 187 out. 189 This proposal may not work if the server enforces specific policies, 190 e.g. only one address per client. If client does not succeed in 191 receiving a second address using a new IAID, it may release the first 192 one (using an old IAID) and then retry asking for a new address. 194 From the Operating System perspective, addresses obtained using this 195 technique SHOULD be treated as temporary as specified in [RFC4941]. 197 3.5. Do not request the FQDN Option 199 A typical client uses FQDN option, defined in [RFC4704] to negotiate 200 with a server the DNS entries that should be updated. In the 201 process, the client typically reveals its hostname and possibly its 202 home domain. Server, depending on configured policies, may accept or 203 override the name with network specific information. 205 PROPOSAL: Clients SHOULD avoid disclosing their hostnames, as the 206 hostnames may contain personally identifying information (e.g. 207 "Tomek's laptop"). Even if the hostname does not contain personally 208 identifying information, it can still be used as a stable identifier 209 for tracking. Therefore a client SHOULD not send FQDN option at all. 210 This ensures that the host does not expose a stable identifier, but 211 also implies that the host will not have a resolvable DNS name. 212 Should DNS name be useful, a client SHOULD send a randomly generated 213 hostname, consisting of a single label. The server is expected to 214 append the domain name and return FQDN to the client. Client can 215 then use this FQDN as its temporary hostname that will be discarded 216 once its location changes or the client chooses to assume a new 217 identity. 219 3.6. Randomize ordering of Options in messages and in the ORO 221 A DHCPv6 client may reveal other types of information, besides unique 222 identifiers. There are many ways a DHCPv6 client can perform certain 223 actions and the specifics can be used to fingerprint the client. 224 This may not reveal the identity of a client, but may provide 225 additional information, such as the device type, vendor type or OS 226 type and in some cases specific version. 228 One specific method used for fingerprinting utilizes the order in 229 which options are included in the message. Another related technique 230 utilizes the order in which option codes are included in an ORO 231 (Option Request Option). 233 PROPOSAL: The client willing to protect its privacy SHOULD randomize 234 options order before sending any DHCPv6 message. Such a client 235 SHOULD also randomly shuffle the option codes order in ORO. 237 3.7. Anonymous Information-Request 239 According to [RFC3315], a DHCPv6 client typically includes its client 240 identifier in most of the messages it sends. There is one exception, 241 however. Client is allowed to omit its client identifier when 242 sending Information-Request. 244 PROPOSAL: When using stateless DHCPv6, clients wanting to protect 245 their privacy SHOULD not include client identifiers in their 246 Information-Request messages. This will prevent the server from 247 specifying client-specific options if it is configured to do so, but 248 the need for anonymity precludes such options anyway. 250 4. Server Mitigation Techniques 252 TODO: - don't send GEOLOCATION options to anyone who asks (preferably 253 don't sent that option at all); - if running on mobile device, 254 possibly change its server-id when its link flips; - don't send FQDN 255 options if you don't intend to do actual DNS Updates; - 257 5. Security Considerations 259 The use of randomized DUIDs and IAIDs allows malicious clients to 260 exhaust address and prefix pools on DHCPv6 servers by simply 261 requesting more and more addresses/prefixes. This attack is 262 certainly possible already in today's networks, but this document 263 provides a *legitimate* use case for random DUIDs and IAIDs making 264 countermeasures more difficult. In addition to exhausting configured 265 address and prefix pools, these clients may also cause increased 266 state (and hence resource utilization) on the DHCPv6 servers. 268 6. Privacy Considerations 270 This document at its entirety discusses privacy considerations in 271 DHCPv6. As such, no separate section about this is needed. 273 7. IANA Considerations 275 This draft does not request any IANA action. 277 8. Acknowledgements 279 The authors would like to thanks the valuable comments made by 280 Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian 281 Schaefer and other members of DHC WG. 283 This document was produced using the xml2rfc tool [RFC2629]. 285 9. References 287 9.1. Normative References 289 [I-D.ietf-dhc-dhcpv6-privacy] 290 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 291 considerations for DHCPv6", draft-ietf-dhc- 292 dhcpv6-privacy-00 (work in progress), February 2015. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 298 and M. Carney, "Dynamic Host Configuration Protocol for 299 IPv6 (DHCPv6)", RFC 3315, July 2003. 301 9.2. Informative References 303 [I-D.ietf-6man-ipv6-address-generation-privacy] 304 Cooper, A., Gont, F., and D. Thaler, "Privacy 305 Considerations for IPv6 Address Generation Mechanisms", 306 draft-ietf-6man-ipv6-address-generation-privacy-03 (work 307 in progress), January 2015. 309 [IEEE-OUI] 310 IEEE, "Organizationally Unique Identifiers 311 http://www.ieee.org/netstorage/standards/oui.txt", . 313 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 314 June 1999. 316 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 317 Host Configuration Protocol (DHCP) version 6", RFC 3633, 318 December 2003. 320 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 321 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 322 2006. 324 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 325 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 326 2006. 328 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 329 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 330 Option", RFC 4704, October 2006. 332 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 333 (DHCPv4 and DHCPv6) Option for Civic Addresses 334 Configuration Information", RFC 4776, November 2006. 336 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 337 Extensions for Stateless Address Autoconfiguration in 338 IPv6", RFC 4941, September 2007. 340 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 341 "DHCPv6 Leasequery", RFC 5007, September 2007. 343 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 344 2009. 346 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 347 Options for Network Boot", RFC 5970, September 2010. 349 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 350 Host Configuration Protocol Options for Coordinate-Based 351 Location Configuration Information", RFC 6225, July 2011. 353 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 354 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 355 2011. 357 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 358 Address Option in DHCPv6", RFC 6939, May 2013. 360 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 361 Morris, J., Hansen, M., and R. Smith, "Privacy 362 Considerations for Internet Protocols", RFC 6973, July 363 2013. 365 Authors' Addresses 367 Tomek Mrugalski 368 Internet Systems Consortium, Inc. 369 950 Charter Street 370 Redwood City, CA 94063 371 USA 373 Email: tomasz.mrugalski@gmail.com 375 Suresh Krishnan 376 Ericsson 377 8400 Decarie Blvd. 378 Town of Mount Royal, QC 379 Canada 381 Phone: +1 514 345 7900 x42871 382 Email: suresh.krishnan@ericsson.com