University of Stuttgart Information Center

Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany ietf-alto@skiesel.de http://www.rus.uni-stuttgart.de/nks/

NEC Laboratories Europe

Kurfuerstenanlage 36 69115 Heidelberg Germany +49 6221 4342 113 mls.ietf@gmail.com http://ietf.stiemerling.org

Thales Deutschland

Thalesplatz 1 71254 Ditzingen Germany ietf@nico-schwan.de

Alcatel-Lucent Bell Labs

Lorenzstrasse 10 70435 Stuttgart Germany michael.scharf@alcatel-lucent.com

Huawei

haibin.song@huawei.com

TSV ALTO ALTO ALTO server discovery The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers. This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource . ALTO is realized by a client-server protocol; see requirement AR-1 in . Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide guidance to this specific client. This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. In other words, this document meets requirement AR-32 in while AR-33 is out of scope. A different approach, which tries to meet requirement AR-33, i.e., third-party ALTO server discovery, is addressed in . A more detailed discussion of various options on where to place the functional entities comprising the overall ALTO architecture can be found in . The ALTO protocol specification is based on HTTP and expects the discovery procedure to yield the HTTP(S) URI of an ALTO server's Information Resource Directory (IRD). Therefore, this procedure is based on a combination of the Dynamic Host Configuration Protocol (DHCP) or local configuration and URI-enabled Naming Authority Pointer (U-NAPTR) resource records in the Domain Name System (DNS), in order to deliver such URIs.

This document makes use of the ALTO terminology defined in . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

The ALTO protocol specification expects that the ALTO discovery procedure yields the HTTP(S) URI of the ALTO server's Information Resource Directory (IRD), which gives further information about the capabilities and services provided by that ALTO server. On hosts with more than one interface or address family (IPv4/v6), the ALTO server discovery procedure has to be run for every interface and address family. For more details see . The ALTO server discovery procedure is performed in two steps: One DNS domain name is retrieved for each combination of interface and address family, either by local configuration (e.g., manual input into a menu or configuration file) or by means of DHCP. These DNS domain names are used for U-NAPTR lookups yielding one or more URIs. Further DNS lookups may be necessary to determine the ALTO server's IP address(es). The primary means for retrieving the DNS domain name is DHCP. However, there may be situations where DHCP is not available or does not return a suitable value. Furthermore, there might be situations in which the user wishes to override the value that could be retrieved from DHCP. In these situations, local configuration may be used. Consequently, the algorithm first checks for a locally configured override, before it tries to retrieve a value from DHCP. Typically, but not necessarily, the DNS domain name is the domain name in which the client is located, i.e., a PTR lookup on the client's IP address (according to , Section 3.5 for IPv4 or , Section 2.5 for IPv6) would yield a similar name. However, due to the widespread use of Network Address Translation (NAT), trying to determine the DNS domain name through a PTR lookup on an interface's IP address is not recommended for resource consumer initiated ALTO server discovery (see also ).

As already outlined in , the ALTO server discovery procedure is performed for every address family on every interface the application considers for communicating with resource providers. First, the algorithm checks for a locally configured domain name, as specified in . If no such name was configured, it tries to retrieve one from DHCP, as specified in . If still no domain name could be found, the procedure has failed and terminates with an appropriate error code. If one or more domain names were found, they will be used as U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) application-unique strings for a DNS lookup, as specified in .

The preferred way to acquire a domain name related to an interface's point of network attachment is the use of DHCP (see ). However, in some network deployment scenarios, there is no DHCP server available. Furthermore, a user may want to use an ALTO service instance provided by an entity that is not the operator of the underlying IP network. Therefore, we allow the user to specify a DNS domain name, for example, in a configuration file option. An example domain name is: my-alternative-alto-provider.example.org Implementations MAY give the user the opportunity (e.g., by means of configuration file options or menu items) to specify an individual domain name for every address family on every interface. Implementations SHOULD allow the user to specify a default name that is used if no more specific name has been configured.

Network operators may provide the domain name to be used for service discovery within an access network using DHCP. RFC 5986 defines DHCP IPv4 and IPv6 access network domain name options to identify a domain name that is suitable for service discovery within the access network. RFC 2132 defines the DHCP IPv4 domain name option. While this option is less suitable, it still may be useful if the RFC 5986 option is not available. For IPv6, the ALTO server discovery procedure MUST try to retrieve DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be retrieved the procedure fails for this interface. For IPv4, the ALTO server discovery procedure MUST try to retrieve DHCP option 213 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the procedure SHOULD try to retrieve option 15 (Domain Name). If neither option can be retrieved, the procedure fails for this interface. If a result can be retrieved, it will be used as an input for the next step (U-NAPTR resolution). One example result could be: example.net

The first step of the ALTO server discovery procedure (see ) retrieved one or -- in case of multiple interfaces and/or IPv4/v6 dual-stack operation -- several domain names, which will be used as U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) application unique strings. An example is: example.net In the second step, the ALTO server discovery procedure uses a U-NAPTR lookup with the "ALTO" Application Service Tag and either the "http" or the "https" Application Protocol Tag to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory. In this document, only the HTTP and HTTPS URI schemes are defined, as the ALTO protocol specification defines the access over both protocols, but no other . Note that the result can be any valid HTTP(S) URI. The following two U-NAPTR resource records can be used for mapping "example.net" to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred.

If no ALTO-specific U-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If further domain names retrieved by Step 1 are known, the discovery procedure may perform the corresponding U-NAPTR lookups immediately. However, before retrying a lookup that has failed, a client MUST wait a time period that is appropriate for the encountered error (NXDOMAIN, timeout, etc.).

describes the usage of a DHCP option that provides a means for the network operator of the network in which the ALTO client is located to provide a DNS domain name. However, this assumes that this particular DHCP option is correctly passed from the DHCP server to the actual host with the ALTO client, and that the particular host understands this DHCP option. This memo assumes the client to be able to understand the proposed DHCP option; otherwise, there is no further use of the DHCP option, but the client has to use the other proposed mechanisms. There are well-known issues with the handling of DHCP options in home gateways. One issue is that unknown DHCP options are not passed through some home gateways, effectively eliminating the DHCP option. Another well-known issue is the use of home-gateway-specific DNS domain names that "override" the DNS domain name provided by the network operator. For instance, a host behind a home gateway may receive a DNS domain name ".local" instead of "example.net". In general, this domain name is not usable for the server discovery procedure, unless a DNS server in the home gateway resolves the corresponding NAPTR lookup correctly, e.g., by means of a DNS split horizon approach.

If the user decides to enter only one (default) DNS domain name in the local configuration facility (see ), only one set of ALTO servers will be discovered, irrespectively of multihoming and mobility. Particularly in mobile scenarios, this can lead to undesirable results. The DHCP-based discovery method can discover different sets of ALTO servers for each interface and address family (i.e., IPv4/v6). In general, if a client wishes to communicate using one of its interfaces and using a specific IP address family, it SHOULD query the ALTO server or servers that have been discovered for this specific interface and address family. How to select an interface and IP address family as well as how to compare results returned from different ALTO servers are out of the scope of this document. 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 re-run the ALTO server discovery procedure without relying on earlier gained information. There are several challenges with DNS on hosts with multiple interfaces , which can affect the ALTO server discovery. If the DNS resolution is performed on the wrong interface, it can return an ALTO server that could provide suboptimal or wrong guidance. Finding the best ALTO server for multi-interfaced hosts is outside the scope of this document. When using Virtual Private Network (VPN) connections, there is usually no DHCP. The user has to enter the DNS domain name in the local configuration facility. For good optimization results, a DNS domain name corresponding to the VPN concentrator, not corresponding to the user's current location, has to be entered. Similar considerations apply for Mobile IP.

IANA has registered the following U-NAPTR application service tag for ALTO: ALTO see or: "The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource." The specification contained within this document The authors of this document The IESG No interoperability issues are known or expected. This tag is to be registered specifically for ALTO, which is a new application without any legacy deployments. see of this document. This document specifies a procedure for discovering an HTTP or HTTPS URI of an ALTO server. HTTP and HTTPS are specified in . The HTTP(S)-based ALTO protocol is specified in . This document specifies how to use the application service tag "ALTO" with the application protocol tags "http" and "https", which have already been registered in the relevant IANA registry. Therefore, IANA is not requested by this document to register any new application protocol tag.

A high-level discussion of security issues related to ALTO is part of the ALTO problem statement . A classification of unwanted information disclosure risks, as well as specific security-related requirements can be found in the ALTO requirements document . The remainder of this section focuses on security threats and protection mechanisms for the ALTO server discovery procedure as such. Once the ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification apply.

An attacker could compromise the ALTO server discovery procedure or infrastructure in a way that ALTO clients would discover a "wrong" ALTO server URI. This is probably the most serious security concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all, or it might give suboptimal or forged information. In the latter case, an attacker could try to use ALTO to affect the traffic distribution in the network or the performance of applications (see also Section 15.1. of ). Furthermore, a hostile ALTO server could threaten user privacy (see also Section 5.2.1, case (5a) in ). However, it should also be noted that, if an attacker was able to compromise DHCP and/or DNS servers used for ALTO server discovery (see below), (s)he could also launch significantly more serious other attacks (e.g., redirecting various application protocols). The ALTO server discovery procedure consists of three building blocks (local configuration, DHCP, and DNS) and each of them is a possible attack vector. The problem of users possibly following "bad advice" that tricks them into manually configuring unsuitable ALTO servers cannot be solved by technical means and is out of the scope of this document. Due to the nature of the protocol, DHCP is rather prone to attacks. As already mentioned, an attacker that is able to inject forged DHCP replies into the network may do significantly more harm than only configuring a wrong ALTO server. Best current practices for safely operating DHCP should be followed. A further threat is the possible alteration of the DNS records used in U-NAPTR resolution. If an attacker was able to modify or spoof any of the DNS records used in the DDDS resolution, this URI could be replaced by a forged URI. The application of DNS security (DNSSEC) 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 . A related risk is the impersonation of the ALTO server (i.e., attacks after the correct URI has been discovered). This threat and protection strategies are discussed in Section 15.1 of . Note that if Transport Layer Security (TLS) is used to protect ALTO, the server certificate will contain the host name (CN). Consequently, only the host part of the HTTPS URI will be authenticated, i.e., the result of the ALTO server discovery procedure. The U-NAPTR based mapping within the ALTO server discovery procedure needs to be secured as described above, e.g., by using DNSSEC. In addition to active protection mechanisms, users and network operators can monitor application performance and network traffic patterns for poor performance or abnormalities. If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random outcomes, the use of the ALTO server may be discontinued (see also Section 15.2 of ).

An attacker could compromise the ALTO server discovery procedure or infrastructure in a way that ALTO clients would not be able to discover any ALTO server. If no ALTO server can be discovered (although a suitable one exists), applications have to make their decisions without ALTO guidance. As ALTO could be temporarily unavailable for many reasons, applications must be prepared to do so. However, the resulting application performance and traffic distribution will correspond to a deployment scenario without ALTO. Operators should follow best current practices to secure their DHCP, DNS, and ALTO (see Section 15.5 of ) servers against Denial-of-Service (DoS) attacks.

An unauthorized party could invoke the ALTO server discovery procedure, or intercept discovery messages between an authorized ALTO client and the DHCP and DNS servers, in order to acquire knowledge of the ALTO server's URI. In the ALTO use cases that have been described in the ALTO problem statement and/or discussed in the ALTO working group, the ALTO server's URI as such has always been considered as public information that does not need protection of confidentiality. No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly.

An unauthorized party could intercept discovery messages between an ALTO client and the DHCP and DNS servers, and thereby find out the fact that said ALTO client uses (or at least tries to use) the ALTO service. In the ALTO use cases that have been described in the ALTO problem statement and/or discussed in the ALTO working group, this scenario has not been identified as a relevant threat. No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Silicon Graphics, Inc.

2011 N. Shoreline Boulevard Mailstop 510 Mountain View CA 94043-1389 (415) 933-6172 sca@engr.sgi.com

Bucknell University

Lewisburg PA 17837 (717) 524-1145 droms@bucknell.edu

bootstrap protocol dynamic host configuration protocol The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in- notes/iana/assignments . All of the vendor information extensions defined in RFC 1497 may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions. The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK] Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK] Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates, which are able to provide a desired resource. This memo discusses deployment related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and CDNs, security considerations, recommendations for network administrators, and also guidance for application designers using ALTO. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. This document specifies a procedure for third-party ALTO server discovery, which can be used if the ALTO client is not co-located with the actual resource consumer, but instead embedded in a third party such as a peer-to-peer tracker. Technically, the algorithm specified in this document takes one IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as parameters. It performs several DNS lookups (for U-NAPTR and SOA resource records) and returns one or more URI(s) of information resources related to that IP address. USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

IAB As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.</t><t> This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community. This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes. Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.</t><t> This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

Olafur Gudmundsson provided an excellent DNS expert review on an earlier version of this document. Thanks to Tina Tsou for an accurate security review. 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 CHANGE project <http://www.change-project.eu>, a research project supported by the European Commission under its 7th Framework Program (contract no. 257422). 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 CHANGE project or the European Commission.

The initial version of this document was coauthored by Marco Tomsu. 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. The authors would also like to thank the following persons for their contribution to this document or its predecessors: Richard Alimi, David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang, Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei Zhang, Ning Zong.