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]