RFC 6708

Application-Layer Traffic Optimization (ALTO) Requirements

📅 published September 2012, from ietf

RFC 6708: Application-Layer Traffic Optimization (ALTO) Requirements 🎀

Okay so this is RFC 6708, and it's called Application-Layer Traffic Optimization (ALTO) Requirements ✨. It came out in September 2012 and its category is Informational, so it's published for information and isn't a standards track spec 📚. The ISSN is 2070-1721.

The authors are S. Kiesel, Ed. (University of Stuttgart), S. Previdi (Cisco Systems, Inc.), M. Stiemerling (NEC Europe Ltd.), R. Woundy (Comcast Corporation), and Y. Yang (Yale University) 🫶. The title block doesn't list any RFCs that it obsoletes or updates 🦋.

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

Abstract 💖

Lots of internet apps are basically shopping for a resource that's sitting on several identical copies across different hosts 🛒. Peer-to-peer file sharing is the famous example, but it's definitely not the only one. ALTO is the helper that gives these apps guidance when they have to pick one or several hosts from a bunch of candidates that can all deliver the thing they want. That guidance shall be based on parameters that affect how well the data moves between the hosts, like topological distance 🗺️.

The endgame is better performance and Quality of Experience for the app, while using less of the network infrastructure underneath 🌈. This document lists out requirements for specifying, assessing, or comparing protocols and implementations 📋. Slay 💅.

Status of This Memo 🧚

This document is not an Internet Standards Track specification, so it's published just for informational purposes 🌸.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈.

Info about the current status of this document, any errata, and how to send feedback on it can be found at http://www.rfc-editor.org/info/rfc6708 🔗.

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. Please read these carefully, bestie, because 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 they're provided without warranty as described in the Simplified BSD License 💜.

1. Introduction 🦋

ALTO's motivation is described in the ALTO problem statement [RFC5693], so go check that out too 💅.

The goal of ALTO is to provide information that helps peer-to-peer (P2P) applications make better decisions about peer selection 🍓. ALTO can be useful for non-P2P apps too, though. For example, clients of client-server applications might use ALTO info to pick one of several servers or information replicas 🌈. Another example: ALTO information could be used to select a media relay that's needed for NAT traversal 🎀. These informed decisions are meant to improve performance or Quality of Experience in the application while reducing how much of the underlying network infrastructure gets used ✨.

It's usually difficult or even impossible for application entities to get this information some other way, like measuring between the peers of a P2P overlay. That's because it can be complicated, or because it's based on network topology information, network operational costs, or network policies that the network provider doesn't want to disclose in detail 🙈.

The functional entities that provide the ALTO service don't take part in the actual user-data transport. In other words, they don't implement functions for relaying user data 🧚. They can live on all kinds of physical nodes, like dedicated servers, auxiliary processes in routers, "trackers" or "super peers" of a P2P application, and so on 🫶.

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" are the ones this document uses, and they're to be interpreted as described in [RFC2119] 🔥.

2.2. ALTO Terminology 🌸

This document uses some ALTO-related terms that are all 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 Query, ALTO Response, ALTO Transaction, Local Traffic, Peering Traffic, Transit Traffic, Application Protocol, ALTO Client Protocol, and Provisioning Protocol 📚.

Plus, there are some extra terms we'll be using:

  • Host-Group Descriptor: This is information used to describe one or more Internet hosts (like the resource consumer that's looking for ALTO guidance, or one or more candidate resource providers) and where they sit in the network topology 🗺️. There can be several types of host-group descriptors, like a single IP address, an address prefix or address range that contains the host(s), or an Autonomous System (AS) number 🦋. Different types can give different levels of detail. Depending on the system architecture, that can affect how good the guidance ALTO can give is, whether recommendations can be aggregated, and how much privacy-sensitive info about users might be disclosed to additional parties 🙈.
  • Rating Criterion: This is the condition or relation that defines the "better" in "better-than-random peer selection", which is the ultimate goal of ALTO 💅. Examples include "host's Internet access is not subject to volume-based charging (flat rate)" or "low topological distance". Some rating criteria, like "low topological distance", need a reference point, such as "low topological distance from a given resource consumer" 🌈. That reference point can be described with a host-group descriptor ✨.
  • Host-Characteristics Attribute: These are properties of a host, other than the host-group descriptor 🧚. One or more rating criteria may be used to evaluate them. This info may be stored in an ALTO server and sent over an ALTO protocol 💜. One example is a data field showing whether a host's Internet access is subject to volume-based charging or not (flat rate) 🍓.
  • Target-Aware Query Mode: In this mode, an ALTO client does the ALTO query once the desired resource and a set of candidate resource providers are already known. That could be after Distributed Hash Table (DHT) lookups, queries to the resource directory, and so on 🎀. To do this, the ALTO client sends 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 using the indicated criteria or a default criterion. Then it sends back a list of these host-group descriptors to the ALTO client, sorted according to the rating criteria and/or enriched with host-characteristics attributes 🔥.
  • Target-Independent Query Mode: In this mode, ALTO queries happen in advance or periodically, so the client can get comprehensive guidance 🌈. The ALTO client says which host-characteristics attributes it wants in the query 🦋. The ALTO server answers with a list that shows, for all known host-group descriptors (possibly limited by the server's policies), the desired host-characteristics attributes 💖. These lists get cached locally and evaluated later, when a resource is about to be accessed ✨.

2.3. Architectural Framework for ALTO

okay so there are lots of ways to build ALTO 🏗️ and this doc is NOT picking a favourite. 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] has a figure that gives a high-level overview of how these components talk to each other 🦋

this document itemizes requirements for the following components: ALTO client protocols, ALTO server discovery mechanisms, host-group descriptors, rating criteria, and host-characteristics attributes. it also covers requirements for the overall architecture, especially around security and privacy 🔐

note that the detailed specification of these protocols and mechanisms is out of scope here 🙈 this doc doesn't even assume there'll be just one single spec for each component. what it does do is list 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 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 spec of an ALTO client protocol is out of scope here. this doc doesn't even assume there'll be only one single protocol spec 🙃 but it does enumerate 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 evaluating several resource providers or groups of resource providers, considering one or more rating criteria. those resource providers or groups 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 🗺️

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 💸

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 🧚

3.1.4. Placement of Entities and Timing of Transactions 🧚

okay so, where do ALTO clients actually live? there are a couple of vibes:

  • Embedded in the resource consumer 💖: the ALTO client sits inside the app that will eventually send and receive the data with the chosen resource provider(s). Picture the peer of a P2P app doing "query flooding" to discover resources, all very main character energy.
  • Embedded in a third party 🎀: the ALTO client lives in something like a resource directory and asks for preferences about potential resource providers on behalf of a resource consumer. Like, a tracker-based P2P app's tracker asking ALTO for guidance for all the peers that contact it. so iconic 🫶

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 so that the ALTO service can be provided by an entity that is not the operator of the underlying IP network. the service and the network don't have to be the same person 👑

Req. AR-21: An ALTO client protocol MUST be designed so 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 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. the negotiating part is non-negotiable bestie 💅

Req. AR-24: An ALTO client protocol SHOULD support version numbering, TTL (time-to-live) attributes, and/or similar mechanisms in ALTO transactions. The point is 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 can mean redistributing an ALTO response to other parties, or using the same ALTO information in a resource directory to improve the responses to different resource consumers within the lifetime of the ALTO response. The ALTO server SHOULD be able to express that:

  • no reuse should occur. 🙅‍♀️
  • 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. the server gets to be a little picky here 🍓
  • 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.
  • 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.
  • 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]. NATs are the gatekeepers of the internet and ALTO has to work through them 🔥

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. new features without breaking the old besties 🫶

Req. AR-28: An ALTO client protocol MUST include protocol versioning support, in order to clearly distinguish between incompatible versions of the protocol. no more mixing up the versions and having a whole meltdown 😭

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:

  • terminate the conversation with the client,
  • redirect the client to another ALTO server, and
  • 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:

  • terminate the conversation with the client,
  • redirect the client to another ALTO server, and
  • request that the client retry the query later.

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. no pressure to use them, servers can be dramatic in their own way 🙈

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. so basically this is the "how do I find the server" section and it's giving treasure hunt 🗺️💜

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. the NAT keeps trying to ruin everything and we keep saying no 💀

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. why reinvent the wheel when the wheel already exists 🛞💅

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: okay bestie, heads up 🎀 these requirements are about putting certain security mechanisms into the protocol spec itself. Whether it's worth turning them on in a given deployment depends on a threat analysis for that specific setup. For a breakdown of the info disclosure risks, check out Section 5.2 🔐

Req. AR-40: an ALTO client protocol spec MUST specify mechanisms for authenticating ALTO servers, or explain how to lean on the right mechanisms from the underlying protocol layers 🛡️

Req. AR-41: an ALTO client protocol spec MUST specify mechanisms for authenticating ALTO clients, or explain how to use appropriate mechanisms provided by the underlying protocol layers 🪪

Req. AR-42: an ALTO client protocol spec MUST specify mechanisms for encrypting messages, or explain how to use appropriate mechanisms provided by the underlying protocol layers 🔒

Req. AR-43: an ALTO client is not required to implement mechanisms, or to follow rules, that limit its ability to pass information it got from the ALTO server along to third parties. Redistribution is not locked down here 💅

Req. AR-44: an ALTO client protocol MUST support different levels of detail in queries and responses. The point is to protect user privacy, so that the operators of ALTO servers and other users of the same application can't work out sensitive stuff 🙈

Req. AR-45: an ALTO client protocol MAY include mechanisms the ALTO client can use when asking for guidance, so it can say which resource (for example, a content identifier) it wants to access. An ALTO server MUST still give adequate guidance even when the client would rather not name the resource, like when the data field is left empty. And the mechanism MUST be designed so the ALTO server operator can't easily figure out the resource identifier (say, a file name in P2P file sharing) when the client prefers not to specify it 🤫🧚

Req. AR-46: an ALTO client protocol spec MUST specify appropriate mechanisms for protecting the ALTO service against Denial-of-Service (DoS) attacks, or explain how to leverage appropriate mechanisms provided by the underlying protocol layers 🚨

4. IANA Considerations

Okay so this requirements doc doesn't make any IANA actions mandatory right now 📋 BUT future ALTO spec docs that try to meet these requirements might end up with IANA considerations of their own 🧚

5. Security Considerations

5.1. High-Level Security Considerations

If you want the high-level security picture for the ALTO service, look at the "Security Considerations" section of the ALTO problem statement document [RFC5693]. Go read it, it's the main event 💖

5.2. Information Disclosure Scenarios

Unwanted disclosure of information is one of the big concerns with 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 a way that violates user privacy. Think: who is swapping which files with whom in a P2P file-sharing app 👀 On top of that, a lot of network operators are worried about how much info about their network infrastructure might leak through ALTO. That includes topology info, the number of "premium customers," or utilization statistics 💅 This section breaks down information disclosure scenarios and the countermeasures you could use against them 🛡️

5.2.1. Classification of Information Disclosure Scenarios

These issues may be considered a risk for the operator of an ALTO server, depending on the deployment scenario:

  • (1) Excess disclosure of the ALTO server operator's data to an authorized ALTO client. The operator has to feed information into the server, such as tables mapping host-group descriptors to host-characteristics attributes, so the server can guide ALTO clients. Some operators might see the full set as confidential (like a detailed map of their network topology), and might want to disclose only a subset, or give ALTO clients somehow obfuscated info 🌸
  • (2) Disclosure of the ALTO server operator's data (for example, network topology information) to an unauthorized third party. There are three subcases here:
    • (2a) An ALTO server receives and answers queries 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 got 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, maybe several times over a long stretch, and then pass the responses around to each other (see also case 2c). By aggregating and correlating the ALTO responses, they could learn more than the ALTO server operator(s) meant to disclose 🕵️‍♀️

These issues may be considered a risk for the user of an ALTO client, depending on the deployment scenario:

  • (4) Disclosure of application behavior or other user private data to the (authorized) ALTO server. The operator of an ALTO server could infer application behavior (for example, content identifiers in P2P file-sharing apps, or lists of resource providers being considered for a connection) from the ALTO queries an ALTO client sends 😳
  • (5) Disclosure of 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, maybe because of a forged response from 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 got from the ALTO client to an unauthorized party.
  • (6) One or several collaborating (see case 5c) ALTO servers could try to infer 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 🔍✨

okay bestie, let's talk about who can see what 👀 An ALTO server operator should consider:

  • Issue (1) may be addressed by the ALTO server operator choosing the level of detail of the information that gets populated into the ALTO server and returned in responses 🎀 For example, by specifying a broader address range (i.e., a shorter prefix length) than the group of hosts actually uses, an ALTO server operator may control to some extent how much network topology info gets disclosed 🫣 Access control mechanisms that filter ALTO responses based on the authenticated ALTO client identity might also 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 💅
  • (2a) and (2b) may be addressed by authentication, access control, and encryption schemes for the ALTO client protocol 🔐 However, deploying encryption schemes might not be effective given the lack of efficient mechanisms for addressing (2c) and (3), see below 🙈
  • Straightforward authentication and encryption schemes will not help solve (2c) and (3), and there is no other simple and efficient mechanism known 😭 Complex approaches, e.g., based on Digital Rights Management (DRM), might easily cost more than the whole ALTO solution is worth, so they are not considered a viable solution 💀 That means ALTO server operators must be aware that (2c) and (3) cannot be prevented from happening, and so they should only feed 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:

  • 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 sits in the source address fields of the IP headers 👀 Using a proxy can avoid disclosing source addresses to the ALTO server, but the cost is disclosing them to said proxy instead 🦋

If, on the other hand, the ALTO client is embedded in a third party (e.g., a resource directory) that 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 🧚 Heads up though, 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 letting ALTO clients use the target-independent query mode 🌸 In this mode, 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 obfuscating the identity of candidate resource consumers, e.g., by specifying a broader address range (i.e., a shorter prefix length) than the group of hosts actually uses, or by zeroing out or randomizing the last few bits of IP addresses 🎀 Again, there is the potential side effect of yielding inaccurate results 🥲

  • (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. 🧠
  • (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) 🤓
  • Straightforward authentication and encryption schemes will not help solve (5c) and (6) 😩 Potential risks can still be mitigated using the same approaches as used for issue (4), see above 💖

These insights are reflected in the requirements in this document ✨🌈

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.

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 the discussions that led to 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 their contributions and feedback, in particular: Richard Alimi, Jason Livingood, Michael Scharf, Nico Schwan, and Jan Seedorf 🥹

Laird Popkin and Y. Richard Yang are grateful for the many contributions made by the members of the P4P working group and the 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 💜

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
📦 where this page comes from