diff options
Diffstat (limited to 'doc/rfc/rfc6708.txt')
| -rw-r--r-- | doc/rfc/rfc6708.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc6708.txt b/doc/rfc/rfc6708.txt new file mode 100644 index 0000000..aa774a6 --- /dev/null +++ b/doc/rfc/rfc6708.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Kiesel, Ed. +Request for Comments: 6708 University of Stuttgart +Category: Informational S. Previdi +ISSN: 2070-1721 Cisco Systems, Inc. + M. Stiemerling + NEC Europe Ltd. + R. Woundy + Comcast Corporation + Y. Yang + Yale University + September 2012 + + + Application-Layer Traffic Optimization (ALTO) Requirements + +Abstract + + 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. + + This document enumerates requirements for specifying, assessing, or + comparing protocols and implementations. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6708. + + + +Kiesel, et al. Informational [Page 1] + +RFC 6708 ALTO Requirements September 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology and Architectural Framework . . . . . . . . . . . 3 + 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 + 2.2. ALTO Terminology . . . . . . . . . . . . . . . . . . . . . 3 + 2.3. Architectural Framework for ALTO . . . . . . . . . . . . . 5 + 3. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. ALTO Client Protocol . . . . . . . . . . . . . . . . . . . 5 + 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 5 + 3.1.2. Host-Group Descriptor Support . . . . . . . . . . . . 6 + 3.1.3. Rating Criteria Support . . . . . . . . . . . . . . . 7 + 3.1.4. Placement of Entities and Timing of Transactions . . . 9 + 3.1.5. Protocol Extensibility . . . . . . . . . . . . . . . . 11 + 3.1.6. Error Handling and Overload Protection . . . . . . . . 11 + 3.2. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 12 + 3.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 13 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 5.1. High-Level Security Considerations . . . . . . . . . . . . 14 + 5.2. Information Disclosure Scenarios . . . . . . . . . . . . . 14 + 5.2.1. Classification of Information Disclosure Scenarios . . 14 + 5.2.2. Discussion of Information Disclosure Scenarios . . . . 16 + 5.3. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 18 + 5.4. Security Requirements . . . . . . . . . . . . . . . . . . 18 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 + + + + + + +Kiesel, et al. Informational [Page 2] + +RFC 6708 ALTO Requirements September 2012 + + +1. Introduction + + The motivation for Application-Layer Traffic Optimization (ALTO) is + described in the ALTO problem statement [RFC5693]. + + The goal of ALTO is to provide information that can help peer-to-peer + (P2P) applications make better decisions with respect to peer + selection. However, ALTO may be useful for non-P2P applications as + well. For example, clients of client-server applications may use + information provided by ALTO to select one of several servers or + information replicas. As another example, ALTO information could be + used to select a media relay needed for NAT traversal. The goal of + these informed decisions is to improve performance or Quality of + Experience in the application while reducing the utilization of the + underlying network infrastructure. + + Usually, it would be difficult or even impossible for application + entities to acquire this information by other mechanisms, e.g., using + measurements between the peers of a P2P overlay, because of + complexity or because it is based on network topology information, + network operational costs, or network policies, which the respective + network provider does not want to disclose in detail. + + The functional entities that provide the ALTO service do not take + part in the actual user-data transport, i.e., they do not implement + functions for relaying user data. These functional entities may be + placed on various kinds of physical nodes, e.g., on dedicated + servers, as auxiliary processes in routers, on "trackers" or "super + peers" of a P2P application, etc. + +2. Terminology and Architectural Framework + +2.1. Requirements Notation + + 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 [RFC2119]. + +2.2. ALTO Terminology + + This document uses the following ALTO-related terms, which are + defined in [RFC5693]: + + Application, Peer, P2P, Resource, Resource Identifier, Resource + Provider, Resource Consumer, Transport Address, Overlay Network, + Resource Directory, ALTO Service, ALTO Server, ALTO Client, ALTO + + + + + +Kiesel, et al. Informational [Page 3] + +RFC 6708 ALTO Requirements September 2012 + + + Query, ALTO Response, ALTO Transaction, Local Traffic, Peering + Traffic, Transit Traffic, Application Protocol, ALTO Client Protocol, + and Provisioning Protocol. + + Furthermore, the following additional terms will be used: + + o Host-Group Descriptor: Information used to describe one or more + Internet hosts (such as the resource consumer that seeks ALTO + guidance, or one or more candidate resource providers) and their + location within the network topology. There can be several + different types of host-group descriptors, for example, a single + IP address, an address prefix or address range that contains the + host(s), or an Autonomous System (AS) number. Different host- + group descriptor types may provide different levels of detail. + Depending on the system architecture, this may have implications + on the quality of the guidance ALTO is able to provide, on whether + recommendations can be aggregated, and on how much privacy- + sensitive information about users might be disclosed to additional + parties. + + o Rating Criterion: The condition or relation that defines the + "better" in "better-than-random peer selection", which is the + ultimate goal of ALTO. Examples may include "host's Internet + access is not subject to volume-based charging (flat rate)" or + "low topological distance". Some rating criteria, such as "low + topological distance", need to include a reference point, e.g., + "low topological distance from a given resource consumer". This + reference point can be described by means of a host-group + descriptor. + + o Host-Characteristics Attribute: Properties of a host, other than + the host-group descriptor. It may be evaluated according to one + or more rating criteria. This information may be stored in an + ALTO server and transmitted via an ALTO protocol. One example for + a host-characteristics attribute would be a data field indicating + whether a host's Internet access is subject to volume-based + charging or not (flat rate). + + o Target-Aware Query Mode: In this mode of operation, an ALTO client + performs the ALTO query when the desired resource and a set of + candidate resource providers are already known, i.e., after + Distributed Hash Table (DHT) lookups, queries to the resource + directory, etc. To this end, the ALTO client transmits a list of + host-group descriptors and optionally one or more rating criteria + to the ALTO server. The ALTO server evaluates the host-group + descriptors according to the indicated criteria or a default + + + + + +Kiesel, et al. Informational [Page 4] + +RFC 6708 ALTO Requirements September 2012 + + + criterion. It returns a list of these host-group descriptors to + the ALTO client, which is sorted according to the rating criteria + and/or enriched with host-characteristics attributes. + + o Target-Independent Query Mode: In this mode of operation, ALTO + queries are performed in advance or periodically, in order to + receive comprehensive guidance. The ALTO client indicates the + desired host-characteristics attributes in the ALTO query. The + ALTO server answers with a list that indicates for all known host- + group descriptors (possibly subject to the server's policies) the + desired host-characteristics attributes. These lists will be + cached locally and evaluated later, when a resource is to be + accessed. + +2.3. Architectural Framework for ALTO + + There are various architectural options for ALTO implementation. + Specifying or mandating one specific architecture is out of the scope + of this document. + + In addition to the terminology (see Section 2 of [RFC5693] and + Section 2.2 of this document), [RFC5693] presents a figure that gives + a high-level overview of protocol interaction between these + components. + + This document itemizes requirements for the following components: + ALTO client protocols, ALTO server discovery mechanisms, host-group + descriptors, rating criteria, and host-characteristics attributes. + Furthermore, requirements regarding the overall architecture, + especially with respect to security and privacy issues, are + presented. + + Note that the detailed specification of such protocols and mechanisms + is out of the scope of this document. In fact, this document does + not even assume that there will be only one single specification for + each of these components, respectively. However, this document + enumerates requirements for ALTO to be considered when specifying, + assessing, or comparing protocols and implementations. + +3. ALTO Requirements + +3.1. ALTO Client Protocol + +3.1.1. General Requirements + + Req. AR-1: The ALTO service is provided by one or more ALTO servers. + It may be queried by ALTO clients seeking guidance for selecting + appropriate resource providers. ALTO clients and ALTO servers MUST + + + +Kiesel, et al. Informational [Page 5] + +RFC 6708 ALTO Requirements September 2012 + + + implement an ALTO client protocol. An ALTO client protocol MUST be + able to transmit ALTO queries from an ALTO client to an ALTO server, + and it MUST be able to transmit the corresponding ALTO replies from + the ALTO server to the ALTO client. + + The detailed specification of an ALTO client protocol is out of the + scope of this document. In fact, this document does not even assume + that there will be only one single protocol specification. However, + this document enumerates requirements for ALTO, to be considered when + specifying, assessing, or comparing protocols and implementations. + + Req. AR-2: An ALTO client protocol MUST provide adequate mechanisms + for operations and management support, as outlined in RFC 5706 + [RFC5706]. + +3.1.2. Host-Group Descriptor Support + + The ALTO guidance is based on the evaluation of several resource + providers or groups of resource providers, considering one or more + rating criteria. The resource providers or groups of resource + providers are characterized by means of host-group descriptors. + + Req. AR-3: An ALTO client protocol MUST support the usage of multiple + host-group descriptor types. + + Req. AR-4: ALTO clients and ALTO servers MUST clearly identify the + type of each host-group descriptor sent in ALTO queries or responses. + An ALTO protocol specification MUST provide appropriate protocol + elements. + + Req. AR-5: An ALTO client protocol MUST support the host group + descriptor types "IPv4 address prefix" and "IPv6 address prefix". + They can be used to specify the IP address of one host, or an IP + address range (in Classless Inter-Domain Routing (CIDR) notation) + containing all hosts in question. + + Req. AR-6: An ALTO client protocol MUST be extensible to enable + future support of other host-group descriptor types. An ALTO client + protocol specification MUST define an appropriate procedure for + adding new host-group descriptor types, e.g., by establishing an IANA + registry. + + Req. AR-7: For host-group descriptor types other than "IPv4 address + prefix" and "IPv6 address prefix", the host-group descriptor type + identification MUST be supplemented by a reference to a facility that + can be used to translate host-group descriptors of this type to IPv4/ + IPv6 address prefixes, e.g., by means of a mapping table or an + algorithm. + + + +Kiesel, et al. Informational [Page 6] + +RFC 6708 ALTO Requirements September 2012 + + + Req. AR-8: Protocol functions for mapping other host-group descriptor + types to IPv4/IPv6 address prefixes SHOULD be designed and specified + as part of an ALTO client protocol, and the corresponding address + mapping information SHOULD be made available by the same entity that + wants to use these host-group descriptors within an ALTO client + protocol. However, an ALTO server or an ALTO client MAY also send a + reference to an external mapping facility, e.g., a translation table + to be obtained via an alternative mechanism. + + Rationale for the previous two requirements: The preferred type of + host-group descriptors are IPv4 and IPv6 prefixes. However, in + some situations, one party may prefer to use another type, e.g., + AS numbers. Usually, applications seeking ALTO guidance work with + IP addresses, e.g., when establishing connections. Understanding + guiding information that is based on other host-group descriptor + types, i.e., mapping from these other types to IP prefixes and + back, may be a non-trivial task. Therefore, before a party may + use other host-group descriptor types, they must provide a mapping + mechanism to IP prefixes. + + Req. AR-9: An ALTO client protocol specification MUST define + mechanisms that can be used by the ALTO server to indicate that a + host-group descriptor used by the ALTO client is of an unsupported + type, or that the indicated mapping mechanism could not be used. + + Req. AR-10: An ALTO client protocol specification MUST define + mechanisms that can be used by the ALTO client to indicate that a + host-group descriptor used by the ALTO server is of an unsupported + type, or that the indicated mapping mechanism could not be used. + +3.1.3. Rating Criteria Support + + Req. AR-11: An ALTO client protocol specification MUST define a + rating criterion that can be used to express and evaluate the + "relative operator's preference". This is a relative measure, i.e., + it is not associated with any unit of measurement. A preferred + rating, according to this criterion, indicates that the application + should prefer the respective candidate resource provider over others + with less preferred ratings (unless information from non-ALTO sources + suggests a different choice, such as transmission attempts suggesting + that the path is currently congested). The operator of the ALTO + server does not have to disclose how and based on which data the + ratings are actually computed. Examples could be: cost for peering + or transit traffic, traffic engineering inside the network, and other + policies. + + + + + + +Kiesel, et al. Informational [Page 7] + +RFC 6708 ALTO Requirements September 2012 + + + Req. AR-12: An ALTO client protocol MUST be extensible to enable + future support of other rating criteria types. An ALTO client + protocol specification MUST define an appropriate procedure for + adding new rating criteria types, e.g., by establishing an IANA + registry. + + Req. AR-13: ALTO client protocol specifications MUST NOT define + rating criteria closely related to the instantaneous network + congestion state, i.e., rating criteria that have the primary aim to + serve as an alternative to established congestion control strategies, + such as using TCP-based transport. + + Req. AR-14: Applications using ALTO guidance MUST NOT rely solely on + the ALTO guidance to avoid causing network congestion. Instead, they + MUST use other appropriate means, such as TCP-based transport, to + avoid causing excessive congestion. + + Rationale for the previous requirement: One design assumption for + ALTO is that it is acceptable for the host-characteristics + attributes, which are stored and processed in the ALTO servers for + giving guidance, to be updated rather infrequently. Typical + update intervals may be several orders of magnitude longer than + the typical network-layer packet round-trip time (RTT). + Therefore, ALTO cannot be a replacement for TCP-like congestion + control mechanisms. + + Req. AR-15: In the target-independent query mode, the ALTO query + message SHOULD allow the ALTO client to express which host- + characteristics attributes should be returned. + + Req. AR-16: In the target-aware query mode, the ALTO query message + SHOULD allow the ALTO client to express which rating criteria should + be considered by the server, as well as their relative relevance for + the specific application that will eventually make use of the + guidance. The corresponding ALTO response message SHOULD allow the + ALTO server to express which rating criteria have been considered + when generating the response. + + Req. AR-17: An ALTO client protocol specification MUST define + mechanisms that can be used by the ALTO client and the ALTO server to + indicate that a rating criteria used by the other party is of an + unsupported type. + + + + + + + + + +Kiesel, et al. Informational [Page 8] + +RFC 6708 ALTO Requirements September 2012 + + +3.1.4. Placement of Entities and Timing of Transactions + + With respect to the placement of ALTO clients, several modes of + operation exist: + + o One mode of ALTO operation is that an ALTO client may be embedded + directly in the resource consumer, i.e., the application protocol + entity that will eventually initiate data transmission to/from the + selected resource provider(s) in order to access the desired + resource. For example, an ALTO client could be integrated into + the peer of a P2P application that uses a distributed algorithm + such as "query flooding" for resource discovery. + + o Another mode of operation is to integrate the ALTO client into a + third party, such as a resource directory. This third party may + issue ALTO queries to solicit preference on potential resource + providers, considering the respective resource consumer. For + example, an ALTO client could be integrated into the tracker of a + tracker-based P2P application, in order to request ALTO guidance + on behalf of the peers contacting the tracker. + + Req. AR-18: An ALTO client protocol MUST support the mode of + operation in which the ALTO client is directly embedded in the + resource consumer. + + Req. AR-19: An ALTO client protocol MUST support the mode of + operation in which the ALTO client is embedded in a third party. + This third party performs queries on behalf of resource consumers. + + Req. AR-20: An ALTO client protocol MUST be designed in a way that + the ALTO service can be provided by an entity that is not the + operator of the underlying IP network. + + Req. AR-21: An ALTO client protocol MUST be designed in a way that + different instances of the ALTO service operated by different + providers can coexist. + + Req. AR-22: An ALTO client protocol specification MUST specify at + least one query mode, either the target-aware or the target- + independent query mode. + + Note that this requirements document does not assume that there will + be only one single protocol specification. + + Req. AR-23: An ALTO client protocol specification SHOULD specify both + the target-aware and the target-independent query mode. If an ALTO + client protocol specification specifies more than one query mode, it + MUST define at least one of these modes as REQUIRED to implement by + + + +Kiesel, et al. Informational [Page 9] + +RFC 6708 ALTO Requirements September 2012 + + + ALTO clients and ALTO servers. Furthermore, it MUST specify an + appropriate protocol mechanism for negotiating between the ALTO + client and ALTO server, which query mode to use. + + Req. AR-24: An ALTO client protocol SHOULD support version numbering, + TTL (time-to-live) attributes, and/or similar mechanisms in ALTO + transactions, in order to enable time validity checking for caching, + and to enable comparisons of multiple recommendations obtained + through redistribution. + + Req. AR-25: An ALTO client protocol SHOULD allow the ALTO server to + add information about appropriate modes of reuse to its ALTO + responses. Reuse may include redistributing an ALTO response to + other parties, as well as using the same ALTO information in a + resource directory to improve the responses to different resource + consumers within the specified lifetime of the ALTO response. The + ALTO server SHOULD be able to express that + + o no reuse should occur. + + o reuse is appropriate for a specific "target audience", i.e., a set + of resource consumers explicitly defined by a list of host-group + descriptors. The ALTO server MAY specify a "target audience" in + the ALTO response that is only a subset of the known actual + "target audience", e.g., if required by operator policies. + + o reuse is appropriate for any resource consumer that would send (or + cause a third party to send on behalf of it) the same ALTO query + (i.e., with the same query parameters, except for the resource + consumer ID, if applicable) to this ALTO server. + + o reuse is appropriate for any resource consumer that would send (or + cause a third party to send on behalf of it) the same ALTO query + (i.e., with the same query parameters, except for the resource + consumer ID, if applicable) to any other ALTO server that was + discovered (using an ALTO discovery mechanism) together with this + ALTO server. + + o reuse is appropriate for any resource consumer that would send (or + cause a third party to send on behalf of it) the same ALTO query + (i.e., with the same query parameters, except for the resource + consumer ID, if applicable) to any ALTO server in the whole + network. + + Req. AR-26: An ALTO client protocol MUST support the transport of + ALTO transactions, even if the ALTO client is located in the private + address realm behind a network address translator (NAT). There are + different types of NAT, see [RFC4787] and [RFC5382]. + + + +Kiesel, et al. Informational [Page 10] + +RFC 6708 ALTO Requirements September 2012 + + +3.1.5. Protocol Extensibility + + Req. AR-27: An ALTO client protocol MUST include support for adding + protocol extensions in a non-disruptive, backward-compatible way. + + Req. AR-28: An ALTO client protocol MUST include protocol versioning + support, in order to clearly distinguish between incompatible + versions of the protocol. + +3.1.6. Error Handling and Overload Protection + + Req. AR-29: An ALTO client protocol MUST use congestion-aware + transport, e.g., by using TCP. + + Req. AR-30: An ALTO client protocol specification MUST specify + mechanisms for an ALTO server to inform clients about an impending or + occurring overload situation, or how to leverage appropriate + mechanisms provided by underlying protocol layers. The mechanisms + MUST provide all of the following options to the server: + + o terminate the conversation with the client, + + o redirect the client to another ALTO server, and + + o request that the client throttle its query rate. + + In particular, a simple form of throttling is to let an ALTO + server answer a query with an error message advising the client to + retry the query later (e.g., using a protocol function such as + HTTP's Retry-After header ([RFC2616], Section 14.37)). Another + simple option is to actually answer the query with the desired + information, but adding an indication that the ALTO client should + not send further queries to this ALTO server before an indicated + period of time has elapsed. + + Req. AR-31: An ALTO client protocol specification MUST specify + mechanisms for an ALTO server to inform clients about its inability + to answer queries due to technical problems or system maintenance, or + how to leverage appropriate mechanisms provided by underlying + protocol layers. The mechanisms MUST provide all of the following + options to the server: + + o terminate the conversation with the client, + + o redirect the client to another ALTO server, and + + o request that the client retry the query later. + + + + +Kiesel, et al. Informational [Page 11] + +RFC 6708 ALTO Requirements September 2012 + + + Note: The existence of the above-mentioned protocol mechanisms does + not imply that an ALTO server must use them when facing an overload, + technical problem, or maintenance situation, respectively. Some + servers may be unable to use them in that situation, or they may + prefer to simply refuse the connection or not to send any answer at + all. + +3.2. ALTO Server Discovery + + An ALTO client protocol is supported by one or more ALTO server + discovery mechanisms, which may be used by ALTO clients to determine + one or more ALTO servers, to which ALTO requests can be sent. This + section enumerates requirements for an ALTO client, as well as + general requirements to be fulfilled by the ALTO server discovery + mechanisms. + + Req. AR-32: An ALTO server discovery mechanism MUST support features + allowing ALTO clients that are embedded in the resource consumer to + find one or several ALTO servers that can provide ALTO guidance + suitable for the resource consumer, using an ALTO protocol version + compatible with the ALTO client. This mode of operation is called + "resource consumer initiated ALTO server discovery". + + Req. AR-33: An ALTO server discovery mechanism MUST support features + allowing ALTO clients that are embedded in a resource directory and + perform third-party ALTO queries on behalf of a remote resource + consumer to find one or several ALTO servers that can provide ALTO + guidance suitable for the respective resource consumer, using an ALTO + protocol version compatible with the ALTO client. This mode of + operation is called "third-party ALTO server discovery". + + Req. AR-34: ALTO clients MUST be able to perform resource consumer + initiated ALTO server discovery, even if they are located behind a + NAT. + + Req. AR-35: ALTO clients MUST be able to perform third-party ALTO + server discovery, even if they are located behind a NAT. + + Req. AR-36: ALTO clients MUST be able to perform third-party ALTO + server discovery, even if the resource consumer, on behalf of which + the ALTO query will be sent, is located behind a NAT. + + Req. AR-37: ALTO server discovery mechanisms SHOULD leverage an + existing protocol or mechanism, such as DNS-, DHCP-, or PPP-based + automatic configuration, etc. A single mechanism with a broad + spectrum of applicability SHOULD be preferred over several different + mechanisms with narrower scopes. + + + + +Kiesel, et al. Informational [Page 12] + +RFC 6708 ALTO Requirements September 2012 + + + Req. AR-38: Every ALTO server discovery mechanism SHOULD be able to + return the respective contact information for multiple ALTO servers. + + Req. AR-39: Every ALTO server discovery mechanism SHOULD be able to + indicate preferences for each returned ALTO server contact + information. + +3.3. Security and Privacy + + Note: The following requirements mandate the inclusion of certain + security mechanisms at a protocol specification level. Whether it + makes sense to enable these mechanisms in a given deployment scenario + depends on a threat analysis for this specific scenario. For a + classification of potential information disclosure risks, refer to + Section 5.2. + + Req. AR-40: An ALTO client protocol specification MUST specify + mechanisms for the authentication of ALTO servers or specify how to + leverage appropriate mechanisms provided by underlying protocol + layers. + + Req. AR-41: An ALTO client protocol specification MUST specify + mechanisms for the authentication of ALTO clients or specify how to + leverage appropriate mechanisms provided by underlying protocol + layers. + + Req. AR-42: An ALTO client protocol specification MUST specify + mechanisms for the encryption of messages or specify how to leverage + appropriate mechanisms provided by underlying protocol layers. + + Req. AR-43: An ALTO client is not required to implement mechanisms or + to comply with rules that limit its ability to redistribute + information retrieved from the ALTO server to third parties. + + Req. AR-44: An ALTO client protocol MUST support different levels of + detail in queries and responses in order to protect the privacy of + users, to ensure that the operators of ALTO servers and other users + of the same application cannot derive sensitive information. + + Req. AR-45: An ALTO client protocol MAY include mechanisms that can + be used by the ALTO client when requesting guidance to specify the + resource (e.g., content identifiers) it wants to access. An ALTO + server MUST provide adequate guidance, even if the ALTO client + prefers not to specify the desired resource (e.g., keeps the data + field empty). The mechanism MUST be designed in a way that the + operator of the ALTO server cannot easily deduce the resource + identifier (e.g., file name in P2P file sharing) if the ALTO client + prefers not to specify it. + + + +Kiesel, et al. Informational [Page 13] + +RFC 6708 ALTO Requirements September 2012 + + + Req. AR-46: An ALTO client protocol specification MUST specify + appropriate mechanisms for protecting the ALTO service against + Denial-of-Service (DoS) attacks or specify how to leverage + appropriate mechanisms provided by underlying protocol layers. + +4. IANA Considerations + + This requirements document does not mandate any immediate IANA + actions. However, such IANA considerations may arise from future + ALTO specification documents that try to meet the requirements given + here. + +5. Security Considerations + +5.1. High-Level Security Considerations + + High-level security considerations for the ALTO service can be found + in the "Security Considerations" section of the ALTO problem + statement document [RFC5693]. + +5.2. Information Disclosure Scenarios + + The unwanted disclosure of information is one key concern related to + ALTO. Neither the ALTO server nor a third party using or misusing + the ALTO service should be able to infer the application behavior or + correlate data in such a way that would violate user privacy, e.g., + who is exchanging which files with whom using a P2P file-sharing + application. Furthermore, many network operators are concerned about + the amount of information related to their network infrastructure + (e.g., topology information, number of "premium customers", or + utilization statistics) that might be released through ALTO. This + section presents a classification and discussion of information + disclosure scenarios and potential countermeasures. + +5.2.1. Classification of Information Disclosure Scenarios + + The following issues may be considered a risk for the operator of an + ALTO server, depending on the specific deployment scenario: + + (1) Excess disclosure of the ALTO server operator's data to an + authorized ALTO client. The operator of an ALTO server has to + feed information, such as tables mapping host-group descriptors + to host-characteristics attributes, into the server, thereby + enabling it to give guidance to ALTO clients. Some operators + might consider the full set of this information confidential + (e.g., a detailed map of the operator's network topology) and + might want to disclose only a subset of it or disclose somehow + obfuscated information to an ALTO client. + + + +Kiesel, et al. Informational [Page 14] + +RFC 6708 ALTO Requirements September 2012 + + + (2) Disclosure of the ALTO server operator's data (e.g., network + topology information) to an unauthorized third party. There are + three subcases here: + + (2a) An ALTO server receives and answers queries originating + from an unauthorized ALTO client. + + (2b) An unauthorized party snoops on the data transmission from + the ALTO server to an authorized ALTO client. + + (2c) An authorized ALTO client knowingly forwards the + information it has received from the ALTO server to an + unauthorized party. + + (3) Excess retrieval of the ALTO server operator's data by + collaborating ALTO clients. Several authorized ALTO clients + could ask one or more ALTO servers for guidance, possibly + several times during an extended period of time, and + redistribute the responses among each other (see also case 2c). + By aggregating and correlating the ALTO responses, they could + find out more information than intended to be disclosed by the + ALTO server operator(s). + + The following issues may be considered a risk for the user of an ALTO + client, depending on the specific deployment scenario: + + (4) Disclosure of the application behavior or other user private + data to the (authorized) ALTO server. The operator of an ALTO + server could infer the application behavior (e.g., content + identifiers in P2P file sharing applications, or lists of + resource providers that are considered for establishing a + connection) from the ALTO queries sent by an ALTO client. + + (5) Disclosure of the application behavior or other user private + data to an unauthorized third party. There are three subcases + here: + + (5a) An ALTO client willingly sends queries directly to an + untrusted or malicious ALTO server, possibly due to a + forged response of the ALTO server discovery mechanism. + + (5b) An unauthorized party snoops on the data transmission from + the ALTO client to an authorized ALTO server. + + (5c) An authorized ALTO server knowingly forwards the + information it has received from the ALTO client to an + unauthorized party. + + + + +Kiesel, et al. Informational [Page 15] + +RFC 6708 ALTO Requirements September 2012 + + + (6) One or several collaborating (see case 5c) ALTO servers could + try to infer the application behavior or other user private data + by aggregating and correlating queries from one or more ALTO + clients, possibly over an extended period of time. + +5.2.2. Discussion of Information Disclosure Scenarios + + An ALTO server operator should consider: + + o Issue (1) may be addressed by the ALTO server operator choosing + the level of detail of the information to be populated into the + ALTO server and returned in the responses. For example, by + specifying a broader address range (i.e., a shorter prefix length) + than a group of hosts in question actually uses, an ALTO server + operator may control to some extent how much information about the + network topology is disclosed. Furthermore, access control + mechanisms for filtering ALTO responses according to the + authenticated ALTO client identity might be installed in the ALTO + server, although this might not be effective given the lack of + efficient mechanisms for addressing (2c) and (3), see below. + + o (2a) and (2b) may be addressed by authentication, access control, + and encryption schemes for the ALTO client protocol. However, + deployment of encryption schemes might not be effective given the + lack of efficient mechanisms for addressing (2c) and (3), see + below. + + o Straightforward authentication and encryption schemes will not + help solving (2c) and (3), and there is no other simple and + efficient mechanism known. The cost of complex approaches, e.g., + based on Digital Rights Management (DRM), might easily outweigh + the benefits of the whole ALTO solution; therefore, they are not + considered as a viable solution. That is, ALTO server operators + must be aware that (2c) and (3) cannot be prevented from + happening; therefore, they should feed only such data into an ALTO + server that they do not consider sensitive with respect to (2c) + and (3). + + A user of an ALTO client should consider: + + o Issue (4) can and needs to be addressed in several ways: If the + ALTO client is embedded in the resource consumer, the resource + consumer's IP address (or the "public" IP address of the outermost + NAT in front of the resource consumer) is disclosed to the ALTO + server as a matter of principle, because it is in the source + address fields of the IP headers. By using a proxy, the + disclosure of source addresses to the ALTO server can be avoided + at the cost of disclosing them to said proxy. If, in contrast, + + + +Kiesel, et al. Informational [Page 16] + +RFC 6708 ALTO Requirements September 2012 + + + the ALTO client is embedded in a third party (e.g., a resource + directory), which issues ALTO requests on behalf of resource + consumers, it is possible to hide the exact addresses of the + resource consumers from the ALTO server, e.g., by zeroing out or + randomizing the last few bits of IP addresses. However, there is + the potential side effect of yielding inaccurate results. + + The disclosure of candidate resource providers' addresses to the + ALTO server can be avoided by allowing ALTO clients to use the + target-independent query mode. In this mode of operation, guiding + information (e.g., "maps") is retrieved from the ALTO server and + used entirely locally by the ALTO client, i.e., without sending + host-location attributes of candidate resource providers to the + ALTO server. In the target-aware query mode, this issue can be + addressed by ALTO clients through obfuscating the identity of + candidate resource consumers, e.g., by specifying a broader + address range (i.e., a shorter prefix length) than a group of + hosts in question actually uses, or by zeroing out or randomizing + the last few bits of IP addresses. However, there is the + potential side effect of yielding inaccurate results. + + o (5a) may be addressed by mandating that the ALTO server discovery + procedure, as a whole, must be secure against spoofing. + + Note: Given that this document does not mandate a specific system + architecture, it is difficult to specify more details than that + the discovery procedure, as a whole, should be secure against + spoofing. There are many different architectural options, e.g., + have an insecure discovery mechanism and use server certificates + to later verify its response (cf. the DNS + HTTPS security model + widely used in the World Wide Web). Therefore, at this + requirements stage, it is not mandatory for the discovery + mechanism itself to be secure against spoofing attacks. + + o (5b) may be addressed by encryption schemes for the ALTO client + protocol. However, the effort vs. benefit should be evaluated for + any specific deployment scenario, while also considering the risks + and solution approaches for issues (4), (5c), and (6). + + o Straightforward authentication and encryption schemes will not + help solving (5c) and (6). However, potential risks can be + mitigated using the same approaches as used for issue (4), see + above. + + These insights are reflected in the requirements in this document. + + + + + + +Kiesel, et al. Informational [Page 17] + +RFC 6708 ALTO Requirements September 2012 + + +5.3. ALTO Server Discovery + + See discussion of (5a) above. + +5.4. Security Requirements + + For a set of specific security requirements, please refer to + Section 3.3 of this document. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic + Optimization (ALTO) Problem Statement", RFC 5693, + October 2009. + +6.2. Informative 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. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. + Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, + RFC 5382, October 2008. + + [RFC5706] Harrington, D., "Guidelines for Considering Operations and + Management of New Protocols and Protocol Extensions", + RFC 5706, November 2009. + + + + + + + + + + + + + + +Kiesel, et al. Informational [Page 18] + +RFC 6708 ALTO Requirements September 2012 + + +Appendix A. Contributors + + Early draft versions of this document were co-authored by Laird + Popkin. + +Appendix B. Acknowledgments + + The authors would like to thank Vijay K. Gurbani and Enrico Marocco + for fostering discussions that lead to the creation of this document, + and for giving valuable comments on it. + + The authors would like to thank the members of the P2PI and ALTO + mailing lists for contributions and feedback, in particular: Richard + Alimi, Jason Livingood, Michael Scharf, Nico Schwan, and Jan Seedorf. + + Laird Popkin and Y. Richard Yang are grateful to the many + contributions made by the members of the P4P working group and Yale + Laboratory of Networked Systems. The P4P working group is hosted by + DCIA. + + 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. Informational [Page 19] + +RFC 6708 ALTO Requirements September 2012 + + +Authors' Addresses + + Sebastian Kiesel (editor) + University of Stuttgart Computing Center + Networks and Communication Systems Department + Allmandring 30 + 70550 Stuttgart + Germany + + EMail: ietf-alto@skiesel.de + URI: http://www.rus.uni-stuttgart.de/nks/ + + + Stefano Previdi + Cisco Systems, Inc. + + EMail: sprevidi@cisco.com + + + Martin Stiemerling + NEC Laboratories Europe + + EMail: martin.stiemerling@neclab.eu + URI: http://ietf.stiemerling.org + + + Richard Woundy + Comcast Corporation + + EMail: Richard_Woundy@cable.comcast.com + + + Yang Richard Yang + Yale University + + EMail: yry@cs.yale.edu + + + + + + + + + + + + + + + +Kiesel, et al. Informational [Page 20] + |