RFC 7286

Application-Layer Traffic Optimization (ALTO) Server Discovery

📅 published November 2014, from ietf

RFC 7286: Application-Layer Traffic Optimization (ALTO) Server Discovery 🦋

okay so the title block first 💅 this one came from the Internet Engineering Task Force (IETF), and it's a Standards Track doc, so it's an actual spec, not just an idea 🔥 it was published in November 2014 (ISSN 2070-1721). the authors are S. Kiesel (University of Stuttgart), M. Stiemerling (NEC Europe Ltd.), N. Schwan (Thales Deutschland), M. Scharf (Alcatel-Lucent Bell Labs), and H. Song (Huawei) 👑 the header has no Obsoletes or Updates line, so it doesn't list anything it replaces or amends.

Abstract ✨

ALTO is all about helping apps pick the right host 🧚 when they have a bunch of candidates that can all provide the same resource. the catch is that ALTO is a client-server protocol, so before an ALTO client can ask for guidance, it has to find one or more ALTO servers first 🫶

this doc lays out how to do that discovery for resource-consumer-initiated ALTO server discovery, which works when the ALTO client lives inside the resource consumer 💜

Status of This Memo 🌸

this is an Internet Standards Track document 💅

it's a product of the IETF, which means it reflects the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7286 🎀

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. read those carefully, because they spell out your rights and restrictions for this doc 🫶 if you pull Code Components out of this doc, they have to include the Simplified BSD License text (see Section 4.e of the Trust Legal Provisions), and they come with no warranty, per the Simplified BSD License 💖

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology and Requirements Language . . . . . . . . . .   3
2.  ALTO Server Discovery Procedure Overview  . . . . . . . . . .   3
3.  ALTO Server Discovery Procedure Specification . . . . . . . .   4
  3.1.  Step 1: Retrieving the Domain Name  . . . . . . . . . . .   5
    3.1.1.  Step 1, Option 1: Local Configuration . . . . . . . .   5
    3.1.2.  Step 1, Option 2: DHCP  . . . . . . . . . . . . . . .   5
  3.2.  Step 2: U-NAPTR Resolution  . . . . . . . . . . . . . . .   6
4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   7
  4.1.  Issues with Home Gateways . . . . . . . . . . . . . . . .   7
  4.2.  Issues with Multihoming, Mobility, and Changing IP
        Addresses . . . . . . . . . . . . . . . . . . . . . . . .   7
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
  6.1.  Integrity of the ALTO Server's URI  . . . . . . . . . . .   9
  6.2.  Availability of the ALTO Server Discovery Procedure . . .  11
  6.3.  Confidentiality of the ALTO Server's URI  . . . . . . . .  11
  6.4.  Privacy for ALTO Clients  . . . . . . . . . . . . . . . .  12
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . . .  14
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction 💖

okay so ALTO's whole goal is giving apps guidance when they need to choose one or several hosts from a set of candidates that can all provide a desired resource [RFC5693] 🎀 ALTO is a client-server protocol (see requirement AR-1 in [RFC6708]), so an ALTO client needs to discover one or more ALTO servers that can guide this specific client before it can ask for anything ✨

this doc covers a discovery procedure for resource-consumer-initiated ALTO server discovery, which works when the ALTO client is embedded in the resource consumer 🧚 in other words, this doc meets requirement AR-32 in [RFC6708], and AR-33 is out of scope 🙈 the third-party version (AR-33, aka third-party ALTO server discovery) is covered in [3PDISC] 🌸

if you want to dig into where all the functional pieces of the overall ALTO architecture can go, [ALTO-DEPLOY] has a much deeper look 🔥

the ALTO protocol spec [RFC7285] is built on HTTP and expects discovery to give back the HTTP(S) URI of an ALTO server's Information Resource Directory (IRD) 💅 so this procedure mixes the Dynamic Host Configuration Protocol (DHCP) or local configuration with URI-enabled Naming Authority Pointer (U-NAPTR) resource records in the Domain Name System (DNS) to deliver those URIs 🫶

1.1. Terminology and Requirements Language

this doc uses the ALTO terminology defined in [RFC5693] 📚

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

2. ALTO Server Discovery Procedure Overview 🦋

so the ALTO protocol spec [RFC7285] expects the discovery procedure to hand back the HTTP(S) URI [RFC7230] of the ALTO server's IRD 🎀 and that IRD tells you what capabilities and services that server offers ✨

on hosts with more than one interface or address family (IPv4/v6), you have to run the ALTO server discovery procedure for every single interface and address family 💅 more details are in Section 4.2 🙈

the procedure happens in two steps 👑

  1. One DNS domain name gets retrieved for each combination of interface and address family. That can come from local configuration (like typing it into a menu or a config file) or from DHCP 🌸
  2. Those DNS domain names feed into U-NAPTR lookups, which give back one or more URIs. Extra DNS lookups might be needed to figure out the ALTO server's IP address(es) 💖

DHCP is the main way to get the DNS domain name 🫶 but sometimes DHCP isn't available or doesn't return anything useful, and sometimes a user just wants to override what DHCP would give them 🙈 in those cases, local configuration can be used ✨ so the algorithm checks for a locally configured override first, and only then tries DHCP 💅

the DNS domain name is usually (but not always) the domain the client is sitting in. a PTR lookup on the client's IP address (per [RFC1035], Section 3.5 for IPv4 or [RFC3596], Section 2.5 for IPv6) would give a similar name 🧚 BUT, because Network Address Translation (NAT) is everywhere, trying to get 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 [RFC3424]) 🚫💀

3. ALTO Server Discovery Procedure Specification 🎀

like we already covered in Section 2, the ALTO server discovery procedure runs for every address family on every interface the application is considering for talking to resource providers 🦋

first, the algorithm checks for a locally configured domain name, as covered in Section 3.1.1 🌈 if none was configured, it tries to get one from DHCP, as covered in Section 3.1.2 🫶 if it still can't find a domain name, the procedure has failed and ends with an appropriate error code 😭

if it finds one or more domain names, they get used as U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848] application-unique strings for a DNS lookup, as covered in Section 3.2 💖

3.1. Step 1: Retrieving the Domain Name 🌸

3.1.1. Step 1, Option 1: Local Configuration ✨

the preferred way to get a domain name tied to an interface's point of network attachment is DHCP (see Section 3.1.2) 💅 BUT sometimes there's no DHCP server around 🙈 and a user might want to use an ALTO service run by someone who isn't the operator of the underlying IP network 👑 so we let the user specify a DNS domain name, for example in a configuration file option 🧚 here's an example domain name:

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

3.1.2. Step 1, Option 2: DHCP 🦋

network operators can provide the domain name for service discovery inside an access network using DHCP 🌈

RFC 5986 [RFC5986] defines DHCP IPv4 and IPv6 access network domain name options that identify a domain name suitable for service discovery within the access network 💖 RFC 2132 [RFC2132] defines the DHCP IPv4 domain name option 📚 this one is less suitable, but it can still be useful if the RFC 5986 option isn't available 🙈

for IPv6, the ALTO server discovery procedure MUST try to retrieve DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). if that option can't 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 that one can't 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 does come back, it gets used as the input for the next step (U-NAPTR resolution) ✨ one example result could be:

example.net

3.2. Step 2: U-NAPTR Resolution

Okay so step 1 handed us one domain name, or ✨ if you've got multiple interfaces and/or you're dual-stack (IPv4 + IPv6), several of them 💖. Each one becomes a U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848] application unique string. Here's an example:

example.net

In step 2, the discovery procedure runs a U-NAPTR [RFC4848] lookup using the "ALTO" Application Service Tag and either the "http" or the "https" Application Protocol Tag 🦋. The goal is to get one or more URIs (protocol, host, and maybe path bits) pointing to the ALTO server's Information Resource Directory. Only HTTP and HTTPS URI schemes are defined in this doc, because the ALTO protocol spec covers access over those two and nothing else [RFC7285] 🌸. Also, the result can be any valid HTTP(S) URI, so keep your eyes open 👀.

Two U-NAPTR resource records that map "example.net" to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird" look like this, with the first one preferred 💅:

example.net.

IN NAPTR 100  10   "u"    "ALTO:https"
     "!.*!https://alto1.example.net/ird!"  ""

IN NAPTR 100  20   "u"    "ALTO:https"
     "!.*!https://alto2.example.net/ird!"  ""
If no ALTO-specific U-NAPTR records can be retrieved, the discovery procedure fails for that domain name (and the matching interface and IP protocol version). That's it, that's the whole failure era 💀.

If there are more domain names from Step 1, the procedure may run those U-NAPTR lookups right away 🚀. But before retrying a lookup that failed, a client MUST wait a time period that fits the error it hit (NXDOMAIN, timeout, etc.) ⏳. No spamming the DNS, bestie 🙅‍♀️.

4. Deployment Considerations 🏠

4.1. Issues with Home Gateways

Section 3.1.2 covers a DHCP option that lets the network operator of the ALTO client's network hand over a DNS domain name 🎀. But this only works if that DHCP option actually gets passed from the DHCP server to the host running the ALTO client, AND that host understands the option 🥺. This memo assumes the client can understand the proposed DHCP option. If it can't, the DHCP option is basically useless to it, and the client has to use the other proposed mechanisms instead 🫶.

Home gateways have some well-known DHCP drama 🍿. One issue: unknown DHCP options don't always get passed through some home gateways, so the option just vanishes 👻.

Another classic problem is home-gateway-specific DNS domain names that "override" the one the network operator gave you 💅. For example, a host behind a home gateway might get the domain name ".local" instead of "example.net". In general, that domain isn't usable for the server discovery procedure, unless a DNS server in the home gateway resolves the NAPTR lookup correctly (say, through a DNS split horizon approach) 🧚.

4.2. Issues with Multihoming, Mobility, and Changing IP Addresses

If the user only enters one (default) DNS domain name in the local configuration facility (see Section 3.1.1), then only one set of ALTO servers will ever get discovered, no matter how many interfaces or how much moving around they're doing 🚶‍♀️. Especially in mobile scenarios, that can go badly 😬.

The DHCP-based discovery method can find a different set of ALTO servers for each interface and address family (IPv4/IPv6) 🌈. Generally speaking, if a client wants to talk through one of its interfaces using a specific IP address family, it SHOULD query the ALTO server or servers discovered for that exact interface and address family 💜. How to pick an interface and IP address family, and how to compare results from different ALTO servers, is out of scope for this document 🙃.

Changing the IP address on an interface invalidates the result of the ALTO server discovery procedure 🚨. For example, if a mobile host's IP address changes because it moved, it is required to re-run the ALTO server discovery procedure without relying on any info it got earlier 🔄.

DNS on hosts with multiple interfaces has several challenges [RFC6418], and they can mess with ALTO server discovery too 🌀. If DNS resolution happens on the wrong interface, it can return an ALTO server that gives suboptimal or wrong guidance 😵. Finding the best ALTO server for multi-interfaced hosts is outside the scope of this document 🙅‍♀️.

When you're using a Virtual Private Network (VPN), there's usually no DHCP 🔐. So the user has to type the DNS domain name into the local configuration facility. For good optimization results, that should be a DNS domain name corresponding to the VPN concentrator, not to the user's current location 📍. Similar considerations apply to Mobile IP 📱.

5. IANA Considerations 📋

IANA has registered the following U-NAPTR [RFC4848] application service tag for ALTO 🎉:

Application Service Tag:  ALTO

Intended usage:  see [RFC5693]  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."

Defining Publication:  The specification contained within this
   document

Contact information:  The authors of this document

Author/Change controller:  The IESG

Interoperability considerations:  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.

Security considerations:  see Section 6 of this document.

Related publications:  This document specifies a procedure for
   discovering an HTTP or HTTPS URI of an ALTO server.  HTTP and
   HTTPS are specified in [RFC7230].  The HTTP(S)-based ALTO protocol
   is specified in [RFC7285].

Application Protocol Tag:  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.

6. Security Considerations 🔒

This is where things get SERIOUS, so pay attention 🚨. A high-level discussion of security issues related to ALTO is part of the ALTO problem statement [RFC5693]. A classification of unwanted information disclosure risks, plus specific security-related requirements, can be found in the ALTO requirements document [RFC6708] 📚.

The rest of this section is about security threats and protection mechanisms for the ALTO server discovery procedure itself 🕵️‍♀️. Once the ALTO server's URI has been discovered and the ALTO client and ALTO server start talking, the threats and protections in the ALTO protocol specification [RFC7285] apply 🫡.

6.1. Integrity of the ALTO Server's URI

Scenario Description

An attacker could compromise the ALTO server discovery procedure or infrastructure so that ALTO clients discover a "wrong" ALTO server URI 😱.

Threat Discussion

This is probably the most serious security concern related to ALTO server discovery 💀. The discovered "wrong" ALTO server might not be able to guide a given ALTO client at all, or it might give suboptimal or forged info. In the latter case, an attacker could try to use ALTO to mess with traffic distribution in the network or with application performance (see also Section 15.1. of [RFC7285]) 🌪️. Plus, a hostile ALTO server could threaten user privacy (see also Section 5.2.1, case (5a) in [RFC6708]) 👁️.

However, it should also be noted that if an attacker managed to compromise the DHCP and/or DNS servers used for ALTO server discovery (see below), (s)he could launch way more serious attacks, like redirecting various application protocols 🚩.

Protection Strategies and Mechanisms

The ALTO server discovery procedure has three building blocks (local configuration, DHCP, and DNS), and each one is a possible attack vector 🎯.

Users might follow "bad advice" that tricks them into manually configuring unsuitable ALTO servers. That problem can't be solved by technical means and is out of scope for this document 🙅‍♀️.

DHCP is pretty prone to attacks, because of the nature of the protocol 😩. As already mentioned, an attacker who can inject forged DHCP replies into the network may do way more harm than just configuring a wrong ALTO server. Best current practices for safely operating DHCP should be followed 🛡️.

Another threat is alteration of the DNS records used in U-NAPTR resolution 🧨. If an attacker can modify or spoof any of the DNS records used in the DDDS resolution, that URI could be replaced by a forged one. Applying DNS security (DNSSEC) [RFC4033] helps limit attacks that rely on modifying the DNS records used in U-NAPTR resolution 🔐. Security considerations specific to U-NAPTR are described in more detail in [RFC4848] 📖.

A related risk is impersonation of the ALTO server (i.e., attacks after the correct URI has been discovered) 🎭. This threat and its protection strategies are discussed in Section 15.1 of [RFC7285]. Note that if Transport Layer Security (TLS) is used to protect ALTO, the server certificate will contain the host name (CN). So only the host part of the HTTPS URI gets authenticated, which is the result of the ALTO server discovery procedure. The U-NAPTR based mapping within the discovery procedure needs to be secured as described above, e.g., by using DNSSEC 🔏.

Users and network operators can also keep an eye on application performance and network traffic patterns for poor performance or abnormalities, on top of the active protections 👀. If relying on a specific ALTO server's guidance doesn't do better than random outcomes, the use of that ALTO server may be discontinued (see also Section 15.2 of [RFC7285]) 🗑️.

6.2. Availability of the ALTO Server Discovery Procedure

Scenario Description

An attacker could compromise the ALTO server discovery procedure or infrastructure so that ALTO clients can't discover any ALTO server at all 😭.

Threat Discussion

If no ALTO server can be discovered (even though a suitable one exists), applications have to make their decisions without ALTO guidance 🫠. ALTO could be temporarily unavailable for lots of reasons, so applications must be prepared for that 🧯. Just know that the resulting application performance and traffic distribution will look like a deployment scenario without ALTO at all 📉.

Protection Strategies and Mechanisms

Operators should follow best current practices to secure their DHCP, DNS, and ALTO servers (see Section 15.5 of [RFC7285]) against Denial-of-Service (DoS) attacks 🏰💖.

6.3. Confidentiality of the ALTO Server's URI

Scenario Description 👀 Okay so the spooky scenario here is that an unauthorized party could run the ALTO server discovery procedure, or sneak in and intercept discovery messages between an authorized ALTO client and the DHCP and DNS servers, just to learn the ALTO server's URI. 😳

Threat Discussion 💅 In the ALTO use cases from the ALTO problem statement [RFC5693] and/or the stuff discussed in the ALTO working group, the ALTO server's URI as such has always been treated as public info that doesn't need confidentiality protection. Lowkey no drama here 🌸

Protection Strategies and Mechanisms 🎀 No protection mechanisms for this scenario have been provided, because it hasn't been identified as a relevant threat. BUT if a new use case shows up that needs this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly. Periodt 🫶

6.4. Privacy for ALTO Clients

Scenario Description 🕵️‍♀️ An unauthorized party could intercept discovery messages between an ALTO client and the DHCP and DNS servers, and that way figure out that the ALTO client uses (or at least tries to use) the ALTO service. Not iconic of them 😭

Threat Discussion 🦋 In the ALTO use cases from the ALTO problem statement [RFC5693] and/or the ALTO working group discussions, this scenario has not been identified as a relevant threat. Easy pass ✨

Protection Strategies and Mechanisms 🌈 Again, no protection mechanisms for this scenario have been provided, since it hasn't been identified as a relevant threat. However, if a new use case comes along that needs this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly. Stay alert, bestie 💜

7. References ✨

7.1. Normative References 📚

7.2. Informative References 🧠

Acknowledgments 🫶

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

Contributors 🌸

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

Authors' Addresses 💌

Sebastian Kiesel
University of Stuttgart Information Center
Networks and Communication Systems Department
Allmandring 30
Stuttgart  70550
Germany

EMail: ietf-alto@skiesel.de
URI:   http://www.rus.uni-stuttgart.de/nks/
Martin Stiemerling
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg  69115
Germany

Phone: +49 6221 4342 113
EMail: mls.ietf@gmail.com
URI:   http://ietf.stiemerling.org
Nico Schwan
Thales Deutschland
Thalesplatz 1
Ditzingen  71254
Germany

EMail: ietf@nico-schwan.de
Michael Scharf
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart  70435
Germany

EMail: michael.scharf@alcatel-lucent.com
Haibin Song
Huawei

EMail: haibin.song@huawei.com

That's the whole thing, bestie! 🌈✨ We made it through the entire RFC 7286 spec, and you now know more about ALTO server discovery than most people ever will. Iconic 💅👑

📦 where this page comes from