Token Binding over HTTP
draft-ietf-tokbind-https-15
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8473.
|
|
---|---|---|---|
Authors | Andrei Popov , Magnus Nyström , Dirk Balfanz , Adam Langley , Nick Harper , Jeff Hodges | ||
Last updated | 2018-05-10 (Latest revision 2018-05-09) | ||
Replaces | draft-balfanz-https-token-binding | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-14)
by Linda Dunbar
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Associated WG milestone |
|
||
Document shepherd | John Bradley | ||
Shepherd write-up | Show Last changed 2017-09-28 | ||
IESG | IESG state | Became RFC 8473 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Eric Rescorla | ||
Send notices to | John Bradley <ve7jtb@ve7jtb.com> | ||
IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-tokbind-https-15
Internet Engineering Task Force (IETF) S. Kiesel Request for Comments: 8686 University of Stuttgart Category: Standards Track M. Stiemerling ISSN: 2070-1721 H-DA February 2020 Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery Abstract The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8686. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Terminology and Requirements Language 2. ALTO Cross-Domain Server Discovery Procedure: Overview 3. ALTO Cross-Domain Server Discovery Procedure: Specification 3.1. Interface 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 3.3. Step 2: Prepare Shortened Domain Names 3.4. Step 3: Perform DNS U-NAPTR Lookups 3.5. Error Handling 4. Using the ALTO Protocol with Cross-Domain Server Discovery 4.1. Network and Cost Map Service 4.2. Map-Filtering Service 4.3. Endpoint Property Service 4.4. Endpoint Cost Service 4.5. Summary and Further Extensions 5. Implementation, Deployment, and Operational Considerations 5.1. Considerations for ALTO Clients 5.2. Considerations for Network Operators 6. Security Considerations 6.1. Integrity of the ALTO Server's URI 6.2. Availability of the ALTO Server Discovery Procedure 6.3. Confidentiality of the ALTO Server's URI 6.4. Privacy for ALTO Clients 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Appendix A. Solution Approaches for Partitioned ALTO Knowledge A.1. Classification of Solution Approaches A.2. Discussion of Solution Approaches A.3. The Need for Cross-Domain ALTO Server Discovery A.4. Our Solution Approach A.5. Relation to the ALTO Requirements Appendix B. Requirements for Cross-Domain Server Discovery B.1. Discovery Client Application Programming Interface B.2. Data Storage and Authority Requirements B.3. Cross-Domain Operations Requirements B.4. Protocol Requirements B.5. Further Requirements Appendix C. ALTO and Tracker-Based Peer-to-Peer Applications C.1. A Generic Tracker-Based Peer-to-Peer Application C.2. Architectural Options for Placing the ALTO Client C.3. Evaluation C.4. Example Acknowledgments Authors' Addresses 1. Introduction 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 [RFC5693]. ALTO is realized by an HTTP-based client-server protocol [RFC7285], which can be used in various scenarios [RFC7971]. The ALTO base protocol document [RFC7285] specifies the communication between an ALTO client and one ALTO server. In principle, the client may send any ALTO query. For example, it might ask for the routing cost between any two IP addresses, or it might request network and cost maps for the whole network, which might be the worldwide Internet. It is assumed that the server can answer any query, possibly with some kind of default value if no exact data is known. No special provisions were made for deployment scenarios with multiple ALTO servers, with some servers having more accurate information about some parts of the network topology while others have better information about other parts of the network ("partitioned knowledge"). Various ALTO use cases have been studied in the context of such scenarios. In some cases, one cannot assume that a topologically nearby ALTO server (e.g., a server discovered with the procedure specified in [RFC7286]) will always provide useful information to the client. One such scenario is detailed in Appendix C. Several solution approaches, such as redirecting a client to a server that has more accurate information or forwarding the request to such a server on behalf of the client, have been proposed and analyzed (see Appendix A), but no solution has been specified so far. Section 3 of this document specifies the "ALTO Cross-Domain Server Discovery Procedure" for client-side usage in these scenarios. An 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 parameter. It will use Domain Name System (DNS) lookups to find one or more ALTO servers that can provide a competent answer. The above wording "related to" was intentionally kept somewhat unspecific, as the exact 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 or prefix (i.e., the corresponding subdomain of "in-addr.arpa." or "ip6.arpa.") -- typically an Internet Service Provider (ISP), a corporate IT department, or a university's computing center -- may add resource records to the DNS that point to one or more relevant ALTO servers. In many cases, it may be an ALTO server run by that ISP or IT department, as they naturally have good insight into routing costs from and to their networks. However, they may also refer to an ALTO server provided by someone else, e.g., their upstream ISP. 1.1. Terminology and Requirements Language This document makes use of the ALTO terminology defined in RFC 5693 [RFC5693]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. ALTO Cross-Domain Server Discovery Procedure: Overview This section gives a non-normative overview of the ALTO Cross-Domain Server Discovery Procedure. The detailed specification will follow in the next section. This procedure was inspired by "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216] and reuses parts of the basic ALTO Server Discovery Procedure [RFC7286]. The basic idea is to use the Domain Name System (DNS), more specifically the "in-addr.arpa." or "ip6.arpa." trees, which are mostly used for "reverse mapping" of IP addresses to host names by means of PTR resource records. There, URI-enabled Naming Authority Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping of domain names to Uniform Resource Identifiers (URIs), are installed 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. The ALTO Cross-Domain Server Discovery Procedure is called with one IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as parameters. The service parameter is usually set to "ALTO:https". However, other parameter values may be used in some scenarios -- e.g., "ALTO:http" to search for a server that supports unencrypted transmission for debugging purposes, or other application protocol or service tags if applicable. The procedure performs DNS lookups and returns one or more URIs of information resources related to said IP address or prefix, usually the URIs of one or more ALTO Information Resource Directories (IRDs; see Section 9 of [RFC7285]). The U-NAPTR records also provide preference values, which should be considered if more than one URI is returned. The discovery procedure sequentially tries two different lookup 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." corresponding to the given IP address or prefix. If this lookup does not yield a usable result, the procedure tries further lookups with truncated domain names, which correspond to shorter prefix lengths. 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 is to be enabled for a large number of IP addresses with a small number of additional DNS resource records. 3. ALTO Cross-Domain Server Discovery Procedure: Specification 3.1. Interface 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 Parameter. The parameter X may be an IPv4 or an IPv6 address or prefix in Classless Inter-Domain Routing (CIDR) notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for 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. From the definitions of IPv4 and IPv6, it follows that syntactically 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 necessary. 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, A=2001:0DB8::20, and L=128. In the intended usage scenario, the procedure is normally always called with the parameter SP set to "ALTO:https". However, for general applicability and in order to support future extensions, the procedure MUST support being called with any valid U-NAPTR Service Parameter (see Section 4.5 of [RFC4848] for the syntax of U-NAPTR Service Parameters and Section 5 of the same document for information about the IANA registries). The procedure performs DNS lookups and returns one or more URIs of information resources related to that IP address or prefix, usually the URIs of one or more ALTO Information Resource Directories (IRDs; see Section 9 of [RFC7285]). For each URI, the procedure also returns order and preference values (see Section 4.1 of [RFC3403]), which should be considered if more than one URI is returned. During execution of this procedure, various error conditions may 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 calling the ALTO Cross-Domain Server Discovery Procedure: IRD_URIS_X = XDOMDISC(X,"ALTO:https") 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 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 procedure aborts and indicates an "unsupported prefix length" error to the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Otherwise, the procedure continues. If AT=IPv4, the procedure will then produce a DNS domain name, which will be referred to as R32. This domain name is constructed 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.". If AT=IPv6, a domain name, which will be called R128, is constructed according to the rules specified in Section 2.5 of [RFC3596], and the special domain "IP6.ARPA." is used. For example (note: a line break was added after the second line), 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. 1.0.0.2.IP6.ARPA." 3.3. Step 2: Prepare Shortened Domain Names 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 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.". 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), 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 R24="100.51.198.IN-ADDR.ARPA." R16="51.198.IN-ADDR.ARPA." R8="198.IN-ADDR.ARPA." If AT=IPv6, the following additional domain names are generated from the result of the previous step: 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) corresponds to shortening the prefix length by 4 bits. 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. 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." 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." R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R32 = "8.B.D.0.1.0.0.2.IP6.ARPA." 3.4. Step 3: Perform DNS U-NAPTR Lookups The address type and the prefix length of X are matched against the first and the second column of the following table, respectively: +------------+-----------+------------+-----------------------+ | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | | Type AT | Length L | 1st lookup | lookups in that order | +============+===========+============+=======================+ | IPv4 | 32 | R32 | R24, R16, R8 | +------------+-----------+------------+-----------------------+ | IPv4 | 24 .. 31 | R24 | R16, R8 | +------------+-----------+------------+-----------------------+ | IPv4 | 16 .. 23 | R16 | R8 | +------------+-----------+------------+-----------------------+ | IPv4 | 8 .. 15 | R8 | (none) | +------------+-----------+------------+-----------------------+ | IPv4 | 0 .. 7 | (none, abort: unsupported prefix | | | | length) | +------------+-----------+------------+-----------------------+ | IPv6 | 128 | R128 | R64, R56, R48, R40, | | | | | R32 | +------------+-----------+------------+-----------------------+ | IPv6 | 64 | R64 | R56, R48, R40, R32 | | | (..127) | | | +------------+-----------+------------+-----------------------+ | IPv6 | 56 .. 63 | R56 | R48, R40, R32 | +------------+-----------+------------+-----------------------+ | IPv6 | 48 .. 55 | R48 | R40, R32 | +------------+-----------+------------+-----------------------+ | IPv6 | 40 .. 47 | R40 | R32 | +------------+-----------+------------+-----------------------+ | IPv6 | 32 .. 39 | R32 | (none) | +------------+-----------+------------+-----------------------+ | IPv6 | 0 .. 31 | (none, abort: unsupported prefix | | | | length) | +------------+-----------+------------------------------------+ Table 1: Perform DNS U-NAPTR lookups Then, the domain name given in the 3rd column and the U-NAPTR Service Parameter SP with which the procedure was called (usually "ALTO:https") MUST be used for a U-NAPTR [RFC4848] lookup, in order to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory (IRD). If such URIs can be found, the ALTO Cross-Domain Server Discovery Procedure returns that information to the caller and terminates successfully. For example, the following two U-NAPTR resource records can be used for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in the previous step) to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred. 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto1.example.net/ird!" "" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" "!.*!https://alto2.example.net/ird!" "" If no matching U-NAPTR records can be found, the procedure SHOULD try further lookups, using the domain names from the fourth column in the indicated order, until one lookup succeeds. If no IRD URI can be found after looking up all domain names from the 3rd and 4th columns, the procedure terminates unsuccessfully, returning an empty URI list. 3.5. Error Handling The ALTO Cross-Domain Server Discovery Procedure may fail for several reasons. If the procedure is called with syntactically invalid parameters or unsupported parameter values (in particular, the prefix length L; see Section 3.2), the procedure aborts, no URI list will be returned, and the error has to be reported to the caller. The procedure performs one or more DNS lookups in a well-defined order (corresponding to descending prefix lengths, see Section 3.4) until one produces a usable result. Each of these DNS lookups might fail to produce a usable result, due to either a normal condition (e.g., a domain name exists, but no ALTO-specific NAPTR resource records are associated with it), a permanent error (e.g., nonexistent domain name), or a temporary error (e.g., timeout). In all three cases, and as long as there are further domain names that can be looked up, the procedure SHOULD immediately try to look up the next 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 MAY retry those domain names that had caused temporary lookup errors. Generally speaking, ALTO provides advisory information for the optimization of applications (peer-to-peer applications, overlay networks, etc.), but applications should not rely on the availability of such information for their basic functionality (see Section 8.3.4.3 of [RFC7285]). Consequently, the speedy detection of an ALTO server, even though it may give less accurate answers than other servers, or the quick realization that there is no suitable ALTO server, is in general preferable to causing long delays by retrying failed queries. Nevertheless, if DNS queries have failed due to temporary errors, the ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller that DNS queries have failed for that reason and that retrying the discovery at a later point in time might give more accurate results. 4. Using the ALTO Protocol with Cross-Domain Server Discovery Based on a modular design principle, ALTO provides several ALTO services, each consisting of a set of information resources that can be accessed using the ALTO protocol. The information resources that are available at a specific ALTO server are listed in its Information Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO protocol specification defines the following ALTO services and their corresponding information resources: * Network and Cost Map Service, see Section 11.2 of [RFC7285] * Map-Filtering Service, see Section 11.3 of [RFC7285] * Endpoint Property Service, see Section 11.4 of [RFC7285] * Endpoint Cost Service, see Section 11.5 of [RFC7285] The ALTO Cross-Domain Server Discovery Procedure is most useful in conjunction with the Endpoint Property Service and the Endpoint Cost Service. However, for the sake of completeness, possible interaction with all four services is discussed below. Extension documents may specify further information resources; however, these are out of scope of this document. 4.1. Network and Cost Map Service An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get a list of one or more IRD URIs, including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s) referenced by these URIs will always contain a network and a cost map, as these are mandatory information resources (see Section 11.2 of [RFC7285]). However, the cost matrix may be very sparse. If, according to the network map, PID_X is the Provider-defined Identifier (PID; see Section 5.1 of [RFC7285]) that contains the IP address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDs, the cost map may look like this: +-------+----------+-------+-------+-------+ | From | To PID_1 | PID_2 | PID_X | PID_3 | +=======+==========+=======+=======+=======+ | PID_1 | | | 92 | | +-------+----------+-------+-------+-------+ | PID_2 | | | 6 | | +-------+----------+-------+-------+-------+ | PID_X | 46 | 3 | 1 | 19 | +-------+----------+-------+-------+-------+ | PID_3 | | | 38 | | +-------+----------+-------+-------+-------+ Table 2: Cost Map In this example, all cells outside Column X and Row X are unspecified. A cost map with this structure contains the same information as what could be retrieved using the Endpoint Cost Service, Cases 1 and 2 in Section 4.4. Accessing cells that are neither in Column X nor Row X may not yield useful results. Trying to assemble a more densely populated cost map from several cost maps with this very sparse structure may be a nontrivial task, as different ALTO servers may use different PID definitions (i.e., network maps) and incompatible scales for the costs, in particular for the "routingcost" metric. 4.2. Map-Filtering Service An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get a list of one or more IRD URIs, including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRDs may provide the optional Map-Filtering Service (see Section 11.3 of [RFC7285]). This service returns a subset of the full map, as specified by the client. As discussed in Section 4.1, a cost map may be very sparse in the envisioned deployment scenario. Therefore, depending on the filtering criteria provided by the client, this service may return results similar to the Endpoint Cost Service, or it may not return any useful result. 4.3. Endpoint Property Service If an ALTO client wants to query an Endpoint Property Service (see Section 11.4 of [RFC7285]) about an endpoint with IP address X or a group of endpoints within IP prefix X, respectively, it has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The result, IRD_URIS_X, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Property Service and query it. If the ALTO client wants to do a similar Endpoint Property query for a different IP address or prefix "Y", the whole procedure has to be repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a different list of IRD URIs. Of course, the results of individual DNS queries may be cached as indicated by their respective time-to-live (TTL) values. 4.4. Endpoint Cost Service The optional ALTO Endpoint Cost Service (ECS; see Section 11.5 of [RFC7285]) provides information about costs between individual endpoints and also supports ranking. The ECS allows endpoints to be denoted by IP addresses or prefixes. The ECS is called with a list of one or more source IP addresses or prefixes, which we will call (S1, S2, S3, ...), and a list of one or more destination IP addresses or prefixes, called (D1, D2, D3, ...). This specification distinguishes several cases, regarding the number of elements in the list of source and destination addresses, respectively: 1. Exactly one source address S1 and more than one destination addresses (D1, D2, D3, ...). In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) with that single source address as a parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result, IRD_URIS_S1, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Cost Service and query it. The ECS is an optional service (see Section 11.5.1 of [RFC7285]), and therefore, it may well be that an IRD does not refer to an ECS. Calling the Cross-Domain Server Discovery Procedure only once with the single source address as a parameter -- as opposed to multiple calls, e.g., one for each destination address -- is not only a matter of efficiency. In the given scenario, it is advisable to send all ECS queries to the same ALTO server. This ensures that the results can be compared (e.g., for sorting candidate resource providers), even when cost metrics lack a well-defined base unit -- e.g., the "routingcost" metric. 2. More than one source address (S1, S2, S3, ...) and exactly one destination address D1. In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure with that single destination address as a parameter: IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result, IRD_URIS_D1, is a list of one or more URIs of IRDs. Considering the order and preference values, the client has to check these IRDs for a suitable ECS and query it. 3. Exactly one source address S1 and exactly one destination address D1. The ALTO client may perform the same steps as in Case 1, as specified above. As an alternative, it may also perform the same steps as in Case 2, as specified above. 4. More than one source address (S1, S2, S3, ...) and more than one destination address (D1, D2, D3, ...). In this case, the ALTO client should split the list of desired queries based on source addresses and perform separately for each source address the same steps as in Case 1, as specified above. As an alternative, the ALTO client may also group the list based on destination addresses and perform separately for each destination address the same steps as in Case 2, as specified above. However, comparing results between these subqueries may be difficult, in particular if the cost metric is a relative preference without a well- defined base unit (e.g., the "routingcost" metric). See Appendix C for a detailed example showing the interaction of a tracker-based peer-to-peer application, the ALTO Endpoint Cost Service, and the ALTO Cross-Domain Server Discovery Procedure. 4.5. Summary and Further Extensions Considering the four services defined in the ALTO base protocol specification [RFC7285], the ALTO Cross-Domain Server Discovery Procedure works best with the Endpoint Property Service (EPS) and the Endpoint Cost Service (ECS). Both the EPS and the ECS take one or more IP addresses as a parameter. The previous sections specify how the parameter for calling the ALTO Cross-Domain Server Discovery Procedure has to be derived from these IP addresses. In contrast, the ALTO Cross-Domain Server Discovery Procedure seems less useful if the goal is to retrieve network and cost maps that cover the whole network topology. However, the procedure may be useful if a map centered at a specific IP address is desired (i.e., a map detailing the vicinity of said IP address or a map giving costs from said IP address to all potential destinations). The interaction between further ALTO services (and their corresponding information resources) needs to be investigated and defined once such further ALTO services are specified in an extension document. 5. Implementation, Deployment, and Operational Considerations 5.1. Considerations for ALTO Clients 5.1.1. Resource-Consumer-Initiated Discovery Resource-consumer-initiated ALTO server discovery (cf. ALTO requirement AR-32 [RFC6708]) can be seen as a special case of cross- domain ALTO server discovery. To that end, an ALTO client embedded in a resource consumer would have to perform the ALTO Cross-Domain Server Discovery Procedure with its own IP address as a parameter. However, due to the widespread deployment of Network Address Translators (NATs), additional protocols and mechanisms such as Session Traversal Utilities for NAT (STUN) [RFC5389] are usually needed to detect the client's "public" IP address before it can be used as a parameter for the discovery procedure. Note that a different approach for resource-consumer-initiated ALTO server discovery, which is based on DHCP, is specified in [RFC7286]. 5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility The procedure specified in this document can discover ALTO server URIs for a given IP address or prefix. The intention is that a third party (e.g., a resource directory) that receives query messages from a resource consumer can use the source address in these messages to discover suitable ALTO servers for this specific resource consumer. However, resource consumers (as defined in Section 2 of [RFC5693]) may reside on hosts with more than one IP address -- for example, due to IPv4/v6 dual stack operation and/or multihoming. IP packets sent with different source addresses may be subject to different routing policies and path costs. In some deployment scenarios, it may even be required to ask different sets of ALTO servers for guidance. Furthermore, source addresses in IP packets may be modified en route by Network Address Translators (NATs). If a resource consumer queries a resource directory for candidate resource providers, the locally selected (and possibly en-route- translated) source address of the query message -- as observed by the resource directory -- will become the basis for the ALTO server discovery and the subsequent optimization of the resource directory's reply. If, however, the resource consumer then selects different source addresses to contact returned resource providers, the desired better-than-random "ALTO effect" may not occur. One solution approach for this problem is that a dual-stack or multihomed resource consumer could always use the same address for contacting the resource directory and all resource providers, thus overriding the operating system's automatic selection of source IP addresses. For example, when using the BSD socket API, one could always bind() the socket to one of the local IP addresses before trying to connect() to the resource directory or the resource providers, respectively. Another solution approach is to perform ALTO-influenced resource provider selection (and source-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 of how to discover ALTO servers for local usage in the resource consumer. 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.1.3. Interaction with Network Address Translation The ALTO Cross-Domain Server Discovery Procedure has been designed to enable the ALTO-based optimization of applications such as large- scale overlay networks, that span -- on the IP layer -- multiple administrative domains, possibly the whole Internet. Due to the widespread usage of Network Address Translators (NATs), 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. If a resource directory is located in the public Internet (i.e., not behind a NAT) and receives a message from a resource consumer behind one or more NATs, the message's source address will be the public IP address of the outermost NAT in front of the resource consumer. The same applies if the resource directory is behind a 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 invocation 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 intradomain 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 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 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 look up 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 it expressly has not been a design goal of this procedure to give clients a means of understanding the IP prefix delegation structure. Furthermore, this specification does not assume or recommend that prefix delegations should preferably 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. BCP 20 and Missing Delegations of the Reverse DNS [RFC2317], also known as BCP 20, 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., less than a whole /24 prefix). The ALTO Cross-Domain Server Discovery Procedure is compatible with this 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 Popov, et al. Expires November 10, 2018 [Page 20] Internet-Draft Token Binding over HTTP May 2018 These other Token Binding IDs can serve as correlation handles for the endpoints of the other connections. If the receiving endpoints are otherwise aware of these other connections, then no additional information is being exposed. For instance, if in a redirect-based federation protocol, the Identity Provider and Relying Party already possess URLs for one another, also having Token Binding IDs for these connections does not provide additional correlation information. If not, then, by providing the other Token Binding IDs, additional information is exposed that can be used to correlate the other endpoints. In such cases, a privacy analysis of enabled correlations and their potential privacy impacts should be performed as part of the application design decisions of how, and whether, to utilize Token Binding. Also, Token Binding implementations must take care to only reveal Token Binding IDs to other endpoints if the application associated with a Token Binding ID signals to do so, see Section 6 ("Implementation Considerations"). Finally, care should be taken to ensure that unrelated applications do not obtain information about each other's Token Bindings. For instance, a Token Binding implementation shared between multiple applications on a given system should prevent unrelated applications from obtaining each other's Token Binding information. This may be accomplished by using techniques such as application isolation and key segregation, depending upon system capabilities. 9. IANA Considerations Below are the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864]. Header field name: Sec-Token-Binding Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): this one Header field name: Include-Referred-Token-Binding-ID Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): this one Popov, et al. Expires November 10, 2018 [Page 21] Internet-Draft Token Binding over HTTP May 2018 10. Acknowledgements This document incorporates comments and suggestions offered by Eric Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony Nadalin, Michael B. Jones, Bill Cox, Brian Campbell, and others. This document was produced under the chairmanship of John Bradley and Leif Johansson. The area directors included Eric Rescorla, Kathleen Moriarty and Stephen Farrell. 11. References 11.1. Normative References [fetch-spec] WhatWG, "Fetch", Living Standard , <https://fetch.spec.whatwg.org/>. [I-D.ietf-tokbind-negotiation] Popov, A., Nystrom, M., Balfanz, D., and A. Langley, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", draft-ietf-tokbind- negotiation-12 (work in progress), May 2018. [I-D.ietf-tokbind-protocol] Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, "The Token Binding Protocol Version 1.0", draft- ietf-tokbind-protocol-17 (work in progress), April 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. Popov, et al. Expires November 10, 2018 [Page 22] Internet-Draft Token Binding over HTTP May 2018 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>. [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 11.2. Informative References [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005, <http://docs.oasis- open.org/security/saml/v2.0/saml-core-2.0-os.pdf>. [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", August 2015, <http://openid.net/specs/openid-connect-core-1_0.html>. Popov, et al. Expires November 10, 2018 [Page 23] Internet-Draft Token Binding over HTTP May 2018 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <https://www.rfc-editor.org/info/rfc5746>. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>. [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>. [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>. [TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS. IEEE Symposium on Security and Privacy", 2014. Authors' Addresses Andrei Popov Microsoft Corp. USA Email: andreipo@microsoft.com Magnus Nystroem Microsoft Corp. USA Email: mnystrom@microsoft.com Dirk Balfanz (editor) Google Inc. USA Email: balfanz@google.com Popov, et al. Expires November 10, 2018 [Page 24] Internet-Draft Token Binding over HTTP May 2018 Adam Langley Google Inc. USA Email: agl@google.com Nick Harper Google Inc. USA Email: nharper@google.com Jeff Hodges PayPal USA Email: Jeff.Hodges@paypal.com Popov, et al. Expires November 10, 2018 [Page 25]