[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

ALTO                                                      M. Stiemerling
Internet-Draft                                           NEC Europe Ltd.
Intended status:  Standards Track                          H. Tschofenig
Expires:  January 28, 2011                        Nokia Siemens Networks
                                                           July 27, 2010


              A DNS-based ALTO Server Discovery Procedure
              draft-stiemerling-alto-dns-discovery-00.txt

Abstract

   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.

   This document specifies the U-NAPTR based resolution process.

Status of this Memo

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

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

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

   This Internet-Draft will expire on January 28, 2011.

Copyright Notice

   Copyright (c) 2010 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
   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



Stiemerling & Tschofenig  Expires January 28, 2011              [Page 1]


Internet-Draft          DNS-based ALTO Discovery               July 2010


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  U-NAPTR Resolution  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6




































Stiemerling & Tschofenig  Expires January 28, 2011              [Page 2]


Internet-Draft          DNS-based ALTO Discovery               July 2010


1.  Introduction

   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.

   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.

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


2.  Terminology

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


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




Stiemerling & Tschofenig  Expires January 28, 2011              [Page 3]


Internet-Draft          DNS-based ALTO Discovery               July 2010


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

   End host learn the ALTO's server host name by means beyond the scope
   of this specification, such as DHCP.


4.  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]


5.  Security Considerations

   The address of a ALTO 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:



Stiemerling & Tschofenig  Expires January 28, 2011              [Page 4]


Internet-Draft          DNS-based ALTO Discovery               July 2010


   1.  1. providing a falsified domain name to be used as input to
       U-NAPTR
   2.  2. altering the DNS records used in U-NAPTR resolution
   3.  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.

   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.


6.  Acknowledgements

   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.


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.



Stiemerling & Tschofenig  Expires January 28, 2011              [Page 5]


Internet-Draft          DNS-based ALTO Discovery               July 2010


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

7.2.  Informative References

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

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


Authors' Addresses

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

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












Stiemerling & Tschofenig  Expires January 28, 2011              [Page 6]


Internet-Draft          DNS-based ALTO Discovery               July 2010


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone:  +358 (50) 4871445
   Email:  Hannes.Tschofenig@gmx.net
   URI:    http://www.tschofenig.priv.at










































Stiemerling & Tschofenig  Expires January 28, 2011              [Page 7]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/