Skip to main content

Properties of an Ideal Naming Service
draft-trammell-inip-pins-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Brian Trammell
Last updated 2016-02-18
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-trammell-inip-pins-00
Names and Identifiers Program                                B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Informational                         February 18, 2016
Expires: August 21, 2016

                 Properties of an Ideal Naming Service
                      draft-trammell-inip-pins-00

Abstract

   This document specifies a set of necessary functions and desirable
   properties of an ideal system for resolving names to addresses and
   associated information for establishing communication associations in
   the Internet.  For each property, it briefly explains the rationale
   behind it, and how the property is or could be met with the present
   Domain Name System.  It is intended to start a discussion within the
   IAB's Names and Identifiers program about gaps between the present
   reality of DNS and the naming service the Internet needs by returning
   to first principles.

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 August 21, 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

Trammell                 Expires August 21, 2016                [Page 1]
Internet-Draft                    PINS                     February 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Query Interface . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Name to Address . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Address to Name . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Name to Name  . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Name to Auxiliary Information . . . . . . . . . . . . . .   4
     3.5.  Name/Address to Auxiliary Information . . . . . . . . . .   4
   4.  Authority Interface . . . . . . . . . . . . . . . . . . . . .   5
   5.  Properties  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Authority . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  Federation of Authority . . . . . . . . . . . . . . .   5
       5.1.2.  Unity of Authority  . . . . . . . . . . . . . . . . .   5
       5.1.3.  Transparency of Authority . . . . . . . . . . . . . .   6
       5.1.4.  Consensus on Root of Authority  . . . . . . . . . . .   6
     5.2.  Authenticity  . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.1.  Authenticity of Delegation  . . . . . . . . . . . . .   6
       5.2.2.  Authenticity of Response  . . . . . . . . . . . . . .   6
       5.2.3.  Authenticity of Negative Response . . . . . . . . . .   7
     5.3.  Consistency . . . . . . . . . . . . . . . . . . . . . . .   7
       5.3.1.  Dynamic Consistency . . . . . . . . . . . . . . . . .   7
       5.3.2.  Explicit Inconsistency  . . . . . . . . . . . . . . .   7
     5.4.  Performance Properties  . . . . . . . . . . . . . . . . .   8
       5.4.1.  Availability  . . . . . . . . . . . . . . . . . . . .   8
       5.4.2.  Lookup Latency  . . . . . . . . . . . . . . . . . . .   8
       5.4.3.  Bandwidth Efficiency  . . . . . . . . . . . . . . . .   8
       5.4.4.  Query Linkability . . . . . . . . . . . . . . . . . .   8
       5.4.5.  Explicit Tradeoff . . . . . . . . . . . . . . . . . .   9
   6.  Observations  . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Delegation and Redirection are Separate Operations  . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Internet's Domain Name System (DNS) [RFC1035] is an excellent
   illustration of the advantages of the decentralized architecture that
   have made the Internet able to scale to its present size.  However,

Trammell                 Expires August 21, 2016                [Page 2]
Internet-Draft                    PINS                     February 2016

   the choices made in the evolution of the DNS since its initial design
   are only one path through the design space of Internet-scale naming
   services.  Many other naming services have been proposed, though none
   has been remotely as successful for general- purpose use in the
   Internet.

   This document returns to first principles, to determine the
   dimensions of the design space of desirable properties of an
   Internet-scale naming service.  It is a work in progress, intended to
   start a discussion within the IAB's Names and Identifiers program
   about gaps between the present reality of DNS and the naming service
   the Internet needs.

   Section 3 and Section 4 define the set of operations a naming service
   should provide for queriers and authorities, Section 5 defines a set
   of desirable properties of the provision of this service, and
   Section 6 examines implications of these properties.

2.  Terminology

   The following capitalized terms are defined and used in this
   document:

   o  Subject: A name, address, or name-address pair about which the
      naming service can answer queries

   o  Association: A mapping between a Subject and information about
      that Subject

   o  Authority: An entity that has the right to determine which
      Associations exist within its namespace

   o  Delegation: An Association that indicates that an Authority has
      given the right to make assertions about the Associations within
      the part of a namespace identified by a Subject to a subordinate
      Authority.

   [EDITOR'S NOTE: need to make a terminology unification pass]

3.  Query Interface

   At its core, a naming service must provide a few basic functions for
   queriers, associating a Subject of a query with information about
   that subject.  The information available from a naming service is
   that which is necessary for a querier to establish a connection with
   some other entity in the Internet, given a name identifying it.

Trammell                 Expires August 21, 2016                [Page 3]
Internet-Draft                    PINS                     February 2016

3.1.  Name to Address

   Given a Subject name, the naming service returns a set of addresses
   associated with that name, if such an association exists, where the
   association is determined by the authority for that name.  Names may
   be associated with addresses in one or more address families (e.g.
   IP version 4, IP version 6).  A querier may specify which address
   families it is interested in receiving addresses for, and the naming
   system treats all address families equally.

   [EDITOR'S NOTE: DNS does this for the Internet via IN A and IN AAAA
   records.]

3.2.  Address to Name

   Given an Subject address, the naming service returns a set of names
   associated with that address, if such an association exists, where
   the association is determined by the authority for that address.

   [EDITOR'S NOTE: DNS does this for the Internet with IN PTR records
   within the in-addr.arpa. and ip6.arpa. zones.  Note the limitation of
   delegation on octet (IPv4) and nibble (IPv6) boundaries.  Cite
   workarounds.]

3.3.  Name to Name

   Given a Subject name, the naming service returns a set of object
   names associated with that name, if such an association exists, where
   the association is determined by the authority for the subject name.

   [EDITOR'S NOTE: DNS does this via IN CNAME, but doesn't handle the
   set case, and there are restrictions on the use of IN CNAME (with
   respect to NS and MX records, but not SRV?)].

3.4.  Name to Auxiliary Information

   Given a Subject name, the naming service returns other auxiliary
   information associated with that name that is useful for establishing
   communication over the Internet with the entities associated with
   that name.

   [EDITOR'S NOTE: Most other RRTYPEs implement this pattern.]

3.5.  Name/Address to Auxiliary Information

   As a name might be associated with more than one address, auxiliary
   information as above may be associated with a name/address pair, as
   opposed to just with a name.

Trammell                 Expires August 21, 2016                [Page 4]
Internet-Draft                    PINS                     February 2016

   [EDITOR'S NOTE: DNS doesn't do this, does it?]

4.  Authority Interface

   The query interface is not the only interface to the naming service:
   the interface a naming service presents to an Authority allows
   updates to the set of Associations and Delegations in that
   Authority's namespace.  Updates consist of additions of, changes to,
   and deletions of Associations and Delegations.  In the present DNS,
   this interface consists of the publication of a new zone file with an
   incremented version number, but other authority interfaces are
   possible.

5.  Properties

   The following properties are desirable in a naming service providing
   the functions in Section 3 and Section 4.

5.1.  Authority

   Every Association among names, addresses, and auxiliary data is
   subject to some Authority: an entity which has the right to determine
   which Associations and Subjects exist in its namespace.  The
   following are properties of Authorities in our ideal naming service:

5.1.1.  Federation of Authority

   An Authority can delegate some part of its namespace to some other
   subordinate Authority.  This property allows the naming service to
   scale to the size of the Internet, and leads to a tree-structured
   namespace, where each Delegation is itself identified with a Subject
   at a given level in the namespace.

5.1.2.  Unity of Authority

   For a given Subject, there is a single Authority that has the right
   to determine the Associations and/or Delegations for that subject.
   The unitary authority for the root of the namespace tree may be
   special, though; see Section 5.1.4.

   [EDITOR'S NOTE: The unitary authority for a given name in the DNS is
   its registry.  The existence of registrars complicates this somewhat;
   see below.]

Trammell                 Expires August 21, 2016                [Page 5]
Internet-Draft                    PINS                     February 2016

5.1.3.  Transparency of Authority

   A querier can determine the identity of the Authority for a given
   Association.  An Authority cannot delegate its rights or
   responsibilities with respect to a subject without that Delegation
   being exposed to the querier.

   [EDITOR'S NOTE: It is very hard to enforce a restriction about
   delegations on the side (i.e.  "I make this assertion 'cause somebody
   paid me to").  One could implement this in the current DNS by having
   the recursive also do a WHOIS, making information about the registrar
   available for local policy decisions.]

5.1.4.  Consensus on Root of Authority

   Authority at the top level of the namespace tree is delegated
   according to a process such that there is universal agreement
   throughout the Internet as to the subordinates of those Delegations.

   [EDITOR'S NOTE: Today, this is the root zone.  But note that this
   property does not necessarily imply a single authority at the root as
   with the present arrangement, only that the process by which the root
   is changed and operated leads to a universally consistent result.]

5.2.  Authenticity

   A querier must be able to verify that the answers that it gets from
   the naming service are authentic.

5.2.1.  Authenticity of Delegation

   Given a Delegation from a superordinate to a subordinate Authority, a
   querier must be able to verify that the superordinate Authority
   authorized the Delegation.

   [EDITOR'S NOTE: DNSSEC does this.]

5.2.2.  Authenticity of Response

   The authenticity of every answer must be verifiable by the querier,
   and the querier must be able to confirm that the Association returned
   in the answer is correct according to the Authority for the Subject
   of the query.

   [EDITOR'S NOTE: DNSSEC does this.]

Trammell                 Expires August 21, 2016                [Page 6]
Internet-Draft                    PINS                     February 2016

5.2.3.  Authenticity of Negative Response

   Some queries will yield no answer, because no such Association
   exists.  In this case, the querier must be able to confirm that the
   Authority for the Subject of the query asserts this lack of
   Association.

   [EDITOR'S NOTE: DNSSEC does this depending on how well you've set it
   up?]

5.3.  Consistency

   Consistency in a naming service is important.  The naming service
   should provide the most globally consistent view possible of the set
   of associations that exist at a given point in time, within the
   limits of latency and bandwidth tradeoffs.

5.3.1.  Dynamic Consistency

   When an Authority makes changes to an Association, every query for a
   given Subject must give either the new valid result or a previously
   valid result, with known and predictable bounds on "how previously".
   Given that additions of, changes to, and deletions of associations
   may have different operational causes, different bounds may apply to
   different operations.

   [EDITOR'S NOTE: This is the point of TTL in DNS.  Additions faster
   than changes and deletions, which is probably the opposite of what
   you really want if you want name-service-based revocation of things.]

5.3.2.  Explicit Inconsistency

   Some techniques require giving different answers to different
   queries, even in the absence of changes: the stable state of the
   namespace is not globally consistent.  This inconsistency should be
   explicit: a querier should be able to know that an answer might be
   dependent on its identity, network location, or other factors.

   Note that explicit inconsistency based on client identity or network
   address may increase query linkability (see Section 5.4.4).

   [EDITOR'S NOTE: DNS doesn't do this.
   [I-D.ietf-dnsop-edns-client-subnet] addresses making the query from
   the recursive explicit that it would like an appropriate answer

Trammell                 Expires August 21, 2016                [Page 7]
Internet-Draft                    PINS                     February 2016

5.4.  Performance Properties

   [EDITOR'S NOTE: note that these have to do with name service
   dynamics, and that explicit tradeoffs here are possible and
   interesting.]

5.4.1.  Availability

   The naming service as a while must be resilient to failures of
   individual nodes providing the naming service, as well as to failures
   of links among them.  Intentional prevention of successful,
   authenticated query by an adversary should be as hard as practical.

   [EDITOR'S NOTE: DNS aims to provide this through explicit secondaries
   and XFER, as well as through operational practice: e.g. through ease
   of anycasting UDP services.]

5.4.2.  Lookup Latency

   The time for the entire process of looking up a name and other
   necessary associated data from the point of view of the querier,
   amortized over all queries for all connections, should not
   significantly impact connection setup or resumption latency.

   [EDITOR'S NOTE: DNS aims to provide this through being small and
   simple, and through the use of caching.]

5.4.3.  Bandwidth Efficiency

   The bandwidth cost for looking up a name and other associated data
   necessary for establishing communication with a given Subject, from
   the point of view of the querier, amortized over all queries for all
   connections, should significantly impact total bandwidth demand for
   an application.

   [EDITOR'S NOTE: What we mean here is that approaches that flood all
   name mapping updates to the entire Internet are probably not
   acceptable.  Cite work on DNS traffic load to show that DNS has this
   property?]

5.4.4.  Query Linkability

   It should be costly for an adversary to monitor the infrastructure in
   order to link specific queries to specific queriers.

   [EDITOR'S NOTE: DPRIVE is working toward this.]

Trammell                 Expires August 21, 2016                [Page 8]
Internet-Draft                    PINS                     February 2016

5.4.5.  Explicit Tradeoff

   A querier should be able to indicate the desire for a benefit with
   respect to one performance property by accepting a tradeoff in
   another, including:

   o  Reduced latency for reduced dynamic consistency

   o  Increased dynamic consistency for increased latency

   o  Reduced request linkability for increased latency and/or reduced
      dynamic consistency

   o  Reduced aggregate bandwidth use for increased latency and/or
      reduced dynamic consistency

   [EDITOR'S NOTE: DNS doesn't do this, and can't really: TTL gives you
   a tradeoff knob but it's in the hands of the authority]

6.  Observations

   We have shown that most of the properties of our ideal name service
   are met, or could be met, by the present DNS protocol or extensions
   thereto.  [EDITOR'S NOTE: not yet, not really.]  We note that there
   are further possibilities for the future evolution of naming services
   meeting these properties.

   [EDITOR'S NOTE: there are probably more than just this one, but this
   is the important one.]

6.1.  Delegation and Redirection are Separate Operations

   Any system which can provide the authenticity properties in
   Section 5.2 is freed from one of the design characteristics of the
   present domain name system: the requirement to bind a zone of
   authority to a specific set of authoritative servers.  Since the
   authenticity of delegation must be a protected by a chain of
   signatures back to the root of authority, the location within the
   infrastructure where an authoritative mapping "lives" is no longer
   bound to a specific name server.  While the present design of DNS
   does have its own scalability advantages, this implication allows a
   much larger design space to be explored for future name service work,
   as a Delegation need not always be implemented via redirection to
   another name server.

Trammell                 Expires August 21, 2016                [Page 9]
Internet-Draft                    PINS                     February 2016

7.  IANA Considerations

   This document has no actions for IANA

8.  Security Considerations

   [EDITOR'S NOTE: todo]

9.  Acknowledgments

   This document is an output of a design work on naming services at the
   Network Security Group at ETH Zurich.  Thanks to the group, including
   Daniele Asoni and Stephen Shirley, for discussions leading to this
   document.  Thanks as well to Andrew Sullivan and Suzanne Woolf for
   input and feedback.

10.  Informative References

   [I-D.ietf-dnsop-edns-client-subnet]
              Contavalli, C., Gaast, W., tale, t., and W. Kumari,
              "Client Subnet in DNS Queries", draft-ietf-dnsop-edns-
              client-subnet-06 (work in progress), December 2015.

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

Author's Address

   Brian Trammell
   ETH Zurich
   Universitaetstrasse 6
   Zurich  8092
   Switzerland

   Email: ietf@trammell.ch

Trammell                 Expires August 21, 2016               [Page 10]