DNSOP Working Group R. Licht Internet-Draft Charter Communications Intended status: Standards Track D. Lawrence, Ed. Expires: July 5, 2017 Akamai Technologies January 2017 Client ID in Forwarded DNS Queries draft-tale-dnsop-edns0-clientid-00 Abstract This draft defines a DNS EDNS option to carry a client-specific identifier in DNS queries, with guidance for privacy protection of such information. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 5, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Licht & Lawrence Expires July 5, 2017 [Page 1] Internet-Draft Client ID in Forwarded DNS Queries January 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Privacy Considerations . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 5.1. DNS Query . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. DNS Response . . . . . . . . . . . . . . . . . . . . . . 5 6. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Some DNS operators generate, or wish to generate, customized DNS responses based on the originator of a DNS query. For example, [RFC7871], "Client Subnet in DNS Queries", defines a method to convey partial IP network address information about the device that originated a DNS request, so that a response could be targeted to be topographically near the source. Some specialized services, however, need more precise client identity information to function adequately. For example, a parental control service that restricts access to particular domains from particular devices needs to have a device-specific identifier. This document defines an EDNS [RFC6891] option to convey client identification information that is relevant to the DNS query. It is added by software on the client's local area network, for transmission to the upstream DNS provider. A similar EDNS option is already being used on the public Internet in two different implementations. One is between the [dnsmasq] resolver on the client side and Nominum's [Vantio_CacheServe] upstream. It uses EDNS option code 65073 from the "Reserved for Local/Experimental Use" range. The other implementation is for Cisco's [Umbrella], aka OpenDNS, which took option code 26946 from the middle of the "Unassigned" range. This document codifies a more extensible format than Nominum's but currently less so than Cisco's, and is intended to supersede those non-standard options. The authors recognize that Cisco's enhanced format is desired by at least a couple of Licht & Lawrence Expires July 5, 2017 [Page 2] Internet-Draft Client ID in Forwarded DNS Queries January 2017 organizations but present this simplied version as a starting point for discussion. This option is intended only for constrained environments where the use of the option can be carefully controlled. It is completely optional and should be ignored by most DNS software. 2. Privacy Considerations The IETF is actively working on enhancing DNS privacy [DPRIVE_Working_Group], and the reinjection of personally identifiable information has been identified as a problematic design pattern [I-D.hardie-privsec-metadata-insertion]. Because this option trasmits information that is meant to identify specific clients, to be considered compliant with this draft implementations MUST NOT add the option without explicit opt-in by an administrator on the local area network. For example, agreeing to the terms of service for a device-specific DNS filtering product would allow the option to be enabled, and only for communication to the product's DNS server(s). Implementers need to be aware of the various laws and regulations governing handling personal data, but they are out of scope of this document. No explicit provision is made in the protocol to opt-out. For more discussion on this, see Section 7, "Security Considerations". 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] For a comprehensive treatment of DNS terms, please see [RFC7719]. This document uses the following additional terms: ECID EDNS Client Identification. Client The user or device that originates a DNS lookup. Nameserver A DNS server capable of resolving a DNS query and formulating a response. Forwarding Resolver A nameserver that does not do iterative resolution itself, but instead passes that responsibility to another resolver, called a "Forwarder" in [RFC2308] section 1. Licht & Lawrence Expires July 5, 2017 [Page 3] Internet-Draft Client ID in Forwarded DNS Queries January 2017 EUI-48 48 bit Extended Unique Identifier. EUI-64 64 bit Extended Unique Identifier. MAC Media Access Control. Tailored Response A response from a nameserver that is customized based on a policy defined for the client requesting the query. 4. Option Format This protocol uses an EDNS [RFC6891] option to include client identification information in DNS messages. The option is structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | OPTION-CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | OPTION-LENGTH | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: | IDENTIFIER-TYPE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 6: | CLIENT-IDENTIFIER | / / / / +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ OPTION-CODE 2 octets per [RFC6891]. For ECID the code is TBD by IANA. OPTION-LENGTH: 2 octets per [RFC6891]. Contains the length of the payload following OPTION-LENGTH, in octets. IDENTIFIER-TYPE 2 octets, indicates the format of the CLIENT- IDENTIFIER contained in the option. This document only defines the format for 3 different types of CLIENT-IDENTIFIER; namely, a 48-bit MAC address, an IPv4 address, or an IPv6 address. Including the IDENTIFIER-TYPE indicator as part of the option allows for easy evolution of ECID to include other types of identifying addresses, such as EUI-48 or EUI-64 [RFC7042] or a DHCP Unique Identifier [RFC3315] and [RFC6355], as devices and needs change. The IDENTIFIER-TYPE could even indicate that the CLIENT-IDENTIFIER is a specially encrypted identifier that only the DNS Nameserver can decrypt. The following IDENTIFIER-TYPE values are defined. The values chosen correspond to the address family codes as assigned by IANA in [Address_Family_Numbers]. Licht & Lawrence Expires July 5, 2017 [Page 4] Internet-Draft Client ID in Forwarded DNS Queries January 2017 IDENTIFIER-TYPE 16389 (0x40 0x05), 48 octet MAC address IDENTIFIER-TYPE 1 (0x00 0x01), 32 octet IP version 4 address IDENTIFIER-TYPE 2 (0x00 0x02), 128 octet IP version 6 address Note that some initial implementations MAY limit support to the IDENTIFIER-TYPE 16389 (48-bit MAC), with other defined IDENTIFIER- TYPE values simply reserved as described above. CLIENT-IDENTIFIER variable number of octets, depending on the value of IDENTIFIER-TYPE. The IDENTIFIER-TYPE, and its corresponding CLIENT-IDENTIFIER, fields may be repeated in a single ECID option, increasing OPTION-LENGTH correspondingly. However, the same IDENTIFIER-TYPE may not appear more than once. (This should be reflected in the packet diagram but I still have to hunt down whether there's a convention for that. All fields are in network byte order ("big-endian", per [RFC1700], Data Notation). 5. Protocol Description 5.1. DNS Query Any client that originates a DNS query message MAY include the ECID option in the DNS Query message. It is normally expected that the client itself would not do this, but rather that it will be added by the local forwarding resolver. When a DNS forwarding resolver, provided as part of a router for example, receives a DNS query message from the originating client it adds any ECID IDENTIFIER-TYPE / CLIENT-IDENTIFIER pairs for IDENTIFIER-TYPEs that it supports but which are not present in the existing client request. It then sends the request to the upstream full-service resolver. Because the option contains personally identifiable information, it should be protected by either only being used within Autonomous Systems [RFC1930] controlled by the same provider, or by going over an opaque channel such as DNS over TLS [RFC7858]. It MUST NOT be sent in clear-text across the Internet. 5.2. DNS Response The logic used by a full-service resolver to customize a response based on ECID is out of scope for this document. The resolver MUST NOT include the ECID option in any queries that it makes to external authoritative DNS servers. Licht & Lawrence Expires July 5, 2017 [Page 5] Internet-Draft Client ID in Forwarded DNS Queries January 2017 For possible caching purposes, the forwarding resolver needs to know whether filtering affected the response. If the name resolution involved any names for which customization was possible, even if such filtering resulted in delivering the original data, the response SHOULD include an ECID option which contains the IDENTIFIER-TYPE and CLIENT-IDENTIFIER that were considered for filtering. For example, if a filter is set such that only names in the example.com domain are possibly restricted to some devices, then a request for foo.example.com would have the ECID in the response even when the request came from a device which was not restricted. Requests for any other names would not include ECID in the response. So that the caching forwarding resolver does not need to have any knowledge about what filters are in place, it is the full-service resolver's responsibility to adjust any TTLs in the response as might be dictated by the filter policy it has configured. That is, if some name is filtered only between the hours of 09:00 and 17:00 and a request is received for that name at 16:59:59, the TTL on a positive response or the SOA ncache field on a negative response should be set to just one second and the ECID option included as described above. If the request contains a malformed ECID option, such as CLIENT- IDENTIFIER not correctly matching the length of described by OPTION- LENGTH and IDENTIFIER-TYPE, the resolver SHOULD reply with DNS rcode FORMERR. If the resolver by policy does not respond to requests that are lacking ECID of the appropriate IDENTIFIER-TYPE, it SHOULD reply with DNS rcode REFUSED. 6. NAT Considerations Devices that perform Network Address Translation (NAT) need not give special consideration for ECID. NAT translates between a layer 3 private IP address assigned to a client device on the Local Area Network and a layer 3 public IP address for use within the Wide Area Network. ECID information identifies a client device by a different means, e.g. its layer 2 address. A device's identifier is NOT impacted by NAT. Therefore, DNS queries may be passed without modification of any ECID information. Licht & Lawrence Expires July 5, 2017 [Page 6] Internet-Draft Client ID in Forwarded DNS Queries January 2017 7. Security Considerations The identifier of the client that initiated the request will be visible to all servers that are passed the ECID option, and the various devices on the path between the local network and the full- service resolver being used by the forwarding resolver. DNS filtering products are easy circumvented and should not be considered real security measures. With commonly available tools it is trivial to discover the non-filtered DNS responses and use them in place of the filtered responses. Along those lines, opting out of this specific protocol is as simple as using a different resolver, such as a full-service resolver on the device itself or one of the well-known public resolvers. Of course, other devices on the local network will still be able to see unencrypted DNS requests from the device, and the only way to really protect against such monitoring is to use an opaque tunnel to a trusted resolver. 8. IANA Considerations IANA is requested to assign a new value in the DNS EDNS Option Codes registry for the Device ID option. 9. Acknowledgements The authors wish to thank the Barry Greene, Martin Deen and Benjamin Petrin for their feedback and review during the initial development of this document. 10. References 10.1. Normative References [Address_Family_Numbers] "Address Family Numbers", n.d., . [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, DOI 10.17487/RFC1700, October 1994, . [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, . Licht & Lawrence Expires July 5, 2017 [Page 7] Internet-Draft Client ID in Forwarded DNS Queries January 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . 10.2. Informative References [dnsmasq] "dnsmasq", n.d., . [DPRIVE_Working_Group] "DPRIVE Working Group", n.d., . [I-D.hardie-privsec-metadata-insertion] Hardie, T., "Design considerations for Metadata Insertion", draft-hardie-privsec-metadata-insertion-05 (work in progress), January 2017. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Licht & Lawrence Expires July 5, 2017 [Page 8] Internet-Draft Client ID in Forwarded DNS Queries January 2017 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10.17487/RFC6355, August 2011, . [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, . [Umbrella] "Umbrella", n.d., . [Vantio_CacheServe] "Vantio CacheServe", n.d., . Authors' Addresses Robert Licht Charter Communications 13820 Sunrise Valley Dr Herndon VA 20171 USA Email: robert.licht@charter.com David C Lawrence (editor) Akamai Technologies 150 Broadway Cambridge MA 02142-1054 USA Email: tale@akamai.com Licht & Lawrence Expires July 5, 2017 [Page 9]