idnits 2.17.00 (12 Aug 2021) /tmp/idnits601/draft-tale-dnsop-edns0-clientid-01.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: Multiple ECID options MAY appear in the OPT record. However, the same IDENTIFIER-TYPE SHOULD not appear more than once, and each ECID option MUST only carry one IDENTIFIER-TYPE and CLIENT-IDENTIFIER pair. -- The document date (March 13, 2017) is 1888 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 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) ** Downref: Normative reference to an Informational RFC: RFC 7871 == Outdated reference: draft-hardie-privsec-metadata-insertion has been published as RFC 8165 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group R. Licht 3 Internet-Draft Charter Communications 4 Intended status: Standards Track D. Lawrence, Ed. 5 Expires: September 14, 2017 Akamai Technologies 6 March 13, 2017 8 Client ID in Forwarded DNS Queries 9 draft-tale-dnsop-edns0-clientid-01 11 Abstract 13 This draft defines a DNS EDNS option to carry a client-specific 14 identifier in DNS queries, with guidance for privacy protection of 15 such information. 17 Ed note 19 Text inside square brackets ([]) is additional background 20 information, answers to frequently asked questions, general musings, 21 etc. They will be removed before publication. This document is 22 being collaborated on in GitHub at . The most recent version of the document, open 24 issues, etc should all be available here. The authors gratefully 25 accept pull requests. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Privacy Considerations . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 66 5.1. DNS Query . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.2. DNS Response . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Using the DNS Address Family . . . . . . . . . . . . . . . . 6 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 70 8. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 12.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Some DNS operators generate, or wish to generate, customized DNS 82 responses based on the originator of a DNS query. For example, 83 [RFC7871], "Client Subnet in DNS Queries", defines a method to convey 84 partial IP network address information about the device that 85 originated a DNS request, so that a response could be targeted to be 86 topographically near the source. 88 Some specialized services, however, need more precise client identity 89 information to function adequately. For example, a parental control 90 service that restricts access to particular domains from particular 91 devices needs to have a device-specific identifier. 93 This document defines an EDNS [RFC6891] option to convey client 94 identification information that is relevant to the DNS query. It is 95 added by software on the client's local area network, for 96 transmission to the upstream DNS provider. 98 A similar EDNS option is already being used on the public Internet in 99 two different implementations. One is between the [dnsmasq] resolver 100 on the client side and Nominum's [Vantio_CacheServe] upstream. It 101 uses EDNS option code 65073 from the "Reserved for Local/Experimental 102 Use" range to pass the client's Media Access Control (MAC) address. 103 The other implementation is for Cisco's [Umbrella], aka OpenDNS, 104 which encodes the client's MAC address and complete IP address. It 105 uses option codes 26946 and 20292, respectively, from the middle of 106 the "Unassigned" range. 108 This document codifies a more flexible format that can accommodate 109 the needs of both implementations, as well as other more opaque 110 identifiers. It is intended to supersede those non-standard options. 112 This option is intended only for constrained environments where its 113 use can be carefully controlled. It is completely optional and 114 should be ignored by most DNS software. 116 2. Privacy Considerations 118 The IETF is actively working on enhancing DNS privacy 119 [DPRIVE_Working_Group], and the re-injection of personally 120 identifiable information has been identified as a problematic design 121 pattern [I-D.hardie-privsec-metadata-insertion]. 123 Because this option transmits information that is meant to identify 124 specific clients, to be considered compliant with this draft 125 implementations MUST NOT add the option without explicit opt-in by an 126 administrator on the local area network. For example, agreeing to 127 the terms of service for a device-specific DNS filtering product 128 would allow the option to be enabled, and only for communication to 129 the product's DNS server(s). 131 Implementers need to be aware of the various laws and regulations 132 governing handling personal data, but they are out of scope of this 133 document. 135 No explicit provision is made in the protocol to opt-out. For more 136 discussion on this, see Section 9, "Security Considerations". 138 3. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119] 144 For a comprehensive treatment of DNS terms, please see [RFC7719]. 145 This document uses the following additional terms: 147 ECID EDNS Client Identification. 149 Client The user or device that originates a DNS lookup. 151 Nameserver A DNS server capable of resolving a DNS query and 152 formulating a response. 154 Forwarding Resolver A nameserver that does not do iterative 155 resolution itself, but instead passes that responsibility to 156 another resolver, called a "Forwarder" in [RFC2308] section 1. 158 Tailored Response A response from a nameserver that is customized 159 based on a policy defined for the client requesting the query. 161 4. Option Format 163 This protocol uses an EDNS [RFC6891] option to include client 164 identification information in DNS messages. The option is structured 165 as follows: 167 +0 (MSB) +1 (LSB) 168 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 169 0: | OPTION-CODE | 170 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 171 2: | OPTION-LENGTH | 172 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 173 4: | IDENTIFIER-TYPE | 174 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 175 6: | / 176 / CLIENT-IDENTIFIER / 177 / / 178 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 180 OPTION-CODE: 2 octets per [RFC6891]. For ECID the code is TBD by 181 IANA. 183 OPTION-LENGTH: 2 octets per [RFC6891]. Contains the length of the 184 payload following OPTION-LENGTH, in octets. 186 IDENTIFIER-TYPE: 2 octets per [Address_Family_Numbers], describing 187 the format of CLIENT-IDENTIFIER as elaborated below. [ Is it 188 better to call this ADDRESS-FAMILY? ] 190 CLIENT-IDENTIFIER: A variable number of octets, depending on 191 IDENTIFIER-TYPE. 193 All fields are in network byte order ("big-endian", per [RFC1700], 194 Data Notation). 196 This draft only specifies behaviour for the following IDENTIFIER-TYPE 197 values and the corresponding CLIENT-IDENTIFIER lengths: 199 o 16389 (0x4005, 48-bit MAC): 6 octets, fixed. 201 o 1 (0x0001, IP version 4): 4 octets, fixed. 203 o 2 (0x0002, IP version 6): 16 octets, fixed. 205 o 16 (0x0010, Domain Name System): Variable-length domain name in 206 uncompressed wire format followed by a variable-length custom 207 token. 209 For DNS servers that implement ECID, it is RECOMMENDED that they 210 recognize at least the 48-bit MAC CLIENT-IDENTIFIER. 212 The use of Domain Name System as an address family is to facilitate 213 custom tokens that are not well-conceptualized as addresses, as 214 described in Section 6. 216 Other types of identifying addresses, such as a 64-bit MAC [RFC7042] 217 or a DHCP Unique Identifier [RFC3315] and [RFC6355] could be 218 accommodated as devices and needs change, without needing to define 219 new EDNS option codes to cover them. [ Why not just bless those 220 obvious candidates now? ] 222 Multiple ECID options MAY appear in the OPT record. However, the 223 same IDENTIFIER-TYPE SHOULD not appear more than once, and each ECID 224 option MUST only carry one IDENTIFIER-TYPE and CLIENT-IDENTIFIER 225 pair. 227 5. Protocol Description 229 5.1. DNS Query 231 Any client that originates a DNS query message MAY include the ECID 232 option in the DNS Query message. It is normally expected that the 233 client itself would not do this, but rather that it will be added by 234 the local forwarding resolver. 236 When a DNS forwarding resolver, provided as part of a router for 237 example, receives a DNS query message from the originating client it 238 adds any IDENTIFIER-TYPE / CLIENT-IDENTIFIER pairs that it supports 239 but which are not present in the existing client request. It then 240 sends the request to the upstream full-service resolver. 242 Because the option contains personally identifiable information, it 243 should be protected by either only being used within Autonomous 244 Systems [RFC1930] controlled by the same provider, by going over an 245 opaque channel such as DNS over TLS [RFC7858], or by being securely 246 encoded and varying per request. It MUST NOT be sent in clear-text 247 across the Internet. 249 5.2. DNS Response 251 The logic used by a full-service resolver to customize a response 252 based on ECID is out of scope for this document. The resolver MUST 253 NOT include the ECID option in any queries that it makes to external 254 authoritative DNS servers. 256 For possible caching purposes, the forwarding resolver needs to know 257 whether filtering affected the response. If the name resolution 258 involved any names for which customization was possible, even if such 259 filtering resulted in delivering the original data, the response 260 SHOULD include an ECID option which contains the FAMILY-ADDRESS and 261 CLIENT-IDENTIFIER pairs that were considered for filtering. 263 For example, if a filter is set such that only names in the 264 example.com domain are possibly restricted to some devices, then a 265 request for foo.example.com would have the ECID in the response even 266 when the request came from a device which was not restricted. 267 Requests for any other names would not include ECID in the response. 269 So that the caching forwarding resolver does not need to have any 270 knowledge about what filters are in place, it is the full-service 271 resolver's responsibility to adjust any TTLs in the response as might 272 be dictated by the filter policy it has configured. That is, if some 273 name is filtered only between the hours of 09:00 and 17:00 and a 274 request is received for that name at 16:59:59, the TTL on a positive 275 response or the SOA ncache field on a negative response should be set 276 to just one second and the ECID option included as described above. 278 If the request contains a malformed ECID option, such as CLIENT- 279 IDENTIFIER not correctly matching the length of described by OPTION- 280 LENGTH and IDENTIFIER-TYPE, the resolver SHOULD reply with DNS rcode 281 FORMERR. 283 If the resolver by policy does not respond to requests that are 284 lacking ECID of the appropriate IDENTIFIER-TYPE, it SHOULD reply with 285 DNS rcode REFUSED. 287 6. Using the DNS Address Family 289 When IDENTIFIER-TYPE 16 is used, the uncompressed wire format of the 290 domain name is followed by a token that is otherwise opaque to this 291 specification. The length of that token is defined by OPTION-LENGTH 292 less the two octets used for IDENTIFIER-TYPE and the length of the 293 domain name. 295 The name used SHOULD be in a namespace that is controlled by the 296 service provider that is using the option, but need not be resolvable 297 in the DNS. We RECOMMEND that providers use short domain names to 298 minimize DNS packet length. 300 The domain name provides protection against conflicts with other 301 users of the option without the burden of creating yet another IANA 302 Registry to manage yet another two-octet code. Co-operating 303 forwarder/resolver pairs are the only users of the data who need to 304 be concerned with its format. 306 7. Implementation Status 308 [RFC Editor: per RFC 6982 this section should be removed prior to 309 publication.] 311 The protocol proposed here is not currently used anywhere exactly as 312 described, though the Nominum and Umbrella implementations are 313 substantially similar. 315 The authors know of at least two providers who wish to have it 316 properly standardized and would implement the standard in preference 317 to either of the existing non-standard methods. 319 8. NAT Considerations 321 Devices that perform Network Address Translation (NAT) SHOULD NOT 322 give special consideration for ECID. NAT translates between a layer 323 3 private IP address assigned to a client device on the Local Area 324 Network and a layer 3 public IP address for use within the Wide Area 325 Network. If ECID is being used to pass an IPv4 or IPv6 address, it 326 SHOULD use the internal address without NAT translation, because 327 transforming it to the public address of the NAT device would 328 coalesce all internal devices to just one address. 330 Other ECID options identify a client device by a different means, 331 e.g. its layer 2 address. This sort of device's identifier is not 332 impacted by NAT. Therefore, DNS queries may be passed without 333 modification of any ECID information. 335 9. Security Considerations 337 The identifier of the client that initiated the request will be 338 visible to all servers that are passed the ECID option, and the 339 various devices on the path between the local network and the full- 340 service resolver being used by the forwarding resolver. 342 DNS filtering products are easy circumvented and should not be 343 considered real security measures. With commonly available tools it 344 is trivial to discover the non-filtered DNS responses and use them in 345 place of the filtered responses. 347 Along those lines, opting out of this specific protocol is as simple 348 as using a different resolver, such as a full-service resolver on the 349 device itself or one of the well-known public resolvers. Of course, 350 other devices on the local network will still be able to see 351 unencrypted DNS requests from the device, and the only way to really 352 protect against such monitoring is to use an opaque tunnel to a 353 trusted resolver. 355 10. IANA Considerations 357 IANA is requested to assign a new value in the DNS EDNS Option Codes 358 registry for the Device ID option. 360 11. Acknowledgements 362 The authors wish to thank the Barry Greene, Martin Deen, Benjamin 363 Petrin, and Robert Fleischman for their feedback and review during 364 the initial development of this document. 366 12. References 368 12.1. Normative References 370 [Address_Family_Numbers] 371 IANA, ., "Address Family Numbers", n.d., 372 . 374 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 375 DOI 10.17487/RFC1700, October 1994, 376 . 378 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 379 selection, and registration of an Autonomous System (AS)", 380 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 381 . 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 389 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 390 . 392 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 393 for DNS (EDNS(0))", STD 75, RFC 6891, 394 DOI 10.17487/RFC6891, April 2013, 395 . 397 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 398 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 399 2015, . 401 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 402 and P. Hoffman, "Specification for DNS over Transport 403 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 404 2016, . 406 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 407 Kumari, "Client Subnet in DNS Queries", RFC 7871, 408 DOI 10.17487/RFC7871, May 2016, 409 . 411 12.2. Informative References 413 [dnsmasq] Kelley, S., "dnsmasq", n.d., 414 . 416 [DPRIVE_Working_Group] 417 Kumari, W. and T. Wicinski, "DPRIVE Working Group", n.d., 418 . 420 [I-D.hardie-privsec-metadata-insertion] 421 Hardie, T., "Design considerations for Metadata 422 Insertion", draft-hardie-privsec-metadata-insertion-07 423 (work in progress), March 2017. 425 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 426 C., and M. Carney, "Dynamic Host Configuration Protocol 427 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 428 2003, . 430 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 431 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 432 DOI 10.17487/RFC6355, August 2011, 433 . 435 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 436 IETF Protocol and Documentation Usage for IEEE 802 437 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 438 October 2013, . 440 [Umbrella] 441 Cisco Systems, Inc., "Umbrella", n.d., 442 . 445 [Vantio_CacheServe] 446 Nominum, Inc., "Vantio CacheServe", n.d., 447 . 449 Authors' Addresses 451 Robert Licht 452 Charter Communications 453 13820 Sunrise Valley Dr 454 Herndon VA 20171 455 USA 457 Email: robert.licht@charter.com 459 David C Lawrence (editor) 460 Akamai Technologies 461 150 Broadway 462 Cambridge MA 02142-1054 463 USA 465 Email: tale@akamai.com