Simple Homenet Naming and Service Discovery Architecture
draft-tldm-simple-homenet-naming-00

Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                                D. Migault
Expires: September 14, 2017                                     Ericsson
                                                          March 13, 2017

        Simple Homenet Naming and Service Discovery Architecture
                  draft-tldm-simple-homenet-naming-00

Abstract

   This document describes a simple name resolution and service
   discovery architecture for homenets.  This architecture covers local
   publication of names, as well as name resolution for local and global
   names.

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 September 14, 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.

Lemon & Migault        Expires September 14, 2017               [Page 1]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Existing solutions  . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Configuring Resolvers . . . . . . . . . . . . . . . . . .   4
     3.2.  Configuring Service Discovery . . . . . . . . . . . . . .   5
     3.3.  Resolution of local names . . . . . . . . . . . . . . . .   5
     3.4.  DNSSEC Validation . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Support for Multiple Provisioning Domains . . . . . . . .   6
     3.6.  Using the Local Namespace While Away From Home  . . . . .   7
   4.  Management Considerations . . . . . . . . . . . . . . . . . .   7
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Associating domain names with hosts on the Internet is a key factor
   in enabling communication with hosts, particularly for service
   discovery.  This document describes a simple way of providing name
   service and service discovery for homenets.  In principle, it may
   make sense to be able to publish names of devices on the homenet, so
   that services on the homenet can be accessed outside of the homenet.
   Such publication is out of scope for this document.  It may be
   desirable to secure the homenet zone using DNSSEC.  This is likewise
   out of scope for this document.

   In order to provide name service, several provisioning mechanisms
   must be available:

   o  Provisioning of a domain name under which names can be published
      and services advertised

   o  Associating names that are subdomains of that name with hosts.

   o  Advertising services available on the local network by publishing
      resource records on those names.

   o  Distribution of names published in that namespace to servers that
      can be queried in order to resolve names

   o  Correct advertisement of name servers that can be queried in order
      to resolve names

Lemon & Migault        Expires September 14, 2017               [Page 2]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

   o  Timely removal of published names and resource records when they
      are no longer in use

   Homenet adds the following considerations:

   1.  Some names may be published in a broader scope than others.  For
       example, it may be desirable to advertise some homenet services
       to users who are not connected to the homenet.  However, it is
       unlikely that all services published on the home network would be
       appropriate to publish outside of the home network.  In many
       cases, no services will be appropriate to publish outside of the
       network, but the ability to do so is required.

   2.  Users cannot be assumed to be skilled or knowledgeable in name
       service operation, or even to have any sort of mental model of
       how these functions work.  All of the operations mentioned here
       must reliably function automatically, without any user
       intervention or debugging.

   3.  Because user intervention cannot be required, naming conflicts
       must be resolved automatically, and, to the extent possible,
       transparently.

   4.  Hosts that do not implement any homenet-specific capabilities
       must still be able to discover and access services on the
       homenet, to the extent possible.

   5.  Devices that provide services must be able to publish those
       services on the homenet, and those services must be available
       from any part of the homenet, not just the link to which the
       device is attached.

   6.  Homenet explicitly supports multihoming--connecting to more than
       one Internet Service Provider--and therefore support for multiple
       provisioning domains [6] is required to deal with situations
       where the DNS may give a different answer depending on whether
       caching resolvers at one ISP or another are queried.

1.1.  Existing solutions

   Previous attempts to automate naming and service discovery in the
   context of a home network are able to function with varying degrees
   of success depending on the topology of the home network.  For
   example, Multicast DNS [4] can provide naming and service discovery
   [5], but only within a single multicast domain.

   The Domain Name System provides a hierarchical namespace [1], a
   mechanism for querying name servers to resolve names [2], a mechanism

Lemon & Migault        Expires September 14, 2017               [Page 3]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

   for updating namespaces by adding and removing names [3], and a
   mechanism for discovering services [5].  Unfortunately, DNS provides
   no mechanism for automatically provisioning new namespaces, and
   secure updates to namespaces require pre-shared keys, which won't
   work for an unmanaged network.  DHCP can be used to populate names in
   a DNS namespace; however at present DHCP cannot provision service
   discovery information.

   Hybrid Multicast DNS [7] proposes a mechanism for extending multicast
   DNS beyond a single multicast domain..  However, it has serious
   shortcomings as a solution to the Homenet naming problem.  The most
   obvious shortcoming is that it requires that every multicast domain
   have a separate name.  This then requires that the homenet generate
   names for every multicast domain, and requires that the end user have
   a mental model of the topology of the network in order to guess on
   which link a given service may appear.  [xxx is this really true at
   the UI?]

2.  Terminology

   This document uses the following terms and abbreviations:

   HNR  Homenet Router

   ISP  Internet Service Provider

   GNRP  Global Name Registration Provider

3.  Name Resolution

3.1.  Configuring Resolvers

   Hosts on the homenet receive a set of resolver IP addresses using
   either DHCP or RA.  IPv4-only hosts will receive IPv4 addresses of
   resolvers, if available, over DHCP.  IPv6-only hosts will receive
   resolver IPv6 addresses using either stateful (if available) or
   stateless DHCPv6, or through the domain name option in router
   advertisements.  All homenet routers provide resolver information
   using both stateless DHCPv6 and RA; support for stateful DHCPv6 and
   DHCPv4 is optional, however if either service is offered, resolver
   addresses will be provided using that mechanism as well.  Resolver IP
   addresses will always be IP addresses on the local link: every HNR is
   required to provide name resolution service.  This is necessary to
   allow DNS update using presence on-link as a mechanism for rejecting
   off-network attacks.

Lemon & Migault        Expires September 14, 2017               [Page 4]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

3.2.  Configuring Service Discovery

   DNS-SD uses several default domains for advertising local zones that
   are available for service discovery.  These include the '.local'
   domain, which is searched using mDNS, and also the IPv4 and IPv6
   reverse zone corresponding to the prefixes in use on the local
   network.  For the homenet, no support for queries against the
   ".local" zone is provided by HNRs: a ".local" query will be satisfied
   or not by services present on the local link.  This should not be an
   issue: all known implementations of DNSSD will do unicast queries
   using the DNS protocol.

   Service discovery is configured using the technique described in
   Section 11 of DNS-Based Service Discovery [5].  HNRs will answer
   domain enumeration ueries against every IPv4 address prefix
   advertised on a homenet link, and every IPv6 address prefix
   advertised on a homenet link, including prefixes derived from the
   homenet's ULA(s).  Whenever the "<domain>" sequence appears in this
   section, it references each of the domains mentioned in this
   paragraph.

   Homenets advertise the availability of several browsing zones in the
   "b._dns_sd.<domain>" subdomain.  By default, the TBD1 domain is
   advertised.  Similarly, TBD1 is advertised as the default browsing
   and service registration domain under "db._dns_sd.<domain>",
   "r._dns_sd.<domain>", "dr._dns_sd.<domain>" and
   "lb._dns_sd.<domain>".

3.3.  Resolution of local names

   Local names appear as subdomains of [TBD1].  These names can only be
   resolved within the homenet; not only is [TBD1] not a globally unique
   name, but queries from outside of the homenet for any name, on or off
   the homenet, must be rejected with a REFUSED response.

   In addition, names can appear as subdomains of the locally-served
   'in-addr.arpa' or 'ip6.addr' zone that corresponding to the ULA that
   is in use on the homenet.  IP addresses and names advertised locally
   MUST use the homenet's ULA.

   It is possible that local services may number themselves using more
   than one of the prefixes advertised locally.  Homenet hybrid proxies
   MUST filter out global IP addresses, providing only ULA addresses,
   similar to the process described in section 5.5.2 of [7]. [xxx is
   this going to be a problem?]

   The Hybrid Proxy model relies on each link having its own name.
   However, homenets do not actually have a way to name local links that

Lemon & Migault        Expires September 14, 2017               [Page 5]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

   will make any sense to the end user.  Consequently, this mechanism
   will not work.  In order to paper over this, some changes are
   required:

   o  The Hybrid Proxy function is divided into two: relaying proxies,
      and aggregating proxies.  There must be exactly one querying proxy
      per link; there can be as few as one aggregating proxy per
      homenet.

   o  Relaying proxies do no translation, for example from ".local" to
      "bldg1.example.com" as shown in section 5.3 of [7].  They simply
      take queries over the DNS protocol for names in subdomains of
      '.local', the link-specific 'ip6.addr', and the link-specific 'in-
      addr.arpa' zones, and respond with the exact answers received.

   o  There must be exactly one querying proxy per internal link on the
      homenet; for links that are connected to more than one homenet
      router, HNCP is used to choose which router will provide the
      service.

   o  Querying proxies perform translation.  Machine readable names are
      presented as subdomains of the TBD1 domain.  Human readable names
      are presented as subdomains of the _hr.TBD1 domain.

   o  Every homenet router can provide a querying proxy, or only one
      router can.  This is determined by HNCP; all homenet routers must
      provide this capability, but some homenet routers may provide
      enhanced querying proxy capabilities such that homenet routers
      providing only those capabilities described in this document must
      be disabled.  Therefore, all homenet routers must be able to act
      as a querying proxy, or forward DNS queries to a central querying
      proxy, according to what is specified through HNCP.

3.4.  DNSSEC Validation

   DNSSEC Validation for the TBD1 zone and for the locally-served
   'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust
   anchor.  Establishment of a trust anchor for such validation is out
   of scope for this document.

3.5.  Support for Multiple Provisioning Domains

   Homenets must support the Multiple Provisioning Domain Architecture
   [6].  In order to support this architecture, each homenet router that
   provides name resolution must provide one resolver for each
   provisioning domain (PvD).  Each homenet router will advertise one
   resolver IP address for each PvD.  DNS requests to the resolver
   associated with a particular PvD, e.g. using RA options [8] will be

Lemon & Migault        Expires September 14, 2017               [Page 6]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

   resolved using the external resolver(s) provisioned by the service
   provider responsible for that PvD.

   The homenet is a separate provisioning domain from any of the service
   providers.  The global name of the homenet can be used as a
   provisioning domain identifier, if one is configured.  Homenets
   should allow the name of the local provisioning domain to be
   configured; otherwise by default it should be "Home Network xxx",
   where xxx is the generated portion of the homenet's ULA prefix,
   represented as a base64 string.

   The resolver for the homenet PvD is offered as the primary resolver
   in RAs and through DHCPv4 and DHCPv6.  When queries are made to the
   homenet-PvD-specific resolver for names that are not local to the
   homenet, the resolver will use a round-robin technique, alternating
   between service providers with each step in the round-robin process,
   and then also between external resolvers at a particular service
   provider if a service provider provides more than one.  The round-
   robining should be done in such a way that no service provider is
   preferred, so if service provider A provides one caching resolver
   (A), and service provider B provides two (B1, B2), the round robin
   order will be (A, B1, A, B2), not (A, B1, B2).

   Every resolver provided by the homenet, regardless of which
   provisioning domain it is intended to serve, will accept updates for
   subdomains of the TBD1 and locally-served 'ip6.arpa' and 'in-
   addr.arpa' domains from hosts on the local link.

3.6.  Using the Local Namespace While Away From Home

   This architecture does not provide a way for service discovery to be
   performed on the homenet by devices that are not directly connected
   to a link that is part of the homenet.

4.  Management Considerations

   This architecture is intended to be self-healing, and should not
   require management.  That said, a great deal of debugging and
   management can be done simply using the DNS service discovery
   protocol.

5.  Privacy Considerations

   Privacy is somewhat protected in the sense that names published on
   the homenet are only visible to devices connected to the homenet.
   This may be insufficient privacy in some cases.

Lemon & Migault        Expires September 14, 2017               [Page 7]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

   The privacy of host information on the local net is left to hosts.
   Various mechanisms are available to hosts to ensure that tracking
   does not occur if it is not desired.  However, devices that need to
   have special permission to manage the homenet will inevitably reveal
   something about themselves when doing so.  It may be possible to use
   something like HTTP token binding[9] to mitigate this risk.

6.  Security Considerations

   There are some clear issues with the security model described in this
   document, which will be documented in a future version of this
   section.  A full analysis of the avenues of attack for the security
   model presented here have not yet been done, and must be done before
   the document is published.

7.  IANA considerations

   This document is relying on the allocation of [TBD1] described in
   Special Use Top Level Domain '.homenet' [10].  As such, no new
   actions are required by IANA, but this document can't proceed until
   that allocation is done.  At that time, the name [TBD1] can be
   substituted for the name that is eventually allocated during the
   processing of that document.

8.  Normative References

   [1]        Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [2]        Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [3]        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>.

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

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

Lemon & Migault        Expires September 14, 2017               [Page 8]
Internet-Draft        Simple Homenet Naming/SD Arch           March 2017

   [6]        Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <http://www.rfc-editor.org/info/rfc7556>.

   [7]        Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
              Discovery", draft-ietf-dnssd-hybrid-05 (work in progress),
              November 2016.

   [8]        Korhonen, J., Krishnan, S., and S. Gundavelli, "Support
              for multiple provisioning domains in IPv6 Neighbor
              Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03
              (work in progress), February 2016.

   [9]        Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
              Hodges, "Token Binding over HTTP", draft-ietf-tokbind-
              https-08 (work in progress), February 2017.

   [10]       Pfister, P. and T. Lemon, "Special Use Top Level Domain
              '.homenet'", draft-ietf-homenet-dot-03 (work in progress),
              March 2017.

Authors' Addresses

   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

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC H4P 2N2
   Canada

   Email: daniel.migault@ericsson.com

Lemon & Migault        Expires September 14, 2017               [Page 9]