idnits 2.17.1 draft-ietf-alto-xdom-disc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC8174], [RFC5693]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1195 has weird spacing: '... and n! =...' -- The document date (October 9, 2018) is 2025 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track M. Stiemerling 5 Expires: April 12, 2019 H-DA 6 October 9, 2018 8 Application Layer Traffic Optimization (ALTO) Cross-Domain Server 9 Discovery 10 draft-ietf-alto-xdom-disc-03 12 Abstract 14 The goal of Application-Layer Traffic Optimization (ALTO) is to 15 provide guidance to applications that have to select one or several 16 hosts from a set of candidates capable of providing a desired 17 resource. ALTO is realized by a client-server protocol. Before an 18 ALTO client can ask for guidance it needs to discover one or more 19 ALTO servers that can provide suitable guidance. 21 In some deployment scenarios, in particular if the information about 22 the network topology is partitioned and distributed over several ALTO 23 servers, it may be needed to discover an ALTO server outside of the 24 own network domain, in order to get appropriate guidance. This 25 document details applicable scenarios, itemizes requirements, and 26 specifies a procedure for ALTO cross-domain server discovery. 28 Technically, the procedure specified in this document takes one 29 IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO: 30 http" or "ALTO:https") as parameters. It performs DNS lookups (for 31 NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and 32 returns one or more URI(s) of information resources related to that 33 IP address or prefix. 35 Terminology and Requirements Language 37 This document makes use of the ALTO terminology defined in RFC 5693 38 [RFC5693]. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in BCP 43 14 [RFC2119] [RFC8174] when, and only when, they appear in all 44 capitals, as shown here. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on April 12, 2019. 63 Copyright Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Overview on the ALTO Cross-Domain Server Discovery 82 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. ALTO Cross-Domain Server Discovery Procedure Specification . . 6 84 3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7 86 3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 7 87 3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 8 88 4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 9 89 4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 9 90 4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 10 91 4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 10 92 4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11 93 4.5. Summary and Further Extensions . . . . . . . . . . . . . . 12 94 5. Implementation, Deployment, and Operational Considerations . . 13 95 5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 13 96 5.2. Deployment Considerations for Network Operators . . . . . 14 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 15 99 6.2. Availability of the ALTO Server Discovery Procedure . . . 16 100 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 17 101 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 17 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 106 Appendix A. Multiple Information Sources and Partitioned 107 Knowledge . . . . . . . . . . . . . . . . . . . . . . 21 108 A.1. Classification of Solution Approaches . . . . . . . . . . 21 109 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 22 110 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 22 111 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 23 112 A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 23 113 Appendix B. Requirements for ALTO Cross-Domain Server 114 Discovery . . . . . . . . . . . . . . . . . . . . . . 24 115 B.1. Discovery Client Application Programming Interface . . . . 24 116 B.2. Data Storage and Authority Requirements . . . . . . . . . 24 117 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 24 118 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 25 119 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 25 120 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 26 121 C.1. Architectural Options . . . . . . . . . . . . . . . . . . 26 122 C.2. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 29 123 C.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 Appendix D. Contributors List and Acknowledgments . . . . . . . . 36 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 127 1. Introduction 129 The goal of Application-Layer Traffic Optimization (ALTO) is to 130 provide guidance to applications that have to select one or several 131 hosts from a set of candidates capable of providing a desired 132 resource [RFC5693]. ALTO is realized by an HTTP-based client-server 133 protocol [RFC7285], which can be used in various scenarios [RFC7971]. 135 The ALTO base protocol document [RFC7285] specifies the communication 136 between an ALTO client and one ALTO server. In principle, the client 137 may send any ALTO query. For example, it might ask for the routing 138 cost between any two IP addresses, or it might request network and 139 cost maps for the whole network, which might be the worldwide 140 Internet. It is assumed that the server can answer any query, 141 possibly with some kind of default value if no exact data is known. 143 No special provisions were made for deployment scenarios with 144 multiple ALTO servers, with some servers having more accurate 145 information about some parts of the network topology while others 146 having better information about other parts of the network 147 ("partitioned knowledge"). Various ALTO use cases have been studied 148 in the context of such scenarios. In some cases, one cannot assume 149 that a topologically nearby ALTO server (e.g., a server discovered 150 with the procedure specified in [RFC7286]) will always provide useful 151 information to the client. One such scenario is detailed in 152 Appendix C. Several solution approaches, such as redirecting a 153 client to a server that has more accurate information or forwarding 154 the request to it on behalf of the client, have been proposed and 155 analyzed (see Appendix A), but none has been specified so far. 157 Section 3 of this document specifies the "ALTO Cross-Domain Server 158 Discovery Procedure" for client-side usage in these scenarios. An 159 ALTO client that wants to send an ALTO query related to a specific IP 160 address or prefix X, may call this procedure with X as a paramenter. 161 It will use DNS lookups to find the IRD URI(s) of one ore more ALTO 162 server(s) that can provide a competent answer. The above wording 163 "related to" was intentionally kept somewhat vague, as the exact 164 semantics depends on the ALTO service to be used; see Section 4. 166 Those who are in control of the "reverse DNS" for a given IP address 167 or prefix (i.e., the corresponding subdomain of in-addr.arpa. or 168 ip6.arpa.) - typically an Internet Service Provider (ISP), a 169 corporate IT department, or a university's computing center - may add 170 resource records to the DNS that point to one or more relevant ALTO 171 server(s). In many cases, it may be an ALTO server run by that ISP 172 or IT department, as they naturally have good insight into routing 173 costs from and to their networks. However, they may also refer to an 174 ALTO server provided by someone else, e.g., their upstream ISP. 176 2. Overview on the ALTO Cross-Domain Server Discovery Procedure 178 This procedure was inspired by the "Location Information Server (LIS) 179 Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses 180 parts of the basic ALTO Server Discovery Procedure [RFC7286]. 182 The basic idea is to use the Domain Name System (DNS), more 183 specifically the "in-addr.arpa." or "ip6.arpa." trees, which are 184 mostly used for "reverse mapping" of IP addresses to host names by 185 means of PTR resource records. There, U-NAPTR resource records 186 [RFC4848], which allow the mapping of domain names to URIs, are 187 installed as needed. Thereby, it is possible to store a mapping from 188 an IP address or prefix to one or more ALTO server URIs in the DNS. 190 The ALTO Cross-Domain Server Discovery Procedure is called with one 191 IP address or prefix X and a U-NAPTR Service Parameter [RFC4848] SP 192 as parameters. 194 The service parameter SP SHOULD always be set to "ALTO:https". 195 However, other parameter values MAY be used in some scenarios, e.g., 196 "ALTO:http" to search for a server that supports unencrypted 197 transmission for debugging purposes, or other application protocol or 198 service tags if applicable. 200 The procedure performs DNS lookups and returns one or more URI(s) of 201 information resources related to the IP address or prefix X, usually 202 the URI(s) of one or more ALTO Information Resource Directory (IRD, 203 see Section 9 of [RFC7285]). The U-NAPTR records also provide 204 preference values, which should be considered if more than one URI is 205 returned. 207 For the remainder of the document, we use the notation: 208 IRD_URIS_X = XDOMDISC(X,"ALTO:https") 210 The discovery procedure sequentially tries two different lookup 211 strategies: First, an ALTO-specific U-NAPTR record is searched in the 212 "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. 213 corresponding to the given IP address or prefix. If this lookup does 214 not yield a usable result, further lookups with truncated domain 215 names may be tried. The goal is to allow deployment scenarios that 216 require fine-grained discovery on a per-IP basis, as well as large- 217 scale scenarios where discovery is to be enabled for a large number 218 of IP addresses with a small number of additional DNS resource 219 records. 221 3. ALTO Cross-Domain Server Discovery Procedure Specification 223 3.1. Interface 225 The procedure specified in this document takes two parameters, X and 226 SP, where X is an IP address or prefix and SP is a U-NAPTR Service 227 Parameter. 229 The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR 230 notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for 231 IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". 232 In both cases, X consists of an IP address A and a prefix length L. 233 For AT="IPv4", it holds: 0 <= L <= 32 and for AT="IPv6", it holds: 234 0 <= L <= 128. 236 For example, for X=198.51.100.0/24, we get AT="IPv4", A=198.51.100.0 237 and L=24. Similarly, for X=2001:0DB8::20/128, we get AT="IPv6", 238 A=2001:0DB8::20 and L=128. 240 In the intended usage scenario, the procedure SHOULD always be called 241 with the parameter SP set to "ALTO:https". However, for general 242 applicabiliy and in order to support future extensions, the procedure 243 MUST support being called with any valid U-NAPTR Service Parameter 244 (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Service 245 Parameters and Section 5. of the same document for information about 246 the IANA registries). 248 The procedure performs DNS lookups and returns one or more URI(s) of 249 information resources related to that IP address or prefix, usually 250 the URI(s) of one or more ALTO Information Resource Directory (IRD, 251 see Section 9 of [RFC7285]). For each URI, it also returns order and 252 preference values (see Section 4.1 of [RFC3403]), which should be 253 considered if more than one URI is returned. 255 The procedure may fail for various reasons, including syntactically 256 invalid parameters, unsupported parameter values, temporary or 257 permanent errors when performing DNS lookups, etc. These error 258 conditions have to be reported to the caller in an appropriate way. 260 For the remainder of the document, we use the following notation for 261 calling the ALTO Cross-Domain Server Discovery Procedure: 263 IRD_URIS_X = XDOMDISC(X,"ALTO:https") 265 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 267 If A is an IPv4 address, a domain name R32 is constructed according 268 to the rules specified in Section 3.5 of [RFC1035] and it is rooted 269 in the special domain "IN-ADDR.ARPA.". 271 For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.". 273 If A is an IPv6 address, the domain name R128 is constructed 274 according to the rules specified in Section 2.5 of [RFC3596] and the 275 special domain "IP6.ARPA." is used. 277 For example (note: a line break was added after the second line), 278 A = 2001:0DB8::20 yields 279 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. 280 1.0.0.2.IP6.ARPA." 282 3.3. Step 2: Prepare Shortened Domain Names 284 For this step, an auxiliary function "skip" is defined as follows: 285 skip(str,n) will skip all characters in the string str, up to and 286 including the n-th dot, and return the remaining part of str. For 287 example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.". 289 If A is an IPv4 address, the following additional domain names are 290 generated from the result of the previous step: R24=skip(R32,1), 291 R16=skip(R32,2), and R8=skip(R32,3). Removing one label from a 292 domain name (i.e., one number of the "dotted quad notation") 293 corresponds to shortening the prefix length by 8 bits. 295 For example, R32="3.100.51.198.IN-ADDR.ARPA." yields 296 R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and 297 R8="198.IN-ADDR.ARPA.". 299 If A is an IPv6 address, the following additional domain names are 300 generated from the result of the previous step: R64=skip(R128,16), 301 R56=skip(R128,18), R48=skip(R128,20), and R32=skip(R128,24). 302 Removing one label from a domain name (i.e., one hex digit) 303 corresponds to shortening the prefix length by 4 bits. 305 For example (note: a line break was added after the first line), 306 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. 307 1.0.0.2.IP6.ARPA." yields 308 R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 309 R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 310 R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and 311 R32 = "8.B.D.0.1.0.0.2.IP6.ARPA." 313 3.4. Step 3: Perform DNS U-NAPTR lookups 315 The address type of A and the prefix length are matched against the 316 first and the second column of the following table, respectively: 318 +------------+------------+------------+------------------------+ 319 | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | 320 | Type AT | Length L | 1st lookup | lookups in that order | 321 +------------+------------+------------+------------------------+ 322 | IPv4 | 32 | R32 | R24, R16, R8 | 323 | IPv4 | 24 .. 31 | R24 | R16, R8 | 324 | IPv4 | 16 .. 23 | R16 | R8 | 325 | IPv4 | 8 .. 15 | R8 | (none) | 326 | IPv4 | 0 .. 7 | (none, procedure fails w/o result) | 327 +------------+------------+------------+------------------------+ 328 | IPv6 | 128 | R128 | R64, R56, R48, R32 | 329 | IPv6 | 64 (..127) | R64 | R56, R48, R32 | 330 | IPv6 | 56 .. 63 | R56 | R48, R32 | 331 | IPv6 | 48 .. 55 | R48 | R32 | 332 | IPv6 | 32 .. 47 | R32 | (none) | 333 | IPv6 | 0 .. 31 | (none, procedure fails w/o result) | 334 +------------+------------+------------+------------------------+ 336 Then, the domain name given in the 3rd column and the U-NAPTR Service 337 Parameter SP the procedure was called with (usually "ALTO:https") 338 MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one 339 or more URIs (indicating protocol, host, and possibly path elements) 340 for the ALTO server's Information Resource Directory (IRD). If such 341 URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure 342 returns that information to the caller and terminates successfully. 344 For example, the following two U-NAPTR resource records can be used 345 for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in 346 the previous step) to the HTTPS URIs "https://alto1.example.net/ird" 347 and "https://alto2.example.net/ird", with the former being preferred. 349 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" 350 "!.*!https://alto1.example.net/ird!" "" 352 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" 353 "!.*!https://alto2.example.net/ird!" "" 355 If no matching U-NAPTR records can be found, the procedure SHOULD try 356 further lookups, using the domain names from the fourth column in the 357 indicated order, until one lookup succeeds. If no IRD URI could be 358 found after looking up all domain names from the 3rd and 4th column, 359 the procedure terminates unsuccessfully, without producing a result. 361 4. Using the ALTO Protocol with Cross-Domain Server Discovery 363 Based on a modular design principle, ALTO provides several ALTO 364 services, each consisting of a set of information resouces that can 365 be accessed using the ALTO protocol. The ALTO protocol specification 366 defines the following ALTO services and their corresponding 367 information resouces: 369 o Network and Cost Map Service, see Section 11.2 of [RFC7285] 371 o Map-Filtering Service, see Section 11.3 of [RFC7285] 373 o Endpoint Property Service, see Section 11.4 of [RFC7285] 375 o Endpoint Cost Service, see Section 11.5 of [RFC7285] 377 Extension documents may specify further information resources; 378 however, these are out of scope of this document. The information 379 resources that are available at a specific ALTO server are listed in 380 its Information Resource Directory (IRD, see Section 9 of [RFC7285]). 382 The ALTO Cross-Domain Server Discovery Procedure is most useful in 383 conjunction with the Endpoint Property Service and the Endpoint Cost 384 Service. However, for the sake of completeness, possible interaction 385 with all four services is discussed below. 387 4.1. Network and Cost Map Service 389 An ALTO client may invoke the ALTO Cross-Domain Server Discovery 390 Procedure (as specified in Section 3) for an IP address or prefix "X" 391 and get a list of one or more IRD URI(s), including order and 392 preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These 393 IRD(s) will always contain a network and a cost map, as these are 394 mandatory information resources (see Section 11.2 of [RFC7285]). 395 However, the cost matrix may be very sparse. If, according to the 396 network map, PID_X is the PID that contains the IP address or prefix 397 X, and PID_1, PID_2, PID_3, ... are other PIDS, the cost map may look 398 like this: 400 From \ To PID_1 PID_2 PID_X PID_3 401 ------+----------------------------------- 402 PID_1 | 92 403 PID_2 | 6 404 PID_X | 46 3 1 19 405 PID_3 | 38 407 In this example, all cells outside column "X" and row "X" are 408 unspecified. A cost map with this structure contains the same 409 information as what could be retrieved using the ECS, cases 1 and 2 410 in Section 4.4. Accessing cells outside column "X" and row "X" may 411 not yield useful results. 413 Trying to assemble a more densely populated cost map from several 414 cost maps with this very sparse structure may be a non-trivial task, 415 as different ALTO servers may use different PID definitions (i.e., 416 network maps) and incompatible scales for the costs, in particular 417 for the "routingcost" metric. 419 4.2. Map-Filtering Service 421 An ALTO client may invoke the ALTO Cross-Domain Server Discovery 422 Procedure (as specified in Section 3) for an IP address or prefix "X" 423 and get a list of one or more IRD URI(s), including order and 424 preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These 425 IRD(s) may provide the optional Map-Filtering Service (see Section 426 11.3 of [RFC7285]). This service returns a subset of the full map, 427 as specified by the client. As discussed in Section 4.1, a cost map 428 may be very sparse in the envisioned deployment scenario. Therefore, 429 depending on the filtering criteria provided by the client, this 430 service may return results similar to the Endpoint Cost Service, or 431 it may not return any useful result. 433 4.3. Endpoint Property Service 435 If an ALTO client wants to query an Endpoint Property Service (see 436 Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address 437 "X" or a group of endpoints within IP prefix "X", respectively, it 438 has to perform the following steps: 440 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 441 specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https") 443 2. The result IRD_URIS_X is a list of one or more Information 444 Resource Directories (IRD, see Section 9 of [RFC7285]). 445 Considering the order and preference values, check these IRDs for 446 a suitable Endpoint Property Service and query it. 448 If the ALTO client wants to do a similar Endpoint Property query for 449 a different IP address or prefix "Y", the whole procedure has to be 450 repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a 451 different list of IRDs. Of course, the results of individual DNS 452 queries may be cached as indicated by their respective time-to-live 453 (TTL) values. 455 4.4. Endpoint Cost Service 457 The ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285 458 [RFC7285]) provides information about costs between individual 459 endpoints and it also supports ranking. The ECS allows that 460 endpoints may be denoted by IP addresses or prefixes. The ECS is 461 called with a list of one or more source IP addresses or prefixes, 462 which we will call (S1, S2, S3, ...), and a list of one or more 463 destination IP addresses or prefixes, called (D1, D2, D3, ...). 465 This specification distinguishes several cases, regarding the number 466 of elements in the list of source and destination addresses, 467 respectively: 469 1. Exactly one source address S1 and more than one destination 470 addresses D1, D2, D3, ... In this case, the ALTO client has to 471 perform the following steps: 473 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 474 specified in Section 3): 475 IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https") 477 2. The result IRD_URIS_S1 is a list of one or more Information 478 Resource Directories (IRD, see Section 9 of [RFC7285]). 479 Considering the order and preference values, check these IRDs 480 for a suitable ECS and query it. 482 Calling the Cross-Domain Server Discovery Procedure only once 483 with the single source address as a parameter - as opposed to 484 multiple calls, e.g., one for each destination address - is not 485 only a matter of efficiency. In the given scenario, it is 486 advisable to send all ECS queries to the same ALTO server. This 487 ensures that the results can be compared (e.g., for sorting 488 candidate resource providers), even with cost metrics without a 489 well-defined base unit, e.g., the "routingcost" metric. 491 2. More than one source addresses S1, S2, S3, ... and exactly one 492 destination address D1. In this case, the ALTO client has to 493 perform the following steps: 495 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 496 specified in Section 3): 497 IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https") 499 2. The result IRD_URIS_D1 is a list of one or more Information 500 Resource Directories (IRD, see Section 9 of [RFC7285]). 501 Considering the order and preference values, check these IRDs 502 for a suitable ECS and query it. 504 3. Exactly one source address S1 and exactly one destination address 505 D1. The ALTO client may perform the same steps as in case 1, as 506 specified above. As an alternative, it may also perform the same 507 steps as in case 2, as specified above. 509 4. More than one source addresses S1, S2, S3, ... and more than one 510 destination addresses D1, D2, D3, ... In this case, the ALTO 511 client should split the list of source addresses, and perform 512 separately for each source address the same steps as in case 1, 513 as specified above. As an alternative, the ALTO client may also 514 split the list of destination addresses, and perform separately 515 for each destination address the same steps as in case 2, as 516 specified above. However, comparing results between these sub- 517 queries may be difficult, in particular if the cost metric is a 518 relative preference without a well-defined base unit (e.g., the 519 "routingcost" metric). 521 See Appendix C for a detailed example showing the interaction of a 522 tracker-based peer-to-peer application, the ALTO Endpoint Cost 523 Service, and the ALTO Cross-Domain Server Discovery Procedure. 525 4.5. Summary and Further Extensions 527 Considering the four services defined in the ALTO base protocol 528 specification [RFC7285], the ALTO Cross-Domain Server Discovery 529 Procedure works best with the Endpoint Property Service (EPS) and the 530 Endpoint Cost Service (ECS). Both the EPS and the ECS take one or 531 more IP addresses as a parameter. The previous sections specify how 532 the parameter for calling the ALTO Cross-Domain Server Discovery 533 Procedure has to be derived from these IP adresses. 535 In contrast, the ALTO Cross-Domain Server Discovery Procedure seems 536 less useful if the goal is to retrieve network and cost maps that 537 cover the whole network topology. However, the procedure may be 538 useful if a map centered at a specific IP address is desired (i.e., a 539 map detailing the vicinity of said IP address or a map giving costs 540 from said IP address to all potential destinations). 542 The interaction between further ALTO services (and their 543 corresponding information resources) needs to be investigated and 544 defined once such further ALTO services are specified in an extension 545 document. 547 5. Implementation, Deployment, and Operational Considerations 549 5.1. Considerations for ALTO Clients 551 5.1.1. Resource Consumer Initiated Discovery 553 To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource 554 consumer initiated ALTO server discovery, can be seen as a special 555 case of cross-domain ALTO server discovery. To that end, an ALTO 556 client embedded in a resource consumer would have to figure out its 557 own "public" IP address and perform the procedures described in this 558 document on that address. However, due to the widespread deployment 559 of Network Address Translators (NAT), additional protocols and 560 mechanisms such as STUN [RFC5389] would be needed and considerations 561 for UNSAF [RFC3424] apply. Therefore, using the procedures specified 562 in this document for resource consumer based ALTO server discovery is 563 generally NOT RECOMMENDED. Note that a less versatile yet simpler 564 approach for resource consumer initiated ALTO server discovery is 565 specified in [RFC7286]. 567 5.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility 569 The procedure specified in this document can discover ALTO server 570 URIs for a given IP address or prefix. The intention is, that a 571 third party (e.g., a resource directory) that receives query messages 572 from a resource consumer can use the source address in these messages 573 to discover suitable ALTO servers for this specific resource 574 consumer. 576 However, resource consumers (as defined in Section 2 of [RFC5693]) 577 may reside on hosts with more than one IP address, e.g., due to 578 IPv4/v6 dual stack operation and/or multihoming. IP packets sent 579 with different source addresses may be subject to different routing 580 policies and path costs. In some deployment scenarios, it may even 581 be required to ask different sets of ALTO servers for guidance. 582 Furthermore, source addresses in IP packets may be modified en-route 583 by Network Address Translators (NAT). 585 If a resource consumer queries a resource directory for candidate 586 resource providers, the locally selected (and possibly en-route 587 translated) source address of the query message - as observed by the 588 resource directory - will become the basis for the ALTO server 589 discovery and the subsequent optimization of the resource directory's 590 reply. If, however, the resource consumer then selects different 591 source addresses to contact returned resource providers, the desired 592 better-than-random "ALTO effect" may not occur. 594 Therefore, a dual stack or multihomed resource consumer SHOULD either 595 always use the same address for contacting the resource directory and 596 the resource providers, i.e., overriding the operating system's 597 automatic source IP address selection, or use resource consumer based 598 ALTO server discovery [RFC7286] to discover suitable ALTO servers for 599 every local address and then locally perform ALTO-influenced resource 600 consumer selection and source address selection. Similarly, resource 601 consumers on mobile hosts SHOULD query the resource directory again 602 after a change of IP address, in order to get a list of candidate 603 resource providers that is optimized for the new IP address. 605 5.2. Deployment Considerations for Network Operators 607 5.2.1. Separation of Interests 609 We assume that if two organizations share parts of their DNS 610 infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa. 611 subdomains, they will also be able to operate a common ALTO server, 612 which still may do redirections if desired or required by policies. 614 Note that the ALTO server discovery procedure is supposed to produce 615 only a first URI of an ALTO server that can give reasonable guidance 616 to the client. An ALTO server can still return different results 617 based on the client's address (or other identifying properties) or 618 redirect the client to another ALTO server using mechanisms of the 619 ALTO protocol (see Sect. 9 of [RFC7285]). 621 6. Security Considerations 623 A high-level discussion of security issues related to ALTO is part of 624 the ALTO problem statement [RFC5693]. A classification of unwanted 625 information disclosure risks, as well as specific security-related 626 requirements can be found in the ALTO requirements document 627 [RFC6708]. 629 The remainder of this section focuses on security threats and 630 protection mechanisms for the cross-domain ALTO server discovery 631 procedure as such. Once the ALTO server's URI has been discovered 632 and the communication between the ALTO client and the ALTO server 633 starts, the security threats and protection mechanisms discussed in 634 the ALTO protocol specification [RFC7285] apply. 636 6.1. Integrity of the ALTO Server's URI 638 Scenario Description 639 An attacker could compromise the ALTO server discovery procedure 640 or infrastructure in a way that ALTO clients would discover a 641 "wrong" ALTO server URI. 643 Threat Discussion 644 This is probably the most serious security concern related to ALTO 645 server discovery. The discovered "wrong" ALTO server might not be 646 able to give guidance to a given ALTO client at all, or it might 647 give suboptimal or forged information. In the latter case, an 648 attacker could try to use ALTO to affect the traffic distribution 649 in the network or the performance of applications (see also 650 Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server 651 could threaten user privacy (see also Section 5.2.1, case (5a) in 652 [RFC6708]). 654 However, it should also be noted that, if an attacker was able to 655 compromise the DNS infrastructure used for cross-domain ALTO 656 server discovery, (s)he could also launch significantly more 657 serious other attacks (e.g., redirecting various application 658 protocols). 660 Protection Strategies and Mechanisms 661 The cross-domain ALTO server discovery procedure relies on a 662 series of DNS lookups. If an attacker was able to modify or spoof 663 any of the DNS records, the resulting URI could be replaced by a 664 forged URI. The application of DNS security (DNSSEC) [RFC4033] 665 provides a means to limit attacks that rely on modification of the 666 DNS records while in transit. Additional operational precautions 667 for safely operating the DNS infrastructure are required in order 668 to ensure that name servers do not sign forged (or otherwise 669 "wrong") resource records. Security considerations specific to 670 U-NAPTR are described in more detail in [RFC4848]. 672 A related risk is the impersonation of the ALTO server (i.e., 673 attacks after the correct URI has been discovered). This threat 674 and protection strategies are discussed in Section 15.1 of 675 [RFC7285]. Note that if TLS is used to protect ALTO, the server 676 certificate will contain the host name (CN). Consequently, only 677 the host part of the HTTPS URI will be authenticated, i.e., the 678 result of the ALTO server discovery procedure. The DNS/U-NAPTR 679 based mapping within the cross-domain ALTO server discovery 680 procedure needs to be secured as described above, e.g., by using 681 DNSSEC. 683 In addition to active protection mechanisms, users and network 684 operators can monitor application performance and network traffic 685 patterns for poor performance or abnormalities. If it turns out 686 that relying on the guidance of a specific ALTO server does not 687 result in better-than-random results, the usage of the ALTO server 688 may be discontinued (see also Section 15.2 of [RFC7285]). 690 6.2. Availability of the ALTO Server Discovery Procedure 692 Scenario Description 693 An attacker could compromise the cross-domain ALTO server 694 discovery procedure or infrastructure in a way that ALTO clients 695 would not be able to discover any ALTO server. 697 Threat Discussion 698 If no ALTO server can be discovered (although a suitable one 699 exists) applications have to make their decisions without ALTO 700 guidance. As ALTO could be temporarily unavailable for many 701 reasons, applications must be prepared to do so. However, The 702 resulting application performance and traffic distribution will 703 correspond to a deployment scenario without ALTO. 705 Protection Strategies and Mechanisms 706 Operators should follow best current practices to secure their DNS 707 and ALTO (see Section 15.5 of [RFC7285]) servers against Denial- 708 of-Service (DoS) attacks. 710 6.3. Confidentiality of the ALTO Server's URI 712 Scenario Description 713 An unauthorized party could invoke the cross-domain ALTO server 714 discovery procedure, or intercept discovery messages between an 715 authorized ALTO client and the DNS servers, in order to acquire 716 knowledge of the ALTO server URI for a specific IP address. 718 Threat Discussion 719 In the ALTO use cases that have been described in the ALTO problem 720 statement [RFC5693] and/or discussed in the ALTO working group, 721 the ALTO server's URI as such has always been considered as public 722 information that does not need protection of confidentiality. 724 Protection Strategies and Mechanisms 725 No protection mechanisms for this scenario have been provided, as 726 it has not been identified as a relevant threat. However, if a 727 new use case is identified that requires this kind of protection, 728 the suitability of this ALTO server discovery procedure as well as 729 possible security extensions have to be re-evaluated thoroughly. 731 6.4. Privacy for ALTO Clients 733 Scenario Description 734 An unauthorized party could intercept messages between an ALTO 735 client and the DNS servers, and thereby find out the fact that 736 said ALTO client uses (or at least tries to use) the ALTO service 737 in order to optimize traffic from/to a specific IP address. 739 Threat Discussion 740 In the ALTO use cases that have been described in the ALTO problem 741 statement [RFC5693] and/or discussed in the ALTO working group, 742 this scenario has not been identified as a relevant threat. 744 Protection Strategies and Mechanisms 745 No protection mechanisms for this scenario have been provided, as 746 it has not been identified as a relevant threat. However, if a 747 new use case is identified that requires this kind of protection, 748 the suitability of this ALTO server discovery procedure as well as 749 possible security extensions have to be re-evaluated thoroughly. 751 7. IANA Considerations 753 This document does not require any IANA action. 755 8. References 757 8.1. Normative References 759 [RFC1035] Mockapetris, P., "Domain names - implementation and 760 specification", STD 13, RFC 1035, November 1987. 762 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 763 Requirement Levels", BCP 14, RFC 2119, March 1997. 765 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 766 Part Three: The Domain Name System (DNS) Database", 767 RFC 3403, October 2002. 769 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 770 "DNS Extensions to Support IP Version 6", RFC 3596, 771 October 2003. 773 [RFC4848] Daigle, L., "Domain-Based Application Service Location 774 Using URIs and the Dynamic Delegation Discovery Service 775 (DDDS)", RFC 4848, April 2007. 777 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 778 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 779 May 2017, . 781 8.2. Informative References 783 [I-D.kiesel-alto-alto4alto] 784 Kiesel, S., "Using ALTO for ALTO server selection", 785 draft-kiesel-alto-alto4alto-00 (work in progress), 786 July 2010. 788 [I-D.kiesel-alto-ip-based-srv-disc] 789 Kiesel, S. and R. Penno, "Application-Layer Traffic 790 Optimization (ALTO) Anycast Address", 791 draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), 792 July 2014. 794 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 795 Self-Address Fixing (UNSAF) Across Network Address 796 Translation", RFC 3424, November 2002. 798 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 799 Rose, "DNS Security Introduction and Requirements", 800 RFC 4033, March 2005. 802 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 803 Architecture", RFC 4291, DOI 10.17487/RFC4291, 804 February 2006, . 806 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 807 (CIDR): The Internet Address Assignment and Aggregation 808 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, 809 August 2006, . 811 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 812 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 813 October 2008. 815 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 816 Optimization (ALTO) Problem Statement", RFC 5693, 817 October 2009. 819 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 820 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 821 Requirements", RFC 6708, September 2012. 823 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 824 (LIS) Discovery Using IP Addresses and Reverse DNS", 825 RFC 7216, April 2014. 827 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 828 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 829 Traffic Optimization (ALTO) Protocol", RFC 7285, 830 September 2014. 832 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 833 H. Song, "Application-Layer Traffic Optimization (ALTO) 834 Server Discovery", RFC 7286, June 2014. 836 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 837 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 838 Deployment Considerations", RFC 7971, DOI 10.17487/ 839 RFC7971, October 2016, 840 . 842 Appendix A. Multiple Information Sources and Partitioned Knowledge 844 The ALTO base protocol document [RFC7285] specifies the communication 845 between an ALTO client and a single ALTO server. It is implicitly 846 assumed that this server can answer any query, possibly with some 847 kind of default value if no exact data is known. No special 848 provisions were made for the case that the ALTO information 849 originates from multiple sources, which are possibly under the 850 control of different administrative entities (e.g., different ISPs) 851 or that the overall ALTO information is partitioned and stored on 852 several ALTO servers. 854 A.1. Classification of Solution Approaches 856 Various protocol extensions and other solutions have been proposed to 857 deal with multiple information sources and partitioned knowledge. 858 They can be classified as follows: 860 1 Ensure that all ALTO servers have the same knowledge 862 1.1 Ensure data replication and synchronization within the 863 provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]). 865 1.2 Use an Inter-ALTO-server data replication protocol. Possibly, 866 the ALTO protocol itself - maybe with some extensions - could be 867 used for that purpose; however, this has not been studied in 868 detail so far. 870 2 Accept that different ALTO servers (possibly operated by 871 different organizations, e.g., ISPs) do not have the same 872 knowledge 874 2.1 Allow ALTO clients to send arbitrary queries to any ALTO server 875 (e.g. the one discovered using [RFC7286]). If this server 876 cannot answer the query itself, it will fetch the data on behalf 877 of the client, using the ALTO protocol or a to-be-defined inter- 878 ALTO-server request forwarding protocol. 880 2.2 Allow ALTO clients to send arbitrary queries to any ALTO server 881 (e.g. the one discovered using [RFC7286]). If this server 882 cannot answer the query itself, it will redirect the client to 883 the "right" ALTO server that has the desired information, using 884 a small to-be-defined extension of the ALTO protocol. 886 2.3 ALTO clients need to use some kind of "search engine" that 887 indexes ALTO servers and redirects and/or gives cached results. 889 2.4 ALTO clients need to use a new discovery mechanism to discover 890 the ALTO server that has the desired information and contact it 891 directly. 893 A.2. Discussion of Solution Approaches 895 The provisioning or initialization protocol for ALTO servers (cf. RFC 896 5693, Fig 1 [RFC5693]) is currently not standardized. It was a 897 conscious decision not to include this in the scope of the IETF ALTO 898 working group. The reason is that there are many different kinds of 899 information sources. This implementation specific protocol will 900 adapt them to the ALTO server, which offers a standardized protocol 901 to the ALTO clients. However, adding the task of synchronization 902 between ALTO servers to this protocol (i.e., approach 1.1) would 903 overload this protocol with a second functionality that requires 904 standardization for seamless multi-domain operation. 906 For the 1.? solution approaches, in addition to general technical 907 feasibility and issues like overhead and caching efficiency, another 908 aspect to consider is legal liability. Operator "A" might prefer not 909 to publish information about nodes in or paths between the networks 910 of operators "B" and "C" through A's ALTO server, even if A knew that 911 information. This is not only a question of map size and processing 912 load on A's ALTO server. Operator A could also face legal liability 913 issues if that information had a bad impact on the traffic 914 engineering between B's and C's networks, or on their business 915 models. 917 No specific actions to build a "search engine" based solution 918 (approach 2.3) are currently known and it is unclear what could be 919 the incentives to operate such an engine. Therefore, this approach 920 is not considered in the remainder of this document. 922 A.3. The Need for Cross-Domain ALTO Server Discovery 924 Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the 925 specification of an ALTO protocol extension or a new protocol that 926 runs between ALTO servers. A large-scale, maybe Internet-wide, 927 multi-domain deployment would also need mechanisms by which an ALTO 928 server could discover other ALTO servers, learn which information is 929 available where, and ideally also who is authorized to publish 930 information related to a given part of the network. Approach 2.4 931 needs the same mechanisms, except that they are used on the client- 932 side instead of the server-side. 934 It is sometimes questioned whether there is a need for a solution 935 that allows clients to ask arbitrary queries, even if the ALTO 936 information is partitioned and stored on many ALTO servers. The main 937 argument is, that clients are supposed to optimize the traffic from 938 and to themselves, and that the information needed for that is most 939 likely stored on a "nearby" ALTO server, i.e., the one that can be 940 discovered using [RFC7286]. However, there are scenarios where the 941 ALTO client is not co-located with an endpoint of the to-be-optimized 942 data transmission. Instead, the ALTO client is located at a third 943 party, which takes part in the application signaling, e.g., a so- 944 called "tracker" in a peer-to-peer application. One such scenario, 945 where it is advantageous to place the ALTO client not at an endpoint 946 of the user data transmission, is analyzed in Appendix C. 948 A.4. Our Solution Approach 950 Several solution approaches for cross-domain ALTO server discovery 951 have been evaluated, using the criteria documented in Appendix B. 952 One of them was to use the ALTO protocol itself for the exchange of 953 information availability [I-D.kiesel-alto-alto4alto]. However, the 954 drawback of that approach is that a new registration administration 955 authority would have to be established. 957 This document specifies a DNS-based procedure for cross-domain ALTO 958 server discovery, which was inspired by "Location Information Server 959 (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The 960 primary goal is that this procedure can be used on the client-side 961 (i.e., approach 2.4), but together with new protocols or protocol 962 extensions it could also be used to implement the other solution 963 approaches itemized above. 965 A.5. Relation to the ALTO Requirements 967 During the design phase of the overall ALTO solution, two different 968 server discovery scenarios have been identified and documented in the 969 ALTO requirements document [RFC6708]. The first scenario, documented 970 in Req. AR-32, can be supported using the discovery mechanisms 971 specified in [RFC7286]. An alternative approach, based on IP anycast 972 [I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This 973 document, in contrast, tries to address Req. AR-33. 975 Appendix B. Requirements for ALTO Cross-Domain Server Discovery 977 This appendix itemizes requirements that have been collected before 978 the design phase and that are reflected by the design of the ALTO 979 Cross-Domain Server Discovery Procedure. 981 B.1. Discovery Client Application Programming Interface 983 The discovery client will be called through some kind of application 984 programming interface (API) and the parameters will be an IP address 985 and, for purposes of extensibility, a service identifier such as 986 "ALTO". It will return one or more URI(s) that offers the requested 987 service ("ALTO") for the given IP address. 989 In other words, the client would be used to retrieve a mapping: 991 (IP address, "ALTO") -> IRD-URI(s) 993 where IRD-URI(s) is one or more URI(s) of Information Resource 994 Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that 995 can give reasonable guidance to a resource consumer with the 996 indicated IP address. 998 B.2. Data Storage and Authority Requirements 1000 The information for mapping IP addresses and service parameters to 1001 URIs should be stored in a - preferably distributed - database. It 1002 must be possible to delegate administration of parts of this 1003 database. Usually, the mapping from a specific IP address to an URI 1004 is defined by the authority that has administrative control over this 1005 IP address, e.g., the ISP in residential access networks or the IT 1006 department in enterprise, university, or similar networks. 1008 B.3. Cross-Domain Operations Requirements 1010 The cross-domain server discovery mechanism should be designed in 1011 such a way that it works across the public Internet and also in other 1012 IP-based networks. This in turn means that such mechanisms cannot 1013 rely on protocols that are not widely deployed across the Internet or 1014 protocols that require special handling within participating 1015 networks. An example is multicast, which is not generally available 1016 across the Internet. 1018 The ALTO Cross-Domain Server Discovery protocol must support gradual 1019 deployment without a network-wide flag day. If the mechanism needs 1020 some kind of well-known "rendezvous point", re-using an existing 1021 infrastructure (such as the DNS root servers or the WHOIS database) 1022 should be preferred over establishing a new one. 1024 B.4. Protocol Requirements 1026 The protocol must be able to operate across middleboxes, especially 1027 across NATs and firewalls. 1029 The protocol shall not require any pre-knowledge from the client 1030 other than any information that is known to a regular IP host on the 1031 Internet. 1033 B.5. Further Requirements 1035 The ALTO cross domain server discovery cannot assume that the server 1036 discovery client and the server discovery responding entity are under 1037 the same administrative control. 1039 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications 1041 This appendix illustrates one ALTO use case and shows that ALTO 1042 Cross-Domain Server Discovery is beneficial in that scenario. 1044 C.1. Architectural Options 1046 The ALTO protocol specification [RFC7285] details how an ALTO client 1047 can query an ALTO server for guiding information and receive the 1048 corresponding replies. However, in the considered scenario of a 1049 tracker-based P2P application, there are two fundamentally different 1050 possibilities where to place the ALTO client: 1052 1. ALTO client in the resource consumer ("peer") 1054 2. ALTO client in the resource directory ("tracker") 1056 In the following, both scenarios are compared in order to explain the 1057 need for ALTO queries on behalf of remote resource consumers. 1059 In the first scenario (see Figure 2), the resource consumer queries 1060 the resource directory for the desired resource (F1). The resource 1061 directory returns a list of potential resource providers without 1062 considering ALTO (F2). It is then the duty of the resource consumer 1063 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 1064 list. 1066 In the second scenario (see Figure 4), the resource directory has an 1067 embedded ALTO client. After receiving a query for a given resource 1068 (F1) the resource directory invokes this ALTO client to evaluate all 1069 resource providers it knows (F2/F3). Then it returns a, possibly 1070 shortened, list containing the "best" resource providers to the 1071 resource consumer (F4). 1073 ............................. ............................. 1074 : Tracker : : Peer : 1075 : ______ : : : 1076 : +-______-+ : : k good : 1077 : | | +--------+ : P2P App. : +--------+ peers +------+ : 1078 : | N | | random | : Protocol : | ALTO- |------>| data | : 1079 : | known |====>| pre- |*************>| biased | | ex- | : 1080 : | peers, | | selec- | : transmit : | peer |------>| cha- | : 1081 : | M good | | tion | : n peer : | select | n-k | nge | : 1082 : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : 1083 :...........................: :.....^.....................: 1084 | 1085 | ALTO 1086 | client protocol 1087 __|___ 1088 +-______-+ 1089 | | 1090 | ALTO | 1091 | server | 1092 +-______-+ 1094 Figure 1: Tracker-based P2P Application with random peer preselection 1096 Peer w. ALTO cli. Tracker ALTO Server 1097 --------+-------- --------+-------- --------+-------- 1098 | F1 Tracker query | | 1099 |======================>| | 1100 | F2 Tracker reply | | 1101 |<======================| | 1102 | F3 ALTO client protocol query | 1103 |---------------------------------------------->| 1104 | F4 ALTO client protocol reply | 1105 |<----------------------------------------------| 1106 | | | 1108 ==== Application protocol (i.e., tracker-based P2P app protocol) 1109 ---- ALTO client protocol 1111 Figure 2: Basic message sequence chart for resource consumer- 1112 initiated ALTO query 1114 ............................. ............................. 1115 : Tracker : : Peer : 1116 : ______ : : : 1117 : +-______-+ : : : 1118 : | | +--------+ : P2P App. : k good peers & +------+ : 1119 : | N | | ALTO- | : Protocol : n-k bad peers | data | : 1120 : | known |====>| biased |******************************>| ex- | : 1121 : | peers, | | peer | : transmit : | cha- | : 1122 : | M good | | select | : n peer : | nge | : 1123 : +-______-+ +--------+ : IDs : +------+ : 1124 :.....................^.....: :...........................: 1125 | 1126 | ALTO 1127 | client protocol 1128 __|___ 1129 +-______-+ 1130 | | 1131 | ALTO | 1132 | server | 1133 +-______-+ 1135 Figure 3: Tracker-based P2P Application with ALTO client in tracker 1137 Peer Tracker w. ALTO cli. ALTO Server 1138 --------+-------- --------+-------- --------+-------- 1139 | F1 Tracker query | | 1140 |======================>| | 1141 | | F2 ALTO cli. p. query | 1142 | |---------------------->| 1143 | | F3 ALTO cli. p. reply | 1144 | |<----------------------| 1145 | F4 Tracker reply | | 1146 |<======================| | 1147 | | | 1149 ==== Application protocol (i.e., tracker-based P2P app protocol) 1150 ---- ALTO client protocol 1152 Figure 4: Basic message sequence chart for ALTO query on behalf of 1153 remote resource consumer 1155 Note: the message sequences depicted in Figure 2 and Figure 4 may 1156 occur both in the target-aware and the target-independent query mode 1157 (c.f. [RFC6708]). In the target-independent query mode no message 1158 exchange with the ALTO server might be needed after the tracker 1159 query, because the candidate resource providers could be evaluated 1160 using a locally cached "map", which has been retrieved from the ALTO 1161 server some time ago. 1163 C.2. Evaluation 1165 The problem with the first approach is, that while the resource 1166 directory might know thousands of peers taking part in a swarm, the 1167 list returned to the resource consumer is usually shortened for 1168 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 1169 potential resource providers might not be contained in that list 1170 anymore, even before ALTO can consider them. 1172 For illustration, consider a simple model of a swarm, in which all 1173 peers fall into one of only two categories: assume that there are 1174 "good" ("good" in the sense of ALTO's better-than-random peer 1175 selection, based on an arbitrary desired rating criterion) and "bad' 1176 peers only. Having more different categories makes the maths more 1177 complex but does not change anything to the basic outcome of this 1178 analysis. Assume that the swarm has a total number of N peers, out 1179 of which are M "good" and N-M "bad" peers, which are all known to the 1180 tracker. A new peer wants to join the swarm and therefore asks the 1181 tracker for a list of peers. 1183 If, according to the first approach, the tracker randomly picks n 1184 peers from the N known peers, the result can be described with the 1185 hypergeometric distribution. The probability that the tracker reply 1186 contains exactly k "good" peers (and n-k "bad" peers) is: 1188 / M \ / N - M \ 1189 \ k / \ n - k / 1190 P(X=k) = --------------------- 1191 / N \ 1192 \ n / 1194 / n \ n! 1195 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 1196 k! (n-k)! 1198 The probability that the reply contains at most k "good" peers is: 1199 P(X<=k)=P(X=0)+P(X=1)+..+P(X=k). 1201 For example, consider a swarm with N=10,000 peers known to the 1202 tracker, out of which M=100 are "good" peers. If the tracker 1203 randomly selects n=100 peers, the formula yields for the reply: 1204 P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% 1205 this list does not contain a single "good" peer, and with 99% 1206 probability there are only four or less of the "good" peers on the 1207 list. Processing this list with the guiding ALTO information will 1208 ensure that the few favorable peers are ranked to the top of the 1209 list; however, the benefit is rather limited as the number of 1210 favorable peers in the list is just too small. 1212 Much better traffic optimization could be achieved if the tracker 1213 would evaluate all known peers using ALTO, and return a list of 100 1214 peers afterwards. This list would then include a significantly 1215 higher fraction of "good" peers. (Note, that if the tracker returned 1216 "good" peers only, there might be a risk that the swarm might 1217 disconnect and split into several disjunct partitions. However, 1218 finding the right mix of ALTO-biased and random peer selection is out 1219 of the scope of this document.) 1221 Therefore, from an overall optimization perspective, the second 1222 scenario with the ALTO client embedded in the resource directory is 1223 advantageous, because it is ensured that the addresses of the "best" 1224 resource providers are actually delivered to the resource consumer. 1225 An architectural implication of this insight is that the ALTO server 1226 discovery procedures must support ALTO queries on behalf of remote 1227 resource consumers. That is, as the tracker issues ALTO queries on 1228 behalf of the peer which contacted the tracker, the tracker must be 1229 able to discover an ALTO server that can give guidance suitable for 1230 that respective peer. This task can be solved using the ALTO Cross- 1231 Domain Server Discovery Procedure. 1233 C.3. Example 1235 This section provides a complete example of the ALTO Cross-Domain 1236 Server Discovery Procedure in a tracker-based peer-to-peer scenario. 1238 The example is based on the network topology shown in Figure 5. Five 1239 access networks - Networks a, b, c, x, and t - are operated by five 1240 different network operators. They are interconnected by a backbone 1241 structure. Each network operator runs an ALTO server in their 1242 network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and 1243 ALTO_SRV_T, respectively. 1245 _____ __ _____ __ _____ __ 1246 __( )__( )_ __( )__( )_ __( )__( )_ 1247 ( Network a ) ( Network b ) ( Network c ) 1248 ( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C ) 1249 (__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __) 1250 (___)--(____) \ (___)--(____) / (___)--(____) 1251 \ / / 1252 ---+---------+-----------------+---- 1253 ( Backbone ) 1254 ------------+------------------+---- 1255 _____ __/ _____ \__ 1256 __( )__( )_ __( )__( )_ 1257 ( Network x ) ( Network t ) 1258 ( Res. Consumer X ) (Resource Directory) 1259 (_ ALTO_SRV_X __) (_ ALTO_SRV_T __) 1260 (___)--(____) (___)--(____) 1262 Figure 5: Example network topology 1264 A new peer of a peer-to-peer application wants to join a specific 1265 swarm (overlay network), in order to access a specific resource. 1266 This new peer will be called "Resource Consumer X" in accordance to 1267 the terminology of [RFC6708] and it is located in Network x. It 1268 contacts the tracker ("Resource Directory"), which is located in 1269 Network t. The mechanism by which the new peer discovers the tracker 1270 is out of the scope of this document. The tracker maintains a list 1271 of peers that take part in the overlay network, and hence it can 1272 determine that Resource Providers A, B, and C are candidate peers for 1273 Resource Consumer X. 1275 As shown in the previous section, a tracker-side ALTO optimization 1276 (c.f. Figure 3 and Figure 4) is more efficient than a client-side 1277 optimization. Consequently, the tracker wants to use the ALTO 1278 Endpoint Cost Service (ECS) to learn the routing costs between X and 1279 A, X and B, as well as X and C, in order to sort A, B, and C by their 1280 respective routing costs to X. 1282 In theory, there are many options how the ALTO Cross-Domain Server 1283 Discovery Procedure could be used. For example, the tracker could do 1284 the following steps: 1286 IRD_URIS_A = XDOMDISC(A,"ALTO:https") 1287 COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A 1289 IRD_URIS_B = XDOMDISC(B,"ALTO:https") 1290 COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B 1292 IRD_URIS_C = XDOMDISC(C,"ALTO:https") 1293 COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C 1295 Maybe, the ALTO Cross-Domain Server Discovery Procedure queries would 1296 yield in this scenario: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = 1297 ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query 1298 would be sent to a different ALTO server. The problem with this 1299 approach is that we are not neccessarily able to compare COST_X_A, 1300 COST_X_B, and COST_X_C with each other. The specification of the 1301 routingcost metric mandates that "A lower value indicates a higher 1302 preference", but "an ISP may internally compute routing cost using 1303 any method that it chooses" (see section 6.1.1.1. of [RFC7285]). 1304 Thus, COST_X_A could be 10 (milliseconds round-trip time), while 1305 COST_X_B could be 200 (kilometers great circle distance between the 1306 approximate geographic locations of the hosts) and COST_X_C could be 1307 3 (router hops, corresponding to a decrease of the TTL field in the 1308 IP header). Each of these metrics fulfills the "lower value is more 1309 preferable" requirement on its own, but obviously, they cannot be 1310 compared with each other. Even if there was a reasonable formula to 1311 compare, for example, kilometers with milliseconds, we could not use 1312 it, as the units of measurement (or any other computation method for 1313 the routingcost) are sent not along with the value in the ECS reply. 1315 To avoid this problem, the tracker tries to send all ECS queries to 1316 the same ALTO server. As specified in Section 4.4 of this document, 1317 case 2, it uses the IP address of Resource Consumer x as parameter to 1318 the discovery procedure: 1320 IRD_URIS_X = XDOMDISC(X,"ALTO:https") 1321 COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X 1322 COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X 1323 COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X 1325 This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be 1326 compared with each other. 1328 As been said, the tracker calls the ALTO Cross-Domain Server 1329 Discovery Procedure with IP address X as a parameter. For the 1330 reminder of this example, we assume that X = 2001:DB8:1:2:227:eff: 1331 fe6a:de42. Thus, the procedure call is 1333 IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https"). 1335 The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6 1336 address. Thus, we get AT = "IPv6", A = 2001:DB8:1:2:227:eff:fe6a: 1337 de42, L = 128, and SP = "ALTO:https". 1339 The procedure constructs (see Step 1 in Section 3.2) 1340 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. 1341 8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3) 1342 R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 1343 R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 1344 R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and 1345 R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". 1347 In order to illustrate the third step of the ALTO Cross-Domain Server 1348 Discovery Procedure, we use the "dig" (domain information groper) DNS 1349 lookup utility that is available for many operating systems (e.g., 1350 Linux). A real implementation of the ALTO Cross-Domain Server 1351 Discovery Procedure would not be based on the "dig" utility, but use 1352 appropriate libraries and/or operating system APIs. Please note that 1353 the following steps have been performed in a controlled lab 1354 environment with a appropriately configured name server. A suitable 1355 DNS configuration will be needed to reproduce these results. Please 1356 also note that the rather verbose output of the "dig" tool has been 1357 shortened to the relevant lines. 1359 Since AT = "IPv6" and L = 128, in the table given in Section 3.4, the 1360 sixth row (not counting the column headers) applies. 1362 As mandated by the third column, we start with a lookup of R128, 1363 looking for NAPTR resource records: 1365 | sk@labpc12:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\ 1366 | 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1367 | 1368 | ;; Got answer: 1369 | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553 1370 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 1372 The domain name R128 does not exist (status: NXDOMAIN), so we cannot 1373 get a useful result. Therefore, we continue with the fourth column 1374 of the table and do a lookup of R64: 1376 | sk@labpc12:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1377 | 1378 | ;; Got answer: 1379 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193 1380 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 1382 The domain name R64 could be looked up (status: NOERROR), but there 1383 are no NAPTR resource records associated with it (ANSWER: 0). Maybe, 1384 there are some other resource records such as PTR, NS, or SOA, but we 1385 are not interested in them. Thus, we do not get a useful result and 1386 we continue with looking up R56: 1388 | sk@labpc12:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1389 | 1390 | ;; Got answer: 1391 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966 1392 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 1393 | 1394 | ;; ANSWER SECTION: 1395 | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 1396 | "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" . 1397 | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u" 1398 | "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" . 1400 The domain name R56 could be looked up and there are NAPTR resource 1401 records associated with it. However, each of these records has a 1402 service parameter that does not match our SP = "ALTO:https" (see 1403 [RFC7216] for "LIS:HELD"), and therefore, we have to ignore them. 1404 Consequently, we still do not have a useful result and continue with 1405 a lookup of R48: 1407 | sk@labpc12:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1408 | 1409 | ;; Got answer: 1410 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459 1411 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 1412 | 1413 | ;; ANSWER SECTION: 1414 | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 1415 | "ALTO:https" "!.*!https://alto1.example.net/ird!" . 1416 | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 1417 | "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" . 1419 This lookup yields two NAPTR resource records. We have to ignore the 1420 second one as its service parameter does not match our SP, but the 1421 first NAPTR resource record has a matching service parameter. 1422 Therefore, the procedure terminates successfully and the final 1423 outcome is: IRD_URIS_X = "https://alto1.example.net/ird". 1425 The ALTO client that is embedded in the tracker will access the ALTO 1426 Information Resource Directory (IRD, see Section 9 of [RFC7285]) at 1427 this URI, look for the Endpoint Cost Service (ECS, see Section 11.5 1428 of [RFC7285]), and query the ECS for the costs between A and X, B and 1429 X, as well as C and X, before returning an ALTO-optimized list of 1430 candidate resource providers to resource consumer X. 1432 Appendix D. Contributors List and Acknowledgments 1434 The initial version of this document was co-authored by Marco Tomsu 1435 (Alcatel-Lucent). 1437 This document borrows some text from [RFC7286], as historically, it 1438 has been part of the draft that eventually became said RFC. Special 1439 thanks to Michael Scharf and Nico Schwan. 1441 Authors' Addresses 1443 Sebastian Kiesel 1444 University of Stuttgart Information Center 1445 Allmandring 30 1446 Stuttgart 70550 1447 Germany 1449 Email: ietf-alto@skiesel.de 1450 URI: http://www.izus.uni-stuttgart.de 1452 Martin Stiemerling 1453 University of Applied Sciences Darmstadt, Computer Science Dept. 1454 Haardtring 100 1455 Darmstadt 64295 1456 Germany 1458 Phone: +49 6151 16 37938 1459 Email: mls.ietf@gmail.com 1460 URI: http://ietf.stiemerling.org