idnits 2.17.1 draft-kiesel-alto-xdom-disc-02.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], [RFC5693]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 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 907 has weird spacing: '... and n! =...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 7, 2016) is 2821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-15 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 5 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: Informational M. Stiemerling 5 Expires: January 8, 2017 H-DA 6 July 7, 2016 8 Application Layer Traffic Optimization (ALTO) Cross-Domain Server 9 Discovery 10 draft-kiesel-alto-xdom-disc-02 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 algorithm specified in this document takes one 29 IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or 30 "ALTO:https") as parameters. It performs DNS lookups (for NAPTR 31 resource records in the in-addr.arpa. or ip6.arpa. tree) and returns 32 one or more URI(s) of information resources related to that IP 33 address. 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", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of this Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 8, 2017. 61 Copyright Notice 63 Copyright (c) 2016 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Multiple Information Sources and Partitioned Knowledge . . 4 80 1.2. The Need for Cross-Domain ALTO Server Discovery . . . . . 5 81 1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 6 82 1.4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . 6 83 1.5. Document History . . . . . . . . . . . . . . . . . . . . . 7 84 1.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 2. ALTO Cross-Domain Server Discovery Procedure Specification . . 8 86 2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 87 2.2. Basic Principle . . . . . . . . . . . . . . . . . . . . . 8 88 2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 8 89 2.4. Step 2: Add Shortened Domain Names . . . . . . . . . . . . 9 90 2.5. Step 3: DNS lookups . . . . . . . . . . . . . . . . . . . 10 91 3. Using ALTO Cross-Domain Server Discovery with the ALTO 92 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 3.1. Endpoint Property Service . . . . . . . . . . . . . . . . 11 94 3.2. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11 95 3.3. Other ALTO services . . . . . . . . . . . . . . . . . . . 11 96 4. Implementation, Deployment, and Operational Considerations . . 12 97 4.1. Considerations for ALTO Clients . . . . . . . . . . . . . 12 98 4.2. Deployment Considerations for Network Operators . . . . . 13 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 100 5.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 14 101 5.2. Availability of the ALTO Server Discovery Procedure . . . 15 102 5.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 16 103 5.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 16 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 108 Appendix A. Requirements for ALTO Cross-Domain Server 109 Discovery . . . . . . . . . . . . . . . . . . . . . . 20 110 A.1. Discovery Client Application Programming Interface . . . . 20 111 A.2. Data Storage and Authority Requirements . . . . . . . . . 20 112 A.3. Cross-Domain Operations Requirements . . . . . . . . . . . 20 113 A.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 21 114 A.5. Further Requirements . . . . . . . . . . . . . . . . . . . 21 115 Appendix B. ALTO and Tracker-based Peer-to-Peer Applications . . 22 116 Appendix C. Contributors List and Acknowledgments . . . . . . . . 27 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 119 1. Introduction 121 The goal of Application-Layer Traffic Optimization (ALTO) is to 122 provide guidance to applications that have to select one or several 123 hosts from a set of candidates capable of providing a desired 124 resource [RFC5693]. ALTO is realized by an HTTP-based client-server 125 protocol [RFC7285], which can be used in various deployment scenarios 126 [I-D.ietf-alto-deployments]. 128 1.1. Multiple Information Sources and Partitioned Knowledge 130 The ALTO base protocol document [RFC7285] specifies the communication 131 between an ALTO client and a single ALTO server. It is implicitly 132 assumed that this server can answer any query, possibly with some 133 kind of default value if no exact data is known. No special 134 provisions were made for the case that the ALTO information 135 originates from multiple sources, which are possibly under the 136 control of different administrative entities (e.g., different ISPs) 137 or that the overall ALTO information is partitioned and stored on 138 several ALTO servers. 140 1.1.1. Classification of Solution Approaches 142 Various protocol extensions and other solutions have been proposed to 143 deal with multiple information sources and partitioned knowledge. 144 They can be classified as follows: 146 1 Ensure that all ALTO servers have the same knowlegde 148 1.1 Ensure data replication and synchronization within the 149 provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]). 151 1.2 Use an Inter-ALTO-server data replication protocol. Possibly, 152 the ALTO protocol itself - maybe with some extensions - could be 153 used for that purpose; however, this has not been studied in 154 detail so far. 156 2 Accept that different ALTO servers (possibly operated by 157 different organizations, e.g., ISPs) do not have the same 158 knowledge 160 2.1 Allow ALTO clients to send arbitrary queries to any ALTO server 161 (e.g. the one discovered using [RFC7286]). If this server 162 cannot answer the query itself, it will fetch the data on behalf 163 of the client, using the ALTO protocol or a to-be-defined inter- 164 ALTO-server request forwarding protocol. 166 2.2 Allow ALTO clients to send arbitrary queries to any ALTO server 167 (e.g. the one discovered using [RFC7286]). If this server 168 cannot answer the query itself, it will redirect the client to 169 the "right" ALTO server that has the desired information, using 170 a small to-be-defined extension of the ALTO protocol. 172 2.3 ALTO clients need to use some kind of "search engine" that 173 indexes ALTO servers and redirects and/or gives cached results. 175 2.4 ALTO clients need to use a new discovery mechanism to discover 176 the ALTO server that has the desired information and contact it 177 directly. 179 1.1.2. Discussion of Solution Approaches 181 The provisioning or initialization protocol for ALTO servers (cf. RFC 182 5693, Fig 1 [RFC5693]) is currently not standardized. It was a 183 conscious decision not to include this in the scope of the IETF ALTO 184 working group. The reason is that there are many different kinds of 185 information sources. This implementation specific protocol will 186 adapt them to the ALTO server, which offers a standardized protocol 187 to the ALTO clients. However, adding the task of synchronization 188 between ALTO servers to this protocol (i.e., approach 1.1) would 189 overload this protocol with a second functionality that requires 190 standardization for seamless multi-domain operation. 192 For the 1.? solution approaches, in addition to general technical 193 feasibility and issues like overhead and caching efficiency, another 194 aspect to consider is legal liability. Operator "A" might prefer not 195 to publish information about nodes in or paths between the networks 196 of operators "B" and "C" through A's ALTO server, even if A knew that 197 information. This is not only a question of map size and processing 198 load on A's ALTO server. Operator A could also face legal liability 199 issues if that information had a bad impact on the traffic 200 engineering between B's and C's networks, or on their business 201 models. 203 No specific actions to build a "search engine" based solution 204 (approach 2.3) are currently known and it is unclear what could be 205 the incentives to operate such an engine. Therefore, this approach 206 is not considered in the remainder of this document. 208 1.2. The Need for Cross-Domain ALTO Server Discovery 210 Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the 211 specification of an ALTO protocol extension or a new protocol that 212 runs between ALTO servers. A large-scale, maybe Internet-wide, 213 multi-domain deployment would also need mechanisms by which an ALTO 214 server could discover other ALTO servers, learn which information is 215 available where, and ideally also who is authorized to publish 216 information related to a given part of the network. Approach 2.4 217 needs the same mechanisms, except that they are used on the client- 218 side instead of the server-side. 220 It is sometimes questioned whether there is a need for a solution 221 that allows clients to ask arbitrary queries, even if the ALTO 222 information is partitioned and stored on many ALTO servers. The main 223 argument is, that clients are supposed to optimize the traffic from 224 and to themselves, and that the information needed for that is most 225 likely stored on a "nearby" ALTO server, i.e., the one that can be 226 discovered using [RFC7286]. However, there are scenarios where the 227 ALTO client is not co-located with an endpoint of the to-be-optimized 228 data transmission. Instead, the ALTO client is located at a third 229 party, which takes part in the application signaling, e.g., a so- 230 called "tracker" in a peer-to-peer application. One such scenario, 231 where it is advantageous to place the ALTO client not at an endpoint 232 of the user data transmission, is analyzed in Appendix B. 234 1.3. Solution Approach 236 Several solution approaches for cross-domain ALTO server discovery 237 have been evaluated, using the criteria documented in Appendix A. 238 One of them was to use the ALTO protocol itself for the exchange of 239 information availability [I-D.kiesel-alto-alto4alto]. However, the 240 drawback of that approach is that a new registration administration 241 authority would have to be established. 243 This document specifies a DNS-based procedure for cross-domain ALTO 244 server discovery, which was inspired by "Location Information Server 245 (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The 246 primary goal is that this procedure can be used on the client-side 247 (i.e., approach 2.4), but together with new protocols or protocol 248 extensions it could also be used to implement the other solution 249 approaches itemized above. 251 1.4. ALTO Requirements 253 During the design phase of the overall ALTO solution, two different 254 server discovery scenarios have been identified and documented in the 255 ALTO requirements document [RFC6708]. The first scenario, documented 256 in Req. AR-32, can be supported using the discovery mechanisms 257 specified in [RFC7286]. An alternative approach, based on IP anycast 258 [I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This 259 document, in contrast, tries to address Req. AR-33. 261 1.5. Document History 263 This document is a direct successor of [I-D.kiesel-alto-3pdisc] and 264 [I-D.kist-alto-3pdisc]. The scenario and mechanisms described here 265 and in these documents have been referred to as "third-party server 266 discovery" in the past. However, to avoid naming ambiguities with a 267 completely different scenario, it has been renamed to "ALTO Cross- 268 Domain Server Discovery". 270 1.6. Feedback 272 Comments and discussions about this document should be directed to 273 the ALTO working group: alto@ietf.org. 275 2. ALTO Cross-Domain Server Discovery Procedure Specification 277 2.1. Interface 279 The algorithm specified in this document takes one IP address and a 280 U-NAPTR [RFC4848] Service Parameter (i.e., "ALTO:http" or "ALTO: 281 https") as parameters. It performs DNS lookups (for NAPTR resource 282 records) and returns one or more URI(s) of information resources 283 related to that IP address. 285 2.2. Basic Principle 287 This algorithm closely follows [RFC7216] and re-uses parts of 288 [RFC7286]. 290 The algorithm sequentially tries two different lookup strategies. 291 First, an ALTO-specific U-NAPTR record is searched in the "reverse 292 tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. 293 corresponding to the given IP address. If this lookup does not yield 294 a usable result, further lookups with truncated domain names may be 295 tried. The goal is to allow deployment scenarios that require fine- 296 grained discovery on a per-IP basis, as well as large-scale scenarios 297 where discovery is to be enabled for a large number of IP addresses 298 with a small number of additional DNS resource records. 300 2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup 302 This task takes the IP address parameter the procedure was called 303 with and constructs a domain name, which is used for DNS lookups in 304 subsequent tasks. 306 If the IP address given as a parameter to the procedure is an IPv4 307 address, the domain name is constructed according to the rules 308 specified in Section 3.5 of [RFC1035] and it is rooted in the in the 309 special domain "IN-ADDR.ARPA.". For IPv6 addresses, the construction 310 rules in Section 2.5 of [RFC3596] apply and the special domain 311 "IP6.ARPA." is used. 313 Example values for IPv4 and IPv6 addresses could be (Note: a line 314 break was added in the IPv6 example): 316 R:="3.100.51.198.in-addr.arpa." 318 R:="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. 319 1.0.0.2.ip6.arpa." 321 2.4. Step 2: Add Shortened Domain Names 323 This task creates a list of several additional domain names, based on 324 the domain name yielded in Step 1. 326 o For IP version 4, the domain name from Step 1 SHOULD be shortened 327 successively by one and two labels (i.e., purge the first or 328 second dot from the left and everything left of it, respectively), 329 and the results being added to the list. This corresponds to a 330 search on a /24 or /16 network prefix. 332 o For IP version 6, the domain name from Step 1 SHOULD be shortened 333 successively by 16, 18, 20, and 24 labels, and the results being 334 added to the list. This corresponds to a search on a /64, /56, 335 /48, or /32 network prefix. 337 This list is intended to provide network operators with a degree of 338 flexibility in where discovery-related resource records can be placed 339 without significantly increasing the number of DNS names that are 340 searched. This does not attach any other significance to these 341 specific zone cuts or create a classful addressing hierarchy based on 342 the reverse DNS tree. 344 For example, the IPv4 address "192.0.2.75" could result in a list of 345 domain names (with the result from Step 1 put in the first position): 347 o 75.2.0.192.in-addr.arpa. 349 o 2.0.192.in-addr.arpa. 351 o 0.192.in-addr.arpa. 353 Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could 354 result in a list: 356 o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0. 357 1.0.0.2.ip6.arpa. 359 o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 361 o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 363 o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 365 o 8.b.d.0.1.0.0.2.ip6.arpa. 367 The limited number of labels by which each name is shortened is 368 intended to limit the maximum number of DNS queries produced by a 369 single invocation of the cross-domain ALTO server discovery 370 procedure. No more than five U-NAPTR resolutions are invoked for 371 each IP address. 373 2.5. Step 3: DNS lookups 375 The list of domain names which was created in the previous step is 376 sequentially (from longest to shortest name) processed, as described 377 in Section 3.2 of RFC 7286 [RFC7286]. 379 3. Using ALTO Cross-Domain Server Discovery with the ALTO Protocol 381 TBD: expand 383 3.1. Endpoint Property Service 385 If an ALTO client wants to query the Endpoint Property Service (see 386 Section 11.4 of RFC 7285 [RFC7285]) for an endpoint with IP address 387 X, it has to invoke the cross-domain ALTO server discovery procedure 388 with parameter X. The result will be the IRD URI of the ALTO server 389 to query. 391 3.2. Endpoint Cost Service 393 If an ALTO client wants to query the Endpoint Cost Service (see 394 Section 11.5 of RFC 7285 [RFC7285]) for the costs from source address 395 X to destination address(es) Y (and Z), it has to invoke the cross- 396 domain ALTO server discovery procedure with parameter X. The result 397 will be the IRD URI of the ALTO server to query for the costs from X 398 to Y (and Z).. 400 3.3. Other ALTO services 402 TBD. In particular, how to assemble a NxN network map from 403 individual snippets (1xN vectors?) retrieved from different ALTO 404 servers? 406 4. Implementation, Deployment, and Operational Considerations 408 4.1. Considerations for ALTO Clients 410 4.1.1. Resource Consumer Initiated Discovery 412 To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource 413 consumer initiated ALTO server discovery, can be seen as a special 414 case of cross-domain ALTO server discovery. To that end, an ALTO 415 client embedded in a resouce consumer would have to figure out its 416 own "public" IP address and perform the procedures described in this 417 document on that address. However, due to the widespread deployment 418 of Network Address Translators (NAT), additional protocols and 419 mechanisms such as STUN [RFC5389] would be needed and considerations 420 for UNSAF [RFC3424] apply. Therefore, using the procedures specified 421 in this document for resource consumer based ALTO server discovery is 422 generally NOT RECOMMENDED. Note that a less versatile yet simpler 423 approach for resource consumer initiated ALTO server discovery is 424 specified in [RFC7286]. 426 4.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility 428 The algortihm specified in this document can discover ALTO server 429 URIs for a given IP address. The intention is, that a third party 430 (e.g., a resource directory) that receives query messages from a 431 resource consumer can use the source address in these messages to 432 discover suitable ALTO servers for this specific resource consumer. 434 However, resource consumers (as defined in Section 2 of [RFC5693]) 435 may reside on hosts with more than one IP address, e.g., due to 436 IPv4/v6 dual stack operation and/or multihoming. IP packets sent 437 with different source addresses may be subject to different routing 438 policies and path costs. In some deployment scenarios, it may even 439 be required to ask different sets of ALTO servers for guidance. 440 Furthermore, source addresses in IP packets may be modified en-route 441 by Network Address Translators (NAT). 443 If a resource consumer queries a resource directory for candidate 444 resource providers, the locally selected (and possibly en-route 445 translated) source address of the query message - as observed by the 446 resource directory - will become the basis for the ALTO server 447 discovery and the subsequent optimization of the resource directory's 448 reply. If, however, the resource consumer then selects different 449 source addresses to contact returned resource providers, the desired 450 better-than-random "ALTO effect" may not occur. 452 Therefore, a dual stack or multihomed resource consumer SHOULD either 453 always use the same address for contacting the resource directory and 454 the resource providers, i.e., overriding the operating system's 455 automatic source IP address selection, or use resource consumer based 456 ALTO server discovery [RFC7286] to discover suitable ALTO servers for 457 every local address and then locally perform ALTO-influenced resource 458 consumer selection and source address selection. Similarly, resource 459 consumers on mobile hosts SHOULD query the resource directory again 460 after a change of IP address, in order to get a list of candidate 461 resource providers that is optimized for the new IP address. 463 4.2. Deployment Considerations for Network Operators 465 4.2.1. Separation of Interests 467 We assume that if two organizations share parts of their DNS 468 infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa. 469 subdomains, they will also be able to operate a common ALTO server, 470 which still may do redirections if desired or required by policies. 472 Note that the ALTO server discovery procedure is supposed to produce 473 only a first URI of an ALTO server that can give reasonable guidance 474 to the client. An ALTO server can still return different results 475 based on the client's address (or other identifying properties) or 476 redirect the client to another ALTO server using mechanisms of the 477 ALTO protocol (see Sect. 9 of [RFC7285]). 479 5. Security Considerations 481 A high-level discussion of security issues related to ALTO is part of 482 the ALTO problem statement [RFC5693]. A classification of unwanted 483 information disclosure risks, as well as specific security-related 484 requirements can be found in the ALTO requirements document 485 [RFC6708]. 487 The remainder of this section focuses on security threats and 488 protection mechanisms for the cross-domain ALTO server discovery 489 procedure as such. Once the ALTO server's URI has been discovered 490 and the communication between the ALTO client and the ALTO server 491 starts, the security threats and protection mechanisms discussed in 492 the ALTO protocol specification [RFC7285] apply. 494 5.1. Integrity of the ALTO Server's URI 496 Scenario Description 497 An attacker could compromise the ALTO server discovery procedure 498 or infrastructure in a way that ALTO clients would discover a 499 "wrong" ALTO server URI. 501 Threat Discussion 502 This is probably the most serious security concern related to ALTO 503 server discovery. The discovered "wrong" ALTO server might not be 504 able to give guidance to a given ALTO client at all, or it might 505 give suboptimal or forged information. In the latter case, an 506 attacker could try to use ALTO to affect the traffic distribution 507 in the network or the performance of applications (see also 508 Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server 509 could threaten user privacy (see also Section 5.2.1, case (5a) in 510 [RFC6708]). 512 However, it should also be noted that, if an attacker was able to 513 compromise the DNS infrastructure used for cross-domain ALTO 514 server discovery, (s)he could also launch significantly more 515 serious other attacks (e.g., redirecting various application 516 protocols). 518 Protection Strategies and Mechanisms 519 The cross-domain ALTO server discovery procedure relies on a 520 series of DNS lookups. If an attacker was able to modify or spoof 521 any of the DNS records, the resulting URI could be replaced by a 522 forged URI. The application of DNS security (DNSSEC) [RFC4033] 523 provides a means to limit attacks that rely on modification of the 524 DNS records while in transit. Additional operational precautions 525 for safely operating the DNS infrastructure are required in order 526 to ensure that name servers do not sign forged (or otherwise 527 "wrong") resource records. Security considerations specific to 528 U-NAPTR are described in more detail in [RFC4848]. 530 A related risk is the impersonation of the ALTO server (i.e., 531 attacks after the correct URI has been discovered). This threat 532 and protection strategies are discussed in Section 15.1 of 533 [RFC7285]. Note that if TLS is used to protect ALTO, the server 534 certificate will contain the host name (CN). Consequently, only 535 the host part of the HTTPS URI will be authenticated, i.e., the 536 result of the ALTO server discovery procedure. The DNS/U-NAPTR 537 based mapping within the cross-domain ALTO server discovery 538 procedure needs to be secured as described above, e.g., by using 539 DNSSEC. 541 In addition to active protection mechanisms, users and network 542 operators can monitor application performance and network traffic 543 patterns for poor performance or abnormalities. If it turns out 544 that relying on the guidance of a specific ALTO server does not 545 result in better-than-random results, the usage of the ALTO server 546 may be discontinued (see also Section 15.2 of [RFC7285]). 548 5.2. Availability of the ALTO Server Discovery Procedure 550 Scenario Description 551 An attacker could compromise the cross-domain ALTO server 552 discovery procedure or infrastructure in a way that ALTO clients 553 would not be able to discover any ALTO server. 555 Threat Discussion 556 If no ALTO server can be discovered (although a suitable one 557 exists) applications have to make their decisions without ALTO 558 guidance. As ALTO could be temporarily unavailable for many 559 reasons, applications must be prepared to do so. However, The 560 resulting application performance and traffic distribution will 561 correspond to a deployment scenario without ALTO. 563 Protection Strategies and Mechanisms 564 Operators should follow best current practices to secure their DNS 565 and ALTO (see Section 15.5 of [RFC7285]) servers against Denial- 566 of-Service (DoS) attacks. 568 5.3. Confidentiality of the ALTO Server's URI 570 Scenario Description 571 An unauthorized party could invoke the cross-domain ALTO server 572 discovery procedure, or intercept discovery messages between an 573 authorized ALTO client and the DNS servers, in order to acquire 574 knowledge of the ALTO server URI for a specific IP address. 576 Threat Discussion 577 In the ALTO use cases that have been described in the ALTO problem 578 statement [RFC5693] and/or discussed in the ALTO working group, 579 the ALTO server's URI as such has always been considered as public 580 information that does not need protection of confidentiality. 582 Protection Strategies and Mechanisms 583 No protection mechanisms for this scenario have been provided, as 584 it has not been identified as a relevant threat. However, if a 585 new use case is identified that requires this kind of protection, 586 the suitability of this ALTO server discovery procedure as well as 587 possible security extensions have to be re-evaluated thoroughly. 589 5.4. Privacy for ALTO Clients 591 Scenario Description 592 An unauthorized party could intercept messages between an ALTO 593 client and the DNS servers, and thereby find out the fact that 594 said ALTO client uses (or at least tries to use) the ALTO service 595 in order to optimize traffic from/to a specific IP address. 597 Threat Discussion 598 In the ALTO use cases that have been described in the ALTO problem 599 statement [RFC5693] and/or discussed in the ALTO working group, 600 this scenario has not been identified as a relevant threat. 602 Protection Strategies and Mechanisms 603 No protection mechanisms for this scenario have been provided, as 604 it has not been identified as a relevant threat. However, if a 605 new use case is identified that requires this kind of protection, 606 the suitability of this ALTO server discovery procedure as well as 607 possible security extensions have to be re-evaluated thoroughly. 609 6. IANA Considerations 611 This document does not require any IANA action. 613 7. References 615 7.1. Normative References 617 [RFC1035] Mockapetris, P., "Domain names - implementation and 618 specification", STD 13, RFC 1035, November 1987. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 624 "DNS Extensions to Support IP Version 6", RFC 3596, 625 October 2003. 627 [RFC4848] Daigle, L., "Domain-Based Application Service Location 628 Using URIs and the Dynamic Delegation Discovery Service 629 (DDDS)", RFC 4848, April 2007. 631 7.2. Informative References 633 [I-D.ietf-alto-deployments] 634 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 635 S. Previdi, "ALTO Deployment Considerations", 636 draft-ietf-alto-deployments-15 (work in progress), 637 May 2016. 639 [I-D.kiesel-alto-3pdisc] 640 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., 641 Tomsu, M., and H. Song, "ALTO Server Discovery Protocol", 642 draft-kiesel-alto-3pdisc-05 (work in progress), 643 March 2011. 645 [I-D.kiesel-alto-alto4alto] 646 Kiesel, S., "Using ALTO for ALTO server selection", 647 draft-kiesel-alto-alto4alto-00 (work in progress), 648 July 2010. 650 [I-D.kiesel-alto-ip-based-srv-disc] 651 Kiesel, S. and R. Penno, "Application-Layer Traffic 652 Optimization (ALTO) Anycast Address", 653 draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), 654 July 2014. 656 [I-D.kist-alto-3pdisc] 657 Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party 658 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05 659 (work in progress), January 2014. 661 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 662 Self-Address Fixing (UNSAF) Across Network Address 663 Translation", RFC 3424, November 2002. 665 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 666 Rose, "DNS Security Introduction and Requirements", 667 RFC 4033, March 2005. 669 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 670 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 671 October 2008. 673 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 674 Optimization (ALTO) Problem Statement", RFC 5693, 675 October 2009. 677 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 678 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 679 Requirements", RFC 6708, September 2012. 681 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 682 (LIS) Discovery Using IP Addresses and Reverse DNS", 683 RFC 7216, April 2014. 685 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 686 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 687 Traffic Optimization (ALTO) Protocol", RFC 7285, 688 September 2014. 690 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 691 H. Song, "Application-Layer Traffic Optimization (ALTO) 692 Server Discovery", RFC 7286, June 2014. 694 Appendix A. Requirements for ALTO Cross-Domain Server Discovery 696 A solution for the problem described in the previous section would be 697 an ALTO Cross-Domain Server Discovery system. This section itemizes 698 requirements. 700 A.1. Discovery Client Application Programming Interface 702 The discovery client will be called through some kind of application 703 programming interface (API) and the parameters will be an IP address 704 and, for purposes of extensibility, a service identifier such as 705 "ALTO". It will return one or more URI(s) that offers the requested 706 service ("ALTO") for the given IP address. 708 In other words, the client would be used to retrieve a mapping: 710 (IP address, "ALTO") -> IRD-URI(s) 712 where IRD-URI(s) is one or more URI(s) of Information Resource 713 Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that 714 can give reasonable guidance to a resource consumer with the 715 indicated IP address. 717 A.2. Data Storage and Authority Requirements 719 The information for mapping IP addresses and service parameters to 720 URIs should be stored in a - preferably distributed - database. It 721 must be possible to delegate administration of parts of this 722 database. Usually, the mapping from a specific IP address to an URI 723 is defined by the authority that has administrative control over this 724 IP address, e.g., the ISP in residential access networks or the IT 725 department in enterprise, university, or similar networks. 727 A.3. Cross-Domain Operations Requirements 729 The cross-domain server discovery mechanism should be designed in 730 such a way that it works across the public Internet and also in other 731 IP-based networks. This in turn means that such mechanisms cannot 732 rely on protocols that are not widely deployed across the Internet or 733 protocols that require special handling within participating 734 networks. An example is multicast, which is not generally available 735 across the Internet. 737 The ALTO Cross-Domain Server Discovery protocol must support gradual 738 deployment without a network-wide flag day. If the mechanism needs 739 some kind of well-known "rendezvous point", re-using an existing 740 infrastructure (such as the DNS root servers or the WHOIS database) 741 should be preferred over establishing a new one. 743 A.4. Protocol Requirements 745 The protocol must be able to operate across middleboxes, especially 746 across NATs and firewalls. 748 The protocol shall not require any pre-knowledge from the client 749 other than any information that is known to a regular IP host on the 750 Internet. 752 A.5. Further Requirements 754 The ALTO cross domain server discovery cannot assume that the server 755 discovery client and the server discovery responding entity are under 756 the same administrative control. 758 Appendix B. ALTO and Tracker-based Peer-to-Peer Applications 760 The ALTO protocol specification [RFC7285] details how an ALTO client 761 can query an ALTO server for guiding information and receive the 762 corresponding replies. However, in the considered scenario of a 763 tracker-based P2P application, there are two fundamentally different 764 possibilities where to place the ALTO client: 766 1. ALTO client in the resource consumer ("peer") 768 2. ALTO client in the resource directory ("tracker") 770 In the following, both scenarios are compared in order to explain the 771 need for ALTO queries on behalf of remote resource consumers. 773 In the first scenario (see Figure 2), the resource consumer queries 774 the resource directory for the desired resource (F1). The resource 775 directory returns a list of potential resource providers without 776 considering ALTO (F2). It is then the duty of the resource consumer 777 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 778 list. 780 In the second scenario (see Figure 4), the resource directory has an 781 embedded ALTO client. After receiving a query for a given resource 782 (F1) the resource directory invokes this ALTO client to evaluate all 783 resource providers it knows (F2/F3). Then it returns a, possibly 784 shortened, list containing the "best" resource providers to the 785 resource consumer (F4). 787 ............................. ............................. 788 : Tracker : : Peer : 789 : ______ : : : 790 : +-______-+ : : k good : 791 : | | +--------+ : P2P App. : +--------+ peers +------+ : 792 : | N | | random | : Protocol : | ALTO- |------>| data | : 793 : | known |====>| pre- |*************>| biased | | ex- | : 794 : | peers, | | selec- | : transmit : | peer |------>| cha- | : 795 : | M good | | tion | : n peer : | select | n-k | nge | : 796 : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : 797 :...........................: :.....^.....................: 798 | 799 | ALTO 800 | client protocol 801 __|___ 802 +-______-+ 803 | | 804 | ALTO | 805 | server | 806 +-______-+ 808 Figure 1: Tracker-based P2P Application with random peer preselection 810 Peer w. ALTO cli. Tracker ALTO Server 811 --------+-------- --------+-------- --------+-------- 812 | F1 Tracker query | | 813 |======================>| | 814 | F2 Tracker reply | | 815 |<======================| | 816 | F3 ALTO client protocol query | 817 |---------------------------------------------->| 818 | F4 ALTO client protocol reply | 819 |<----------------------------------------------| 820 | | | 822 ==== Application protocol (i.e., tracker-based P2P app protocol) 823 ---- ALTO client protocol 825 Figure 2: Basic message sequence chart for resource consumer- 826 initiated ALTO query 828 ............................. ............................. 829 : Tracker : : Peer : 830 : ______ : : : 831 : +-______-+ : : : 832 : | | +--------+ : P2P App. : k good peers & +------+ : 833 : | N | | ALTO- | : Protocol : n-k bad peers | data | : 834 : | known |====>| biased |******************************>| ex- | : 835 : | peers, | | peer | : transmit : | cha- | : 836 : | M good | | select | : n peer : | nge | : 837 : +-______-+ +--------+ : IDs : +------+ : 838 :.....................^.....: :...........................: 839 | 840 | ALTO 841 | client protocol 842 __|___ 843 +-______-+ 844 | | 845 | ALTO | 846 | server | 847 +-______-+ 849 Figure 3: Tracker-based P2P Application with ALTO client in tracker 851 Peer Tracker w. ALTO cli. ALTO Server 852 --------+-------- --------+-------- --------+-------- 853 | F1 Tracker query | | 854 |======================>| | 855 | | F2 ALTO cli. p. query | 856 | |---------------------->| 857 | | F3 ALTO cli. p. reply | 858 | |<----------------------| 859 | F4 Tracker reply | | 860 |<======================| | 861 | | | 863 ==== Application protocol (i.e., tracker-based P2P app protocol) 864 ---- ALTO client protocol 866 Figure 4: Basic message sequence chart for ALTO query on behalf of 867 remote resource consumer 869 Note: the message sequences depicted in Figure 2 and Figure 4 may 870 occur both in the target-aware and the target-independent query mode 871 (c.f. [RFC6708]). In the target-independent query mode no message 872 exchange with the ALTO server might be needed after the tracker 873 query, because the candidate resource providers could be evaluated 874 using a locally cached "map", which has been retrieved from the ALTO 875 server some time ago. 877 The problem with the first approach is, that while the resource 878 directory might know thousands of peers taking part in a swarm, the 879 list returned to the resource consumer is usually shortened for 880 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 881 potential resource providers might not be contained in that list 882 anymore, even before ALTO can consider them. 884 For illustration, consider a simple model of a swarm, in which all 885 peers fall into one of only two categories: assume that there are 886 "good" ("good" in the sense of ALTO's better-than-random peer 887 selection, based on an arbitrary desired rating criterion) and "bad' 888 peers only. Having more different categories makes the maths more 889 complex but does not change anything to the basic outcome of this 890 analysis. Assume that the swarm has a total number of N peers, out 891 of which are M "good" and N-M "bad" peers, which are all known to the 892 tracker. A new peer wants to join the swarm and therefore asks the 893 tracker for a list of peers. 895 If, according to the first approach, the tracker randomly picks n 896 peers from the N known peers, the result can be described with the 897 hypergeometric distribution. The probability that the tracker reply 898 contains exactly k "good" peers (and n-k "bad" peers) is: 900 / m \ / N - m \ 901 \ k / \ n - k / 902 P(X=k) = --------------------- 903 / N \ 904 \ n / 906 / n \ n! 907 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 908 k! (n-k)! 910 The probability that the reply contains at most k "good" peers is: 911 P(X<=k)=P(X=0)+P(X=1)+..+P(X=k). 913 For example, consider a swarm with N=10,000 peers known to the 914 tracker, out of which M=100 are "good" peers. If the tracker 915 randomly selects n=100 peers, the formula yields for the reply: 916 P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% 917 this list does not contain a single "good" peer, and with 99% 918 probability there are only four or less of the "good" peers on the 919 list. Processing this list with the guiding ALTO information will 920 ensure that the few favorable peers are ranked to the top of the 921 list; however, the benefit is rather limited as the number of 922 favorable peers in the list is just too small. 924 Much better traffic optimization could be achieved if the tracker 925 would evaluate all known peers using ALTO, and return a list of 100 926 peers afterwards. This list would then include a significantly 927 higher fraction of "good" peers. (Note, that if the tracker returned 928 "good" peers only, there might be a risk that the swarm might 929 disconnect and split into several disjunct partitions. However, 930 finding the right mix of ALTO-biased and random peer selection is out 931 of the scope of this document.) 933 Therefore, from an overall optimization perspective, the second 934 scenario with the ALTO client embedded in the resource directory is 935 advantageous, because it is ensured that the addresses of the "best" 936 resource providers are actually delivered to the resource consumer. 937 An architectural implication of this insight is that the ALTO server 938 discovery procedures must support ALTO queries on behalf of remote 939 resource consumers. That is, as the tracker issues ALTO queries on 940 behalf of the peer which contacted the tracker, the tracker must be 941 able to discover an ALTO server that can give guidance suitable for 942 that respective peer. 944 Appendix C. Contributors List and Acknowledgments 946 The initial version of this document was co-authored by Marco Tomsu 947 (Alcatel-Lucent). 949 This document borrows some text from [RFC7286], as it was 950 historically part of that memo. Special thanks to Michael Scharf and 951 Nico Schwan. 953 Authors' Addresses 955 Sebastian Kiesel 956 University of Stuttgart Information Center 957 Allmandring 30 958 Stuttgart 70550 959 Germany 961 Email: ietf-alto@skiesel.de 962 URI: http://www.rus.uni-stuttgart.de/nks/ 964 Martin Stiemerling 965 University of Applied Sciences Darmstadt, Computer Science Dept. 966 Haardtring 100 967 Darmstadt 64295 968 Germany 970 Phone: +49 6151 16 7938 971 Email: mls.ietf@gmail.com 972 URI: http://ietf.stiemerling.org