[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                              July 8, 2016
Expires: January 9, 2017

           Homenet Naming and Service Discovery Architecture


   This document recommends a naming and service discovery resolution
   architecture for homenets.  This architecture covers local and global
   publication of names, discusses security and privacy implications,
   and addresses those implications.  The architecture also covers name
   resolution and service discovery for hosts on the homenet, and for
   hosts that roam off of the homenet and still need access to homenet

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 9, 2017.

Copyright Notice

   Copyright (c) 2016 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

Lemon                    Expires January 9, 2017                [Page 1]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Existing solutions  . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Homenet Naming Database . . . . . . . . . . . . . . . . . . .   5
     3.1.  Global Name . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Local namespaces  . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Public namespaces . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Maintaining Namespaces  . . . . . . . . . . . . . . . . .   9
       3.4.1.  Multicast DNS . . . . . . . . . . . . . . . . . . . .   9
       3.4.2.  DNS Update  . . . . . . . . . . . . . . . . . . . . .  10
     3.5.  Recovery from loss  . . . . . . . . . . . . . . . . . . .  10
     3.6.  Well-known names  . . . . . . . . . . . . . . . . . . . .  11
   4.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Configuring Resolvers . . . . . . . . . . . . . . . . . .  12
     4.2.  Configuring Service Discovery . . . . . . . . . . . . . .  12
     4.3.  Resolution of local namespaces  . . . . . . . . . . . . .  13
     4.4.  Service Discovery Resolution  . . . . . . . . . . . . . .  13
     4.5.  Local and Public Zones  . . . . . . . . . . . . . . . . .  14
     4.6.  DNSSEC Validation . . . . . . . . . . . . . . . . . . . .  15
     4.7.  Support for Multiple Provisioning Domains . . . . . . . .  15
     4.8.  Using the Local Namespace While Away From Home  . . . . .  16
   5.  Publishing the Public Namespace . . . . . . . . . . . . . . .  17
     5.1.  Acquiring the Global Name . . . . . . . . . . . . . . . .  17
     5.2.  Hidden Primary/Public Secondaries . . . . . . . . . . . .  17
     5.3.  PKI security  . . . . . . . . . . . . . . . . . . . . . .  18
     5.4.  Renumbering . . . . . . . . . . . . . . . . . . . . . . .  18
     5.5.  ULA . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   6.  Management  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.  End-user management . . . . . . . . . . . . . . . . . . .  18
     6.2.  Central management  . . . . . . . . . . . . . . . . . . .  18
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   9.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  19
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Associating domain names with hosts on the Internet is a key factor
   in enabling communication with hosts, particularly for service
   discovery.  In order to provide name service, several provisioning
   mechanisms must be available:

Lemon                    Expires January 9, 2017                [Page 2]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   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

   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.  With the possible exception of policy
        decisions, all of the operations mentioned here must reliably
        function automatically, without any user intervention or

   3.   Even to the extent that users may provide input on policy, such
        as whether a service should or should not be advertised outside
        of the home, the user must be able to safely provide such input
        without having a correct mental model of how naming and service
        discovery work, and without being able to reason about security
        in a nuanced way.

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

   5.   Where services are advertised both on and off the home network,
        differences in naming conventions that may vary depending on the
        user's location must likewise be transparent to the end user.

Lemon                    Expires January 9, 2017                [Page 3]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   6.   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.

   7.   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.

   8.   Homenet explicitly supports multihoming--connecting to more than
        one Internet Service Provider--and therefore support for
        multiple provisioning domains [9] 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.

   9.   Multihomed homenets may treat all service provider links as
        equivalent, or may treat some links as primary and some as
        backup, either because of differing transit costs or differing
        performance.  Services advertised off-network may therefore be
        advertised for some links and not others.

   10.  To the extent possible, the homenet should support DNSSEC.  If
        the homenet local domain is not unique, there should still be a
        mechanism that homenet-aware devices can use to bootstrap trust
        for a particular homenet.

   In addition to these considerations, there may be a need to provide
   for secure communication between end users and the user interface of
   the home network, as well as to provide secure name validation (e.g.,
   DNSSEC).  Secure communications require that the entity being secured
   have a name that is unique and can be cryptographically authenticated
   within the scope of use of all devices that must communicate with
   that entity.  Because it is very likely that devices connecting to
   one homenet will be sufficiently portable that they may connect to
   many homenets, the scope of use must be assumed to be global.
   Therefore, each homenet must have a globally unique identifier.

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 [7] can provide naming and service discovery
   [8], 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
   for updating namespaces by adding and removing names [4], and a

Lemon                    Expires January 9, 2017                [Page 4]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   mechanism for discovering services [8].  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 [10] 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.  Homenet Naming Database

   In order to resolve names, there must be a place where names are
   stored.  There are two ways to go about this: either names are stored
   on the devices that own them, or they are stored in the network
   infrastructure.  This isn't a clean division of responsibility,
   however.  It's possible for the device to maintain change control
   over its own name, while still performing name resolution for that
   name in the network infrastructure.

   If devices maintain change control on their own names, conflicts can
   arise.  Two devices might present the same name, either because their
   default names or the same, or as a result of accidental.  Devices can
   be attached to more than one link, in which case we want the same
   name to identify them on both networks.  Although homenets are self-
   configuring, user customization is permitted and useful, and while
   some devices may provide a user interface for setting their name, it
   may be worthwhile to provide a user interface and underlying support
   for allowing the user to specify a device's name in the homenet

Lemon                    Expires January 9, 2017                [Page 5]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   In order to achieve this, the Homenet Naming Database (HNDB) provides
   a persistent central store into which names can be registered.

3.1.  Global Name

   Every homenet must be able to have a name in the global DNS hierarchy
   which serves as the root of the zone in which the homenet publishes
   its public namespaces.  Homenets that do not yet have a name in the
   global namespace use the homenet special-use top-level name [TBD1] as
   their "global name" until they are configured with a global name.

   A homenet's global name can be a name that the homenet user has
   registered on their own in the DNS using a public DNS registrar.
   However, this is not required and, indeed, presents some operational
   challenges.  It can also be a subdomain of a domain owned by one of
   the user's ISP, or managed by some DNS service provider that
   specifically provides homenet naming services.

   For most end-users, the second or third options will be preferable.
   It will allow them to choose an easily-remembered homenet domain name
   under an easily-remembered service provider subdomain, and will not
   require them to maintain a DNS registration.

   Homenets must support automatic configuration of the homenet global
   name in a secure manner, as well as manual configuration of the name.
   The solution must allow a user with a smartphone application or a
   user with a web browser to successfully configure the homenet's
   global name without manual data entry.  The security implications of
   this process must be identified and, to the extent possible,

3.2.  Local namespaces

   Every homenet has two or more non-hierarchical local namespaces, one
   for names of hosts--the host namespace--and one or more for IP
   addresses--the address namespaces.  A namespace is a database table
   mapping each of a set keys to its value.  "Local" in this context
   means "visible to users of the homenet," as opposed to "public,"
   meaning visible to anyone.

   For the host namespace, the key is the set of labels in a name,
   excluding whatever labels represent the domain name of the namespace.
   So for example if the homenet's global name is "dog-
   pixel.example.com" and the name being looked up is "alice.dog-
   pixel.example.com", the key will be "alice".

   The local namespace may be available both in the global DNS namespace
   and under the [TBD1] special-use name.  The set of keys is the same

Lemon                    Expires January 9, 2017                [Page 6]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   in both cases--in the above example, the name could be either
   'alice.dog-pixel.example.com' or 'alice.[TBD1]'.  Whichever one of
   the two representations is used, the key is simply 'alice'.

   For each address namespace, the key is the locally-significant
   portion of the IP address.  For example, if the local prefix assigned
   by an ISP is 2001:DB8:bee7::/48, the name of that address namespace
   will be '7.e.e.b.8.b.d.'.  An IP address of
   2001:db8:bee7::1 would therefore yield a key of

   Every prefix in use on the homenet has an address namespace, whether
   its subdomain is delegated in the DNS or not.  This includes any
   public or private IPv4 prefixes in use [3] as well as any ULA
   prefixes in use [5], which can't be delegated [6].  When the valid
   lifetime for a prefix that had been in use on the homenet ends, the
   address namespace for that prefix is discarded.  Namespaces for
   prefixes that are manually configured, like IPv4 public prefixes and
   IPv4 private prefixes, persist as long as the prefix is configured.
   Since ULA prefixes have lifetimes, the lifetime rule applies to their
   address namespaces.

   In all namespaces, the value that the key addresses is a sub-table
   containing one or more RRsets, each of which is identified by its
   RRtype.  In the terminology of the DNS protocol, each of these
   namespaces is analogous to a DNS zone (but bear in mind that from the
   perspective of DNS queries, the namespace for names may appear to
   hosts connected to the homenet as two different zones containing
   identical data.

   However, in addition to DNS zone data, each RRset also has two
   metadata flags: the public flag and the critical flag.  The public
   flag indicates whether the data in this RRset should be publicly
   visible.  The critical flag indicates whether the service should be
   advertised even on high-cost internet links.

   Each RR that contains a name (e.g, a CNAME or SRV record) either
   contains a local name or a name in the public DNS.  Local names can
   be subdomains of the homenet's global name, yet not be public, if no
   RRsets in the namespace for names is marked public.  Local names can
   also be subdomains of [TBD1].  Names in the public DNS that are not
   subdomains of the homenet's global name can only be added by explicit
   action in one of the management interfaces described in Section 6.

   Each local namespace is maintained as a distributed database with
   copies on every homenet router.  No copy is the master copy.
   Although the local namespace is non-hierarchical, it is permissible
   for it to contain RRtypes that contain delegations.  However, from an

Lemon                    Expires January 9, 2017                [Page 7]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   operational perspective is is most likely better for the local
   namespace to be at the bottom of the delegation hierarchy, and so we
   do not recommend the use of such delegations.

3.3.  Public namespaces

   Every homenet has one or more public namespaces.  These are subsets
   of the local namespaces with the following modifications:

   1.  Names with no RRsets whose public bits are set are not included
       in the public namespace.

   2.  RRs that contain IP addresses in the homenet's ULA prefix are

   3.  By default, RRs that contain IPv4 addresses are omitted, because
       IPv4 doesn't support renumbering.  However, there should be a
       whitelist of IPv4 addresses that may be published, so that if the
       end user has static IPv4 addresses, those can be published.
       Private IPv4 addresses, however, are never published.

   4.  If an RRset is marked best-effort rather than critical, RRs
       containing IP addresses that have prefixes assigned by backup
       links are omitted.

   5.  If an RRset contains names, names that are subdomains of either
       the homenet's global name or [TBD1] are checked in the local host
       namespace to see if they are marked public.  If not, they are

   Because the public namespaces are subsets of the local namespaces,
   replication is not necessary: each homenet router automatically
   produces public namespaces by deriving them from the local namespaces
   using the above rules.  Answers to queries in the public namespaces
   can be generated on demand.  However, it may be preferable to
   maintain these namespaces as if they were DNS zones.  This makes it
   possible to use DNS zone transfers to offload the contents of public
   zones to a secondary service provider, eliminating the need to handle
   arbitrary numbers of queries from off of the homenet.

   A mechanism will be present that allows devices that have been
   configured to publicly advertise services to indicate to the homenet
   that the public bit and/or the backup bit will be set in RRsets that
   they publish.

Lemon                    Expires January 9, 2017                [Page 8]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

3.4.  Maintaining Namespaces

   Homenets support three methods for maintaining local namespaces.
   These rely on Multicast DNS, DNS updates, and any of the management
   mechanisms mentioned in Section 6.

3.4.1.  Multicast DNS

   HNRs cooperate to maintain a DNS mirror of the set of names published
   by mDNS.  This works similarly to the Multicast DNS Hybrid Proxy
   [10].  However, the DNSSD hybrid proxy exposes the topology of the
   network in which it operates to the user.

   In order to avoid this, the homenet solution maintains a host
   namespace for each non-edge link in the homenet.  Queries for names
   in the host namespace are looked up in the per-link host namespaces
   as well (and trigger mDNS queries as in the hybrid solution).  When a
   cross-link name conflict is present for a name, the name is presented
   with a short modifier identifying the link.

   For example, if two devices on two separate links both advertise the
   name 'janus' using mDNS, and the name 'janus' is not present in the
   host namespace, the two hosts' names are modified to, for example,
   'janus-1' and 'janus-2'.  If both devices present the human readable
   name 'Janus', then that name is presented as 'Janus (1)' and 'Janus
   (2)'.  If the name 'janus' appears in the host namespace, then that
   name is presented just as 'janus'.

   If a mDNS service advertises a name that appears in the host
   namespace, the HNR that hears the advertisement will defend the name,
   forcing the mDNS service to choose a different name.

   This solution shares a problem that mdns hybrid has: user interfaces
   on hosts that present mDNS names in their mDNS format (e.g.,
   'janus.local') will not have a DNS entry for 'janus.local'.
   Connections to such hosts using the name presented in the UI will
   work when both hosts are attached to the same link, but not

   It is preferable that devices that are homenet-aware publish their
   names using DNS updates rather than using mDNS.  mDNS is not
   supported as a query mechanism on homenets, other than in the sense
   that homeneds do not filter mDNS traffic on the local link.  Service
   discovery is instead done using DNS service discovery [8].  This
   mechanism is supported on all modern devices that do service
   discovery, so there is no need to rely on mDNS.

Lemon                    Expires January 9, 2017                [Page 9]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

3.4.2.  DNS Update

   DNS updates to the resolver on the local link are supported for
   adding names to local zones.  When an update is received, if the name
   being updated does not exist, or if the update contains the same
   information as is present in the existing record, then the update is
   accepted.  If a conflicting entry exists, the update is rejected.

   This update procedure is available to hosts that implement DNS update
   for DNS service discovery, but are not homenet-aware.  Hosts cannot
   delete records they have added, nor modify them; such records can
   only time out.  Updates to server list records require that the host
   referenced by the update exist, and that the update come from that
   host.  Such updates are additive, and are removed automatically when
   they become stale.

   Hosts that are homenet-aware generate a KEY record containing a
   public key for which they retain the private key.  They then publish
   their name in the host namespace, with whatever data they intend to
   publish on the name, and include the KEY record they have generated.
   The update is signed using SIG(0) on the provided key.  If a record
   already exists, and does not contain the same KEY record, the update
   is refused.  Otherwise it is accepted.

   Homenet-aware hosts can then update their entries in the address
   table and in service tables by using their KEY record with SIG(0).
   Entries can be added _and_ deleted.  However, only modifications to
   RRs that reference the name in the host namespace are allowed; all
   other RRs must be left as they are.

3.5.  Recovery from loss

   In principle the names in the zone aren't precious.  If there are
   multiple HNRs and one is replaced, the replacement recovers by
   copying the local namespaces and other info from the others.  If all
   are lost, there are a few pieces of persistent data that need to be

   o  The global name

   o  The ZSK for both local namespaces

   o  Names configured statically through the UI

   All other names were acquired dynamically, and recovery is simply a
   matter of waiting for the device to re-announce its name, which will
   happen when the device is power cycled, and also may happen when it

Lemon                    Expires January 9, 2017               [Page 10]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   sees a link state transition.  The hybrid mDNS implementation will
   also discover devices automatically when service queries are made.

   Devices that maintain their state using DNS update, but that are not
   homenet-aware, may or may not update their information when they see
   a link state transition.  Homenet-aware devices will update whenever
   they see a link-state transition, and also update periodically.  When
   the Homenet configuration has been lost, HNRs advertise a special ND
   option that indicates that naming and service discovery on the
   homenet is in a recovery state.  Homenet-aware devices will be
   sensitive to this ND option, and will update when it is seen.

   Homenets will present an standard management API, reachable through
   any homenet router, that allows a device that has stored the DNSSEC
   ZSK and KSK to re-upload it when it has been lost.  This is safest
   solution for the end user: the keys can be stored on some device they
   control, under password protection.

   ZSKs and KSKs can also be saved by the ISP or GNRP and re-installed
   using one of the management APIs.  This solution is not preferable,
   since it means that the end user's security is reliant on the
   security of the GNRP or ISP's infrastructure.

   If the ZSK and KSK are lost, they can be regenerated.  This requires
   that the homenet's global name change: there is no secure way to re-
   key in this situation.  Once the homenet has been renamed and re-
   keyed, all devices that use the homenet will simply see it as a
   different homenet.

3.6.  Well-known names

   Homenets serve a zone under the special-use top-level name [TBD2]
   that answers queries for local configuration information and can be
   used to advertise services provided by the homenet (as opposed to
   services present on the homenet).  This provides a standard means for
   querying the homenet that can be assumed by management functions and
   homenet clients.  A registry of well-known names for this zone is
   defined in IANA considerations (Section 9).  Names and RRs in this
   zone are only ever provided by the homenet--this is not a general
   purpose service discovery zone.

   All resolvers on the homenet will answer questions about names in
   this zone.  Entries in the zone are guaranteed not to be globally
   unique: different homenets are guaranteed to give independent and
   usually different answers to queries against this zone.  Hosts and
   services that use the special names under this TLD are assumed to be
   aware that it is a special TLD.  If such hosts cache DNS entries, DNS

Lemon                    Expires January 9, 2017               [Page 11]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   entries under this TLD are discarded whenever the host detects a
   network link state transition.

   The uuid.[TBD2] name contains a TXT RR that contains the UUID of the
   homenet.  Each homenet generates its own distinct UUID; homenet
   routers on any particular homenet all use the same UUID, which is
   agreed upon using HNCP.  If the homenet has not yet generated a UUID,
   queries against this name will return NXDOMAIN.

   The global-name.[TBD2] name contains a PTR record that contains the
   global name of the homenet.  If the homenet does not have a global
   name, queries against this name will return NXDOMAIN.

   The global-name-register.[TBD2] name contains one or more A and/or
   AAAA records referencing hosts (typically HNRs) that provide a
   RESTful API over HTTP that can be used to register the global name of
   the homenet, once that name has been configured.

   The all-resolver-names.[TBD2] name contains an NS RRset listing a
   global name for each HNR.  It will return NXDOMAIN if the homenet has
   no global name.  These names are generated automatically by each HNR
   when joining the homenet, or when a homenet to which the HNR is
   connected establishes a global name.

4.  Name Resolution

4.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.

4.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

Lemon                    Expires January 9, 2017               [Page 12]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

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

   Homenets advertise the availability of several browsing zones in the
   "b._dns_sd.<domain>" subdomain.  The zones advertised are the "well
   known" zone (TBD2) and the zone containing the local namespace.  If
   the global name is available, only that name is advertised for the
   local namespace; otherwise [TBD1] is advertised.  Similarly, if the
   global name is available, it 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>"; otherwise, the name [TBD1] is advertised as
   the default.

4.3.  Resolution of local namespaces

   The local namespace appears in two places, under [TBD1] and, if the
   homenet has a global name, under the global name.  Resolution from
   inside the homenet yields the contents of the local namespaces;
   resolution outside of the homenet yields the contents of the public
   namespaces.  If there is a global name for the homenet, RRs
   containing names in both instances of the local namespace are
   qualified with the global name; otherwise they are qualified with

4.4.  Service Discovery Resolution

   Because homenets provide service discovery over DNS, rather than over
   mDNS, support for DNS push notifications [11].  When a query arrives
   for a local namespace, and no data exists in that namespace to answer
   the query, that query is retransmitted as an mDNS query.  Data that
   exists to answer the query in mdns cached namespaces does not prevent
   an mDNS query being issued.

   If there is data available to answer the query in the host namespace
   or any of the dnssd cached namespaces, that data is aggregated and

Lemon                    Expires January 9, 2017               [Page 13]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   returned immediately.  If the host that sent the query requested push
   notification, then any mDNS responses that come in subsequent to the
   initial answer are sent as soon as they are received, and also added
   to the cache.  This means that if a name has been published directly
   using DNS, no mDNS query for that name is ever generated.

4.5.  Local and Public Zones

   The homenet's global name serves both as a unique identifier for the
   homenet and as a delegation point in the DNS for the zone containing
   the homenet's forward namespace.  There are two versions of the
   forward namespace: the public version and the private version.  Both
   of these versions of the namespace appear under the global name
   delegation, depending on which resolver a host is querying.

   The homenet provides two versions of the zone.  One is the public
   version, and one is the local version.  The public version is never
   visible on the homenet (could be an exception for a guest net).  The
   public version is available outside of the homenet.  The local
   version is visible on the homenet.  Whenever the zone is updated, it
   is signed with the ZSK.  Both versions of the zone are signed; the
   local signed version always has a serial number greater than the
   public signed version. [we want to not re-sign the public zone if no
   public names in the private zone changed.]

   This dual publication model relies on hosts connected to the homenet
   using the local resolver and not some external resolver.  Hosts that
   use an external resolver will see the public version of the
   namespace.  From a security UI design perspective, allowing queries
   from hosts on the homenet to resolvers off the homenet is risky, and
   should be prevented by default.  This is because if the user sees
   inconsistent behavior on hosts that have external resolvers
   configured, they may attempt to fix this by making all local names
   public.  If an alternate external resolver is to be used, it should
   be configured on the homenet, not on the individual host.

   One way to make this work is to intercept all DNS queries to non-
   homenet IP addresses, check to see if they reference the local
   namespace, and if so resolve them locally, answering as if from the
   remote cache.  If the query does not reference a local namespace, and
   is listed as "do not forward" in RFC 6761 or elsewhere, it can be
   sent to the intended cache server for resolution without any special
   handling for the response.  This functionality is not required for
   homenet routers, but is likely to present a better user experience.

Lemon                    Expires January 9, 2017               [Page 14]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

4.6.  DNSSEC Validation

   All namespaces are signed using the same ZSK.  The ZSK is signed by a
   KSK, which is ideally kept offline.  Validation for the global name
   is done using the normal DNSSEC trust hierarchy.  Validation for the
   [TBD1] and [TBD2] zones can be done by fetching the global name from
   the [TBD2] zone, fetching and validating the ZSK using DNSSEC, and
   then using that as a trust anchor.

   Only homenet-aware hosts will be able to validate names in the [TBD1]
   and [TBD2] zones.  The homenet-aware host validates non-global zones
   by determining which homenet it is connected to querying the
   uuid.[TBD2] and global-name.[TBD2] names.  If there is an answer for
   the global-name.[TBD2] query, validation can proceed using the trust
   anchor published in the zone that delegates the global name.  If only
   the uuid is present, then the homenet-aware host can use trust-on-
   first-use to validate that an answer came from the homenet that
   presented that UUID.  This provides only a limited degree of

4.7.  Support for Multiple Provisioning Domains

   Homenets must support the Multiple Provisioning Domain Architecture
   [9].  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 [12] will be
   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

Lemon                    Expires January 9, 2017               [Page 15]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   (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
   services in the local service namespace from hosts on the local link.

4.8.  Using the Local Namespace While Away From Home

   Homenet routers do not answer unauthenticated DNS queries from off
   the local network.  However, some applications may benefit from the
   ability to resolve names in the local namespace while off-network.
   Therefore hosts connected to the homenet can register keys in the
   host namespace using DNS Update.  Such keys must be validated by the
   end user before queries against the local namespace can be
   authenticated using that key.  A host that will make remote queries
   to the local namespace caches the names of all DNS servers on the
   homenet by querying all-resolver-names.[TBD2].

   Hosts that require name resolution from the local network must have a
   stub resolver configured to contact the dns server on one or more
   routers in the homenet when resolving names in the host or address
   namespaces.  To do this, resolvers must know the global name of the
   local namespace, which they can retain from previous connections to
   the homenet.

   The homenet may not have a stable IP address, so such resolvers
   cannot merely cache the IP address of the homenet routers.  Instead,
   they cache the NS record listing the HNRs and use those names to
   determine the IP addresses of the homenet routers at the time of
   resolution.  Such IP addresses can be safely cached for the duration
   of the TTL of the A or AAAA record that contained them.  The names of
   the homenet router DNS servers should be randomly generated so that
   they can't be guessed by off-network attackers.

   To make a homenet DNS query, the host signs the request using SIG(0)
   with the key that they registered to the homenet.  The homenet router
   first checks the question in the query for validity: it must be a
   subdomain of the global name.  The homenet router then checks the
   name of the signing key against the list of cached, validated keys;
   if that key is cached and validated, then the homenet router attempts
   to validate the SIG(0) signature using that key.  If the signature is
   valid, then the homenet router answers the query.  If the zone
   doesn't have a trust anchor in the parent zone, the responding server
   signs the answer with its own ZSK.  The resolver that sent the query
   validates the response using DNSSEC if possible, and otherwise using
   the ZSK directly.

Lemon                    Expires January 9, 2017               [Page 16]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

5.  Publishing the Public Namespace

5.1.  Acquiring the Global Name

   There are two ways to acquire a global name: the end-user can
   register a domain name using a public domain name registry, or the
   end-user can be assigned a subdomain of a registered domain by a
   homenet global name service provider.  We will refer to this as the
   Global Name Registration Provider [GNRP].  In either case, the
   registration process can either be manual or automatic.  Homenet
   routers support automatic registration regardless of the source of
   the homenet's global name, using a RESTful API.

5.2.  Hidden Primary/Public Secondaries

   The default configuration for a homenet's external name service is
   that the primary server for the zone is not published in an NS record
   in the zone's delegation.  Instead, the GNRP provides authoritative
   name service for the zone.  Whenever the public zone is updated, the
   hidden primary sends NOTIFY messages to all the secondaries, using
   the zone's ZSK to sign the message.

   When any of the GNRP secondary servers receives a notify for the
   zone, it checks to see that the notify is signed with a valid ZSK for
   that zone.  If so, it contacts the IP address from which the NOTIFY
   was send and initiates a zone transfer.  Using this IP address avoids
   renumbering issues.  Upon finishing the zone transfer, the zone is
   validated using each ZSK used to sign it.  If any validation fails,
   the new version of the zone is discarded.  If updates have been
   recevied, but no valid updates received, over a user-settable
   interval defaulting to a day (or?), the GNRP will communicate to the
   registered user that there is a problem.

   The reverse zone for any prefix delegated by an ISP should be
   delegated by that ISP to the home gateway to which the delegation was
   sent.  The list of secondaries for that zone is sent to the home
   gateway using DHCPv6 prefix delegation.  The ZSK is announced to the
   ISP in each DHCP PD message sent by the home gateway.  Whenever an
   update is made to this zone, the home gateway sends a NOTIFY to each
   of the listed secondaries for the delegation, and updates occur as
   described above.  Once the delegation is established, the ISP will
   not accept a different ZSK unless the prefix and its delegated zone
   are reassigned.

Lemon                    Expires January 9, 2017               [Page 17]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

5.3.  PKI security

   All communication with the homenet using HTTP is encrypted using
   opportunistic security.  If the homenet is configured with PKI, then
   the PKI certificate is used.  Homenets should automatically acquire a
   PKI certificate when a global name is established.  This certificate
   should be published in a TLSA record in the host namespace on any
   hostnames on which HTTP service is offered by HNRs.

5.4.  Renumbering

   The homenet may renumber at any time.  IP address RRs published in
   any namespace must never have a TTL that is longer than the valid
   lifetime for the prefix from which the IP address was allocated.  If
   a particular ISP has deprecated a prefix (its preferred lifetime is
   zero), IP addresses derived from that prefix are not published in the
   any namespace.  If more than one prefix is provided by the same ISP
   and some have different valid lifetimes, only IP addresses in the
   prefix or prefixes with the longest valid lifetime are published.

5.5.  ULA

   Homenets have at least one ULA prefix.  If a homenet has two ULA
   prefixes, and one is deprecated, addresses in the second ULA prefix
   are not published.  The default source address selection algorithm
   ensures that if a service is available on a ULA, that ULA will be
   used rather than the global address.  Therefore, no special effort is
   made in the DNS to offer only ULAs in response to local queries.

6.  Management

6.1.  End-user management

   Homenets provide two management mechanisms for end users: an HTTP-
   based user interface and an HTTP-based RESTful API [tbw].

   Homenets also provide a notification for end users.  By default, when
   an event occurs that requires user attention, the homenet will
   attract the user's attention by triggering captive portal detection
   on user devices.  Users can also configure specific devices to
   received management alerts using the RESTful management API; in this
   case, no captive portal notification is performed.

6.2.  Central management

   Possibly can be done mostly through RESTful API, but might want
   Netconf/Yang as well.  Should be possible to have the local namespace
   mastered on an external DNS auth server, e.g. in case a bunch of HNRs

Lemon                    Expires January 9, 2017               [Page 18]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   are actually set up in an org, or in case an ISP wants to provide a
   service package for users who would rather not have an entirely self-
   operating network.

7.  Privacy Considerations

   Private information must not leak out as a result of publishing the
   public namespace.  The 'public' flag on RRsets in homenet-managed
   namespaces prevents leakage of information that has not been
   explicitly marked for publication.

   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[13] to mitigate this risk.

8.  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.

9.  IANA considerations

   IANA will add a new registry titled Homenet Management Well-Known
   Names, which initially contains:

   uuid  Universally Unique Identifier--TXT record containing, in base64
      encoding, a stable, randomly generated identifier for the homenet
      that is statistically unlikely to be shared by any other homenet.

   global-name  The homenet's global name, represented as a PTR record
      to that name.

   global-name-register  The hostname of the homenet's global name
      registry service, with A and/or AAAA records.

   all-resolver-names  A list of all the names of the homenet's
      resolvers for the homenet PvD, represented as an RRset containing
      one or more PTR records.

   The IANA will allocate two names out of the Special-Use Domain Names

Lemon                    Expires January 9, 2017               [Page 19]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   TBD1  Suggested value: "homenet"

   TBD2  Suggested value: "_hnsd"

10.  Normative References

   [1]        Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

   [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]        Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,

   [4]        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,

   [5]        Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,

   [6]        Andrews, M., "Locally Served DNS Zones", BCP 163,
              RFC 6303, DOI 10.17487/RFC6303, July 2011,

   [7]        Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,

   [8]        Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

   [9]        Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,

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

Lemon                    Expires January 9, 2017               [Page 20]

Internet-Draft       Homenet Naming/SD Architecture            July 2016

   [11]       Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              draft-ietf-dnssd-push-07 (work in progress), April 2016.

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

   [13]       Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
              Hodges, "Token Binding over HTTP", draft-ietf-tokbind-
              https-05 (work in progress), July 2016.

Author's Address

   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

Lemon                    Expires January 9, 2017               [Page 21]

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