[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

ALTO                                                           S. Kiesel
Internet-Draft                                   University of Stuttgart
Intended status: Standards Track                                M. Tomsu
Expires: April 28, 2011                                   Alcatel-Lucent
                                                               N. Schwan
                                                               M. Scharf
                                                Alcatel-Lucent Bell Labs
                                                          M. Stiemerling
                                                         NEC Europe Ltd.
                                                        October 25, 2010


                     ALTO Server Discovery Protocol
                      draft-kiesel-alto-3pdisc-04

Abstract

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications, which have to select one or several
   hosts from a set of candidates that are able to provide a desired
   resource.

   Entities seeking guidance need to discover and possibly select an
   ALTO server to ask.  This is called ALTO server discovery.  This memo
   describes an ALTO server discovery mechanism based on several
   alternative mechanisms that are applicable in a diverse set of ALTO
   deployments.

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 April 28, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Kiesel, et al.           Expires April 28, 2011                 [Page 1]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   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
   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.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Pre-Conditions . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Retrieving the URI by DHCP . . . . . . . . . . . . . . . . . .  7
     3.1.  ALTO Server Domain Name Encoding . . . . . . . . . . . . .  7
     3.2.  ALTO Server DHCPv4 Option  . . . . . . . . . . . . . . . .  7
     3.3.  ALTO Server DHCPv6 Option  . . . . . . . . . . . . . . . .  8
   4.  Retrieving the URI by U-NAPTR  . . . . . . . . . . . . . . . . 10
     4.1.  U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Retrieving the Domain Name . . . . . . . . . . . . . . . . 10
       4.2.1.  Option 1: User input . . . . . . . . . . . . . . . . . 11
       4.2.2.  Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 12
       4.2.3.  Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12
   5.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Applicability for Resource Consumer Server Discovery . . . 13
     5.2.  Applicability for Third Party Server Discovery . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
     7.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  For U-NAPTR  . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23








Kiesel, et al.           Expires April 28, 2011                 [Page 2]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications, which have to select one or several
   hosts from a set of candidates, that are able to provide a desired
   resource [RFC5693].  The requirements for ALTO are itemized in
   [I-D.ietf-alto-reqs].  ALTO is realized by a client-server protocol.
   ALTO clients send queries to ALTO servers, in order to solicit
   guidance.

   ALTO clients have to discover suitable ALTO servers.  Therefore the
   output of the herein defined ALTO discovery procedure tells the ALTO
   client which ALTO servers to send the queries to.  The ALTO discovery
   procedure, as part of the the ALTO client, can be embedded in the
   resource consumer, which will eventually access the desired resource.
   As an alternative, they can be embedded in a resource directory,
   which assists resource consumers in finding appropriate resource
   providers.  In some specific peer-to-peer application protocols these
   resource directories are called "trackers".  Finally the ALTO server
   discovery procedure can be embedded in the resource consumer, whereas
   the ALTO client is embedded in the resource directory.  ALTO queries,
   which are issued by a resource directory on behalf of a resource
   consumer, are referred to as third-party ALTO queries.  The various
   possibilities to place ALTO servers and the placement of ALTO clients
   is discussed in [I-D.stiemerling-alto-deployments].
   [I-D.song-alto-server-discovery] compares different protocol options
   and identifies DHCP and DNS as two approaches for the ALTO server
   discovery without detailing on the exact solution.

   No matter where ALTO server and client are located, clients have to
   first find out if there is an ALTO server deployed that is in charge
   for them, and second they have to get the contact information of that
   server, i.e., the IP address, port number, and probably transport
   protocol (which defaults to TCP for [I-D.ietf-alto-protocol]).

   The goal of this memo is to propose a uniform mechanism for all types
   of ALTO client deployments that is implementable and deployable at a
   fast pace, i.e., without creating other deployment dependecies for
   ALTO.  We propose to use a combination of DHCP and DNS to retrieve
   the URL of the resposnsible ALTO server.

   Comments and discussions about this memo should be directed to the
   ALTO working group: alto@ietf.org.

1.1.  Requirements

   There is other related works on server discovery, for instance
   GEOPRIV has rather strong security requirements (for good reasons),



Kiesel, et al.           Expires April 28, 2011                 [Page 3]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   which are documented in [I-D.ietf-geopriv-lis-discovery].  However,
   these requirements do not apply for the ALTO server discovery, as
   ALTO as such has very different requirements (see
   [I-D.ietf-alto-reqs]).

   The result of the guidance provided to the application via the ALTO
   protocol is input to improve the initial peer selection process for
   peer-to-peer applications, or any other application applicable.  A
   missing ALTO server, i.e., no result returned as part of the ALTO
   server discovery procedure, does not prevent the application to
   operate.  A wrong or forged guidance from the ALTO server may only
   impact the overall operational result of the peer-to-peer system for
   a limited time, as these systems fine-tune their behavior depending
   on the experience network behavior.

   This means that a wrong, missing, or forged ALTO guidance will not
   cause damage to the application or peer-to-peer system.  This is in
   sharp contrast to the GEOPRIV use case, where a failure may have
   severe impact, including loss of human life.  This is not the case
   for ALTO, as it is intended to be used today and as it is explored
   right now from the networking community.

1.2.  Pre-Conditions

   The whole document assumes certain pre-conditions, such as:

   o  The ALTO server discovery procedure is executed on a per IP
      address base.  Multiple IP addresses per interface or multiple IP
      addresses assigned to different IP interfaces require to repeat
      the procedure for every IP address.  It may be fine to group IP
      addresses according their domain suffixes and to perfom the
      procedure for such a group.  However, this is out of scope of this
      document.

   o  The ALTO server discovery procedure is executed on a per IP family
      base, i.e., seperate for IPv4 and IPv6.  It is up to the ALTO
      client to decide which of the possible multiple results of
      different IP address families to use.  The choice of whether to
      use IPv4 or IPv6 is out of scope of this document.

   o  A change of the IP address at an interface invalidates the result
      of the ALTO server discovery procedure.  For instance, if the IP
      address assigned to a mobile host changes due to host mobility, it
      is required to run the ALTO server discovery procedure for the new
      IP address without relying on earlier gained information.






Kiesel, et al.           Expires April 28, 2011                 [Page 4]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


2.  Protocol Overview

   We define multiple alternatives to discover the IP address of the
   ALTO server, as there are a number of ways possible how such
   information can be provided to the ALTO client.  The choice of method
   is up to the local network deployment.  For instance, there can be
   deployments where the ALTO server in charge for ALTO client is
   provisioned by the network operator and communicated to the ALTO
   client's host via a DHCP option, while in other deployments no such
   means may exist.

   The following figure illustrates the different protocols that are
   used to find the URI of a suitable ALTO server.

                          Descending order of Preference
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>

             --------     --------------   --------    ---------------
             | DHCP |     | User Input |   | DHCP |    | Reverse DNS |
             --------     --------------   --------    ---------------
                 |                |           |             |
                 |                 \          |            /
                 |                 Retrieving the DNS suffix
                 |                   \        |          /
                 |                    --------+----------
                  \                           |
                   \               Determine own IP address
                    \                         |
                     \                   -----------
                      \                  | U-NAPTR |
                       \                 -----------
                        \                     |
                        Retrieving ALTO Server URI
                          \                   |
                           ---------+----------
                                    |
                             Final DNS lookup

                        Figure 1: Protocol Overview

   One option to retrieve the URI directly from the access network
   provider is DHCP.  However for DHCP there are problems with
   residential gateways or broadband routers with NAT.  If the network
   operator gives information about ALTO serves to the residential
   gateway via DHCP, the residential gateway would have to forward this
   information to the hosts with the (P2P) applications within the local
   network.  This is not supported by already deployed residential
   gateways.  Also DHCP poorly supports third-party ALTO server



Kiesel, et al.           Expires April 28, 2011                 [Page 5]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   discovery, i.e., in scenarios where the ALTO client is co-located
   with a resource directory ("tracker"), which is located in a
   different administrative domain than the client which will eventually
   access the ressource.

   Thus in deployment scenarios where DHCP is not possible, we specify a
   U-NAPTR based resolution process as a second option to retrieve the
   URL.  As a precondition for resolution the U-NAPTR process needs the
   right domain name as input.  This domain name is determined by the IP
   address of the client and the DNS suffix of the access network where
   the client is registered in.  In order to retrieve the DNS suffix we
   specify three options:

   User input:  a user may manually specify the DNS suffix on its own,
      either to access a 3rd party ALTO service provider or as it does
      know such information.

   DHCP:  a network provider provides the DNS suffix through a DHCP
      option.

   Reverse DNS:  the DNS system can be used to retrieve the DNS suffix
      through reverse lookup of an FQDN associated with an IP address.
      This is the last resort if all other options failed.




























Kiesel, et al.           Expires April 28, 2011                 [Page 6]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


3.  Retrieving the URI by DHCP

   One way of directly configuring the ALTO server URI for an access
   network provider is the DHCP protocol.  The ALTO server URI consists
   of a domain name and the protocol the client should use to contact
   the server.  While the domain name can vary and is configured by
   DHCP, the protocol is always HTTP.

   For example a client may retrieve the domain name
   altoserver.example.com by the DHCP option as described in the
   remaining section.  The client uses this domain name to contact the
   ALTO server under

      http://altoserver.example.com/

3.1.  ALTO Server Domain Name Encoding

   This section describes the encoding of the domain name used in the
   DHCPv4 option shown in Section 3.2 and also used in the DHCPv6 option
   shown in Section 3.3.

   The domain name is encoded according to Section 3.1 of [RFC1035]
   whereby each label is represented as a one-octet length field
   followed by that number of octets.  Since every domain name ends with
   the null label of the root, a domain name is terminated by a length
   byte of zero.  The high-order two bits of every length octet MUST be
   zero, and the remaining six bits of the length field limit the label
   to 63 octets or less.  To simplify implementations, the total length
   of a domain name (i.e., label octets and label length octets) is
   restricted to 255 octets or less.

3.2.  ALTO Server DHCPv4 Option

   The ALTO server DHCPv4 option carries a DNS ([RFC1035]) fully-
   qualified domain name (FQDN) to be used by the ALTO client to locate
   a ALTO server.

   The DHCP option for this encoding has the following format:

            Code    Len   ALTO Server Domain Name
            +-----+-----+-----+-----+-----+-----+-----+----
            | tba |  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
            +-----+-----+-----+-----+-----+-----+-----+----

                        Figure 2: ALTO FQDN DHCPv4 Option

   The values s1, s2, s3, etc. represent the domain name labels in the
   domain name encoding.  Note that the length field in the DHCPv4



Kiesel, et al.           Expires April 28, 2011                 [Page 7]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   option represents the length of the entire domain name encoding,
   whereas the length fields in the domain name encoding (see
   Section 3.1) is the length of a single domain name label.

   Code:  to be assigned by IANA

   Len:  Length of the 'ALTO Server Domain Name' field in octets;
      variable.

   ALTO Server Domain Name:  The domain name of the ALTO server for the
      client to use.

   A DHCPv4 client MAY request a ALTO server domain name in a Parameter
   Request List option, as described in [RFC2131].

   The encoding of the domain name is described in Section 3.1.

   This option contains a single domain name and, as such, MUST contain
   precisely one root label.

3.3.  ALTO Server DHCPv6 Option

   This section specifies the DHCP option for IPv6 (DHCPv6) to carry the
   domain name of the ALTO server.  It is similar formatted to the
   DHCPv4 option

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    TBA: OPTION CODE           |        option-length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                    ALTO Server Domain Name                    .
      .                              ...                              .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 3: ALTO Server Domain Name DHCPv4 Option

   option-code:  to be assigned by IANA

   option-length:  The length of the 'ALTO Server Domain Name' field in
      octets; variable.

   ALTO Server Domain Name:  The domain name of the ALTO server for the
      client to use.

   A DHCPv6 client MAY request a ALTO server domain name in an Options
   Request Option (ORO), as described in [RFC3315].



Kiesel, et al.           Expires April 28, 2011                 [Page 8]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   The encoding of the domain name is described in Section 3.1.

   This option contains a single domain name and, as such, MUST contain
   precisely one root label.















































Kiesel, et al.           Expires April 28, 2011                 [Page 9]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


4.  Retrieving the URI by U-NAPTR

   As already described a direct DHCP configuration may not always be
   possible, for example due to deployment restrictions of the access
   network.  Alternatively the ALTO server URI can be discovered by a
   U-NAPTR resolution process, as specified in this section.

   The section is devided in two parts: Section 4.1 describes the
   U-NAPTR resolution process itself.  As a precondition this process
   requires the domain name of the access network where the resouce
   consumer is registered in.  How the client identifies this DNS suffix
   is described in Section 4.2.

4.1.  U-NAPTR Resolution

   ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
   Dynamic Delegation Discovery Service) [RFC4848] application unique
   strings, in the form of a DNS name.  An example is
   'altoserver.example.com'.

   Clients need to use the U-NAPTR [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.

   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.


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

4.2.  Retrieving the Domain Name

   The U-NAPTR resolution process requires a domain name as input.  The
   algorithm that is applied to determine this domain name is described
   in this section.  We specify three different options.  In option 1
   the user manually configures a specific ALTO service instance that he
   wants to use.  Option 2 defines a DHCP option to allow the network
   service provider a remote configuration of the client.  In option 3



Kiesel, et al.           Expires April 28, 2011                [Page 10]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   the client tries to get the domain name by performing a reverse DNS
   lookup on its IP address.

   The resource consumer may have private IP addresses and public IP
   addresses and depending on the deployment it might be necessary to
   determine for all IP addresses the ALTO server in charge of.  To
   determine its public IP address the resource consumer may need to use
   STUN[RFC5389] or BEP24[bep24].  For the following examples we assume
   that the IP address of the resource consumer is a.b.c.d.

4.2.1.  Option 1: User input

   A user may want to use a third party ALTO service instance.
   Therefore we allow the user to specify a DNS suffix on its own, for
   example in a config file option.  The DNS suffix given by the user is
   combined with the IP address of the resource consumer to allow the
   third party ALTO service to direct the client to a suitable ALTO
   server based on the location of the client.  A possible DNS suffix
   entered by the user may be:

      myaltoprovider.org

   This DNS suffix is prepended with the IP address of the resource
   consumer in reverse order to compose the domain name used for the
   final U-NAPTR lookup Section 4.1.  In case there are multiple ALTO
   servers deployed, the third party ALTO service instance can direct
   the ALTO client to the ALTO server closest to the client based on the
   IP address.

   Multiple lookups with different domain names might be necessary to
   complete the U-NAPTR resolution process.  If there is no response for
   a lookup the domain name is shortened by one part for the succeeding
   lookup, until a lookup is successful, as for example

      d.c.b.a.myaltoprovider.org.

      c.b.a.myaltoprovider.org.

      b.a.myaltoprovider.org.

      a.myaltoprovider.org.

      myaltoprovider.org.








Kiesel, et al.           Expires April 28, 2011                [Page 11]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


4.2.2.  Option 2: DHCP

   As a second option network operators can configure the domain name to
   be used for service discovery within an access network.  RFC
   5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain name
   options that identify a domain name that is suitable for service
   discovery within the access network.  The ALTO server discovery
   procedure uses these DHCP options to retrieve the domain name as an
   input for the U-NAPTR resolution.  One example could be:

      example.com

4.2.3.  Option 3: Reverse DNS Lookup

   The last option to get the domain name is to use a DNS PTR query for
   the IP address of the resource consumer.  The local DNS server
   resolves the IP address to the FQDN that also contains the DNS suffix
   for the respective IP address.  A possible answer for a PTR lookup
   for d.c.b.a.in-addr.apra might be, for example:

      d-c-b-a.dsl.westcoast.myisp.net

   This domain name can be used for the final U-NAPTR lookup
   Section 4.1.  Again, if there is no response to the lookup the domain
   name is shortened by one part for the succeeding lookup.  The domain
   names used for the example as described above are:

      d-c-b-a.dsl.westcoast.myisp.net.

      dsl.westcoast.myisp.net.

      westcoast.myisp.net.

      myisp.net.

















Kiesel, et al.           Expires April 28, 2011                [Page 12]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


5.  Applicability

   This section discusses the applicability of the proposed solution
   with respect to the resource consumer server discovery and the third
   party deployment scenarios.  Each section discusses the proposed
   steps that are needed to determine the ALTO Server URI.

5.1.  Applicability for Resource Consumer Server Discovery

   In this scenario the ALTO server discovery procedure is performed by
   the resource consumer, for example a peer in a P2P system.  After the
   discovery the peer does the ALTO query on its own, or it might share
   the ALTO server contact information with a third party, for example a
   tracker, which then does the ALTO query on behalf of the peer.

   The access network provider has two options based on DHCP to remotely
   configure the ALTO client to use its ALTO server.  The first option
   is to provide the ALTO server URI directly by a DHCP option as
   described in Section 3, the second option is to provide the access
   network domain name as described in Section 4.2.2.  It is up to the
   access network provider to choose one of both options.

   To complete the ALTO server discovery process the resource consumer
   first SHOULD try to retrieve the ALTO server URI by the DHCP option
   as described in Section 3.  In case this is successful the discovery
   process is finished, in case it fails, either as the access network
   provider has not configured the specified option or through
   deployment restrictions, the resource consumer SHOULD subsequently
   check whether the user has provider the domain name through manual
   configuration.  If this is also not the case the next step SHOULD be
   to check for the access network domain name DHCP option
   (Section 4.2.2).  Finally the client SHOULD try to retrieve the
   domain name by the last option, the DNS reverse lookup on its IP
   address as described in Section 4.2.3.

   In case the ALTO discovery client has determined the domain name
   through one of the described options it proceedes with the U-NAPTR
   lookup as described in Section 4.1.

   If the ALTO server URI could not be retrieved either through direct
   configuration by the access network provider through DHCP nor through
   the U-NAPTR lookup the discovery process fails.

5.2.  Applicability for Third Party Server Discovery

   In case of the third party server discovery deployment scenario the
   entity performing the ALTO server discovery process is different from
   the resource consumer.  Typically the resource consumer is a peer



Kiesel, et al.           Expires April 28, 2011                [Page 13]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   whereas the ALTO client is a resource directory which seeks for ALTO
   guidance on behalf of the peer.  Another use case for the third party
   discovery is an application that looks for ALTO guidance
   transparently for the resource consumer, for example a CDN.

   Here the ALTO server discovery process can also retrieve guidance
   through one of the DHCP options or manual user configuration, but
   only if the provided discovery information is forwarded by the
   resource consumer to the third party entity.  In this case,
   additional mechanisms for the forwarding of this discovery
   information need to be specified.  However these mechanisms are out
   of scope of this doument.

   If the third party entity cannot obtain this discovery information,
   the ALTO server discovery process relies on retrieving the domain
   name used as input to the U-NAPTR lookup through reverse DNS lookup
   of the IP address of the resource consumer as described in
   Section 4.2.3.  Usually the third party entity already knows the IP
   address of the resource consumer which was used to establish the
   initial connection.  In general this IP address is a public address,
   either of the resource consumer or of the last NAT on the path to the
   ALTO client.  This makes the IP address a good candidate for the DNS
   PTR query.  Thus, we expect that the DNS query will be successfully
   resolved to the FQDN of the domain where the resource consumer is
   registered in.

   In case the resource consumer needs guidance for a different IP
   address, for example one from a private network, we recommend that
   the resource consumer discovers the server itself and forwards the
   ALTO server contact information directly to the third party entity,
   which in turn can then do the third party ALTO query.  Again,
   forwarding the contact information from the resource consumer to the
   third party entity is out of scope of this document.


















Kiesel, et al.           Expires April 28, 2011                [Page 14]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


6.  IANA Considerations

   This document registers the following U-NAPTR application service
   tag:



      Application Service Tag:  ALTO

      Defining Publication:  The specification contained within this
         document.

   This document registers the following U-NAPTR application protocol
   tags:

   o  Application Protocol Tag: http

      Defining Publication: RFC 2616 [RFC2616]

   o  Application Protocol Tag: https

      Defining Publication: RFC 2818 [RFC2818]





























Kiesel, et al.           Expires April 28, 2011                [Page 15]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


7.  Security Considerations

7.1.  General

   This is still to be done in later revision of this draft, as the
   draft evolves heavily right now.

7.2.  For U-NAPTR

   The address of an ALTO server is usually well-known within an access
   network; therefore, interception of messages does not introduce any
   specific concerns.

   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.

   An attacker could attempt to compromise ALTO discovery at any of
   three stages:

   1.  providing a falsified domain name to be used as input to U-NAPTR

   2.  altering the DNS records used in U-NAPTR resolution

   3.  impersonation of the ALTO

   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 [I-D.ietf-geopriv-lis-discovery].

   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) [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 [RFC4848].

   An "https:" URI is authenticated using the method described in
   Section 3.1 of [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 [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.



Kiesel, et al.           Expires April 28, 2011                [Page 16]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   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.














































Kiesel, et al.           Expires April 28, 2011                [Page 17]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


8.  Open Issues

   Here are a few open issues to be clarified:

   Handling of reverse DNS lookups for IPv6:  Refer to [RFC4472] for a
      discussion about the issues.

   Missing reverse DNS entries for an IP address:  There may be cases
      where the reverse DNS lookup does not yield any result.  However,
      this will leave the ALTO client with no choice, other than giving
      up.  This needs better documentation.

   How to handled multiple results:  For instance, a host behind a NAT
      that yields an ALTO server in the private IP address domain and
      one in the public IP address domain.  Whom to ask?

   Suffix Issues  Document issues with suffix information provided by
      DHCP or by other means.  For instance, a host behind a NAT may
      have a configured DNS suffix ".local".  This suffix is not usuable
      for the server discovery procedure.































Kiesel, et al.           Expires April 28, 2011                [Page 18]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


9.  Conclusion

   This document describes a general ALTO server discovery process and
   discusses how the process can be applied in different deployment
   scenarios, including the resouce consumer discovery as well as the
   third party discovery.













































Kiesel, et al.           Expires April 28, 2011                [Page 19]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


10.  References

10.1.  Normative References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

10.2.  Informative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              draft-ietf-alto-protocol-05 (work in progress), July 2010.

   [I-D.ietf-alto-reqs]
              Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", draft-ietf-alto-reqs-06 (work in progress),
              October 2010.

   [I-D.ietf-geopriv-lis-discovery]
              Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)",
              draft-ietf-geopriv-lis-discovery-15 (work in progress),
              March 2010.

   [I-D.song-alto-server-discovery]
              Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V.
              Avila, "ALTO Service Discovery",
              draft-song-alto-server-discovery-03 (work in progress),
              July 2010.

   [I-D.stiemerling-alto-deployments]
              Stiemerling, M. and S. Kiesel, "ALTO Deployment



Kiesel, et al.           Expires April 28, 2011                [Page 20]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


              Considerations", draft-stiemerling-alto-deployments-05
              (work in progress), October 2010.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472,
              April 2006.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, April 2007.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.

   [RFC5986]  Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)", RFC 5986,
              September 2010.

   [bep24]    Harrison, D., "Tracker Returns External IP",
              BEP http://bittorrent.org/beps/bep_0024.html.




















Kiesel, et al.           Expires April 28, 2011                [Page 21]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


Appendix A.  Acknowledgments

   The authors would like to thank Haibin Song, Richard Alimi, and Roni
   Even for fruitful discussions during the 75th IETF meeting.

   Hannes Tschofenig provided the initial input to the U-NAPTR solution
   part.  Hannes and Martin Thomson provided excellent feedback and
   input to the server discovery.

   Marco Tomsu and Nico Schwan are partially supported by the ENVISION
   project (http://www.envision-project.org), a research project
   supported by the European Commission under its 7th Framework Program
   (contract no. 248565).  The views and conclusions contained herein
   are those of the authors and should not be interpreted as necessarily
   representing the official policies or endorsements, either expressed
   or implied, of the ENVISION project or the European Commission.

   Michael Scharf is supported by the German-Lab project
   (http://www.german-lab.de) funded by the German Federal Ministry of
   Education and Research (BMBF).

   Martin Stiemerling is partially supported by the COAST project
   (COntent Aware Searching, retrieval and sTreaming,
   http://www.coast-fp7.eu), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   248036).  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the COAST project or the European Commission.






















Kiesel, et al.           Expires April 28, 2011                [Page 22]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


Authors' Addresses

   Sebastian Kiesel
   University of Stuttgart Computing Center
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: ietf-alto@skiesel.de
   URI:   http://www.rus.uni-stuttgart.de/nks/


   Marco Tomsu
   Alcatel-Lucent
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: marco.tomsu@alcatel-lucent.com
   URI:   www.alcatel-lucent.com/bell-labs


   Nico Schwan
   Alcatel-Lucent Bell Labs
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: nico.schwan@alcatel-lucent.com
   URI:   www.alcatel-lucent.com/bell-labs


   Michael Scharf
   Alcatel-Lucent Bell Labs
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: michael.scharf@alcatel-lucent.com
   URI:   www.alcatel-lucent.com/bell-labs











Kiesel, et al.           Expires April 28, 2011                [Page 23]

Internet-Draft       ALTO Server Discovery Protocol         October 2010


   Martin Stiemerling
   NEC Laboratories Europe/University of Goettingen
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 113
   Email: martin.stiemerling@neclab.eu
   URI:   http://ietf.stiemerling.org










































Kiesel, et al.           Expires April 28, 2011                [Page 24]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/