<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY RFC4119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml'>
 <!ENTITY RFC3693 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml'>
 <!ENTITY RFC4848 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml'>   
 <!ENTITY RFC2616 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>   
 <!ENTITY RFC2818 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>   
 <!ENTITY RFC4033 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>   
 <!ENTITY RFC3958 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml'>
 <!ENTITY I-D.ietf-geopriv-lis-discovery PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lis-discovery.xml'>
 
 
]>
    
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="std" ipr="trust200902" docName="draft-stiemerling-alto-dns-discovery-00.txt">
  <front>
    <title abbrev="DNS-based ALTO Discovery">A DNS-based ALTO Server Discovery Procedure</title>
  
    <author fullname="Martin Stiemerling" initials="M." surname="Stiemerling">
      <organization abbrev="NEC Europe Ltd.">NEC Laboratories
      Europe/University of Goettingen</organization>

      <address>
        <postal>
          <street>Kurfuerstenanlage 36</street>

          <code>69115</code>

          <city>Heidelberg</city>

          <country>Germany</country>
        </postal>

        <phone>+49 6221 4342 113</phone>

        <facsimile>+49 6221 4342 155</facsimile>

        <email>martin.stiemerling@neclab.eu</email>

        <uri>http://ietf.stiemerling.org</uri>
      </address>
    </author>


    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <date year="2010"/>
    <area>RAI</area>
    <workgroup>ALTO</workgroup>
    <abstract>
      <t>   The Application-Layer Traffic Optimization (ALTO) provides
   guidance to applications having to select one or several
   hosts from a set of candidates that are able to provide a desired
   resource.
</t>
   <t>This document specifies the U-NAPTR based resolution process. 
   </t>
    </abstract>
  </front>
  <middle>
    <!-- **************************************************************************************** -->
    <section title="Introduction">
      <t>   Networking applications today already have access to a great amount
   of Inter-Provider network topology information.  For example, views
   of the Internet routing table are easily available at looking glass
   servers and entirely practical to be downloaded by clients.  What is
   missing is knowledge of the underlying network topology from the ISP
   or Content Provider (henceforth referred as Provider) point of view.
   In other words, what a Provider prefers in terms of traffic
   optimization -- and a way to distribute it.</t>
   <t>
   The ALTO Service provides information such as preferences of network
   resources with the goal of modifying network resource consumption
   patterns while maintaining or improving application performance.
   This document describes a protocol implementing the ALTO Service.
   While such service would primarily be provided by the network (i.e.,
   the ISP), content providers and third parties could also operate this
   service.  Applications that could use this service are those that
   have a choice in connection endpoints.  Examples of such applications
   are peer-to-peer (P2P) and content delivery networks.
</t>
   <t>This document specifies the U-NAPTR based resolution process. To start 
   the U-NAPTR resolution process a domain name needs to be obtained first.
   One mechanism to obtain such a domain name is via DHCP, as described in 
   <xref target="I-D.ietf-geopriv-lis-discovery"/>.
   </t>
    </section>
    <!-- **************************************************************************************** -->
    <section anchor="terms" title="Terminology">
      <t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
        described in RFC 2119 <xref target="RFC2119"/>.</t>
    </section>

    <!-- **************************************************************************************** -->

	   <section title="U-NAPTR Resolution">

      <t>ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) <xref target="RFC4848"/> application unique
        strings, in the form of a DNS name. An example is 'altoserver.example.com'.</t>

      <t>Clients need to use the U-NAPTR <xref target="RFC4848"/> specification described below to
        obtain a URI (indicating host and protocol) for the applicable ALTO service. In this
        document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any
        valid HTTP URL, including those containing path elements.</t>

      <t>The following two DNS entries show the U-NAPTR resolution for "example.com" to the HTTPS
        URL https://altoserver.example.com/secure or the HTTP URL http://altoserver.example.com, with
        the former being preferred.</t>

      <t>
        <figure>
          <artwork><![CDATA[
    example.com.

    IN NAPTR 100  10   "u"    "ALTO:https"
         "!.*!https://altoserver.example.com/secure!"  ""

    IN NAPTR 200  10   "u"    "ALTO:http"
         "!.*!http://altoserver.example.com!"  ""
]]></artwork>
        </figure>
      </t>

      <t>End host learn the ALTO's server host name by means beyond the scope of this specification, such as DHCP.
  </t>
    </section>
    <!-- **************************************************************************************** -->
    <section anchor="iana" title="IANA Considerations">


        <t>This document registers the following U-NAPTR application
        service tag: 
	<list style="empty">  
	  <list style="hanging">
            <t hangText="Application Service Tag:">ALTO</t>
            <t hangText="Defining Publication:">The specification contained within this
            document.</t>
          </list>
          </list>
        </t>

        <t>This document registers the following U-NAPTR application
        protocol tags: 
<list style="symbols">
                <t>Application Protocol Tag: http
		  <vspace blankLines="1" />
                Defining Publication: <xref target="RFC2616">RFC
                2616</xref>
		</t>

                <t>Application Protocol Tag: https
                <vspace blankLines="1" />
                Defining Publication: <xref target="RFC2818">RFC 2818</xref>
                </t>
              </list>
        </t>
    </section>
    <!-- **************************************************************************************** -->
    <section anchor="security" title="Security Considerations">
	  <t>
	   The address of a ALTO is usually well-known within an access network;
   therefore, interception of messages does not introduce any specific
   concerns.</t>
   <t>
   The primary attack against the methods described in this document is
   one that would lead to impersonation of a ALTO server since a device
   does not necessarily have a prior relationship with a ALTO server. 
</t>
<t>
   An attacker could attempt to compromise ALTO discovery at any of three
   stages:</t>
   <t>
<list style="numbers"> 
<t>
   1.  providing a falsified domain name to be used as input to U-NAPTR
</t>
<t>
   2.  altering the DNS records used in U-NAPTR resolution
</t>
<t>
   3.  impersonation of the ALTO
</t>
</list> 
</t>
<t>This document focuses on the U-NAPTR resolution process and hence this section discusses the security considerations related to the DNS handling. The security aspects of obtaining the domain name that is used for input to the U-NAPTR process is described in respective documents, such as <xref target="I-D.ietf-geopriv-lis-discovery"/>.
</t>

<t>The domain name that is used to authenticated the ALTO server is the domain
   name in the URI that is the result of the U-NAPTR resolution.
   Therefore, if an attacker were able to modify or spoof any of the DNS
   records used in the DDDS resolution, this URI could be replaced by an
   invalid URI.  The application of DNS security (DNSSEC) <xref target="RFC4033"/>
   provides a means to limit attacks that rely on modification of the
   DNS records used in U-NAPTR resolution.  Security considerations
   specific to U-NAPTR are described in more detail in <xref target="RFC4848"/>.
</t>
<t>
   An "https:" URI is authenticated using the method described in
   Section 3.1 of <xref target="RFC2818"/>.  The domain name used for this
   authentication is the domain name in the URI resulting from U-NAPTR
   resolution, not the input domain name as in <xref target="RFC3958"/>.  Using the
   domain name in the URI is more compatible with existing HTTP client
   software, which authenticate servers based on the domain name in the
   URI.
</t>
<t>
   An ALTO server that is identified by an "http:" URI cannot be authenticated.
   If an "http:" URI is the product of
   the ALTO discovery, this leaves devices vulnerable to several attacks.
   Lower layer protections, such as layer 2 traffic separation might be
   used to provide some guarantees.
</t>
    </section>
    <!-- **************************************************************************************** -->
    <section title="Acknowledgements">
      <t>The authors would like to thank Martin Thomson for his feedback on this document. We would like to thank the ALTO working group for their prior discussions on discovery.</t>
    </section>
    <!-- **************************************************************************************** -->
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>
            <address>
              <postal>
                <street>1350 Mass. Ave.</street>
                <street>Cambridge</street>
                <street>MA 02138</street>
              </postal>
              <phone>- +1 617 495 3864</phone>
              <email>-</email>
            </address>
          </author>
          <date month="March" year="1997"/>
          <area>General</area>
          <keyword>keyword</keyword>
        </front>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="BCP" value="14"/>
      </reference>&RFC2616; &RFC2818; &RFC4033; &RFC3958;  
      </references>
    <references title="Informative References"> &I-D.ietf-geopriv-lis-discovery; 
     &RFC4848; </references>
  </back>
</rfc>
