[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
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.,
              <http://www.iana.org/assignments/address-family-numbers/>.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              DOI 10.17487/RFC1700, October 1994,
              <http://www.rfc-editor.org/info/rfc1700>.

   [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,
              <http://www.rfc-editor.org/info/rfc1930>.




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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <http://www.rfc-editor.org/info/rfc2308>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <http://www.rfc-editor.org/info/rfc6891>.

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <http://www.rfc-editor.org/info/rfc7719>.

   [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, <http://www.rfc-editor.org/info/rfc7858>.

   [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,
              <http://www.rfc-editor.org/info/rfc7871>.

10.2.  Informative References

   [dnsmasq]  "dnsmasq", n.d.,
              <http://www.thekelleys.org.uk/dnsmasq/doc.html>.

   [DPRIVE_Working_Group]
              "DPRIVE Working Group", n.d.,
              <https://datatracker.ietf.org/wg/dprive/charter/>.

   [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, <http://www.rfc-editor.org/info/rfc3315>.





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,
              <http://www.rfc-editor.org/info/rfc6355>.

   [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, <http://www.rfc-editor.org/info/rfc7042>.

   [Umbrella]
              "Umbrella", n.d., <https://docs.umbrella.com/developer/
              networkdevices-api/identifying-dns-traffic2>.

   [Vantio_CacheServe]
              "Vantio CacheServe", n.d.,
              <http://www.nominum.com/product/caching-dns/>.

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]