< draft-ietf-alto-xdom-disc-04.txt   draft-ietf-alto-xdom-disc-05.txt >
ALTO S. Kiesel ALTO S. Kiesel
Internet-Draft University of Stuttgart Internet-Draft University of Stuttgart
Intended status: Standards Track M. Stiemerling Intended status: Standards Track M. Stiemerling
Expires: May 18, 2019 H-DA Expires: January 6, 2020 H-DA
November 14, 2018 July 5, 2019
Application Layer Traffic Optimization (ALTO) Cross-Domain Server Application Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery Discovery
draft-ietf-alto-xdom-disc-04 draft-ietf-alto-xdom-disc-05
Abstract Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource. ALTO is realized by a client-server protocol. Before an resource. ALTO is realized by a client-server protocol. Before an
ALTO client can ask for guidance it needs to discover one or more ALTO client can ask for guidance it needs to discover one or more
ALTO servers that can provide suitable guidance. ALTO servers that can provide suitable guidance.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 18, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview on the ALTO Cross-Domain Server Discovery 2. ALTO Cross-Domain Server Discovery Procedure: Overview . . . . 5
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. ALTO Cross-Domain Server Discovery Procedure: Specification . 6
3. ALTO Cross-Domain Server Discovery Procedure Specification . . 6
3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 6 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7
3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 7 3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 8
3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 8 3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 9
3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10
4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 10 4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 11
4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 10 4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 11
4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 11 4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 12
4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 11 4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 12
4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11 4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 12
4.5. Summary and Further Extensions . . . . . . . . . . . . . . 13 4.5. Summary and Further Extensions . . . . . . . . . . . . . . 14
5. Implementation, Deployment, and Operational Considerations . . 14 5. Implementation, Deployment, and Operational Considerations . . 15
5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 14 5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 15
5.2. Deployment Considerations for Network Operators . . . . . 15 5.2. Considerations for Network Operators . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 16 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 19
6.2. Availability of the ALTO Server Discovery Procedure . . . 17 6.2. Availability of the ALTO Server Discovery Procedure . . . 20
6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 18 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 21
6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 18 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Solution Approaches for Partitioned ALTO Knowledge . 22 Appendix A. Solution Approaches for Partitioned ALTO Knowledge . 27
A.1. Classification of Solution Approaches . . . . . . . . . . 22 A.1. Classification of Solution Approaches . . . . . . . . . . 27
A.2. Discussion of Solution Approaches . . . . . . . . . . . . 23 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 28
A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 23 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 28
A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 24 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 29
A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 24 A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 29
Appendix B. Requirements for ALTO Cross-Domain Server Appendix B. Requirements for Cross-Domain Server Discovery . . . 30
Discovery . . . . . . . . . . . . . . . . . . . . . . 25 B.1. Discovery Client Application Programming Interface . . . . 30
B.1. Discovery Client Application Programming Interface . . . . 25 B.2. Data Storage and Authority Requirements . . . . . . . . . 30
B.2. Data Storage and Authority Requirements . . . . . . . . . 25 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 30
B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 25 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 31
B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 26 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 31
B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 26 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 32
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 27 C.1. A generic Tracker-based Peer-to-Peer Application . . . . . 32
C.1. Architectural Options . . . . . . . . . . . . . . . . . . 27 C.2. Architectural Options for Placing the ALTO Client . . . . 33
C.2. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 30 C.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36
C.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 32 C.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix D. Contributors List and Acknowledgments . . . . . . . . 37 Appendix D. Contributors List and Acknowledgments . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource [RFC5693]. ALTO is realized by an HTTP-based client-server resource [RFC5693]. ALTO is realized by an HTTP-based client-server
protocol [RFC7285], which can be used in various scenarios [RFC7971]. protocol [RFC7285], which can be used in various scenarios [RFC7971].
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
skipping to change at page 4, line 41 skipping to change at page 4, line 41
client to a server that has more accurate information or forwarding client to a server that has more accurate information or forwarding
the request to it on behalf of the client, have been proposed and the request to it on behalf of the client, have been proposed and
analyzed (see Appendix A), but none has been specified so far. analyzed (see Appendix A), but none has been specified so far.
Section 3 of this document specifies the "ALTO Cross-Domain Server Section 3 of this document specifies the "ALTO Cross-Domain Server
Discovery Procedure" for client-side usage in these scenarios. An Discovery Procedure" for client-side usage in these scenarios. An
ALTO client that wants to send an ALTO query related to a specific IP ALTO client that wants to send an ALTO query related to a specific IP
address or prefix X, may call this procedure with X as a paramenter. address or prefix X, may call this procedure with X as a paramenter.
It will use Domain Name System (DNS) lookups to find of one ore more It will use Domain Name System (DNS) lookups to find of one ore more
ALTO servers that can provide a competent answer. The above wording ALTO servers that can provide a competent answer. The above wording
"related to" was intentionally kept somewhat vague, as the exact "related to" was intentionally kept somewhat unspecific, as the exact
semantics depends on the ALTO service to be used; see Section 4. semantics depends on the ALTO service to be used; see Section 4.
Those who are in control of the "reverse DNS" for a given IP address Those who are in control of the "reverse DNS" for a given IP address
or prefix (i.e., the corresponding subdomain of in-addr.arpa. or or prefix (i.e., the corresponding subdomain of in-addr.arpa. or
ip6.arpa.) - typically an Internet Service Provider (ISP), a ip6.arpa.) - typically an Internet Service Provider (ISP), a
corporate IT department, or a university's computing center - may add corporate IT department, or a university's computing center - may add
resource records to the DNS that point to one or more relevant ALTO resource records to the DNS that point to one or more relevant ALTO
server(s). In many cases, it may be an ALTO server run by that ISP server(s). In many cases, it may be an ALTO server run by that ISP
or IT department, as they naturally have good insight into routing or IT department, as they naturally have good insight into routing
costs from and to their networks. However, they may also refer to an costs from and to their networks. However, they may also refer to an
ALTO server provided by someone else, e.g., their upstream ISP. ALTO server provided by someone else, e.g., their upstream ISP.
2. Overview on the ALTO Cross-Domain Server Discovery Procedure 2. ALTO Cross-Domain Server Discovery Procedure: Overview
This section gives a non-normative overview on the ALTO Cross-Domain
Server Discovery Procedure. The detailed specification will follow
in the next section.
This procedure was inspired by the "Location Information Server (LIS) This procedure was inspired by the "Location Information Server (LIS)
Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses
parts of the basic ALTO Server Discovery Procedure [RFC7286]. parts of the basic ALTO Server Discovery Procedure [RFC7286].
The basic idea is to use the Domain Name System (DNS), more The basic idea is to use the Domain Name System (DNS), more
specifically the "in-addr.arpa." or "ip6.arpa." trees, which are specifically the "in-addr.arpa." or "ip6.arpa." trees, which are
mostly used for "reverse mapping" of IP addresses to host names by mostly used for "reverse mapping" of IP addresses to host names by
means of PTR resource records. There, URI-enabled Naming Authority means of PTR resource records. There, URI-enabled Naming Authority
Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping
of domain names to Uniform Resource Identifiers (URIs), are installed of domain names to Uniform Resource Identifiers (URIs), are installed
as needed. Thereby, it is possible to store a mapping from an IP as needed. Thereby, it is possible to store a mapping from an IP
address or prefix to one or more ALTO server URIs in the DNS. address or prefix to one or more ALTO server URIs in the DNS.
The ALTO Cross-Domain Server Discovery Procedure is called with one The ALTO Cross-Domain Server Discovery Procedure is called with one
IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as
parameters. parameters.
The service parameter SHOULD always be set to "ALTO:https". However, The service parameter is usually always be set to "ALTO:https".
other parameter values MAY be used in some scenarios, e.g., However, other parameter values may be used in some scenarios, e.g.,
"ALTO:http" to search for a server that supports unencrypted "ALTO:http" to search for a server that supports unencrypted
transmission for debugging purposes, or other application protocol or transmission for debugging purposes, or other application protocol or
service tags if applicable. service tags if applicable.
The procedure performs DNS lookups and returns one or more URI(s) of The procedure performs DNS lookups and returns one or more URI(s) of
information resources related to said IP address or prefix, usually information resources related to said IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD, the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]). The U-NAPTR records also provide see Section 9 of [RFC7285]). The U-NAPTR records also provide
preference values, which should be considered if more than one URI is preference values, which should be considered if more than one URI is
returned. returned.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
strategies: First, an ALTO-specific U-NAPTR record is searched in the strategies: First, an ALTO-specific U-NAPTR record is searched in the
"reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
corresponding to the given IP address or prefix. If this lookup does corresponding to the given IP address or prefix. If this lookup does
not yield a usable result, the procedure tries further lookups with not yield a usable result, the procedure tries further lookups with
truncated domain names, which correspond to shorter prefix lengths. truncated domain names, which correspond to shorter prefix lengths.
The goal is to allow deployment scenarios that require fine-grained The goal is to allow deployment scenarios that require fine-grained
discovery on a per-IP basis, as well as large-scale scenarios where discovery on a per-IP basis, as well as large-scale scenarios where
discovery is to be enabled for a large number of IP addresses with a discovery is to be enabled for a large number of IP addresses with a
small number of additional DNS resource records. small number of additional DNS resource records.
3. ALTO Cross-Domain Server Discovery Procedure Specification 3. ALTO Cross-Domain Server Discovery Procedure: Specification
3.1. Interface 3.1. Interface
The procedure specified in this document takes two parameters, X and The procedure specified in this document takes two parameters, X and
SP, where X is an IP address or prefix and SP is a U-NAPTR Service SP, where X is an IP address or prefix and SP is a U-NAPTR Service
Parameter. Parameter.
The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR
notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for
IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". IPv6). Consequently, the address type AT is either "IPv4" or "IPv6".
In both cases, X consists of an IP address A and a prefix length L. In both cases, X consists of an IP address A and a prefix length L.
For AT=IPv4, it holds: 0 <= L <= 32 and for AT=IPv6, it holds: From the definition of IPv4 and IPv6 it follows that syntactically
0 <= L <= 128. valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128
when AT=IPv6. However, not all syntactically valid values of L are
actually supported by this procedure - Step 1 (see below) will check
for unsupported values and report an error if neccessary.
For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0 For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0
and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6, and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6,
A=2001:0DB8::20 and L=128. A=2001:0DB8::20 and L=128.
In the intended usage scenario, the procedure SHOULD always be called In the intended usage scenario, the procedure is normally always
with the parameter SP set to "ALTO:https". However, for general called with the parameter SP set to "ALTO:https". However, for
applicabiliy and in order to support future extensions, the procedure general applicabiliy and in order to support future extensions, the
MUST support being called with any valid U-NAPTR Service Parameter procedure MUST support being called with any valid U-NAPTR Service
(see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Service Parameter (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR
Parameters and Section 5. of the same document for information about Service Parameters and Section 5. of the same document for
the IANA registries). information about the IANA registries).
The procedure performs DNS lookups and returns one or more URI(s) of The procedure performs DNS lookups and returns one or more URI(s) of
information resources related to that IP address or prefix, usually information resources related to that IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD, the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]). For each URI, it also returns order and see Section 9 of [RFC7285]). For each URI, it also returns order and
preference values (see Section 4.1 of [RFC3403]), which should be preference values (see Section 4.1 of [RFC3403]), which should be
considered if more than one URI is returned. considered if more than one URI is returned.
During execution of this procedure, various error conditions may During execution of this procedure, various error conditions may
occur and have to be reported to the caller; see Section 3.5. occur and have to be reported to the caller; see Section 3.5.
For the remainder of the document, we use the following notation for For the remainder of the document, we use the following notation for
calling the ALTO Cross-Domain Server Discovery Procedure: calling the ALTO Cross-Domain Server Discovery Procedure:
IRD_URIS_X = XDOMDISC(X,"ALTO:https") IRD_URIS_X = XDOMDISC(X,"ALTO:https")
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
First, the procedure checks the prefix length L for unsupported First, the procedure checks the prefix length L for unsupported
values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the
procedure aborts and indicates an "invalid prefix length" error to procedure aborts and indicates an "unsupported prefix length" error
the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts to the caller. Similarly, if AT=IPv6 and L < 32, the procedure
and indicates an "invalid prefix length" error to the caller. aborts and indicates an "unsupported prefix length" error to the
Otherwise, the procedure continues. caller. Otherwise, the procedure continues.
If AT=IPv4, a domain name R32 is constructed according to the rules If AT=IPv4, the procedure will then produce a DNS domain name, which
specified in Section 3.5 of [RFC1035] and it is rooted in the special will be referred to as R32. This domain name is constructed
domain "IN-ADDR.ARPA.". according to the rules specified in Section 3.5 of [RFC1035] and it
is rooted in the special domain "IN-ADDR.ARPA.".
For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.". For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.".
If AT=IPv6, the domain name R128 is constructed according to the If AT=IPv6, a domain name. which will be called R128, is constructed
rules specified in Section 2.5 of [RFC3596] and the special domain according to the rules specified in Section 2.5 of [RFC3596] and the
"IP6.ARPA." is used. special domain "IP6.ARPA." is used.
For example (note: a line break was added after the second line), For example (note: a line break was added after the second line),
A = 2001:0DB8::20 yields A = 2001:0DB8::20 yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." 1.0.0.2.IP6.ARPA."
3.3. Step 2: Prepare Shortened Domain Names 3.3. Step 2: Prepare Shortened Domain Names
For this step, an auxiliary function "skip" is defined as follows: For this step, an auxiliary function "skip" is defined as follows:
skip(str,n) will skip all characters in the string str, up to and skip(str,n) will skip all characters in the string str, up to and
including the n-th dot, and return the remaining part of str. For including the n-th dot, and return the remaining part of str. For
example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.". example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".
If AT=IPv4, the following additional domain names are generated from If AT=IPv4, the following additional domain names are generated from
the result of the previous step: R24=skip(R32,1), R16=skip(R32,2), the result of the previous step:
and R8=skip(R32,3). Removing one label from a domain name (i.e., one
number of the "dotted quad notation") corresponds to shortening the R24=skip(R32,1),
prefix length by 8 bits.
R16=skip(R32,2), and
R8=skip(R32,3).
Removing one label from a domain name (i.e., one number of the
"dotted quad notation") corresponds to shortening the prefix length
by 8 bits.
For example, R32="3.100.51.198.IN-ADDR.ARPA." yields For example, R32="3.100.51.198.IN-ADDR.ARPA." yields
R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and
R8="198.IN-ADDR.ARPA.". R8="198.IN-ADDR.ARPA.".
If AT=IPv6, the following additional domain names are generated from If AT=IPv6, the following additional domain names are generated from
the result of the previous step: R64=skip(R128,16), the result of the previous step:
R56=skip(R128,18), R48=skip(R128,20), and R32=skip(R128,24).
R64=skip(R128,16),
R56=skip(R128,18),
R48=skip(R128,20),
R40=skip(R128,22), and
R32=skip(R128,24).
Removing one label from a domain name (i.e., one hex digit) Removing one label from a domain name (i.e., one hex digit)
corresponds to shortening the prefix length by 4 bits. corresponds to shortening the prefix length by 4 bits.
For example (note: a line break was added after the first line), For example (note: a line break was added after the first line),
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." yields 1.0.0.2.IP6.ARPA." yields
R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA." R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.".
3.4. Step 3: Perform DNS U-NAPTR lookups 3.4. Step 3: Perform DNS U-NAPTR lookups
The address type of A and the prefix length are matched against the The address type and the prefix length of X are matched against the
first and the second column of the following table, respectively: first and the second column of the following table, respectively:
+------------+------------+------------+----------------------------+ +------------+------------+------------+----------------------------+
| 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type AT | Length L | 1st lookup | lookups in that order | | Type AT | Length L | 1st lookup | lookups in that order |
+------------+------------+------------+----------------------------+ +------------+------------+------------+----------------------------+
| IPv4 | 32 | R32 | R24, R16, R8 | | IPv4 | 32 | R32 | R24, R16, R8 |
| IPv4 | 24 .. 31 | R24 | R16, R8 | | IPv4 | 24 .. 31 | R24 | R16, R8 |
| IPv4 | 16 .. 23 | R16 | R8 | | IPv4 | 16 .. 23 | R16 | R8 |
| IPv4 | 8 .. 15 | R8 | (none) | | IPv4 | 8 .. 15 | R8 | (none) |
| IPv4 | 0 .. 7 | (none, abort: invalid prefix length L) | | IPv4 | 0 .. 7 | (none, abort: unsupported prefix length)|
+------------+------------+------------+----------------------------+ +------------+------------+------------+----------------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R32 | | IPv6 | 128 | R128 | R64, R56, R48, R40, R32 |
| IPv6 | 64 (..127) | R64 | R56, R48, R32 | | IPv6 | 64 (..127) | R64 | R56, R48, R40, R32 |
| IPv6 | 56 .. 63 | R56 | R48, R32 | | IPv6 | 56 .. 63 | R56 | R48, R40, R32 |
| IPv6 | 48 .. 55 | R48 | R32 | | IPv6 | 48 .. 55 | R48 | R40, R32 |
| IPv6 | 32 .. 47 | R32 | (none) | | IPv6 | 40 .. 47 | R40 | R32 |
| IPv6 | 0 .. 31 | (none, abort: invalid prefix length L) | | IPv6 | 32 .. 39 | R32 | (none) |
| IPv6 | 0 .. 31 | (none, abort: unsupported prefix length)|
+------------+------------+------------+----------------------------+ +------------+------------+------------+----------------------------+
Then, the domain name given in the 3rd column and the U-NAPTR Service Then, the domain name given in the 3rd column and the U-NAPTR Service
Parameter SP the procedure was called with (usually "ALTO:https") Parameter SP the procedure was called with (usually "ALTO:https")
MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one
or more URIs (indicating protocol, host, and possibly path elements) or more URIs (indicating protocol, host, and possibly path elements)
for the ALTO server's Information Resource Directory (IRD). If such for the ALTO server's Information Resource Directory (IRD). If such
URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure
returns that information to the caller and terminates successfully. returns that information to the caller and terminates successfully.
skipping to change at page 9, line 16 skipping to change at page 10, line 16
The ALTO Cross-Domain Server Discovery Procedure may fail for several The ALTO Cross-Domain Server Discovery Procedure may fail for several
reasons. reasons.
If the procedure is called with syntactically invalid parameters or If the procedure is called with syntactically invalid parameters or
unsupported parameter values (in particular the prefix length L, see unsupported parameter values (in particular the prefix length L, see
Section 3.2), the procedure aborts, no URI list will be returned and Section 3.2), the procedure aborts, no URI list will be returned and
the error has to be reported to the caller. the error has to be reported to the caller.
The procedure performs one or more DNS lookups in a well-defined The procedure performs one or more DNS lookups in a well-defined
order (corresponding to descending prefix lenghts, see Section 3.4), order (corresponding to descending prefix lengths, see Section 3.4),
until one produces a usable result. Each of these DNS lookups might until one produces a usable result. Each of these DNS lookups might
not produce a usable result, either due to a normal condition (e.g., not produce a usable result, either due to a normal condition (e.g.,
domain name exists, but no ALTO-specific NAPTR resource records are domain name exists, but no ALTO-specific NAPTR resource records are
associated with it), a permanent error (e.g., non-existent domain associated with it), a permanent error (e.g., non-existent domain
name), or due to a temporary error (e.g., timeout). In all three name), or due to a temporary error (e.g., timeout). In all three
cases, and as long as there are further domain names that can be cases, and as long as there are further domain names that can be
looked up, the procedure SHOULD immediately try to lookup the next looked up, the procedure SHOULD immediately try to lookup the next
domain name (from column 4 in the table given in Section 3.4). Only domain name (from column 4 in the table given in Section 3.4). Only
after all domain names have been tried at least once, the procedure after all domain names have been tried at least once, the procedure
MAY retry those domain names that had caused temporary lookup errors. MAY retry those domain names that had caused temporary lookup errors.
skipping to change at page 10, line 35 skipping to change at page 11, line 35
Service. However, for the sake of completeness, possible interaction Service. However, for the sake of completeness, possible interaction
with all four services is discussed below. Extension documents may with all four services is discussed below. Extension documents may
specify further information resources; however, these are out of specify further information resources; however, these are out of
scope of this document. scope of this document.
4.1. Network and Cost Map Service 4.1. Network and Cost Map Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 3) for an IP address or prefix "X" Procedure (as specified in Section 3) for an IP address or prefix "X"
and get a list of one or more IRD URI(s), including order and and get a list of one or more IRD URI(s), including order and
preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s)
IRD(s) will always contain a network and a cost map, as these are referenced by these URI(s) will always contain a network and a cost
mandatory information resources (see Section 11.2 of [RFC7285]). map, as these are mandatory information resources (see Section 11.2
However, the cost matrix may be very sparse. If, according to the of [RFC7285]). However, the cost matrix may be very sparse. If,
network map, PID_X is the PID that contains the IP address or prefix according to the network map, PID_X is the PID that contains the IP
X, and PID_1, PID_2, PID_3, ... are other PIDS, the cost map may look address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDS, the
like this: cost map may look like this:
From \ To PID_1 PID_2 PID_X PID_3 From \ To PID_1 PID_2 PID_X PID_3
------+----------------------------------- ------+-----------------------------------
PID_1 | 92 PID_1 | 92
PID_2 | 6 PID_2 | 6
PID_X | 46 3 1 19 PID_X | 46 3 1 19
PID_3 | 38 PID_3 | 38
In this example, all cells outside column "X" and row "X" are In this example, all cells outside column "X" and row "X" are
unspecified. A cost map with this structure contains the same unspecified. A cost map with this structure contains the same
information as what could be retrieved using the ECS, cases 1 and 2 information as what could be retrieved using the Endpoint Cost
in Section 4.4. Accessing cells outside column "X" and row "X" may Service, cases 1 and 2 in Section 4.4. Accessing cells that are
not yield useful results. neither in column "X" nor row "X" may not yield useful results.
Trying to assemble a more densely populated cost map from several Trying to assemble a more densely populated cost map from several
cost maps with this very sparse structure may be a non-trivial task, cost maps with this very sparse structure may be a non-trivial task,
as different ALTO servers may use different PID definitions (i.e., as different ALTO servers may use different PID definitions (i.e.,
network maps) and incompatible scales for the costs, in particular network maps) and incompatible scales for the costs, in particular
for the "routingcost" metric. for the "routingcost" metric.
4.2. Map-Filtering Service 4.2. Map-Filtering Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
skipping to change at page 14, line 11 skipping to change at page 15, line 11
corresponding information resources) needs to be investigated and corresponding information resources) needs to be investigated and
defined once such further ALTO services are specified in an extension defined once such further ALTO services are specified in an extension
document. document.
5. Implementation, Deployment, and Operational Considerations 5. Implementation, Deployment, and Operational Considerations
5.1. Considerations for ALTO Clients 5.1. Considerations for ALTO Clients
5.1.1. Resource Consumer Initiated Discovery 5.1.1. Resource Consumer Initiated Discovery
To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource Resource consumer initiated ALTO server discovery (c.f. ALTO
consumer initiated ALTO server discovery, can be seen as a special requirement AR-32 [RFC6708]) can be seen as a special case of cross-
case of cross-domain ALTO server discovery. To that end, an ALTO domain ALTO server discovery. To that end, an ALTO client embedded
client embedded in a resource consumer would have to figure out its in a resource consumer would have to perform the ALTO Cross-Domain
own "public" IP address and perform the procedures described in this Server Discovery Procedure with its own IP address as a parameter.
document on that address. However, due to the widespread deployment However, due to the widespread deployment of Network Address
of Network Address Translators (NAT), additional protocols and Translators (NAT), additional protocols and mechanisms such as STUN
mechanisms such as STUN [RFC5389] would be needed and considerations [RFC5389] are usually needed to detect the client's "public" IP
for UNSAF [RFC3424] apply. Therefore, using the procedures specified address, before it can be used as a parameter to the discovery
in this document for resource consumer based ALTO server discovery is procedure. Note that a different approach for resource consumer
generally NOT RECOMMENDED. Note that a less versatile yet simpler initiated ALTO server discovery, which is based on DHCP, is specified
approach for resource consumer initiated ALTO server discovery is in [RFC7286].
specified in [RFC7286].
5.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility 5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility
The procedure specified in this document can discover ALTO server The procedure specified in this document can discover ALTO server
URIs for a given IP address or prefix. The intention is, that a URIs for a given IP address or prefix. The intention is, that a
third party (e.g., a resource directory) that receives query messages third party (e.g., a resource directory) that receives query messages
from a resource consumer can use the source address in these messages from a resource consumer can use the source address in these messages
to discover suitable ALTO servers for this specific resource to discover suitable ALTO servers for this specific resource
consumer. consumer.
However, resource consumers (as defined in Section 2 of [RFC5693]) However, resource consumers (as defined in Section 2 of [RFC5693])
may reside on hosts with more than one IP address, e.g., due to may reside on hosts with more than one IP address, e.g., due to
skipping to change at page 14, line 52 skipping to change at page 15, line 51
If a resource consumer queries a resource directory for candidate If a resource consumer queries a resource directory for candidate
resource providers, the locally selected (and possibly en-route resource providers, the locally selected (and possibly en-route
translated) source address of the query message - as observed by the translated) source address of the query message - as observed by the
resource directory - will become the basis for the ALTO server resource directory - will become the basis for the ALTO server
discovery and the subsequent optimization of the resource directory's discovery and the subsequent optimization of the resource directory's
reply. If, however, the resource consumer then selects different reply. If, however, the resource consumer then selects different
source addresses to contact returned resource providers, the desired source addresses to contact returned resource providers, the desired
better-than-random "ALTO effect" may not occur. better-than-random "ALTO effect" may not occur.
Therefore, a dual stack or multihomed resource consumer SHOULD either One solution approach for this problem is, that a dual stack or
always use the same address for contacting the resource directory and multihomed resource consumer could always use the same address for
the resource providers, i.e., overriding the operating system's contacting the resource directory and all resource providers, thus
automatic source IP address selection, or use resource consumer based overriding the operating system's automatic source IP address
ALTO server discovery [RFC7286] to discover suitable ALTO servers for selection. For example, when using the BSD socket API, one could
every local address and then locally perform ALTO-influenced resource always bind() the socket to one of the local IP addresses before
consumer selection and source address selection. Similarly, resource trying to connect() to the resource directory or the resource
consumers on mobile hosts SHOULD query the resource directory again providers, respectively. Another solution approach is to perform
after a change of IP address, in order to get a list of candidate ALTO-influenced resource provider selection (and source address
resource providers that is optimized for the new IP address. selection) locally in the resource consumer, in addition to or
instead of performing it in the resource directory. See
Section 5.1.1 for a discussion how to discover ALTO servers for local
usage in the resource consumer.
5.2. Deployment Considerations for Network Operators Similarly, resource consumers on mobile hosts SHOULD query the
resource directory again after a change of IP address, in order to
get a list of candidate resource providers that is optimized for the
new IP address.
5.2.1. Separation of Interests 5.1.3. Interaction with Network Address Translation
We assume that if two organizations share parts of their DNS The ALTO Cross-Domain Server Discovery Procedure has been designed to
infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa. enable the ALTO-based optimization of applications such as large-
subdomains, they will also be able to operate a common ALTO server, scale overlay networks, that span - on the IP layer - multiple
which still may do redirections if desired or required by policies. adminstrative domains, possibly the whole Internet. Due to the
widespread usage of Network Address Translators (NAT) it may well be
that nodes of the overlay network (i.e., resource consumers or
resource providers) are located behind a NAT, maybe even behind
several cascaded NATs.
Note that the ALTO server discovery procedure is supposed to produce If a resource directory is located in the public Internet (i.e., not
only a first URI of an ALTO server that can give reasonable guidance behind a NAT) and if it receives a message from a resource consumer
to the client. An ALTO server can still return different results behind one or more NATs, the message's source address will be the
based on the client's address (or other identifying properties) or public IP address of the outermost NAT in front of the resource
redirect the client to another ALTO server using mechanisms of the consumer. The same applies if the resource directory is behind a
ALTO protocol (see Sect. 9 of [RFC7285]). different NAT than the resource consumer. The resource directory may
call the ALTO Cross-Domain Server Discovery Procedure with the
message's source address as a parameter. In effect, not the resource
consumer's (private) IP address, but the public IP address of the
outermost NAT in front of it will be used as a basis for ALTO-
optimization. This will work fine as long as the network behind the
NAT is not too big (e.g., if the NAT is in a residential gateway).
If a resource directory receives a message from a resource consumer
and the message's source address is a "private" IP address [RFC1918],
this may be a sign that both of them are behind the same NAT. An
invokation of the ALTO Cross-Domain Server Discovery Procedure with
this private address may be problematic, as this will only yield
usable results if a DNS "split horizon" and DNSSEC trust anchors are
configured correctly. In this situation it may be more advisable to
query an ALTO server that has been discovered using [RFC7286] or any
other local configuration. The interaction between intra-domain ALTO
for large private domains (e.g., behind a "carrier-grade NAT") and
cross-domain, Internet-wide optimization, is beyond the scope of this
document.
5.2. Considerations for Network Operators
5.2.1. Flexibility vs. Load on the DNS
The ALTO Cross-Domain Server Discovery Procedure, as specified in
Section 3, first produces a list of domain names (steps 1 and 2) and
then looks for relevant NAPTR records associated with these names,
until a useful result can be found (step 3). The number of candidate
domain names on this list is a compromise between flexibility when
installing NAPTR records and avoiding excess load on the DNS.
A single invocation of the ALTO Cross-Domain Server Discovery
Procedure, with an IPv6 address as a parameter, may cause up to, but
no more than, six DNS lookups for NAPTR records. For IPv4, the
maximum is four lookups. Should the load on the DNS infrastructure
caused by these lookups become a problem, one solution approach is to
actually populate the DNS with ALTO-specific NAPTR records. If such
records can be found for individual IP addresses (possibly installed
using a wildcarding mechanism in the name server) or for long
prefixes, the procedure will terminate successfully and not perform
lookups for shorter prefix lengths, thus reducing the total number of
DNS queries. Another approach for reducing the load on the DNS
infrastructure is to increase the TTL for caching negative answers.
On the other hand, the ALTO Cross-Domain Server Discovery Procedure
trying to lookup truncated domain names allows for efficient
configuration of large-scale scenarios, where discovery is to be
enabled for a large number of IP addresses with a small number of
additional DNS resource records. Note that expressly, it has not
been a design goal of this procedure to give clients a means to
understand the IP prefix delegation structure. Furthermore, this
specification does not assume or reccomend that prefix delegations
should preferrably occur at those prefix lengths that are used in
Step 2 of this procedure (see Section 3.3). A network operator that
uses, for example, an IPv4 /18 prefix and wants to install the NAPTR
records efficiently, could either install 64 NAPTR records (one for
each of the /24 prefixes contained within the /18 prefix), or they
could try to team up with the owners of the other fragments of the
enclosing /16 prefix, in order to run a common ALTO server to which
only one NAPTR would point.
5.2.2. BCP20 and missing delegations of the reverse DNS
RFC2317 [RFC2317], also known as BCP20, describes a way to delegate
the "reverse DNS" (i.e., subdomains of in-addr.arpa.) for IPv4
address ranges with fewer than 256 addresses (i.e., smaller than a
whole /24 prefix). The ALTO Cross-Domain Server Discovery procedure
is compatible with method.
In some deployment scenarios, e.g., residential Internet access,
where customers often dynamically receive a single IPv4 address
(and/or a small IPv6 address block) from a pool of addresses, ISPs
typically will not delegate the "reverse DNS" to their customers.
This practice makes it impossible for these customers to populate the
DNS with NAPTR resource records that point to an ALTO server of their
choice. Yet, the ISP may publish NAPTR resource records in the
"reverse DNS" for individual addresses or the whole address pool.
While ALTO is by no means technologically tied to BGP, it is
anticipated that BGP will be an important source of information for
ALTO and that the operator of the outermost BGP-enabled router will
have a strong incentive to publish a digest of their routing policies
and costs through ALTO. In contrast, an individual user or an
organization that has been assigned only a small address range (less
than a /24) will typically connect to the Internet using only a
single ISP, and they might not be interested in publishing their own
ALTO information. Consequently, they might wish to leave the
operation of an ALTO server up to their ISP. This ISP may populate
the subdomain of in-addr.arpa. that corresponds to the whole /24
prefix with the relevant NAPTR resource records, even if BCP20-style
delegations or no delegations at all are used.
6. Security Considerations 6. Security Considerations
A high-level discussion of security issues related to ALTO is part of A high-level discussion of security issues related to ALTO is part of
the ALTO problem statement [RFC5693]. A classification of unwanted the ALTO problem statement [RFC5693]. A classification of unwanted
information disclosure risks, as well as specific security-related information disclosure risks, as well as specific security-related
requirements can be found in the ALTO requirements document requirements can be found in the ALTO requirements document
[RFC6708]. [RFC6708].
The remainder of this section focuses on security threats and The remainder of this section focuses on security threats and
protection mechanisms for the cross-domain ALTO server discovery protection mechanisms for the cross-domain ALTO server discovery
procedure as such. Once the ALTO server's URI has been discovered procedure as such. Once the ALTO server's URI has been discovered
and the communication between the ALTO client and the ALTO server and the communication between the ALTO client and the ALTO server
starts, the security threats and protection mechanisms discussed in starts, the security threats and protection mechanisms discussed in
the ALTO protocol specification [RFC7285] apply. the ALTO protocol specification [RFC7285] apply.
6.1. Integrity of the ALTO Server's URI 6.1. Integrity of the ALTO Server's URI
Scenario Description Scenario Description
An attacker could compromise the ALTO server discovery procedure An attacker could compromise the ALTO server discovery procedure
or infrastructure in a way that ALTO clients would discover a or the underlying infrastructure in a way that ALTO clients would
"wrong" ALTO server URI. discover a "wrong" ALTO server URI.
Threat Discussion 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 give guidance to a given ALTO client at all, or it might
give suboptimal or forged information. In the latter case, an
attacker could try to use ALTO to affect the traffic distribution
in the network or the performance of applications (see also
Section 15.1. of [RFC7285]). Furthermore, 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 was able to
compromise the DNS infrastructure used for cross-domain ALTO
server discovery, (s)he could also launch significantly more
serious other attacks (e.g., redirecting various application
protocols).
Protection Strategies and Mechanisms
The cross-domain ALTO server discovery procedure relies on a The cross-domain ALTO server discovery procedure relies on a
series of DNS lookups. If an attacker was able to modify or spoof series of DNS lookups, in order to produce one or more URI(s). If
any of the DNS records, the resulting URI could be replaced by a an attacker was able to modify or spoof any of the DNS records,
forged URI. The application of DNS security (DNSSEC) [RFC4033] the resulting URI(s) could be replaced by forged URI(s). This is
provides a means to limit attacks that rely on modification of the probably the most serious security concern related to ALTO server
DNS records while in transit. Additional operational precautions discovery. The discovered "wrong" ALTO server might not be able
for safely operating the DNS infrastructure are required in order to give guidance to a given ALTO client at all, or it might give
to ensure that name servers do not sign forged (or otherwise suboptimal or forged information. In the latter case, an attacker
"wrong") resource records. Security considerations specific to could try to use ALTO to affect the traffic distribution in the
U-NAPTR are described in more detail in [RFC4848]. network or the performance of applications (see also Section 15.1.
of [RFC7285]). Furthermore, a hostile ALTO server could threaten
user privacy (see also Section 5.2.1, case (5a) in [RFC6708]).
A related risk is the impersonation of the ALTO server (i.e., Protection Strategies and Mechanisms
attacks after the correct URI has been discovered). This threat The application of DNS security (DNSSEC) [RFC4033] provides a
and protection strategies are discussed in Section 15.1 of means to detect and avert attacks that rely on modification of the
[RFC7285]. Note that if TLS is used to protect ALTO, the server DNS records while in transit. All implementations of the cross-
certificate will contain the host name (CN). Consequently, only domain ALTO server discovery procedure MUST support DNSSEC or be
the host part of the HTTPS URI will be authenticated, i.e., the able to use of such functionality provided by the underlying
result of the ALTO server discovery procedure. The DNS/U-NAPTR operating system. Network operators that publish U-NAPTR resource
based mapping within the cross-domain ALTO server discovery records to be used for the cross-domain ALTO server discovery
procedure needs to be secured as described above, e.g., by using procedure SHOULD use DNSSEC to protect their subdomains of in-
DNSSEC. addr.arpa. and/or ip6.arpa., respectively. Additional operational
precautions for safely operating the DNS infrastructure are
required in order to ensure that name servers do not sign forged
(or otherwise "wrong") resource records. Security considerations
specific to U-NAPTR are described in more detail in [RFC4848].
In addition to active protection mechanisms, users and network In addition to active protection mechanisms, users and network
operators can monitor application performance and network traffic operators can monitor application performance and network traffic
patterns for poor performance or abnormalities. If it turns out patterns for poor performance or abnormalities. If it turns out
that relying on the guidance of a specific ALTO server does not that relying on the guidance of a specific ALTO server does not
result in better-than-random results, the usage of the ALTO server result in better-than-random results, the usage of the ALTO server
may be discontinued (see also Section 15.2 of [RFC7285]). may be discontinued (see also Section 15.2 of [RFC7285]).
Note
The cross-domain ALTO server discovery procedure finishes
successfully when it has discovered one or more URI(s). Once an
ALTO server's URI has been discovered and the communication
between the ALTO client and the ALTO server starts, the security
threats and protection mechanisms discussed in the ALTO protocol
specification [RFC7285] apply.
A threat related to the one considered above is the impersonation
of an ALTO server after its correct URI has been discovered. This
threat and protection strategies are discussed in Section 15.1 of
[RFC7285]. The ALTO protocol's primary mechanism for protecting
authenticity and integrity (as well as confidentiality) is the use
of HTTPS-based transport, i.e., HTTP over TLS [RFC2818].
Typically, when the URI's host component is a host name, a further
DNS lookup is needed to map it to an IP address, before the
communication with the server can begin. This last DNS lookup
(for A or AAAA resource records) does not necessarily have to be
protected by DNSSEC, as the server identity checks specified in
[RFC2818] are able to detect DNS spoofing or similar attacks,
after the connection to the (possibly wrong) host has been
established. However, this validation, which is based on the
server certificate, can only protect the steps that occur after
the server URI has been discovered. It cannot detect attacks
against the authenticity of the U-NAPTR lookups needed for the
cross-domain ALTO server discovery procedure, and therefore, these
resource records have to be secured using DNSSEC.
6.2. Availability of the ALTO Server Discovery Procedure 6.2. Availability of the ALTO Server Discovery Procedure
Scenario Description Scenario Description
An attacker could compromise the cross-domain ALTO server An attacker could compromise the cross-domain ALTO server
discovery procedure or infrastructure in a way that ALTO clients discovery procedure or the underlying infrastructure in a way that
would not be able to discover any ALTO server. ALTO clients would not be able to discover any ALTO server.
Threat Discussion Threat Discussion
If no ALTO server can be discovered (although a suitable one If no ALTO server can be discovered (although a suitable one
exists) applications have to make their decisions without ALTO exists) applications have to make their decisions without ALTO
guidance. As ALTO could be temporarily unavailable for many guidance. As ALTO could be temporarily unavailable for many
reasons, applications must be prepared to do so. However, The reasons, applications must be prepared to do so. However, The
resulting application performance and traffic distribution will resulting application performance and traffic distribution will
correspond to a deployment scenario without ALTO. correspond to a deployment scenario without ALTO.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
skipping to change at page 18, line 29 skipping to change at page 21, line 42
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as No protection mechanisms for this scenario have been provided, as
it has not been identified as a relevant threat. However, if a it has not been identified as a relevant threat. However, if a
new use case is identified that requires this kind of protection, new use case is identified that requires this kind of protection,
the suitability of this ALTO server discovery procedure as well as the suitability of this ALTO server discovery procedure as well as
possible security extensions have to be re-evaluated thoroughly. possible security extensions have to be re-evaluated thoroughly.
6.4. Privacy for ALTO Clients 6.4. Privacy for ALTO Clients
Scenario Description Scenario Description
An unauthorized party could intercept messages between an ALTO An unauthorized party could eavesdrop on the messages between an
client and the DNS servers, and thereby find out the fact that ALTO client and the DNS servers, and thereby find out the fact
said ALTO client uses (or at least tries to use) the ALTO service that said ALTO client uses (or at least tries to use) the ALTO
in order to optimize traffic from/to a specific IP address. service in order to optimize traffic from/to a specific IP
address.
Threat Discussion Threat Discussion
In the ALTO use cases that have been described in the ALTO problem In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group, statement [RFC5693] and/or discussed in the ALTO working group,
this scenario has not been identified as a relevant threat. this scenario has not been identified as a relevant threat.
However, Pervasive Surveillance [RFC7624] and DNS Privacy
Considerations [RFC7626] have seen significant attention in the
Internet community in recent years.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means
it has not been identified as a relevant threat. However, if a for protecting confidentiality (and integrity) of DNS traffic
new use case is identified that requires this kind of protection, between a client (stub) and its recursive name servers, including
the suitability of this ALTO server discovery procedure as well as DNS queries and replies caused by the ALTO Cross-Domain Server
possible security extensions have to be re-evaluated thoroughly. Discovery Procedure.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002. RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/info/rfc3403>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", STD 88,
October 2003. RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007,
<https://www.rfc-editor.org/info/rfc4848>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.kiesel-alto-alto4alto] [I-D.kiesel-alto-alto4alto]
Kiesel, S., "Using ALTO for ALTO server selection", Kiesel, S., "Using ALTO for ALTO server selection",
draft-kiesel-alto-alto4alto-00 (work in progress), draft-kiesel-alto-alto4alto-00 (work in progress),
July 2010. July 2010.
[I-D.kiesel-alto-ip-based-srv-disc] [I-D.kiesel-alto-ip-based-srv-disc]
Kiesel, S. and R. Penno, "Application-Layer Traffic Kiesel, S. and R. Penno, "Application-Layer Traffic
Optimization (ALTO) Anycast Address", Optimization (ALTO) Anycast Address",
draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), draft-kiesel-alto-ip-based-srv-disc-03 (work in progress),
July 2014. July 2014.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
Self-Address Fixing (UNSAF) Across Network Address and E. Lear, "Address Allocation for Private Internets",
Translation", RFC 3424, November 2002. BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, Architecture", RFC 4291, DOI 10.17487/RFC4291,
February 2006, <https://www.rfc-editor.org/info/rfc4291>. February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632,
August 2006, <http://www.rfc-editor.org/info/rfc4632>. August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. DOI 10.17487/RFC5693, October 2009,
<https://www.rfc-editor.org/info/rfc5693>.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and [RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R.,
Y. Yang, "Application-Layer Traffic Optimization (ALTO) and Y. Yang, "Application-Layer Traffic Optimization
Requirements", RFC 6708, September 2012. (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708,
September 2012, <https://www.rfc-editor.org/info/rfc6708>.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server [RFC7216] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS", (LIS) Discovery Using IP Addresses and Reverse DNS",
RFC 7216, April 2014. RFC 7216, DOI 10.17487/RFC7216, April 2014,
<https://www.rfc-editor.org/info/rfc7216>.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
Traffic Optimization (ALTO) Protocol", RFC 7285, "Application-Layer Traffic Optimization (ALTO) Protocol",
September 2014. RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO) H. Song, "Application-Layer Traffic Optimization (ALTO)
Server Discovery", RFC 7286, June 2014. Server Discovery", RFC 7286, DOI 10.17487/RFC7286,
November 2014, <https://www.rfc-editor.org/info/rfc7286>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858,
May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO) S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971, DOI 10.17487/ Deployment Considerations", RFC 7971, DOI 10.17487/
RFC7971, October 2016, RFC7971, October 2016,
<http://www.rfc-editor.org/info/rfc7971>. <https://www.rfc-editor.org/info/rfc7971>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
Appendix A. Solution Approaches for Partitioned ALTO Knowledge Appendix A. Solution Approaches for Partitioned ALTO Knowledge
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
between an ALTO client and a single ALTO server. It is implicitly between an ALTO client and a single ALTO server. It is implicitly
assumed that this server can answer any query, possibly with some assumed that this server can answer any query, possibly with some
kind of default value if no exact data is known. No special kind of default value if no exact data is known. No special
provisions were made for the case that the ALTO information provisions were made for the case that the ALTO information
originates from multiple sources, which are possibly under the originates from multiple sources, which are possibly under the
control of different administrative entities (e.g., different ISPs) control of different administrative entities (e.g., different ISPs)
skipping to change at page 25, line 5 skipping to change at page 30, line 5
A.5. Relation to the ALTO Requirements A.5. Relation to the ALTO Requirements
During the design phase of the overall ALTO solution, two different During the design phase of the overall ALTO solution, two different
server discovery scenarios have been identified and documented in the server discovery scenarios have been identified and documented in the
ALTO requirements document [RFC6708]. The first scenario, documented ALTO requirements document [RFC6708]. The first scenario, documented
in Req. AR-32, can be supported using the discovery mechanisms in Req. AR-32, can be supported using the discovery mechanisms
specified in [RFC7286]. An alternative approach, based on IP anycast specified in [RFC7286]. An alternative approach, based on IP anycast
[I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This [I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This
document, in contrast, tries to address Req. AR-33. document, in contrast, tries to address Req. AR-33.
Appendix B. Requirements for ALTO Cross-Domain Server Discovery Appendix B. Requirements for Cross-Domain Server Discovery
This appendix itemizes requirements that have been collected before This appendix itemizes requirements that have been collected before
the design phase and that are reflected by the design of the ALTO the design phase and that are reflected by the design of the ALTO
Cross-Domain Server Discovery Procedure. Cross-Domain Server Discovery Procedure.
B.1. Discovery Client Application Programming Interface B.1. Discovery Client Application Programming Interface
The discovery client will be called through some kind of application The discovery client will be called through some kind of application
programming interface (API) and the parameters will be an IP address programming interface (API) and the parameters will be an IP address
and, for purposes of extensibility, a service identifier such as and, for purposes of extensibility, a service identifier such as
skipping to change at page 27, line 7 skipping to change at page 32, line 7
Internet. Internet.
B.5. Further Requirements B.5. Further Requirements
The ALTO cross domain server discovery cannot assume that the server The ALTO cross domain server discovery cannot assume that the server
discovery client and the server discovery responding entity are under discovery client and the server discovery responding entity are under
the same administrative control. the same administrative control.
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications Appendix C. ALTO and Tracker-based Peer-to-Peer Applications
This appendix illustrates one ALTO use case and shows that ALTO This appendix provides a complete example of using ALTO and the ALTO
Cross-Domain Server Discovery is beneficial in that scenario. Cross-Domain Server Discovery Procedure in one specific application
scenario, namely a tracker-based peer-to-peer application. First, in
subsection C.1, we introduce a generic model of such an application
and show why ALTO optimization is desirable. Then, in C.2, we
introduce two architectural options for integrating ALTO into the
tracker-based peer-to-peer application - one option is based on the
"regular" ALTO server discovery procedure [RFC7286], one relies on
the ALTO Cross-Domain Server Discovery Procedure. In C.3, a simple
mathematical model is used to show that the latter approach is
expected to yield significantly better optimization results. The
appendix concludes with subsection C.4, which details an exemplary
complete walk-through of the ALTO Cross-Domain Server Discovery
Procedure.
C.1. Architectural Options C.1. A generic Tracker-based Peer-to-Peer Application
The optimization of peer-to-peer (P2P) applications such as
BitTorrent was one of the first use cases that lead to the inception
of the IETF ALTO working group. Further use cases have been
identified as well, yet we will use this scenario to illustrate the
operation and usefulness of the ALTO Cross-Domain Server Discovery
Procedure.
For the remainder of this chapter we consider a generic, tracker-
based peer-to-peer file sharing application. The goal is the
dissemination of a large file, without using one large server with a
correspondingly high upload bandwidth. The file is split into
chunks. So-called "peers" assume the role of both a client and a
server. That is, they may request chunks from other peers and they
may serve the chunks they already possess to other peers at the same
time, thereby contributing their upload bandwidth. Peers that want
to share the same file participate in a "swarm". They use the peer-
to-peer protocol to inform each other about the availability of
chunks and to request and transfer chunks from one peer to another.
A swarm may consist of a very large number of peers. Consequently,
peers usually maintain logical connections only to a subset of all
peers in the swarm. If a new peer wants to join a swarm, it first
contacts a well-known server, the "tracker", which provides a list of
IP addresses of peers in the swarm.
A swarm is an overlay network on top of the IP network. Algorithms
that determine the overlay topology and the traffic distribution in
the overlay may consider information about the underlying IP network,
such as topological distance, link bandwidth, (monetary) costs for
sending traffic from one host to another, etc. ALTO is a protocol
for retrieving such information. The goal of such "topology aware"
decisions is to improve performance or Quality of Experience in the
application while reducing the utilization of the underlying network
infrastructure.
C.2. Architectural Options for Placing the ALTO Client
The ALTO protocol specification [RFC7285] details how an ALTO client The ALTO protocol specification [RFC7285] details how an ALTO client
can query an ALTO server for guiding information and receive the can query an ALTO server for guiding information and receive the
corresponding replies. However, in the considered scenario of a corresponding replies. However, in the considered scenario of a
tracker-based P2P application, there are two fundamentally different tracker-based P2P application, there are two fundamentally different
possibilities where to place the ALTO client: possibilities where to place the ALTO client:
1. ALTO client in the resource consumer ("peer") 1. ALTO client in the resource consumer ("peer")
2. ALTO client in the resource directory ("tracker") 2. ALTO client in the resource directory ("tracker")
skipping to change at page 28, line 17 skipping to change at page 34, line 17
: ______ : : : : ______ : : :
: +-______-+ : : k good : : +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ : : | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | : : | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | : : | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | : : | peers, | | selec- | : transmit : | peer |------>| cha- | :
: | M good | | tion | : n peer : | select | n-k | nge | : : | M good | | tion | : n peer : | select | n-k | nge | :
: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
:...........................: :.....^.....................: :...........................: :.....^.....................:
| |
| ALTO | ALTO protocol
| client protocol
__|___ __|___
+-______-+ +-______-+
| | | |
| ALTO | | ALTO |
| server | | server |
+-______-+ +-______-+
Figure 1: Tracker-based P2P Application with random peer preselection Figure 1: Tracker-based P2P Application with random peer preselection
Peer w. ALTO cli. Tracker ALTO Server Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+-------- --------+-------- --------+-------- --------+--------
| F1 Tracker query | | | F1 Tracker query | |
|======================>| | |======================>| |
| F2 Tracker reply | | | F2 Tracker reply | |
|<======================| | |<======================| |
| F3 ALTO client protocol query | | F3 ALTO query | |
|---------------------------------------------->| |---------------------------------------------->|
| F4 ALTO client protocol reply | | F4 ALTO reply | |
|<----------------------------------------------| |<----------------------------------------------|
| | | | | |
==== Application protocol (i.e., tracker-based P2P app protocol) ==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol ---- ALTO protocol
Figure 2: Basic message sequence chart for resource consumer- Figure 2: Basic message sequence chart for resource consumer-
initiated ALTO query initiated ALTO query
............................. ............................. ............................. .............................
: Tracker : : Peer : : Tracker : : Peer :
: ______ : : : : ______ : : :
: +-______-+ : : : : +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ : : | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | : : | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | : : | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | : : | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | : : | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ : : +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................: :.....................^.....: :...........................:
| |
| ALTO | ALTO protocol
| client protocol
__|___ __|___
+-______-+ +-______-+
| | | |
| ALTO | | ALTO |
| server | | server |
+-______-+ +-______-+
Figure 3: Tracker-based P2P Application with ALTO client in tracker Figure 3: Tracker-based P2P Application with ALTO client in tracker
Peer Tracker w. ALTO cli. ALTO Server Peer Tracker w. ALTO cli. ALTO Server
--------+-------- --------+-------- --------+-------- --------+-------- --------+-------- --------+--------
| F1 Tracker query | | | F1 Tracker query | |
|======================>| | |======================>| |
| | F2 ALTO cli. p. query | | | F2 ALTO query |
| |---------------------->| | |---------------------->|
| | F3 ALTO cli. p. reply | | | F3 ALTO reply |
| |<----------------------| | |<----------------------|
| F4 Tracker reply | | | F4 Tracker reply | |
|<======================| | |<======================| |
| | | | | |
==== Application protocol (i.e., tracker-based P2P app protocol) ==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol ---- ALTO protocol
Figure 4: Basic message sequence chart for ALTO query on behalf of Figure 4: Basic message sequence chart for ALTO query on behalf of
remote resource consumer remote resource consumer
Note: the message sequences depicted in Figure 2 and Figure 4 may Note: the message sequences depicted in Figure 2 and Figure 4 may
occur both in the target-aware and the target-independent query mode occur both in the target-aware and the target-independent query mode
(c.f. [RFC6708]). In the target-independent query mode no message (c.f. [RFC6708]). In the target-independent query mode no message
exchange with the ALTO server might be needed after the tracker exchange with the ALTO server might be needed after the tracker
query, because the candidate resource providers could be evaluated query, because the candidate resource providers could be evaluated
using a locally cached "map", which has been retrieved from the ALTO using a locally cached "map", which has been retrieved from the ALTO
server some time ago. server some time ago.
C.2. Evaluation C.3. Evaluation
The problem with the first approach is, that while the resource The problem with the first approach is, that while the resource
directory might know thousands of peers taking part in a swarm, the directory might know thousands of peers taking part in a swarm, the
list returned to the resource consumer is usually shortened for list returned to the resource consumer is usually shortened for
efficiency reasons. Therefore, the "best" (in the sense of ALTO) efficiency reasons. Therefore, the "best" (in the sense of ALTO)
potential resource providers might not be contained in that list potential resource providers might not be contained in that list
anymore, even before ALTO can consider them. anymore, even before ALTO can consider them.
For illustration, consider a simple model of a swarm, in which all For illustration, consider a simple model of a swarm, in which all
peers fall into one of only two categories: assume that there are peers fall into one of only two categories: assume that there are
skipping to change at page 32, line 5 skipping to change at page 38, line 5
advantageous, because it is ensured that the addresses of the "best" advantageous, because it is ensured that the addresses of the "best"
resource providers are actually delivered to the resource consumer. resource providers are actually delivered to the resource consumer.
An architectural implication of this insight is that the ALTO server An architectural implication of this insight is that the ALTO server
discovery procedures must support ALTO queries on behalf of remote discovery procedures must support ALTO queries on behalf of remote
resource consumers. That is, as the tracker issues ALTO queries on resource consumers. That is, as the tracker issues ALTO queries on
behalf of the peer which contacted the tracker, the tracker must be behalf of the peer which contacted the tracker, the tracker must be
able to discover an ALTO server that can give guidance suitable for able to discover an ALTO server that can give guidance suitable for
that respective peer. This task can be solved using the ALTO Cross- that respective peer. This task can be solved using the ALTO Cross-
Domain Server Discovery Procedure. Domain Server Discovery Procedure.
C.3. Example C.4. Example
This section provides a complete example of the ALTO Cross-Domain This section provides a complete example of the ALTO Cross-Domain
Server Discovery Procedure in a tracker-based peer-to-peer scenario. Server Discovery Procedure in a tracker-based peer-to-peer scenario.
The example is based on the network topology shown in Figure 5. Five The example is based on the network topology shown in Figure 5. Five
access networks - Networks a, b, c, x, and t - are operated by five access networks - Networks a, b, c, x, and t - are operated by five
different network operators. They are interconnected by a backbone different network operators. They are interconnected by a backbone
structure. Each network operator runs an ALTO server in their structure. Each network operator runs an ALTO server in their
network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and
ALTO_SRV_T, respectively. ALTO_SRV_T, respectively.
skipping to change at page 34, line 21 skipping to change at page 40, line 21
The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6 The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6
address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42, address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42,
L = 128, and SP = "ALTO:https". L = 128, and SP = "ALTO:https".
The procedure constructs (see Step 1 in Section 3.2) The procedure constructs (see Step 1 in Section 3.2)
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0. R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0.
8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3) 8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3)
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.".
In order to illustrate the third step of the ALTO Cross-Domain Server In order to illustrate the third step of the ALTO Cross-Domain Server
Discovery Procedure, we use the "dig" (domain information groper) DNS Discovery Procedure, we use the "dig" (domain information groper) DNS
lookup utility that is available for many operating systems (e.g., lookup utility that is available for many operating systems (e.g.,
Linux). A real implementation of the ALTO Cross-Domain Server Linux). A real implementation of the ALTO Cross-Domain Server
Discovery Procedure would not be based on the "dig" utility, but use Discovery Procedure would not be based on the "dig" utility, but use
appropriate libraries and/or operating system APIs. Please note that appropriate libraries and/or operating system APIs. Please note that
the following steps have been performed in a controlled lab the following steps have been performed in a controlled lab
environment with a appropriately configured name server. A suitable environment with a appropriately configured name server. A suitable
 End of changes. 69 change blocks. 
225 lines changed or deleted 462 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/