Internet DRAFT - draft-lemon-homenet-naming-architecture

draft-lemon-homenet-naming-architecture







Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                            March 21, 2016
Expires: September 22, 2016


           Homenet Naming and Service Discovery Architecture
               draft-lemon-homenet-naming-architecture-00

Abstract

   This document recommends a naming and service discovery resolution
   architecture for homenets.  This architecture covers the publication
   and resolution of names of hosts on the homenet both within the
   homenet and on the public internet, and the use of such names for
   offering and discovering services that exist on the homenet both
   within the homenet and on the public internet.  Security and privacy
   implications and techniques for automatically and administratively
   setting security and privacy policies for such names are also
   described.

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 22, 2016.

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



Lemon                  Expires September 22, 2016               [Page 1]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Existing solutions  . . . . . . . . . . . . . . . . . . .   4
   2.  Homenet Naming Database . . . . . . . . . . . . . . . . . . .   5
     2.1.  Global Name . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Local namespaces  . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Public namespaces . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Adding Names  . . . . . . . . . . . . . . . . . . . . . .   8
       2.4.1.  mDNS Snooping . . . . . . . . . . . . . . . . . . . .   8
       2.4.2.  DHCP DNS Update (stateful or stateless) . . . . . . .   9
       2.4.3.  DNS Update  . . . . . . . . . . . . . . . . . . . . .   9
     2.5.  Removing Names  . . . . . . . . . . . . . . . . . . . . .   9
     2.6.  Name Collisions . . . . . . . . . . . . . . . . . . . . .  10
     2.7.  Recovery from loss  . . . . . . . . . . . . . . . . . . .  10
     2.8.  Persistence . . . . . . . . . . . . . . . . . . . . . . .  10
     2.9.  Well-known names  . . . . . . . . . . . . . . . . . . . .  11
   3.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Configuring Resolvers . . . . . . . . . . . . . . . . . .  11
     3.2.  Configuring Service Discovery . . . . . . . . . . . . . .  12
     3.3.  Resolution of local namespaces  . . . . . . . . . . . . .  12
     3.4.  Local and Public Zones  . . . . . . . . . . . . . . . . .  12
     3.5.  Legacy support  . . . . . . . . . . . . . . . . . . . . .  13
     3.6.  DNSSEC Validation . . . . . . . . . . . . . . . . . . . .  13
     3.7.  Support for Multiple Provisioning Domains . . . . . . . .  14
     3.8.  Using the Local Namespace While Away From Home  . . . . .  14
   4.  Publishing the Public Namespace . . . . . . . . . . . . . . .  15
     4.1.  Acquiring the Global Name . . . . . . . . . . . . . . . .  15
     4.2.  Hidden Primary/Public Secondaries . . . . . . . . . . . .  16
     4.3.  DNSSEC security . . . . . . . . . . . . . . . . . . . . .  17
     4.4.  PKI security  . . . . . . . . . . . . . . . . . . . . . .  17
     4.5.  Renumbering . . . . . . . . . . . . . . . . . . . . . . .  18
     4.6.  ULA . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   5.  Management  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.1.  End-user management . . . . . . . . . . . . . . . . . . .  18
     5.2.  Central management  . . . . . . . . . . . . . . . . . . .  19
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20





Lemon                  Expires September 22, 2016               [Page 2]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


1.  Introduction

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

   o  Provisioning of a namespace in which names can be published and
      services advertised

   o  Associating a name within that namespace to the set of IP
      addresses on which a host is reachable

   o  Advertising services available on the local network and
      associating those services with names published in the namespace

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






Lemon                  Expires September 22, 2016               [Page 3]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


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

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

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

   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.

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

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

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



Lemon                  Expires September 22, 2016               [Page 4]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   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 solving the single-
   multicast-domain problem.  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.

2.  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.
   This isn't a clean dichotomy, however: it's possible for the source
   of truth about a name to be owned by the device, while the resolution
   of the name is owned by a service separate from the device.
   Additionally, if names are owned by devices, conflicts can arise,
   since two devices might present the same name by default or by
   accident.  Further, devices can be attached to more than one network,
   in which case we want the same name to identify them on both
   networks.  Additionally, although homenets are self-configuring, user
   customization is permitted and useful.

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

2.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 TLD [TBD1] as their
   "global name" until they are configured with a global name.

   [It's tempting to have the homenet generate a UUID-like name that can
   be used as a global name, but we really don't want that, because it
   will be quite ugly to the user, difficult to remember, and therefore
   not protective against the kinds of mistakes we'd want such a name to
   protect against.  It's better as a security UI to have the user see a
   name that is the same on all homenets.  This will allow the user to
   fairly easily notice that they see the same name on every homenet.
   To present a name that isn't really unique and isn't easily



Lemon                  Expires September 22, 2016               [Page 5]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   identified as anything other than "random gibberish," may lull the
   end user into a sense that they are talking to the right homenet when
   they see the random gibberish, without realizing that actually it's
   different gibberish and they aren't talking to their own homenet.]

   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 name under a domain owned by one of the
   user's service providers, or managed by some 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.

   [This doesn't belong in the arch document, at least not in this part,
   but I'm writing it down because I think we should discuss it and
   figure out exactly what we should recommend, and I do believe we
   should recommend something here and not just hope for the best.  I am
   also hoping to stave off frivolous, privacy-harming patents by
   publishing this now:]

   Providers of either of these types of homenet naming service should
   offer a selection of different provider TLDs rather than a flat
   namespace, so as to avoid the exampleuser1997 problem.  So for
   example rather than having a single namespace "isp.example.com", the
   provider should have a series of subdomains, like
   "grapefruit.example.com", "warrior.example.com", "koala.example.com",
   "rocket.example.com", and so forth.

   Some small number of such subdomains should be presented to the user
   when registering.  Subdomains with more than perhaps 50,000 homenets
   registered in them should never be presented for registration, to
   avoid chosen name collisions.  If the user is unable to find a
   namespace they like, it may be beneficial to allow the user to cycle
   through a larger set of namespaces.  The user should wind up with a
   global name like "hamburger.warrior.example.com".

   This specification may seem frivolous or overly-prescriptive.  The
   reason for being this specific is that it is important for the user
   to be able to quickly choose a memorable name that doesn't contain
   personal identifying information.  Getting this user interface right
   has significant implications for the user's privacy and security.
   Any user interface that meets the criterion that the user can quickly
   choose a memorable name that doesn't contain personal information
   will address this requirement.  The user should be specifically told



Lemon                  Expires September 22, 2016               [Page 6]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   not to use personal information like birthdays or names of friends or
   pets, and should be encouraged to write the chosen name down until
   they have it memorized.

2.2.  Local namespaces

   Every homenet has two non-hierarchical local namespaces, one for
   associating DNS RRs with names, and one for associating DNS RRs with
   IP addresses.  These namespaces are key-data stores, where for the
   name mapping the primary key is a single DNS label, and for the IP
   address mapping the primary key is an IP address.  The secondary key
   is an RRtype, so that there can be more than one RRset per IP
   address, and each data element is an RRset of the corresponding
   RRtype.

   Each RRset in each local namespace is marked with a flag that
   indicates whether it is to be public or private.  Each RRset is also
   marked with a flag that indicates whether its availability is
   critical or best-effort.  This flag only has meaning if the RRset is
   marked public.

   Each RR that contains a name (e.g, a CNAME or SRV record) either
   contains a name in the local namespace or a global name.  All global
   names are references to external services, not to services on the
   homenet.  All local names are qualified with the homenet-specific
   special-use TLD, [TBD1].

   [Question: do we need RRset granularity for these flags?]

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

2.3.  Public namespaces

   Every homenet has two public namespaces.  These are copies of the
   private namespaces with four modifications:

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

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




Lemon                  Expires September 22, 2016               [Page 7]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   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.

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

   [Are there RRtypes or classes of DNSSD records that we want to always
   omit?]

   Because the public namespaces are copies of the private namespaces,
   replication is not necessary: each homenet router automatically
   produces public namespaces by deriving them from the private
   namespaces using the above rules.  The public namespaces can be
   derived on demand, or maintained automatically as updates are made to
   the private namespaces.

   [Security/privacy considerations: It can be argued that public
   namespaces provide a means for botnets to publish rendezvous
   information.  However, in fact this isn't really true because if
   botnets did so, it would be very obvious, so would wind up being used
   as a means of tracking and suppressing them.  It's probably better to
   encourage this mistake rather than trying to prevent it, since the
   former benefits white hats, and the latter limits functionality.]

   [Presumably we want it to be possible for devices that are meant to
   be public servers to publish their names in the DNS, but how do we
   automatically determine that a device is "meant" to be public?  This
   needs thought.]

2.4.  Adding Names

   Several mechanisms are available for updating the HNDB.

2.4.1.  mDNS Snooping

   Homenet snoops mDNS for device names.  Homenet does not defend names.
   If two devices with the same name appear on a link, mDNS handles
   collision resolution.  If two devices with the same name appear on
   different links, homenet deterministically generates names for both
   devices using the link-layer address of each device, plus the name
   that device claimed.  If a device that appears on two links is the
   same device (presents the same link-layer address or DHCID) then it
   is treated as a single device, with a single name.  This whole
   discussion probably belongs in a separate draft.




Lemon                  Expires September 22, 2016               [Page 8]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


2.4.2.  DHCP DNS Update (stateful or stateless)

   A and PTR records can be set up this way.  Doesn't work (yet) for
   service discovery.  Should we write a draft, or just rely on:

2.4.3.  DNS Update

   DNS updates can be send to any resolver in the homenet to add names
   to the local zone.  If there is no conflict, the name is added;
   otherwise the update is rejected.

   [Really, what we ought to do is just allow devices to declare an ID
   that is a public key, and then do DNS updates to the local service
   zone signed with the corresponding private key.  Devices would also
   sign their mDNS claims with the same key, so that mDNS updates for
   devices that support this functionality can be ignored by the mDNS
   snooping agent.]

   [Records added to the namespace that contain names are problematic:
   the hostname label is obvious, but what about the domain name?  I
   think the answer is that these names shouldn't be qualified, and the
   name server should qualify them appropriately.  What does mDNS do?]

   [Add something about [TBD1] versus global name.  If there is a global
   name, that is what we use for name resolution on the local network.
   This is necessary because of the security implications, both for
   DNSSEC and for PKI.]

2.5.  Removing Names

   mDNS: names time out

   DHCP: names go away when lease expires, or, for stateless, when
   refresh timer expires

   DNS Update: names have to have a lifetime, determined by the DNS
   server, and DNSSD devices that do DNS Update have to keep sending
   updates at appropriate intervals to reset the timer.  If the lifetime
   of a name expires, the name is deleted.  Names can also be deleted by
   a new update, which must either be signed with SIG(0) using a key
   published on the name, or else must come from an IP address published
   in the name if no key is published on the name (what if there's no IP
   address?)








Lemon                  Expires September 22, 2016               [Page 9]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


2.6.  Name Collisions

   Covered under adding names.  Say more?

2.7.  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
   recovered:

   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.  We should
   have a protocol for informing devices that they should do this,
   either using an ND option or a DHCP message, or else devices should
   know to do a fresh announcement whenever the link goes away (but that
   doesn't work if the device is connected to the nearest router through
   a separate switch, so ND option is better).

   There should be some way (ideally) for the global name to be
   recovered.  How?  This will cause problems with DNSSEC, because the
   private ZSK is lost, and we don't expect the user to be smart about
   keys.  ZSK or KSK could be stored encrypted at the SP.  Subject to
   brute force attacks if so, probably not a good idea.  Better to just
   have a flag day?  One answer is the end-user management RESTful API:
   if the end-user has a phone, the ZSK and other static info can be
   maintained in an app on the phone; this app can then be in touch with
   the homenet, and if the homenet finds that it is amnesiac, the app
   can notify the user.  Of course, this is a potential attack--we don't
   want some other network the phone connects to to be able to steal the
   ZSK just by telling the app it's amnesiac.

2.8.  Persistence

   When the whole homenet goes away, can we recover the zone?  Step 1:
   figure out what name we had: how?  Then, if we have off-site
   secondaries that have copies of the private zone, we can poll for the
   highest serial number and copy the contents of that zone.  If we only
   have secondaries for the public part of the zone, we can recover
   that; should we?




Lemon                  Expires September 22, 2016              [Page 10]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


2.9.  Well-known names

   Homenets serve a zone under the special-use TLD [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 8).  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.  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 entries under this TLD are discarded whenever
   the host detects a network reattachment.

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

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 (right?).





Lemon                  Expires September 22, 2016              [Page 11]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


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, queries against the ".local" zone are
   supported, as well as queries 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).  In addition, the [TBD2] domain can be used, and is
   preferred.  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.  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.

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

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



Lemon                  Expires September 22, 2016              [Page 12]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   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.

3.5.  Legacy support

   In principle, devices that support DNSSD should be able to do service
   discovery using DNS without any special help.  Devices that only
   support mDNS should be able to get a complete list of services from a
   combination of names published by devices on the same link and by the
   homenet router that serves that link (what if there's more than
   one?).  In cases where the homenet router has an off-link entry that
   has the same claimed name as an on-link service, the homenet router
   does not advertise the off-link service.

3.6.  DNSSEC Validation

   The [TBD1] zone is not validated.  We could define a special rule,
   such that any particular local zone publishes a unique identifier for
   that zone and signs itself with a ZSK; a homenet-aware host could to
   TOFU on the id/ZSK, and could keep a list of id/ZSKs it has seen, and
   then do DNSSEC validation on names in the local zone that way, but
   it's a bit rickety and nonstandard, so I don't know if there's enough
   benefit to justify the cost.  Worth thinking about, though--could be
   the keystone of a homenet security model if done right.



Lemon                  Expires September 22, 2016              [Page 13]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


3.7.  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
   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
   services in the local service namespace.

3.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
   same way that services are registered, and the homenet will cache
   such keys.  Such keys must be validated by the end user before
   queries against the local namespace that have been authenticated with
   that key are permitted.  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].  If the local zone is not signed
   using DNSSEC, the host also caches each server's SIG(0) key.



Lemon                  Expires September 22, 2016              [Page 14]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   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 local namespace.
   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 names of the homenet routers that provide DNS
   service 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 is not
   signed, or doesn't have a trust anchor in the parent zone, the
   responding server signs the answer with its own SIG(0) key.  The
   resolver that sent the query validates the response using DNSSEC if
   possible, and otherwise using the SIG(0) key.

   [it can be argued that this isn't necessary for the base spec, and it
   obviously requires some additional protocol work, so may want to
   leave it out of the base architecture.  It may also make more sense
   to serve queries using DNS-over-TLS (dprive) rather than SIG(0).]

4.  Publishing the Public Namespace

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

   The RESTful API provides a method for generating a unique URL which
   can be used for a limited time by the GNRP to register the global



Lemon                  Expires September 22, 2016              [Page 15]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   name once the end user has chosen one and made payment arrangements
   (if necessary).  When the GNRP is ready to convey the global name to
   the homenet, it uses the specified URL to submit (POST) the name.
   The URL will be https, but the certificate will not be valid; its
   purpose is to provide privacy, not authenticity.

   In response, the homenet server either rejects the POST, if the URL
   has expired or is invalid, or else returns a text response containing
   a single label, '@', representing the local namespace.  Under that
   label, the homenet will include one or more DNSKEY records for zone
   signing keys, one of which is required, and key signing keys, which
   are not required.

   The returned zone will also include a TLSA record.  The record has a
   Usage field value of 0 (PKI Cert), a Selector value of 1 (just the
   public key), and a matching type of 0 (exact match).  The Certificate
   Association data field contains a public key generated by the homenet
   for use in authenticating local web traffic.

   The returned zone may include NS records; if it does, the GNRP is
   expected to use those NS records in the delegation for the global
   name.  Otherwise, it provides the NS records for its own
   authoritative servers.

   The GNRP then sets up a secure delegation using the currently-valid
   ZSKs included in the zone.  The GNRP also signs the public key
   provided in the TLSA record using a PKI cert owned by the GNRP that
   can be validated by web browsers, and posts it back to the homenet
   using the RESTful API URL.

   More detail on this process will be provided in a future document.
   [or really, how much detail should there be here?]

4.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 (or?) 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,



Lemon                  Expires September 22, 2016              [Page 16]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   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 (or?).  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.

4.3.  DNSSEC security

   All zones published by the homenet are signed.  Internal zones cannot
   have secure delegations, however.  Hosts that are aware of homenets
   can do TOFU authentication of a particular instance of the homenet
   zones [TBD1] or [TBD2].  To do this, the host queries the uuid.[TBD2]
   name.  The homenet always publishes this name with a single TXT RR
   containing a UUID, which is expected to be unique and stable.  The
   homenet will also publish a name, rev.[TBD2] which contains a PTR
   RRset that enumerates the outer delegations of all reverse zones
   operated by the homenet at the time of the query that are in private
   address spaces.

   The homenet-aware host can then query and cache the ZSKs of the
   [TBD2] domain on that homenet, using the UUID to identify it.  The
   homenet uses the same ZSK for all zones that it publishes.  Homenet-
   aware hosts can validate any record in the [TBD1] and [TBD2] zones
   and in reverse zones for private and ULA number spaces using the
   stashed ZSK for the homenet UUID to which the host is currently
   connected (may be different on different interfaces).  Names in non-
   private, non-ULA number spaces are validated using secure
   delegations, not homenet TOFU trust anchors, as are all other zones
   other than [TBD1] and [TBD2].

4.4.  PKI security

   PKI security is only possible if the homenet has a global name.  The
   homenet should not use TLS unless it has a certificate that will be
   successfully validated by web servers; otherwise, the homenet will be
   training end-users to click through certificate warnings, and will be
   inoperable to web browsers with correct security user interfaces
   (which never present such warnings).  If the homenet has a global
   name, it should also have gotten a valid PKI certificate as part of
   the process of acquiring the global name.



Lemon                  Expires September 22, 2016              [Page 17]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


   The homenet tracks the expiration date of the TLS certificate.  One
   month before expiration, the homenet will send a renewal request to
   the GNRP using the URL provided by the GNRP during registration.  The
   GNRP will then provide a new certificate and a new URL, which the
   homenet will record for the next renewal (the URL is not required to
   change).  Because the key to be signed is published in the public
   namespace of the homenet, there is no need for a secondary
   authentication path for the key.

4.5.  Renumbering

   The homenet may renumber at any time.  IP address RRs published in
   either 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
   DNS.  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.

4.6.  ULA

   Question: If the homenet has one or more ULAs, should we only publish
   the ULAs and not the global addresses in the local namespace?  This
   would prevent renumbering events from having any impact on local
   communication.  Any reason not to do this?  Would require some
   rewording of the local/global namespace text.

5.  Management

5.1.  End-user management

   Need to have well-known name with RESTful API that apps can connect
   to, so that you can have an app on your phone, laptop or whatever
   that operates the network.  This is a model that seems popular and
   accepted by end-users; having a well-defined API allows us to avoid a
   million different undocumented vendor-specific management APIs.  Web
   API would also be nice, but we can't specify that, so better to
   specify the RESTful API and let vendors decide what sort of frock to
   put on it.

   This API should provide a means for notifying end-users of issues on
   the home network, using whatever app they have installed.  The API
   must provide a mechanism for registering end-users or devices that
   are permitted to manage the homenet, and a way to recover if all such
   devices are lost.





Lemon                  Expires September 22, 2016              [Page 18]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


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

6.  Privacy Considerations

   Private information must not leak out as a result of publishing the
   public namespace.  We believe the current provisions adequately
   address this concern. (right?)

7.  Security Considerations

   Need someone with security fu to review the registration model, etc.,
   once we have it.

8.  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 TLD names
   registry:

   TBD1  Suggested value: "homenet"

   TBD2  Suggested value: "_hnsd"






Lemon                  Expires September 22, 2016              [Page 19]

Internet-Draft       Homenet Naming/SD Architecture           March 2016


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

   [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-03 (work in progress),
              February 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.

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 September 22, 2016              [Page 20]