[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                              S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Informational                                  T. Lemon
Expires: January 3, 2018                                   Nominum, Inc.
                                                            July 2, 2017


     Service Registration Protocol for DNS-Based Service Discovery
                   draft-sctl-service-registration-00

Abstract

   The DNS-SD Service Registration Protocol provides a way to perform
   DNS-Based Service Discovery using only unicast packets.  This
   eliminates the dependency on Multicast DNS as the foundation layer,
   which has worked well in some environments, like the simplest of home
   networks, but not in others, like large enterprise networks (where
   multicast does not scale well to thousands of devices) and mesh
   networks (where multicast and broadcast are supported poorly, if at
   all).  Broadly speaking, the DNS-SD Service Registration Protocol is
   DNS Update, with a few additions.

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 January 3, 2018.

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



Cheshire & Lemon         Expires January 3, 2018                [Page 1]


Internet-Draft        Service Registration Protocol            July 2017


   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.

1.  Introduction

   DNS-Based Service Discovery [RFC6763] is a component of Zero
   Configuration Networking [RFC6760] [ZC] [Roadmap].

   There are two facets of DNS-Based Service Discovery to consider:
   how relevant information makes its way into the DNS namespace
   (how a server offers its services to interested clients) and how
   clients access that information (how an interested client discovers
   and uses a service instance).

   This document is concerned with the first of those two facets:
   how relevant information makes its way into the DNS namespace.

   In the DNS-Based Service Discovery specification [RFC6763] Section 10
   "Populating the DNS with Information" briefly discusses ways that
   relevant information can make its way into the DNS namespace.  In the
   case of Multicast DNS [RFC6762], the relevant information trivially
   becomes visible in the ".local" namespace by virtue of devices
   answering for themselves.  For unicast DNS names, ways that
   information makes its way into the DNS namespace include manual
   configuration of DNS zone files, possibly assisted using tools such
   as the "dns-sd -Z" command, automated tools such as a Discovery Proxy
   [DisProx], or explicit registration by the services themselves.  It
   is the last option -- explicit registration by the services
   themselves -- that is the subject of this document.



















Cheshire & Lemon         Expires January 3, 2018                [Page 2]


Internet-Draft        Service Registration Protocol            July 2017


2.  Service Registration Protocol

   The DNS-SD Service Registration Protocol is largely built on DNS
   Update [RFC2136] [RFC3007], with some additions.

   When a device advertises services using Multicast DNS, the parent
   domain is implicitly ".local".

   When a device advertises services in the traditional unicast DNS
   namespace, it needs to know the parent domain name for its services.
   This parent domain can be manually configured by a human operator, or
   learned from the network.  In the DNS-SD specification [RFC6763]
   section 11, "Discovery of Browsing and Registration Domains (Domain
   Enumeration)", describes how a client device can learn a recommended
   default registration domain from the network.

   In the remainder of this document, Section 3 covers cleanup of stale
   data, and Section 4 covers advertising services on behalf of devices
   that are sleeping to reduce power consumption.

   The final question is security.  Most dynamic DNS servers will not
   accept unauthenticated updates.  In the case of manual configuration
   of registration domain by a human operator, the human operator can
   also configure an appropriate TSIG security key.  In the case of
   automatic configuration via DNS-SD Domain Enumeration queries, it
   would be nice to also have zero-configuration security.  While at
   first glance zero-configuration security may seem to be a self-
   contradiction, this document proposes a simple first-come first-
   served security mechanism, described below in Section 5.






















Cheshire & Lemon         Expires January 3, 2018                [Page 3]


Internet-Draft        Service Registration Protocol            July 2017


3.  Cleanup of Stale Data

   The traditional DNS Update mechanisms [RFC2136] [RFC3007] implicitly
   assume they are being used by a human operator.  If a human operator
   uses DNS Update (perhaps via the 'nsupdate' command) to create a
   record, then that record should stay created until the human operator
   decides to remove it.

   The same assumptions do not apply to machine-generated records.  If a
   mobile device creates one or more records using DNS Update, and later
   unceremoniously departs the network, then those stale records should
   eventually be removed.

   The mechanism proposed here is modeled on DHCP.  Just like a DHCP
   address lease, a record created using DNS Update has a lifetime.  If
   the record is not refreshed before its lifetime expires, then the
   record is deleted.

   When a client performs a DNS Update, it includes a EDNS(0) Update
   Lease option [DNS-UL].  The DNS Update Lease option indicates the
   requested lifetime of the records created or updated in the
   associated DNS Update message.  In the DNS Update reply, the server
   returns its own EDNS(0) Update Lease option indicating the granted
   lifetime, which may be shorter, the same, or longer than the client
   requested.  If the records are not refreshed before the granted
   lifetime expires, then the records are deleted.

   DNS servers may be configured to refuse DNS Updates that do not
   include a DNS Update Lease option.






















Cheshire & Lemon         Expires January 3, 2018                [Page 4]


Internet-Draft        Service Registration Protocol            July 2017


4.  Sleep Proxy

   Another use of Service Registration Protocol is for devices that
   sleep to reduce power consumption.

   In this case, in addition to the DNS Update Lease option [DNS-UL]
   described above, the device includes an EDNS(0) OWNER Option [Owner].

   The DNS Update Lease option constitutes a promise by the device that
   it will wake up before this time elapses, to renew its records and
   thereby demonstrate that it is still attached to the network.  If it
   fails to renew the records by this time, that indicates that it is no
   longer attached to the network, and its records should be deleted.

   The EDNS(0) OWNER Option indicates that the device will be asleep,
   and will not be receptive to normal network traffic.  When a DNS
   server receives a DNS Update with an EDNS(0) OWNER Option, that
   signifies that the DNS server should act as a proxy for any IPv4 or
   IPv6 address records in the DNS Update message.  This means that the
   DNS server should send ARP or ND messages claiming ownership of the
   IPv4 and/or IPv6 addresses in the records in question.  In addition,
   the DNS server should answer future ARP or ND requests for those IPv4
   and/or IPv6 addresses, claiming ownership of them.  When the DNS
   server receives a TCP SYN or UDP packet addressed to one of the IPv4
   or IPv6 addresses for which it proxying, it should then wake up the
   sleeping device using the information in the EDNS(0) OWNER Option.
   At present version 0 of the OWNER Option specifies the "Wake-on-LAN
   Magic Packet" that needs to be sent; future versions could be
   extended to specify other wakeup mechanisms.






















Cheshire & Lemon         Expires January 3, 2018                [Page 5]


Internet-Draft        Service Registration Protocol            July 2017


5.  First-Come First-Served Naming

   In some environments, such as home networks with an appropriate
   border gateway, it may be preferable to have some limited security on
   the protected internal network rather than no security at all.

   Users have shown limited willingness to endure complicated
   configuration for their networked home devices.  It is rare for home
   users to change even the factory-default name for their wireless
   printer, so it's questionable whether it's reasonable to expect them
   to configure passwords or security keys.

   This document presents a zero-configuration first-come first-served
   naming mechanism.

   Instead of requiring a preconfigured key installed by manual
   administration, a new device optimistically creates its DNS Service
   Discovery records, plus a DNS SIG(0) public key, using a DNS Update
   signed with its DNS SIG(0) private key.

   The DNS server validates the signature on the message using the
   SIG(0) key already stored on the name, if present, and otherwise with
   the key sent in the update, if the requested name is not yet present.
   The server may check that the two public keys are the same before
   validating, and refuse the update if they are not, to avoid the cost
   of verifying the signature.

   The lifetime of the DNS-SD PTR, SRV and TXT records [RFC6763] is
   typically set to two hours.  That way, if a device is disconnected
   from the network, its stale data does not persist for too long,
   advertising a service that is not accessible.

   However, the lifetime of its DNS SIG(0) public key should be set to a
   much longer time, typically 14 days.  The result of this is that even
   though a device may be temporarily unplugged, disappearing from the
   network for a few days, it makes a claim on its name that lasts much
   longer.

   This way, even if a device is unplugged from the network for a few
   days, and its services are not available for that time, no other
   rogue device can come along and immediately claim its name the moment
   it disappears from the network.  It takes a much longer time before
   an abandoned name becomes available for re-use.

   When using this first-come first-served security mechanism, the
   server accepting or rejecting the updates utilizes knowledge of the
   DNS-Based Service Discovery semantics [RFC6763].  Specifically, for
   all records aside from PTR records, the update must be validly signed



Cheshire & Lemon         Expires January 3, 2018                [Page 6]


Internet-Draft        Service Registration Protocol            July 2017


   using the SIG(0) key with the same DNS resource record owner name
   (the name on the left in a traditional textual zone file).  For
   additions or deletions of PTR records, the update must be validly
   signed using the SIG(0) key with the same DNS resource record owner
   name as the rdata in the PTR record (the name on the right in a
   traditional textual zone file).

6.  Security Considerations

   To be completed.









































Cheshire & Lemon         Expires January 3, 2018                [Page 7]


Internet-Draft        Service Registration Protocol            July 2017


7.  References

7.1.  Normative References

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

7.2.  Informative References

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <http://www.rfc-editor.org/info/rfc2136>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <http://www.rfc-editor.org/info/rfc3007>.

   [RFC6760]  Cheshire, S. and M. Krochmal, "Requirements for a Protocol
              to Replace the AppleTalk Name Binding Protocol (NBP)",
              RFC 6760, DOI 10.17487/RFC6760, February 2013,
              <http://www.rfc-editor.org/info/rfc6760>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

   [DisProx]  Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery", draft-ietf-dnssd-hybrid-06 (work in
              progress), March 2017.

   [DNS-UL]   Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns-
              ul-01 (work in progress), August 2006.

   [Roadmap]  Cheshire, S., "Service Discovery Road Map", draft-
              cheshire-dnssd-roadmap-00 (work in progress), July 2017.

   [Owner]    Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft-
              cheshire-edns0-owner-option-01 (work in progress), July
              2017.

   [ZC]       Cheshire, S. and D. Steinberg, "Zero Configuration
              Networking: The Definitive Guide", O'Reilly Media, Inc. ,
              ISBN 0-596-10100-7, December 2005.






Cheshire & Lemon         Expires January 3, 2018                [Page 8]


Internet-Draft        Service Registration Protocol            July 2017


Authors' Addresses

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com


   Ted Lemon
   Nominum, Inc.
   800 Bridge Parkway
   Redwood City, California  94065
   United States of America

   Phone: +1 650 381 6000
   Email: ted.lemon@nominum.com































Cheshire & Lemon         Expires January 3, 2018                [Page 9]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/