One document matched: draft-trammell-inip-pins-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-trammell-inip-pins-00" category="info">

  <front>
    <title abbrev="PINS">Properties of an Ideal Naming Service</title>

    <author initials="B." surname="Trammell" fullname="Brian Trammell">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Universitaetstrasse 6</street>
          <city>Zurich</city>
          <code>8092</code>
          <country>Switzerland</country>
        </postal>
        <email>ietf@trammell.ch</email>
      </address>
    </author>

    <date year="2016" month="February" day="18"/>

    <area>Internet Architecture Board</area>
    <workgroup>Names and Identifiers Program</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


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



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The Internet’s Domain Name System (DNS) <xref target="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, 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.</t>

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

<t><xref target="query-interface"/> and <xref target="authority-interface"/> define the set of operations a naming service should provide for queriers and authorities, <xref target="properties"/> defines a set of desirable properties of the provision of this service, and <xref target="observations"/> examines implications of these properties.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The following capitalized terms are defined and used in this document:</t>

<t><list style="symbols">
  <t>Subject: A name, address, or name-address pair about which the naming service can answer queries</t>
  <t>Association: A mapping between a Subject and information about that Subject</t>
  <t>Authority: An entity that has the right to determine which Associations exist within its namespace</t>
  <t>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.</t>
</list></t>

<t>[EDITOR’S NOTE: need to make a terminology unification pass]</t>

</section>
<section anchor="query-interface" title="Query Interface">

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

<section anchor="name-to-address" title="Name to Address">

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

<t>[EDITOR’S NOTE: DNS does this for the Internet via IN A and IN AAAA records.]</t>

</section>
<section anchor="address-to-name" title="Address to Name">

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

<t>[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.]</t>

</section>
<section anchor="name-to-name" title="Name to Name">

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

<t>[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?)].</t>

</section>
<section anchor="name-to-auxiliary-information" title="Name to Auxiliary Information">

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

<t>[EDITOR’S NOTE: Most other RRTYPEs implement this pattern.]</t>

</section>
<section anchor="nameaddress-to-auxiliary-information" title="Name/Address to Auxiliary Information">

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

<t>[EDITOR’S NOTE: DNS doesn’t do this, does it?]</t>

</section>
</section>
<section anchor="authority-interface" title="Authority Interface">

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

</section>
<section anchor="properties" title="Properties">

<t>The following properties are desirable in a naming service providing the functions in <xref target="query-interface"/> and <xref target="authority-interface"/>.</t>

<section anchor="authority" title="Authority">

<t>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:</t>

<section anchor="federation-of-authority" title="Federation of Authority">

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

</section>
<section anchor="unity-of-authority" title="Unity of Authority">

<t>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
<xref target="consensus-on-root-of-authority"/>.</t>

<t>[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.]</t>

</section>
<section anchor="transparency-of-authority" title="Transparency of Authority">

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

<t>[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.]</t>

</section>
<section anchor="consensus-on-root-of-authority" title="Consensus on Root of Authority">

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

<t>[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.]</t>

</section>
</section>
<section anchor="authenticity" title="Authenticity">

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

<section anchor="authenticity-of-delegation" title="Authenticity of Delegation">

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

<t>[EDITOR’S NOTE: DNSSEC does this.]</t>

</section>
<section anchor="authenticity-of-response" title="Authenticity of Response">

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

<t>[EDITOR’S NOTE: DNSSEC does this.]</t>

</section>
<section anchor="authenticity-of-negative-response" title="Authenticity of Negative Response">

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

<t>[EDITOR’S NOTE: DNSSEC does this depending on how well you’ve set it up?]</t>

</section>
</section>
<section anchor="consistency" title="Consistency">

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

<section anchor="dynamic-consistency" title="Dynamic Consistency">

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

<t>[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.]</t>

</section>
<section anchor="explicit-inconsistency" title="Explicit Inconsistency">

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

<t>Note that explicit inconsistency based on client identity or network address
may increase query linkability (see <xref target="query-linkability"/>).</t>

<t>[EDITOR’S NOTE: DNS doesn’t do this. <xref target="I-D.ietf-dnsop-edns-client-subnet"/> addresses making the query from the recursive explicit that it would like an appropriate answer</t>

</section>
</section>
<section anchor="performance-properties" title="Performance Properties">

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

<section anchor="availability" title="Availability">

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

<t>[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.]</t>

</section>
<section anchor="lookup-latency" title="Lookup Latency">

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

<t>[EDITOR’S NOTE: DNS aims to provide this through being small and simple, and through the use of caching.]</t>

</section>
<section anchor="bandwidth-efficiency" title="Bandwidth Efficiency">

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

<t>[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?]</t>

</section>
<section anchor="query-linkability" title="Query Linkability">

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

<t>[EDITOR’S NOTE: DPRIVE is working toward this.]</t>

</section>
<section anchor="explicit-tradeoff" title="Explicit Tradeoff">

<t>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:</t>

<t><list style="symbols">
  <t>Reduced latency for reduced dynamic consistency</t>
  <t>Increased dynamic consistency for increased latency</t>
  <t>Reduced request linkability for increased latency and/or reduced dynamic consistency</t>
  <t>Reduced aggregate bandwidth use for increased latency and/or reduced dynamic consistency</t>
</list></t>

<t>[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]</t>

</section>
</section>
</section>
<section anchor="observations" title="Observations">

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

<t>[EDITOR’S NOTE: there are probably more than just this one, but this is the important one.]</t>

<section anchor="delegation-and-redirection-are-separate-operations" title="Delegation and Redirection are Separate Operations">

<t>Any system which can provide the authenticity properties in <xref target="authenticity"/>
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.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no actions for IANA</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>[EDITOR’S NOTE: todo]</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

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

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor='RFC1035' target='http://www.rfc-editor.org/info/rfc1035'>
<front>
<title>Domain names - implementation and specification</title>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author>
<date year='1987' month='November' />
<abstract><t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System.  It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1035'/>
<seriesInfo name='DOI' value='10.17487/RFC1035'/>
</reference>



<reference anchor='I-D.ietf-dnsop-edns-client-subnet'>
<front>
<title>Client Subnet in DNS Queries</title>

<author initials='C' surname='Contavalli' fullname='Carlo Contavalli'>
    <organization />
</author>

<author initials='W' surname='Gaast' fullname='Wilmer van der Gaast'>
    <organization />
</author>

<author initials='t' surname='tale' fullname='tale'>
    <organization />
</author>

<author initials='W' surname='Kumari' fullname='Warren Kumari'>
    <organization />
</author>

<date month='December' day='15' year='2015' />

<abstract><t>This document defines an EDNS0 extension to carry information about the network that originated a DNS query, and the network for which the subsequent response can be cached.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-edns-client-subnet-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-edns-client-subnet-06.txt' />
</reference>




    </references>



  </back>
</rfc>