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


                        Service Discovery Broker
                     draft-sctl-discovery-broker-00

Abstract

   DNS-Based Service Discovery allows clients to discover available
   services using unicast DNS queries.  In simple configurations these
   unicast DNS queries go directly to the appropriate authoritative
   server(s).  In large networks that have complicated topology, or
   many client devices, or both, it can be advantageous to have an
   intermediary between the clients and authoritative servers.  This
   intermediary, called a Discovery Broker, serves several purposes.
   A Discovery Broker can reduce load on both the servers and the
   clients, and gives the option of presenting clients with service
   discovery organized around logical, rather than physical, topology.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



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


Internet-Draft          Service Discovery Broker               July 2017


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

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

   DNS-SD operates on a single network link (broadcast domain) using
   Multicast DNS [RFC6762].  DNS-SD can span multiple links using
   unicast DNS.

   In the DNS-SD specification [RFC6763] section 11, "Discovery of
   Browsing and Registration Domains (Domain Enumeration)", describes
   how client devices are automatically configured with the appropriate
   unicast DNS domains in which to perform their service discovery
   queries.  When used in conjunction with a Discovery Proxy [DisProx]
   this allows clients to discover services on remote links, even when
   the devices providing those services support only the basic Multicast
   DNS form of DNS-Based Service Discovery.  A Discovery Broker is a
   companion technology that operates in conjunction with existing
   authoritative DNS servers (such as a Discovery Proxy [DisProx]) and
   existing clients performing service discovery using unicast DNS
   queries.























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


Internet-Draft          Service Discovery Broker               July 2017


2.  Problem Statement

   The following description of how a Discovery Broker works is
   illustrated using the example of a long rectangular office building.
   The building is large enough to have hundreds or even thousands of
   employees working there, the network is large enough that it would be
   impractical to operate it as a single link (a single broadcast
   domain, with a single IPv4 subnet or IPv6 network prefix).

   Suppose, for this example, that the network is divided into twelve
   separate links, connected by routers.  Each link has its own IPv6
   network prefix.  The division of the network into twelve sections of
   roughly equal size is somewhat arbitrary, and does not necessarily
   follow any physical boundaries in the building that are readily
   apparent to its inhabitants.  Two people in adjacent offices on the
   same corridor may have Ethernet ports connected to different links.
   Indeed, two devices in the same office, connected to the company
   network using secure Wi-Fi, may inadvertently associate with
   different access points, which happen to be connected to different
   wired links with different IPv6 network prefixes.

   If this network were operated the way most networks have historically
   been operated, it would use only Multicast DNS Service Discovery, and
   adjacent devices that happen to connect to different underlying links
   would be unable to discover each other.  And this would not be a rare
   occurrence.  Since this example building contains eleven invisible
   boundaries between the twelve different links, anyone close to one of
   those invisible boundaries will have a population of nearby devices
   that are not discoverable on the network, because they're on a
   different link.  For example, a shared printer in a corridor outside
   one person's office may not be discoverable by the person in the very
   next office.

   One path to solving this problem is as follows:

   1.  Install a Discovery Proxy [DisProx] on each of the twelve links.

   2.  Create twelve named subdomains, such as, "services1.example.com",
       "services2.example.com", "services3.example.com", and so on.

   3.  Delegate each named subdomain to the corresponding Discovery
       Proxy on that link.

   4.  Create entries in the 'ip6.arpa' reverse mapping zone directing
       clients on each link to perform service discovery queries in the
       appropriate named subdomains, as documented in section 11 of the
       DNS-SD specification [RFC6763].




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


Internet-Draft          Service Discovery Broker               July 2017


   In step 4 above, it might be tempting to add only a single record in
   each reverse mapping domain referencing the corresponding services
   subdomain.  This would work, but it would only facilitate each client
   discovering the same services it could already discover using
   Multicast DNS [RFC6762].  In some cases even this is useful, such as
   when using Wi-Fi Access Points with multicast disabled for
   efficiency.  In such cases this configuration would allow wireless
   clients to discover services on the wired network segment without
   having to use costly Wi-Fi multicast.

   But for this example we want to achieve more than just equivalency
   with Multicast DNS.

   In this example, each reverse mapping domain is populated with the
   name of its own services subdomain, plus its neighbors.  The reverse
   mapping domain for the first link has two "lb._dns-sd._udp" PTR
   records, referencing "services1.example.com" and
   "services2.example.com".  The second link references services1,
   services2, and services3.  The third link references services2,
   services3, and services4.  This continues along the building, until
   the last link, which references services11 and services12.

   In this way a "sliding window" is created, where devices on each link
   are directed to look for services both on that link and on its two
   immediate neighbors.  Depending on the physical and logical
   topologies of the building and its network, it may be appropriate to
   direct clients to query in more than three services subdomains.  If
   the building were a ring instead of a linear rectangle, then the
   network topology would "wrap around", so that links 1 and 12 would be
   neighbors.

   This solves the problem of being unable to discover a nearby device
   because it happens to be just the other side of one of the twelve
   arbitrary invisible network link boundaries.

   For many cases this solution is adequate, but there is an issue to
   consider.  In the example above, a client device on link 5 has TCP
   connections to three Discovery Proxies, on links 4, 5 and 6.  In a
   more complex setup each client could have many more TCP connections
   to different Discovery Proxies.

   Similarly, if there are a many clients, each Discovery Proxy could be
   required to handle thousands of simultaneous TCP connections from
   clients.

   The solution to these two problems is the Discovery Broker.





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


Internet-Draft          Service Discovery Broker               July 2017


3.  Discovery Broker Operation

   The Discovery Broker is an intermediary between the client devices
   and the Discovery Proxies.  It is a kind of multiplexing crossbar
   switch.  It shields the clients from having to connect to multiple
   Discovery Proxies, and it shields the Discovery Proxies from having
   to accept connections from thousands of clients.

   Each client needs only a single TCP connection to a single Discovery
   Broker, rather than multiple TCP connections directly to multiple
   Discovery Proxies.  This eases the load on client devices, which may
   be mobile and battery-powered.

   Each Discovery Proxy needs to support connections to at most a small
   number of Discovery Brokers.  The burden of supporting thousands of
   clients is taken by the Discovery Broker, which can be a powerful
   server in a data center.  This eases the load on the Discovery Proxy,
   which may be implemented in a device with limited RAM and CPU
   resources, like a Wi-Fi access point or IP router.

   Recall that a Discovery Proxy [DisProx] is a special kind of
   authoritative DNS server [RFC1034] [RFC1035].  Externally it behaves
   like a traditional authoritative DNS server, except that instead of
   getting its zone data from a manually-administered zone file, it
   learns its zone data dynamically as a result of performing Multicast
   DNS queries on its local link.

   A Discovery Broker is a similar concept, except that it learns its
   zone data dynamically as a result of performing *unicast* DNS
   queries.  For example, a Discovery Broker could be configured so that
   the answer for "<something>.discovery5.example.com" is obtained by
   performing corresponding unicast DNS queries:

      <something>.services4.example.com
      <something>.services5.example.com
      <something>.services6.example.com

   and then returning the union of the results as the answer.  The rdata
   of the returned answers is not rewritten or modified in any way by
   the Discovery Broker.











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


Internet-Draft          Service Discovery Broker               July 2017


4.  Protocol Transparency

   From the point of view of an authoritative DNS server such as a
   Discovery Proxy, the protocol a Discovery Broker uses to make
   requests of it is the exact same DNS protocol that any other client
   would use to make requests of it (which may be traditional one-shot
   DNS queries [RFC1034] [RFC1035] or long-lived DNS Push Notifications
   [Push]).

   A Discovery Broker making requests is no different from any other
   client making requests.  The fact that the Discovery Broker may be
   making a single request on behalf of thousands of clients making the
   same request, thereby shielding the Discovery Proxy from excessive
   traffic burden, is invisible to the Discovery Proxy.

   This means that an authoritative DNS server such as a Discovery Proxy
   does not have to be aware that it is being queried by a Discovery
   Broker.  In some scenarios a Discovery Proxy may be deployed with
   clients talking to it directly; in other scenarios the same Discovery
   Proxy product may be deployed with clients talking via a Discovery
   Broker.  The Discovery Proxy simply answers queries as usual in both
   cases.

   Similarly, from the point of view of a client, the protocol it uses
   to talk to a Discovery Broker is the exact same DNS protocol it uses
   to talk to a Discovery Proxy or any other authoritative DNS server.

   This means that the client does not have to be aware that it is using
   a Discovery Broker.  The client simply sends service discovery
   queries as usual, according to configuration it received from the
   network or otherwise, and receives answers as usual.  A Discovery
   Broker may be employed to shield a Discovery Proxy from excessive
   traffic burden, but this is transparent to a client.

   Another benefit for the client is that by having the Discovery Broker
   query multiple subdomains and aggregate the results, it saves the
   client from having to do multiple separate queries of its own.














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


Internet-Draft          Service Discovery Broker               July 2017


5.  Logical vs. Physical Topology

   In the example so far, we have focussed on facilitating discovery of
   devices and services that are physically nearby.

   Another application of the Discovery Broker is to facilitate
   discovery of devices and services according to other logical
   relationships.

   For example, it might be considered desirable for the company's two
   file servers to be discoverable company-wide, but for its many
   printers to only be discovered (by default) by devices on nearby
   network links.

   As another example, company policy may block access to certain
   resources from Wi-Fi; in such cases it would make sense to implement
   consistent policies at the service discovery layer, to avoid the user
   frustration of services being discoverable on Wi-Fi that are not
   usable from Wi-Fi.

   Such policies, and countless variations thereon, may be implemented
   in a Discovery Broker, limited only by the imagination of the vendor
   creating the Discovery Broker implementation.




























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


Internet-Draft          Service Discovery Broker               July 2017


6.  Recursive Application

   Due to the Protocol Transparency property described above, multiple
   Discovery Brokers may be "stacked" in whatever combinations are
   useful.  A Discovery Broker makes queries in exactly the same way a
   client would, and a Discovery Broker accepts queries in exactly the
   same way a Discovery Proxy (or other authoritative DNS server) would.
   This means that a Discovery Broker talking to another Discovery
   Broker is no different from client-to-broker or broker-to-proxy
   communication, or indeed, direct client-to-proxy communication.  The
   arrows in the chart below are all instances of the same communication
   protocol.

      client -> proxy

      client -> broker -> proxy

      client -> broker -> broker -> proxy

   This makes it possible to combine Discovery Brokers with different
   functionality.  A Discovery Broker performing physical aggregation
   could be used in conjunction with a Discovery Broker performing
   policy-based filtering, as illustrated below:

   ------------                       ---------------     -------------
   | Ethernet |          -->          | Aggregating | --> | Discovery |
   |  Client  |                       |   Broker    |     |   Proxy   |
   ------------                       ---------------     -------------

   ------------     -------------     ---------------     -------------
   |  Wi-Fi   | --> | Filtering | --> | Aggregating | --> | Discovery |
   |  Client  |     |  Broker   |     |   Broker    |     |   Proxy   |
   ------------     -------------     ---------------     -------------


















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


Internet-Draft          Service Discovery Broker               July 2017


7.  Security Considerations

   Discovery (or non-discovery) of services is not a substitute for
   suitable access control.  Servers listening on open ports are
   generally discoverable via a brute-force port scan anyway; DNS-Based
   Service Discovery makes access to these services easier for
   legitimate users.

8.  Informative References

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

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

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

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

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

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

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

   [Push]     Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              draft-ietf-dnssd-push-12 (work in progress), July 2017.

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







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


Internet-Draft          Service Discovery Broker               July 2017


Authors' Addresses

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

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


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

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































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