idnits 2.17.1 draft-kist-alto-3pdisc-05.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 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 826 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 (January 13, 2014) is 3756 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-08 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-21 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft K. Krause 4 Intended status: Experimental University of Stuttgart 5 Expires: July 17, 2014 M. Stiemerling 6 NEC Europe Ltd. 7 January 13, 2014 9 Third-Party ALTO Server Discovery (3pdisc) 10 draft-kist-alto-3pdisc-05 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 This document specifies a procedure for third-party ALTO server 22 discovery, which can be used if the ALTO client is not co-located 23 with the actual resource consumer, but instead embedded in a third 24 party such as a peer-to-peer tracker. 26 Technically, the algorithm specified in this document takes one 27 IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or 28 "ALTO:https") as parameters. It performs several DNS lookups (for 29 U-NAPTR and SOA resource records) and returns one or more URI(s) of 30 information resources related to that IP address. 32 Terminology and Requirements Language 34 This document makes use of the ALTO terminology defined in RFC 5693 35 [RFC5693]. 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on July 17, 2014. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Third-party ALTO Server Discovery Procedure Specification . . 5 77 2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2.2. Basic Principle . . . . . . . . . . . . . . . . . . . . . 5 79 2.3. Overall Procedure . . . . . . . . . . . . . . . . . . . . 6 80 2.4. Specification of Tasks and Conditional Branches . . . . . 7 81 2.4.1. T1: Prepare Domain Name for Reverse DNS Lookup . . . . 7 82 2.4.2. T2/B1: U-NAPTR Lookup in Reverse Zone . . . . . . . . 7 83 2.4.3. B2/T3/B3: Acquire SOA Record for Reverse Zone . . . . 8 84 2.4.4. T4/B4: U-NAPTR Lookup on SOA-MNAME . . . . . . . . . . 9 85 3. Implementation, Deployment, and Operational Considerations . . 10 86 3.1. Considerations for ALTO Clients . . . . . . . . . . . . . 10 87 3.1.1. Resource Consumer Initiated Discovery . . . . . . . . 10 88 3.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host 89 Mobility . . . . . . . . . . . . . . . . . . . . . . . 10 90 3.2. Deployment Considerations for Network Operators . . . . . 11 91 3.2.1. NAPTR in Reverse Tree vs. SOA-based discovery . . . . 11 92 3.2.2. Separation of Interests . . . . . . . . . . . . . . . 11 93 3.3. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 12 94 3.3.1. Non-PTR Resource Records in Reverse Tree . . . . . . . 12 95 3.3.2. Usage with DNS Hidden Master Servers . . . . . . . . . 12 96 3.3.3. Load on the DNS . . . . . . . . . . . . . . . . . . . 12 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 98 4.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 13 99 4.2. Availability of the ALTO Server Discovery Procedure . . . 14 100 4.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 15 101 4.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 15 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 103 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 105 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 106 Appendix A. ALTO and Tracker-based Peer-to-Peer Applications . . 19 107 Appendix B. Contributors List and Acknowledgments . . . . . . . . 24 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 110 1. Introduction 112 The goal of Application-Layer Traffic Optimization (ALTO) is to 113 provide guidance to applications that have to select one or several 114 hosts from a set of candidates capable of providing a desired 115 resource [RFC5693]. ALTO is realized by a client-server protocol; 116 see requirement AR-1 in [RFC6708]. Before an ALTO client can ask for 117 guidance it needs to discover one or more ALTO servers that can 118 provide suitable guidance. For applications that use a centralized 119 resource directory, such as tracker-based P2P applications, the 120 efficiency of ALTO is significantly improved if the ALTO client is 121 embedded in said resource directory instead of the resource consumer 122 (see Appendix A for a detailed example and analysis of such a 123 scenario). The ALTO client embedded into the resource directory asks 124 for guidance on behalf of the resource consumers. To that end, it 125 needs to discover ALTO servers that can give guidance suitable for 126 these resource consumers, respectively. This is called third-party 127 party ALTO server discovery. 129 This document specifies a procedure for third-party ALTO server 130 discovery. In other words, this document tries to meet requirement 131 AR-33 in [RFC6708]. 133 The ALTO protocol specification [I-D.ietf-alto-protocol] is based on 134 HTTP and expects the discovery procedure to yield the HTTP(S) URI of 135 an ALTO server's information resource directory. Therefore, this 136 document specifies an algorithm that takes a resource consumer's IP 137 address as argument, performs several DNS lookups (for U-NAPTR 138 [RFC4848] and SOA resource records), and produces URIs of ALTO 139 servers that are able to give reasonable ALTO guidance to a resource 140 consumer willing to communicate using this IP address. 142 To some extent, AR-32, i.e., resource consumer initiated ALTO server 143 discovery, can be seen as a special case of third-party ALTO server 144 discovery. However, the considerations in Section 3.1.1 apply. Note 145 that a less versatile yet simpler approach for resource consumer 146 initiated ALTO server discovery is specified in 147 [I-D.ietf-alto-server-discovery]. 149 A more detailed discussion of various options where to place the 150 functional entities comprising the overall ALTO architecture can be 151 found in [I-D.ietf-alto-deployments]. 153 Comments and discussions about this memo should be directed to the 154 ALTO working group: alto@ietf.org. 156 2. Third-party ALTO Server Discovery Procedure Specification 158 2.1. Interface 160 The algorithm specified in this document takes one IP address and a 161 U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as 162 parameters. It performs several DNS lookups (for U-NAPTR and SOA 163 resource records) and returns one or more URI(s) of information 164 resources related to that IP address. 166 2.2. Basic Principle 168 The algorithm sequentially tries two different lookup strategies. 169 First, an ALTO-specific U-NAPTR lookup is performed in the "reverse 170 tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa., 171 respectively. If this lookup does not yield a usable result, the SOA 172 record for the reverse zone is acquired, its master name server 173 (MNAME) value is extracted and used for a further ALTO-specific 174 U-NAPTR lookup. 176 The goal is to allow deployment scenarios that require fine-grained 177 discovery on a per-IP basis, as well as large-scale scenarios where 178 discovery is to be enabled for a large number of IP addresses with a 179 small number of additional DNS resource records. 181 2.3. Overall Procedure 183 This figure gives an overview on the third-party discovery procedure. 184 All tasks (T) and conditional branches (B) are specified below. 186 (---------------------------------------) 187 ( START 3pdisc with parameters ) 188 ( IP_address IP, Service_Parameter SP ) 189 (-------------------+-------------------) 190 V 191 +- T1 --------------+-------------------+ 192 | R:=.in-addr.arpa. / .ip6.arpa.| 193 +-------------------+-------------------+ 194 V 195 +- T2 --------------+-------------------+ 196 | X:=DNSlookup(R,U-NAPTR,SP) | 197 +-------------------+-------------------+ 198 V 199 / B1 --------------+------------------\ 200 /---------< One or more U-NAPTR results in X > 201 | yes \------------------+------------------/ 202 | V no 203 | /- B2 -------------+------------------\ 204 | /----< Authority sect. with SOA record in X > 205 | | yes \------------------+------------------/ 206 | | V no 207 | | +- T3 --------------+-------------------+ 208 | | | X:=DNSlookup(R,SOA) | 209 | | +-------------------+-------------------+ 210 | | V 211 | | /- B3 -------------+------------------\ 212 | | < Lookup OK, SOA record present in X >----\ 213 | | \------------------+------------------/ no | 214 | | V yes | 215 | \----------------------->+ | 216 | V | 217 | +- T4 --------------+-------------------+ | 218 | | M:=extract MNAME from SOA record in X | | 219 | | X:=DNSlookup(M,U-NAPTR,SP) | | 220 | +-------------------+-------------------+ | 221 | V | 222 | /- B4 -------------+------------------\ V 223 \--->+<---< One or more U-NAPTR results in X >--->+ 224 | yes \-------------------------------------/ no | 225 V V 226 (-------+-------) (-------+-------) 227 ( END, result X ) ( END, failure ) 228 (---------------) (---------------) 230 2.4. Specification of Tasks and Conditional Branches 232 2.4.1. T1: Prepare Domain Name for Reverse DNS Lookup 234 Task T1 takes the IP address parameter the 3pdisc procedure was 235 called with and constructs a domain name, which is stored in variable 236 "R" for use in subsequent tasks. 238 If the IP address given as a parameter to the 3pdisc procedure is an 239 IPv4 address, the domain name is constructed according to the rules 240 specified in Section 3.5 of [RFC1035] and it is rooted in the in the 241 special domain "IN-ADDR.ARPA.". For IPv6 addresses, the construction 242 rules in Section 2.5 of [RFC3596] apply and the special domain 243 "IP6.ARPA." is used. 245 Example values for "R" for IPv4 and IPv6 addresses could be (Note: a 246 line break was added in the IPv6 example): 248 R:="3.100.51.198.in-addr.arpa." 250 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. 251 1.0.0.2.ip6.arpa." 253 2.4.2. T2/B1: U-NAPTR Lookup in Reverse Zone 255 Task T1 performs a U-NAPTR lookup as specified in [RFC4848] on "R", 256 in order to get service-specific U-NAPTR resource records that are 257 directly associated with the IP address in question. 259 The ALTO protocol specification defines HTTP and HTTPS as transport 260 mechanisms and URI schemes for ALTO. Consequently, the U-NAPTR 261 lookup is performed with the "ALTO" Application Service Tag and 262 either the "http" or the "https" Application Protocol Tag. 263 Application Service Tag and Application Protocol Tag are concatenated 264 to form the Service Parameter SP, i.e., either "ALTO:http" or "ALTO: 265 https". 267 The goal of said U-NAPTR lookup is to obtain one or more URIs for the 268 ALTO server's Information Resource Directory. If two or more URIs 269 are found they are sorted according to their order and preference 270 fields as specified in [RFC4848] and [RFC3403]. 272 The lookup result, including a SOA record that may or may not be 273 present in the authority section, is stored in variable "X". 275 As an example, the following two U-NAPTR resource records can be used 276 for mapping "3.100.51.198.in-addr.arpa." to the HTTPS URI 277 https://altoserver.isp.example.net/secure/directory or the HTTP URI 278 http://altoserver.isp.example.net/directory, with the former being 279 preferred. 281 3.100.51.198.in-addr.arpa. 283 IN NAPTR 100 10 "u" "ALTO:https" 284 "!.*!https://altoserver.isp.example.net/secure/directory!" "" 286 IN NAPTR 200 10 "u" "ALTO:http" 287 "!.*!http://altoserver.isp.example.net/directory!" "" 289 Conditional Branch B1 checks whether at least one U-NAPTR record 290 matching the service parameter SP could be retrieved. If so, the 291 procedure ends successfully and the sorted list of U-NAPTR records is 292 the result. Otherwise, if no U-NAPTR records could be retrieved, we 293 continue with B2. 295 Note: The U-NAPTR lookup in Task T2 is identical to Step 2 specified 296 in [I-D.ietf-alto-server-discovery], which specifies with "manual 297 input" and "DHCP" two alternatives for acquiring the name to be 298 looked up. Therefore, it is possible to merge both documents into a 299 common ALTO server discovery framework. 301 2.4.3. B2/T3/B3: Acquire SOA Record for Reverse Zone 303 The task of B2/T3/B3 is to acquire the SOA record for the "reverse 304 zone", i.e., the zone in the in-addr.arpa. or ip6.arpa. domain that 305 contains the IP address in question. 307 A sample SOA record could be: 309 100.51.198.in-addr.arpa 310 IN SOA dns1.isp.example.net. hostmaster.isp.example.net. ( 311 1 ; Serial 312 604800 ; Refresh 313 86400 ; Retry 314 2419200 ; Expire 315 604800 ) ; Negative Cache TTL 317 Conditional Branch B2 checks whether the SOA record was present in 318 the authority section of X, i.e., the result of Task T2. If not, an 319 explicit lookup is done in Task T3. If Conditional Branch B3 320 determines that this explicit lookup failed, the discovery procedure 321 is aborted without a result; otherwise we continue with T4. 323 2.4.4. T4/B4: U-NAPTR Lookup on SOA-MNAME 325 Now that the SOA record is available, Task T4 first extracts the 326 MNAME field, i.e., the responsible master name server from the SOA 327 record. An example MNAME could be: 329 dns1.isp.example.net. 331 Then, a U-NAPTR lookup as specified in Task T2 is performed on this 332 MNAME and the result is stored in variable "X". 334 Conditional Branch B4 checks whether at least one U-NAPTR record 335 matching the service parameter SP could be retrieved. If so, the 336 procedure ends successfully and the sorted list of U-NAPTR records is 337 the result. Otherwise, if no U-NAPTR records could be retrieved, the 338 discovery procedure is aborted without a result. 340 3. Implementation, Deployment, and Operational Considerations 342 3.1. Considerations for ALTO Clients 344 3.1.1. Resource Consumer Initiated Discovery 346 To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource 347 consumer initiated ALTO server discovery, can be seen as a special 348 case of third-party ALTO server discovery. To that end, an ALTO 349 client embedded in a resouce consumer would have to figure out its 350 own "public" IP address and perform the procedures described in this 351 document on that address. However, due to the widespread deployment 352 of Network Address Translators (NAT), additional protocols and 353 mechanisms such as STUN [RFC5389] would be needed and considerations 354 for UNSAF [RFC3424] apply. Therefore, using the procedures specified 355 in this document for resource consumer based ALTO server discovery is 356 generally NOT RECOMMENDED. Note that a less versatile yet simpler 357 approach for resource consumer initiated ALTO server discovery is 358 specified in [I-D.ietf-alto-server-discovery]. 360 3.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility 362 The algortihm specified in this document can discover ALTO server 363 URIs for a given IP address. The intention is, that a third party 364 (e.g., a resource directory) that receives query messages from a 365 resource consumer can use the source address in these messages to 366 discover suitable ALTO servers for this specific resource consumer. 368 However, resource consumers (as defined in Section 2 of [RFC5693]) 369 may reside on hosts with more than one IP address, e.g., due to 370 IPv4/v6 dual stack operation and/or multihoming. IP packets sent 371 with different source addresses may be subject to different routing 372 policies and path costs. In some deployment scenarios, it may even 373 be required to ask different sets of ALTO servers for guidance. 374 Furthermore, source addresses in IP packets may be modified en-route 375 by Network Address Translators (NAT). 377 If a resource consumer queries a resource directory for candidate 378 resource providers, the locally selected (and possibly en-route 379 translated) source address of the query message - as observed by the 380 resource directory - will become the basis for the ALTO server 381 discovery and the subsequent optimization of the resource directory's 382 reply. If, however, the resource consumer then selects different 383 source addresses to contact returned resource providers, the desired 384 better-than-random "ALTO effect" may not occur. 386 Therefore, a dual stack or multihomed resource consumer SHOULD either 387 always use the same address for contacting the resource directory and 388 the resource providers, i.e., overriding the operating system's 389 automatic source IP address selection, or use resource consumer based 390 ALTO server discovery [I-D.ietf-alto-server-discovery] to discover 391 suitable ALTO servers for every local address and then locally 392 perform ALTO-influenced resource consumer selection and source 393 address selection. Similarly, resource consumers on mobile hosts 394 SHOULD query the resource directory again after a change of IP 395 address, in order to get a list of candidate resource providers that 396 is optimized for the new IP address. 398 3.2. Deployment Considerations for Network Operators 400 3.2.1. NAPTR in Reverse Tree vs. SOA-based discovery 402 As already outlined in Section 2.2, the third-party discovery 403 procedure sequentially tries two different lookup strategies, thus 404 giving network operators the choice of two different deployment 405 options: 407 o Individual NAPTR records in the in-addr.arpa or ip6.arpa domains 408 allow very fine-grained discovery of ALTO "entry point" URIs on a 409 per-IP-address basis. This method also gives the fastest response 410 times and causes a comparatively low load on the DNS, as the 411 algorithm terminates successfully after the first DNS query. DNS 412 operators that already maintain reverse zones (e.g., for PTR 413 records) should prefer this option, possibly using DNS server 414 implementation-specific methods for mass deployment (e.g., BIND9's 415 $GENERATE statement). 417 o If a DNS operator considers the first option too cumbersome, or if 418 IPv6 privacy extensions is to be used without dynamic PTR updates, 419 setting up SOA records in the in-addr.arpa. or ip6.arpa. 420 subdomains plus setting up corresponding ALTO-specific U-NAPTR 421 records will also give reasonable, yet less fine-grained results 422 at the cost of slightly higher delay and load on the DNS. 424 3.2.2. Separation of Interests 426 We assume that if two organizations share parts of their DNS 427 infrastructure, i.e., have a common SOA record in their in-addr.arpa. 428 or ip6.arpa. subdomain(s), they will also be able to operate a common 429 ALTO server, which still may do redirections if desired or required 430 by policies. 432 Note that the ALTO server discovery procedure is supposed to produce 433 only a first URI of an ALTO server that can give reasonable guidance 434 to the client. An ALTO server can still return different results 435 based on the client's address (or other identifying properties) or 436 redirect the client to another ALTO server using mechanisms of the 437 ALTO protocol (see Sect. 6.7 of [I-D.ietf-alto-protocol]). 439 3.3. Impact on DNS 441 3.3.1. Non-PTR Resource Records in Reverse Tree 443 Installing NAPTR records, i.e., a record type other than PTR records, 444 in the in-addr.arpa or ip6.arpa domain may seem uncommon, but it is 445 not a new concept. Earlier documents that specify the usage of Non- 446 PTR resource records in the reverse tree include RFC 4025 [RFC4025], 447 RFC 4255 [RFC4255], and RFC 4322 [RFC4322]. 449 3.3.2. Usage with DNS Hidden Master Servers 451 In some deployment scenarios, the Master DNS server for a in- 452 addr.arpa. or ip6.arpa. subdomain, as indicated in the respective SOA 453 record, may not be reachable due to traffic restrictions ("hidden 454 master"). This does not cause any problems with the algorithm 455 described here, as the MNAME is only used for further DNS lookups; 456 but it is never attempted to contact this server directly. 458 3.3.3. Load on the DNS 460 The procedure described in this document features several nested 461 conditional branches, but no loops. Each time being called it 462 attempts one to three DNS lookups. 464 4. Security Considerations 466 A high-level discussion of security issues related to ALTO is part of 467 the ALTO problem statement [RFC5693]. A classification of unwanted 468 information disclosure risks, as well as specific security-related 469 requirements can be found in the ALTO requirements document 470 [RFC6708]. 472 The remainder of this section focuses on security threats and 473 protection mechanisms for the third-party ALTO server discovery 474 procedure as such. Once the ALTO server's URI has been discovered 475 and the communication between the ALTO client and the ALTO server 476 starts, the security threats and protection mechanisms discussed in 477 the ALTO protocol specification [I-D.ietf-alto-protocol] apply. 479 4.1. Integrity of the ALTO Server's URI 481 Scenario Description 482 An attacker could compromise the ALTO server discovery procedure 483 or infrastructure in a way that ALTO clients would discover a 484 "wrong" ALTO server URI. 486 Threat Discussion 487 This is probably the most serious security concern related to ALTO 488 server discovery. The discovered "wrong" ALTO server might not be 489 able to give guidance to a given ALTO client at all, or it might 490 give suboptimal or forged information. In the latter case, an 491 attacker could try to use ALTO to affect the traffic distribution 492 in the network or the performance of applications (see also 493 Section 14.1. of [I-D.ietf-alto-protocol]). Furthermore, a 494 hostile ALTO server could threaten user privacy (see also Section 495 5.2.1, case (5a) in [RFC6708]). 497 However, it should also be noted that, if an attacker was able to 498 compromise the DNS infrastructure used for third-party ALTO server 499 discovery (see below), (s)he could also launch significantly more 500 serious other attacks (e.g., redirecting various application 501 protocols). 503 Protection Strategies and Mechanisms 504 The third-party ALTO server discovery procedure relies on a series 505 of DNS lookups. If an attacker was able to modify or spoof any of 506 the DNS records, the resulting URI could be replaced by a forged 507 URI. The application of DNS security (DNSSEC) [RFC4033] provides 508 a means to limit attacks that rely on modification of the DNS 509 records while in transit. Additional operational precautions for 510 safely operating the DNS infrastructure are required in order to 511 ensure that name servers do not sign forged (or otherwise "wrong") 512 resource records. Security considerations specific to U-NAPTR are 513 described in more detail in [RFC4848]. 515 A related risk is the impersonation of the ALTO server (i.e., 516 attacks after the correct URI has been discovered). This threat 517 and protection strategies are discussed in Section 14.1 of 518 [I-D.ietf-alto-protocol]. Note that if TLS is used to protect 519 ALTO, the server certificate will contain the host name (CN). 520 Consequently, only the host part of the HTTPS URI will be 521 authenticated, i.e., the result of the ALTO server discovery 522 procedure. The DNS/U-NAPTR based mapping within the third-party 523 ALTO server discovery procedure needs to be secured as described 524 above, e.g., by using DNSSEC. 526 In addition to active protection mechanisms, users and network 527 operators can monitor application performance and network traffic 528 patterns for poor performance or abnormalities. If it turns out 529 that relying on the guidance of a specific ALTO server does not 530 result in better-than-random results, the usage of the ALTO server 531 may be discontinued (see also Section 14.2 of 532 [I-D.ietf-alto-protocol]). 534 4.2. Availability of the ALTO Server Discovery Procedure 536 Scenario Description 537 An attacker could compromise the third-party ALTO server discovery 538 procedure or infrastructure in a way that ALTO clients would not 539 be able to discover any ALTO server. 541 Threat Discussion 542 If no ALTO server can be discovered (although a suitable one 543 exists) applications have to make their decisions without ALTO 544 guidance. As ALTO could be temporarily unavailable for many 545 reasons, applications must be prepared to do so. However, The 546 resulting application performance and traffic distribution will 547 correspond to a deployment scenario without ALTO. 549 Protection Strategies and Mechanisms 550 Operators should follow best current practices to secure their DNS 551 and ALTO (see Section 14.5 of [I-D.ietf-alto-protocol]) servers 552 against Denial-of-Service (DoS) attacks. 554 4.3. Confidentiality of the ALTO Server's URI 556 Scenario Description 557 An unauthorized party could invoke the third-party ALTO server 558 discovery procedure, or intercept discovery messages between an 559 authorized ALTO client and the DNS servers, in order to acquire 560 knowledge of the ALTO server URI for a specific resource consumer. 562 Threat Discussion 563 In the ALTO use cases that have been described in the ALTO problem 564 statement [RFC5693] and/or discussed in the ALTO working group, 565 the ALTO server's URI as such has always been considered as public 566 information that does not need protection of confidentiality. 568 Protection Strategies and Mechanisms 569 No protection mechanisms for this scenario have been provided, as 570 it has not been identified as a relevant threat. However, if a 571 new use case is identified that requires this kind of protection, 572 the suitability of this ALTO server discovery procedure as well as 573 possible security extensions have to be re-evaluated thoroughly. 575 4.4. Privacy for ALTO Clients 577 Scenario Description 578 An unauthorized party could intercept messages between an ALTO 579 client and the DNS servers, and thereby find out the fact that 580 said ALTO client uses (or at least tries to use) the ALTO service 581 on behalf of a specific resource consumer. 583 Threat Discussion 584 In the ALTO use cases that have been described in the ALTO problem 585 statement [RFC5693] and/or discussed in the ALTO working group, 586 this scenario has not been identified as a relevant threat. 588 Protection Strategies and Mechanisms 589 No protection mechanisms for this scenario have been provided, as 590 it has not been identified as a relevant threat. However, if a 591 new use case is identified that requires this kind of protection, 592 the suitability of this ALTO server discovery procedure as well as 593 possible security extensions have to be re-evaluated thoroughly. 595 5. IANA Considerations 597 This document does not require any IANA action. 599 This document specifies an algorithm that uses U-NAPTR lookups 600 [RFC4848] with the Application Service Tag "ALTO" and the Application 601 Protocol Tags "http" and "https". These tags have already been 602 registered with IANA. In particular, for the registration of the 603 Application Service Tag "ALTO", see [I-D.ietf-alto-server-discovery]. 605 6. References 607 6.1. Normative References 609 [RFC1035] Mockapetris, P., "Domain names - implementation and 610 specification", STD 13, RFC 1035, November 1987. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 616 Part Three: The Domain Name System (DNS) Database", 617 RFC 3403, October 2002. 619 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 620 "DNS Extensions to Support IP Version 6", RFC 3596, 621 October 2003. 623 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 624 Rose, "DNS Security Introduction and Requirements", 625 RFC 4033, March 2005. 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 6.2. Informative References 633 [I-D.ietf-alto-deployments] 634 Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, 635 "ALTO Deployment Considerations", 636 draft-ietf-alto-deployments-08 (work in progress), 637 October 2013. 639 [I-D.ietf-alto-protocol] 640 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 641 draft-ietf-alto-protocol-21 (work in progress), 642 November 2013. 644 [I-D.ietf-alto-server-discovery] 645 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 646 H. Song, "ALTO Server Discovery", 647 draft-ietf-alto-server-discovery-10 (work in progress), 648 September 2013. 650 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 651 Self-Address Fixing (UNSAF) Across Network Address 652 Translation", RFC 3424, November 2002. 654 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 655 Material in DNS", RFC 4025, March 2005. 657 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 658 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 659 January 2006. 661 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 662 Encryption using the Internet Key Exchange (IKE)", 663 RFC 4322, December 2005. 665 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 666 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 667 October 2008. 669 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 670 Optimization (ALTO) Problem Statement", RFC 5693, 671 October 2009. 673 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 674 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 675 Requirements", RFC 6708, September 2012. 677 Appendix A. ALTO and Tracker-based Peer-to-Peer Applications 679 The ALTO protocol specification [I-D.ietf-alto-protocol] details how 680 an ALTO client can query an ALTO server for guiding information and 681 receive the corresponding replies. However, in the considered 682 scenario of a tracker-based P2P application, there are two 683 fundamentally different possibilities where to place the ALTO client: 685 1. ALTO client in the resource consumer ("peer") 687 2. ALTO client in the resource directory ("tracker") 689 In the following, both scenarios are compared in order to explain the 690 need for third-party ALTO queries. 692 In the first scenario (see Figure 2), the resource consumer queries 693 the resource directory for the desired resource (F1). The resource 694 directory returns a list of potential resource providers without 695 considering ALTO (F2). It is then the duty of the resource consumer 696 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 697 list. 699 In the second scenario (see Figure 4), the resource directory has an 700 embedded ALTO client, which we will refer to as 3PAC (Third-Party 701 ALTO Client) in this document. After receiving a query for a given 702 resource (F1) the resource directory invokes the 3PAC to evaluate all 703 resource providers it knows (F2/F3). Then it returns a, possibly 704 shortened, list containing the "best" resource providers to the 705 resource consumer (F4). 707 ............................. ............................. 708 : Tracker : : Peer : 709 : ______ : : : 710 : +-______-+ : : k good : 711 : | | +--------+ : P2P App. : +--------+ peers +------+ : 712 : | N | | random | : Protocol : | ALTO- |------>| data | : 713 : | known |====>| pre- |*************>| biased | | ex- | : 714 : | peers, | | selec- | : transmit : | peer |------>| cha- | : 715 : | M good | | tion | : n peer : | select | n-k | nge | : 716 : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : 717 :...........................: :.....^.....................: 718 | 719 | ALTO 720 | client protocol 721 __|___ 722 +-______-+ 723 | | 724 | ALTO | 725 | server | 726 +-______-+ 728 Figure 1: Tracker-based P2P Application with random peer preselection 730 Peer w. ALTO cli. Tracker ALTO Server 731 --------+-------- --------+-------- --------+-------- 732 | F1 Tracker query | | 733 |======================>| | 734 | F2 Tracker reply | | 735 |<======================| | 736 | F3 ALTO client protocol query | 737 |---------------------------------------------->| 738 | F4 ALTO client protocol reply | 739 |<----------------------------------------------| 740 | | | 742 ==== Application protocol (i.e., tracker-based P2P app protocol) 743 ---- ALTO client protocol 745 Figure 2: Basic message sequence chart for resource consumer- 746 initiated ALTO query 748 ............................. ............................. 749 : Tracker : : Peer : 750 : ______ : : : 751 : +-______-+ : : : 752 : | | +--------+ : P2P App. : k good peers & +------+ : 753 : | N | | ALTO- | : Protocol : n-k bad peers | data | : 754 : | known |====>| biased |******************************>| ex- | : 755 : | peers, | | peer | : transmit : | cha- | : 756 : | M good | | select | : n peer : | nge | : 757 : +-______-+ +--------+ : IDs : +------+ : 758 :.....................^.....: :...........................: 759 | 760 | ALTO 761 | client protocol 762 __|___ 763 +-______-+ 764 | | 765 | ALTO | 766 | server | 767 +-______-+ 769 Figure 3: Tracker-based P2P Application with ALTO client in tracker 771 Peer Tracker w. 3PAC ALTO Server 772 --------+-------- --------+-------- --------+-------- 773 | F1 Tracker query | | 774 |======================>| | 775 | | F2 ALTO cli. p. query | 776 | |---------------------->| 777 | | F3 ALTO cli. p. reply | 778 | |<----------------------| 779 | F4 Tracker reply | | 780 |<======================| | 781 | | | 783 ==== Application protocol (i.e., tracker-based P2P app protocol) 784 ---- ALTO client protocol 786 Figure 4: Basic message sequence chart for third-party ALTO query 788 Note: the message sequences depicted in Figure 2 and Figure 4 may 789 occur both in the target-aware and the target-independent query mode 790 (c.f. [RFC6708]). In the target-independent query mode no message 791 exchange with the ALTO server might be needed after the tracker 792 query, because the candidate resource providers could be evaluated 793 using a locally cached "map", which has been retrieved from the ALTO 794 server some time ago. 796 The problem with the first approach is, that while the resource 797 directory might know thousands of peers taking part in a swarm, the 798 list returned to the resource consumer is usually shortened for 799 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 800 potential resource providers might not be contained in that list 801 anymore, even before ALTO can consider them. 803 For illustration, consider a simple model of a swarm, in which all 804 peers fall into one of only two categories: assume that there are 805 "good" ("good" in the sense of ALTO's better-than-random peer 806 selection, based on an arbitrary desired rating criterion) and "bad' 807 peers only. Having more different categories makes the maths more 808 complex but does not change anything to the basic outcome of this 809 analysis. Assume that the swarm has a total number of N peers, out 810 of which are M "good" and N-M "bad" peers, which are all known to the 811 tracker. A new peer wants to join the swarm and therefore asks the 812 tracker for a list of peers. 814 If, according to the first approach, the tracker randomly picks n 815 peers from the N known peers, the result can be described with the 816 hypergeometric distribution. The probability that the tracker reply 817 contains exactly k "good" peers (and n-k "bad" peers) is: 819 / m \ / N - m \ 820 \ k / \ n - k / 821 P(X=k) = --------------------- 822 / N \ 823 \ n / 825 / n \ n! 826 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 827 k! (n-k)! 829 The probability that the reply contains at most k "good" peers is: 830 P(X<=k)=P(X=0)+P(X=1)+..+P(X=k). 832 For example, consider a swarm with N=10,000 peers known to the 833 tracker, out of which M=100 are "good" peers. If the tracker 834 randomly selects n=100 peers, the formula yields for the reply: 835 P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% 836 this list does not contain a single "good" peer, and with 99% 837 probability there are only four or less of the "good" peers on the 838 list. Processing this list with the guiding ALTO information will 839 ensure that the few favorable peers are ranked to the top of the 840 list; however, the benefit is rather limited as the number of 841 favorable peers in the list is just too small. 843 Much better traffic optimization could be achieved if the tracker 844 would evaluate all known peers using ALTO, and return a list of 100 845 peers afterwards. This list would then include a significantly 846 higher fraction of "good" peers. (Note, that if the tracker returned 847 "good" peers only, there might be a risk that the swarm might 848 disconnect and split into several disjunct partitions. However, 849 finding the right mix of ALTO-biased and random peer selection is out 850 of the scope of this document.) 852 Therefore, from an overall optimization perspective, the second 853 scenario with the ALTO client embedded in the resource directory is 854 advantageous, because it is ensured that the addresses of the "best" 855 resource providers are actually delivered to the resource consumer. 856 An architectural implication of this insight is that the ALTO server 857 discovery procedures must support third-party discovery. That is, as 858 the tracker issues ALTO queries on behalf of the peer which contacted 859 the tracker, the tracker must be able to discover an ALTO server that 860 can give guidance suitable for that respective peer. 862 Appendix B. Contributors List and Acknowledgments 864 The initial version of this document was co-authored by Marco Tomsu 865 . 867 Hannes Tschofenig provided the initial input to the U-NAPTR solution 868 part. Hannes and Martin Thomson provided excellent feedback and 869 input to the server discovery. 871 This memo borrows some text from [I-D.ietf-alto-server-discovery], as 872 the 3pdisc was historically part of that memo. Special thanks to 873 Michael Scharf and Nico Schwan. 875 Authors' Addresses 877 Sebastian Kiesel 878 University of Stuttgart Information Center 879 Allmandring 30 880 Stuttgart 70550 881 Germany 883 Email: ietf-alto@skiesel.de 884 URI: http://www.rus.uni-stuttgart.de/nks/ 886 Kilian Krause 887 University of Stuttgart Information Center 888 Allmandring 30 889 Stuttgart 70550 890 Germany 892 Email: schreibt@normalerweise.net 893 URI: http://www.rus.uni-stuttgart.de/nks/ 895 Martin Stiemerling 896 NEC Laboratories Europe 897 Kurfuerstenanlage 36 898 Heidelberg 69115 899 Germany 901 Phone: +49 6221 4342 113 902 Email: martin.stiemerling@neclab.eu 903 URI: http://ietf.stiemerling.org