idnits 2.17.1 draft-ietf-alto-server-discovery-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 : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 194 has weird spacing: '...Service o ...' -- The document date (March 7, 2012) is 4432 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 normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Informational RFC: RFC 6418 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-03 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-10 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-11 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: September 8, 2012 NEC Europe Ltd. 6 N. Schwan 7 M. Scharf 8 Alcatel-Lucent Bell Labs 9 H. Song 10 Huawei 11 March 7, 2012 13 ALTO Server Discovery 14 draft-ietf-alto-server-discovery-03 16 Abstract 18 The goal of Application-Layer Traffic Optimization (ALTO) is to 19 provide guidance to applications, which have to select one or several 20 hosts from a set of candidates that are able to provide a desired 21 resource. 23 Entities seeking guidance need to discover and possibly select an 24 ALTO server to ask. This is called ALTO server discovery. This memo 25 describes an ALTO server discovery mechanism based on several 26 alternative mechanisms that are applicable in a diverse set of ALTO 27 deployment scenarios. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on September 8, 2012. 52 Copyright Notice 54 Copyright (c) 2012 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 5 71 1.1.1. ALTO Server Discovery by Resource Consumers . . . . . 6 72 1.1.2. ALTO Server Discovery by a Third Party . . . . . . . . 7 73 1.2. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 8 74 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 75 3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 12 76 3.1. Retrieving the Domain Name . . . . . . . . . . . . . . . . 12 77 3.1.1. Option 1: User input . . . . . . . . . . . . . . . . . 12 78 3.1.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 13 79 3.1.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 13 80 3.2. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 14 81 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.1. Applicability for Resource Consumer Server Discovery . . . 15 83 4.2. Applicability for Third Party Server Discovery . . . . . . 16 84 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 85 5.1. Reverse DNS Lookup . . . . . . . . . . . . . . . . . . . . 17 86 5.1.1. Private customers or very small businesses . . . . . . 17 87 5.1.2. Medium-size customer networks . . . . . . . . . . . . 17 88 5.1.3. Large Customers . . . . . . . . . . . . . . . . . . . 18 89 5.2. Operational Considerations . . . . . . . . . . . . . . . . 18 90 5.3. DHCP option for DNS Suffix . . . . . . . . . . . . . . . . 19 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 21 95 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 99 Appendix A. Contributors List and Acknowledgments . . . . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 102 1. Introduction 104 The goal of Application-Layer Traffic Optimization (ALTO) is to 105 provide guidance to applications, which have to select one or several 106 hosts from a set of candidates, that are able to provide a desired 107 resource [RFC5693]. The requirements for ALTO are itemized in 108 [I-D.ietf-alto-reqs]. 110 ALTO is realized by a client-server protocol. ALTO clients send 111 queries to ALTO servers, in order to solicit guidance. Hence, ALTO 112 clients need to know the contact information of ALTO servers, which 113 can provide appropriate guidance for a given resource consumer. 114 Typically the closer an ALTO server is to a resource consumer the 115 more accurate guidance it can provide. Thus a design objective is to 116 automatically discover an ALTO server topologically close to the 117 resource consumer, if available. Redirecting an ALTO client from one 118 ALTO server to another, potentially closer, ALTO server raises 119 several issues. First ALTO servers by definition provide Network 120 Maps for the whole IP address space and thus can provide each client 121 with a potentially useful answer. Second ALTO servers are deployed 122 independently and are thus not necessarily aware of each other. The 123 contact information of the ALTO server is thus retrieved by invoking 124 the ALTO discover procedure defined in this document. 126 The ALTO protocol specification [I-D.ietf-alto-protocol] is based on 127 HTTP. Therefore, it expects that the ALTO discovery procedure yields 128 the HTTP(S) URI of the ALTO server's Information Resource Directory, 129 which gives further information about the capabilities and services 130 provided by that ALTO server. Further (DNS) lookups may be necessary 131 in order to find out the ALTO server's IP address. 133 There are various architectural options where to place the ALTO 134 client and the ALTO server discovery procedure: 136 o One option is that the ALTO client and the ALTO server discovery 137 procedure are embedded directly in the resource consumer, i.e., 138 the application protocol entity that will eventually initiate data 139 transmission to/from the selected resource provider(s). In this 140 case, the ALTO server discovery procedure might be able to 141 interact with the user (i.e., prompt for a host name). 142 Furthermore, it may use services such as DHCP, which are only 143 available within the access network to which the resource consumer 144 is connected. 146 o Another option is to integrate the ALTO client and the ALTO server 147 discovery procedure into a third party such as a resource 148 directory ("peer-to-peer tracker"), which issues ALTO queries on 149 behalf of various resource consumers. This third party may reside 150 in a different part of the network (administrative domain) than 151 the resource consumer. It may occur that said third party whishes 152 to issue ALTO queries on behalf of a resouce consumer, but all it 153 knows about the resource consumer is the source IP address of 154 messages originating from it (i.e., the resource consumer's IP 155 address or the "public" IP address of the outermost NAT in front 156 of the resource consumer). This IP address will be the only input 157 parameter to the ALTO server discovery procedure, which will have 158 to find an ALTO server that can give appropriate guidance for that 159 resource consumer. 161 A more detailed discussion of various options where to place the 162 funcional entities comprising the overall ALTO architecture can be 163 found in [I-D.ietf-alto-deployments]. 165 The goal of this memo is to propose a uniform mechanism for all types 166 of ALTO client deployments that is implementable and deployable at a 167 fast pace, i.e., without creating other deployment dependencies for 168 ALTO. We propose a schema which employs the U-NAPTR mechanism 169 [RFC4848] to determine the URI of the ALTO server and where mutliple 170 input methods to the U-NAPTR process can be used. U-NAPTR is used 171 because the discovery mechanism must return an URI, and thus other 172 discovery mechanisms are not applicable (e. g., DNS SRV records). 174 Comments and discussions about this memo should be directed to the 175 ALTO working group: alto@ietf.org. 177 1.1. Discovery Scenarios 179 Figure 1 below shows an overview on the different entities of a 180 generic ALTO framework. The ALTO Server discovery mechanism is used 181 by the peer-to-peer (P2P) application in order retrieve the point of 182 contact of the ALTO Service. 184 +------+ 185 +-----+ | Peers 186 +-----+ +------+ +=====| |--+-oo 187 | |......| |====+ oo+--*--+ o 188 +-----+ +------+ | o * ooooooo 189 Source of ALTO | o * 190 Topological Service | o +--*--+ 191 information +===o=| | Tracker 192 o +-----+ /Super-peer 193 ALTO Discovery o o 194 Service o o 195 +------+ o o 196 | |oooooooooo 197 +------+ 199 Legend: 201 === ALTO query protocol 202 ooo ALTO service discovery protocol 203 *** Application protocol (out of scope) 204 ... Provisioning or initialization (out of scope) 206 Figure 1: ALTO Discovery Overview 208 Hereby the ALTO service discovery scenarios are classified into two 209 types: one is the ALTO server discovery by the resource consumer, and 210 the other is the ALTO server discovery by a third party, such as 211 application trackers. Before the specification of the discovery 212 mechanism the following section illustrates and discusses both 213 scenarios. 215 1.1.1. ALTO Server Discovery by Resource Consumers 217 The ALTO service discovery in some scenarios needs to be performed by 218 the resource consumer itself. In particular in P2P applications 219 without a tracker like DHTs and other conventional client/server 220 applications. 222 In addition also P2P application which are tracker based may embed 223 the ALTO client into the resource consumer to allow peers a selection 224 of peers after retrieving the peer list from the application tracker. 225 Another option is that the resource consumer peer sends its ALTO 226 server address information to the application tracker or any other 227 third party entity, which in turn will contact the specific ALTO 228 server in order to retrieve ALTO guidance on behalf of the resource 229 consumer. 231 The following figure illustrates this scenario, showing the 232 relationship between the different entities as discussed before. 234 +---------------+ 235 | ALTO Server | 236 +---------------+ 237 ^ ^ +-----------+ 238 | | | ALTO | 239 | +---+---+ | Service | 240 | |tracker| | Discovery | 241 | +-------+ +---------+-+ 242 | | o o 243 +------------+--+ | o o 244 |P2P Application|ooooo|oooooooooooo o 245 | Client A | | o 246 +---------------+ | o 247 | o 248 +--+-------------+ o 249 | P2P Application|oooooo 250 | Client B | 251 +----------------+ 253 Figure 2: Resource Consumer ALTO Server Discovery (Example) 255 1.1.2. ALTO Server Discovery by a Third Party 257 Some P2P applications have trackers, and these applications might not 258 need to have their clients looking for the ALTO server guidance. In 259 these scenarios trackers query the ALTO servers for guidance 260 themselves, and then return the final ranked result to the 261 application clients. However, application clients are distributed 262 among different network operators and autonomous systems. Trackers 263 thus need to find different ALTO servers for the clients located in 264 different operator networks or autonomous systems. In such scenarios 265 the discovery is thus not performed by the resource consumer, but a 266 third party entity on behalf of the resource consumer. 268 Figure 3 shows an example for a third party ALTO server discovery. 269 For Client1 (1), the tracker has not cached yet the mapping between 270 Client1's network operator and its ALTO server address, so it uses 271 the ALTO Discovery Service to determine the address of the ALTO 272 server in that operator's domain (2). Then the tracker interacts 273 with ALTO Server1 (3)(4) on behalf of Client1 (to get the network map 274 and cost map), finally, the ranked list is sent back to Client1 (5). 275 For Client2, the tracker has cached the mapping between Client2's 276 network operator and ALTO Server2's address, so it does not need to 277 perform the discovery process (which are the labels (a),(b), (c), and 278 (d)). If the application tracker already has the network map and 279 cost map from ALTO Server2, then it does not need to query the ALTO 280 Server for network map and cost map frequently. 282 +-------------+ +-------------+ 283 | ALTO Server1| | ALTO Server2| 284 +-------------+ +-------------+ 285 ^ | ^ | 286 3| 4| b| |c 287 | | | | 288 v /----------+-\ v 289 +-----------+ ////// \\\\\ 290 | | ||| ||| 291 | ALTO |<===>| | 292 | Discovery | 2 | Application Tracker | 293 | Service | ||| ||| 294 | | \\\\\\ ///// 295 +-----------+ ^ | \------------/ | 296 | |5 ^ |d 297 1| | a| | 298 | v | v 299 +-+---------+ +---+--------+ 300 |Application| |Application | 301 | Client1 | | Client2 | 302 +-----------+ +------------+ 304 Figure 3: Third Party ALTO Server Discovery (Example) 306 1.2. Pre-Conditions 308 The whole document assumes certain pre-conditions, in particular: 310 o The ALTO server discovery procedure is executed on a per IP family 311 base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO 312 client to decide which of the possible multiple results of 313 different IP address families to use. The choice of whether to 314 use IPv4 or IPv6 is out of scope of this document. 316 o A change of the IP address at an interface invalidates the result 317 of the ALTO server discovery procedure. For instance, if the IP 318 address assigned to a mobile host changes due to host mobility, it 319 is required to run the ALTO server discovery procedure for the new 320 IP address without relying on earlier gained information. 322 o The ALTO server discovery procedure is executed on a per IP 323 address base. Multiple IP addresses per interface or multiple IP 324 addresses assigned to different IP interfaces require to repeat 325 the procedure for every IP address. It may be fine to group IP 326 addresses according their domain suffixes and to perfom the 327 procedure for such a group. However, this is out of scope of this 328 document. 330 o There are several challenges with DNS on hosts with multiple 331 interfaces [RFC6418], which can affect the ALTO server discovery. 332 If the DNS resolution is performed on the wrong interface, it can 333 return an ALTO server that could provide sub-optimal or wrong 334 guidance. Finding the best ALTO server for multi-interfaced hosts 335 is outside the scope of this document. 337 o The discovery procedure may need information about the public IP 338 address and thus have to discover NATs. Details of NAT discovery 339 are not discussed in this memo. 341 2. Protocol Overview 343 We define multiple alternatives to discover the IP address of the 344 ALTO server, as there are a number of ways possible how such 345 information can be provided to the ALTO client. The choice of method 346 is up to the local network deployment. For instance, there can be 347 deployments where the ALTO server in charge for ALTO client is 348 provisioned by the network operator and communicated to the ALTO 349 client's host via a DHCP option, while in other deployments no such 350 means may exist. 352 It should be noted that there is no silver bullet solution to the 353 ALTO server discovery, as there too many deployment scenarios in the 354 server discovery space. 356 The following figure illustrates the different protocols that SHOULD 357 be used to find the URI of a suitable ALTO server. 359 Descending Order of Preference 360 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 362 -------------- -------------- --------------------- 363 | User Input | | DHCP query | | DNS PTR lookup on | 364 | in res.c. | | by res.c. | | res.c's IP addr. | 365 -------------- -------------- --------------------- 366 | | | 367 \ | / 368 \--------+----------/ 369 | 370 V 371 DNS suffix 372 | 373 V 374 ------------------ 375 | U-NAPTR lookup | 376 ------------------ 377 | 378 V 379 ALTO Server's Information Resource Directory URI 381 Figure 4: Protocol Overview 383 Figure 4 illustrates the U-NAPTR based resolution process to retrieve 384 the ALTO Server URL. As a precondition for resolution the U-NAPTR 385 process needs the right domain name as input. This domain name is 386 determined by the IP address of the client and the DNS suffix of the 387 access network where the client is registered in. In order to 388 retrieve the DNS suffix we specify three options, as are listed in 389 descending order of preference. A client SHOULD use the first DNS 390 suffix determined and MAY try other methods in case the U-NAPTR 391 lookup failed. 393 User input: A user MAY manually specify the DNS suffix on its own, 394 either to access a 3rd party ALTO service provider or as it does 395 know such information. This input MAY also origin from a web page 396 where the user downloads the configuration, which is loaded as 397 user input, or obtained by other discovery methods. 399 DHCP: A network provider MAY provide the DNS suffix through a DHCP 400 option. 402 Reverse DNS: The DNS system MAY be used to retrieve the DNS suffix 403 through reverse lookup of an FQDN associated with an IP address. 404 This is the last resort if all other options failed. It must be 405 noted that the Reverse DNS lookup results in significant 406 operational and deployment challanges and it is thus RECOMMENDED 407 to avoid that method if possible. 409 This discovery method SHOULD be repeated if the resource consumer 410 moves, i. e., if its IP address changes. 412 Instead of using the standard ALTO server discovery method, 413 applications MAY also use own methods to discover an ALTO server. 414 This variant is outside the scope of this document. 416 3. Retrieving the URI by U-NAPTR 418 This section specifies the U-NAPTR based resolution process. To 419 start the U-NAPTR resolution process a domain name is required as 420 input. Thus the section is devided into two parts: Section 3.2 421 describes the U-NAPTR resolution process itself. How the client 422 identifies this DNS suffix of the access network where the resource 423 consumer is registered in is described in Section 3.1. 425 3.1. Retrieving the Domain Name 427 The U-NAPTR resolution process requires a domain name as input. The 428 algorithm that SHOULD be applied to determine this domain name is 429 described in this section. We specify three different options. In 430 option 1 the user manually configures a specific ALTO service 431 instance that he wants to use. Option 2 defines a DHCP option to 432 allow the network service provider a remote configuration of the 433 client. In option 3 the client tries to get the domain name by 434 performing a reverse DNS lookup on its IP address. 436 The resource consumer may have private IP addresses and public IP 437 addresses and depending on the deployment it might be necessary to 438 determine for all IP addresses the ALTO server in charge of. To 439 determine its public IP address the resource consumer may need to use 440 STUN[RFC5389] or BEP24[bep24]. Determining the correct IP address 441 out of multiple options strongly depends on the deployment scenario 442 but is out of scope for this document, although we discuss it to some 443 extend in Section 4. For the following examples we assume that the 444 IP address of the resource consumer is a.b.c.d. 446 3.1.1. Option 1: User input 448 A user may want to use a third party ALTO service instance. 449 Therefore we allow the user to specify a DNS suffix on its own, for 450 example in a config file option. The DNS suffix given by the user is 451 combined with the IP address of the resource consumer to allow the 452 third party ALTO service to direct the client to a suitable ALTO 453 server based on the location of the client. A possible DNS suffix 454 entered by the user may be: 456 myaltoprovider.org 458 This DNS suffix SHOULD be prepended with the IP address of the 459 resource consumer in reverse order to compose the domain name used 460 for the final U-NAPTR lookup Section 3.2. This is useful in case 461 there are multiple ALTO servers deployed, and the ALTO client should 462 be redirected to the ALTO server closest to the client based on the 463 IP address. 465 Multiple lookups with different domain names MAY be necessary to 466 complete the U-NAPTR resolution process. If there is no response for 467 a lookup i. e., if no ALTO NAPTR records are found, the domain name 468 is shortened by the IP address part for the succeeding lookup, as for 469 example 471 d.c.b.a.myaltoprovider.org. 473 myaltoprovider.org. 475 In case not ALTO NAPTR records are found for both lookups we consider 476 the discovery process based on user input as failed. A client MAY 477 try one of the other options. 479 3.1.2. Option 2: DHCP 481 As a second option network operators MAY configure the domain name to 482 be used for service discovery within an access network. RFC 483 5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain name 484 options that identify a domain name that is suitable for service 485 discovery within the access network. The ALTO server discovery 486 procedure uses these DHCP options to retrieve the domain name as an 487 input for the U-NAPTR resolution. One example could be: 489 example.com 491 3.1.3. Option 3: Reverse DNS Lookup 493 The last option to get the domain name is to use a DNS PTR query for 494 the IP address of the resource consumer. The local DNS server 495 resolves the IP address to the FQDN that also contains the DNS suffix 496 for the respective IP address. A possible answer for a PTR lookup 497 for d.c.b.a.in-addr.apra might be, for example: 499 d-c-b-a.dsl.westcoast.myisp.net 501 This domain name MAY be used for the final U-NAPTR lookup 502 Section 3.2. If there is no response to the lookup the domain name 503 ii MAY be shortened by one part for one succeeding lookup. If there 504 is still no response we consider the reverse lookup being failed. 505 The domain names used for the example as described above are: 507 d-c-b-a.dsl.westcoast.myisp.net. 509 dsl.westcoast.myisp.net. 511 3.2. U-NAPTR Resolution 513 The ALTO protocol specification [I-D.ietf-alto-protocol] expects that 514 the ALTO discovery procedure yields the HTTP(S) URI of the ALTO 515 server's Information Resource Directory, which gives further 516 information about the capabilities and services provided by that ALTO 517 server. The first step of the ALTO server discovery procedure (see 518 Section 3.1) yielded an U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic 519 Delegation Discovery Service) [RFC4848] application unique strings, 520 in the form of a DNS name. An example is "example.com". 522 In the second step, the ALTO Server discovery procedure needs to use 523 the U-NAPTR [RFC4848] specification described below to obtain a URI 524 (indicating host and protocol) for the ALTO server's Information 525 Resource Directory. In this document, only the HTTP and HTTPS URL 526 schemes are defined, as the ALTO protocol specification defines the 527 access over both protocols, but no other [I-D.ietf-alto-protocol]. 528 Note that the HTTP URL can be any valid HTTP(s) URL, including those 529 containing path elements. 531 The following two DNS entries show the U-NAPTR resolution for 532 "example.com" to the HTTPS URL 533 https://altoserver.example.com/secure/directory or the HTTP URL 534 http://altoserver.example.com/directory, with the former being 535 preferred. 537 example.com. 539 IN NAPTR 100 10 "u" "ALTO:https" 540 "!.*!https://altoserver.example.com/secure/directory!" "" 542 IN NAPTR 200 10 "u" "ALTO:http" 543 "!.*!http://altoserver.example.com/directory!" "" 545 There is a potential that retrieveing the domain name or the U-NAPTR 546 lookup itself does not yield to a result, i.e. no ALTO NAPTR record 547 is found. In this case the discovery procedure failed for this IP 548 address. It is RECOMMENDED that clients give up the discovery 549 process and wait a period of time before repeating the procedure. 550 Clients MAY repeat the discovery procedure for a different IP address 551 instantaneously. 553 4. Applicability 555 This section discusses the applicability of the proposed solution 556 with respect to the resource consumer server discovery and the third 557 party deployment scenarios. Each section discusses the proposed 558 steps that are needed to determine the ALTO Server URI. 560 4.1. Applicability for Resource Consumer Server Discovery 562 In this scenario the ALTO server discovery procedure is performed by 563 the resource consumer, for example a peer in a P2P system. After the 564 discovery the peer does the ALTO query on its own, or it might share 565 the ALTO server contact information with a third party, for example a 566 tracker, which then executes the ALTO query on behalf of the peer. 568 To complete the ALTO server discovery process the resource consumer 569 first SHOULD check whether the user has provider the domain name 570 through manual configuration. If this is not the case the next step 571 SHOULD be to check for the access network domain name DHCP option 572 (Section 3.1.2). Finally the client MAY try to retrieve the domain 573 name by the last option, the DNS reverse lookup on its IP address as 574 described in Section 3.1.3. 576 A client can have several candidate IP addresses that it may use for 577 the discovery process. For example if it is located behind a NAT, a 578 private and a public IP address may be used for the discovery 579 process. It depends on the deployment scenario which of the IP 580 addresses is the correct one. Thus it is out-of-scope of this 581 document to specify how exactly the client finds the right IP 582 address. However in the following we list methods that may be used 583 in order to determine these candidate IP addresses. Generally in P2P 584 environments peers already have implemented mechanisms for NAT- 585 traversal. This includes proprietary solutions to determine a peer's 586 public IP address, for example by asking a neighbour peer about its 587 record of the own IP address. Non-proprietary solutions that are 588 favorable include the Session Traversal Utilities for NAT (STUN) 589 [RFC5986] protocol to determine the public address. If the client is 590 behind a residential gateway another option may be to use Universal 591 Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port 592 Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp]. 594 In case the ALTO discovery client has determined the domain name 595 through one of the described options it proceedes with the U-NAPTR 596 lookup as described in Section 3.2. 598 4.2. Applicability for Third Party Server Discovery 600 In case of the third party server discovery deployment scenario the 601 entity performing the ALTO server discovery process is different from 602 the resource consumer. Typically the resource consumer is a peer 603 whereas the ALTO client is a resource directory which seeks for ALTO 604 guidance on behalf of the peer. Another use case for the third party 605 discovery is an application that looks for ALTO guidance 606 transparently for the resource consumer, for example a CDN. 608 Here the ALTO server discovery process can also retrieve guidance 609 through the DHCP option or manual user configuration, but only if the 610 provided discovery information is forwarded by the resource consumer 611 to the third party entity. In this case, additional mechanisms for 612 the forwarding of this discovery information need to be specified. 613 However these mechanisms are out of scope of this doument. 615 If the third party entity cannot obtain this discovery information, 616 the ALTO server discovery process relies on retrieving the domain 617 name used as input to the U-NAPTR lookup through reverse DNS lookup 618 of the IP address of the resource consumer as described in 619 Section 3.1.3. Usually the third party entity already knows the IP 620 address of the resource consumer which was used to establish the 621 initial connection. In general this IP address is a public address, 622 either of the resource consumer or of the last NAT on the path to the 623 ALTO client. This makes the IP address a good candidate for the DNS 624 PTR query. Thus, we expect that the DNS query will be successfully 625 resolved to the FQDN of the domain where the resource consumer is 626 registered in. 628 In case the resource consumer needs guidance for a different IP 629 address, for example one from a private network, we recommend that 630 the resource consumer discovers the server itself and forwards the 631 ALTO server contact information directly to the third party entity, 632 which in turn can then do the third party ALTO query. Again, 633 forwarding the contact information from the resource consumer to the 634 third party entity is out of scope of this document. 636 5. Deployment Considerations 638 The mechanism specified in this document needs some configuration 639 effort in order to work properly. 641 5.1. Reverse DNS Lookup 643 Especially the domain name retrieved through the reverse DNS lookup 644 (PTR records) and the U-NAPTR entry need to be coordinated. In this 645 section we discuss this configuration for different scenarios. 647 5.1.1. Private customers or very small businesses 649 For private customers and very small businesses that are DSL or cable 650 customers often a dynamically assigned IP address is provisioned. 651 Here, the reverse DNS lookup (PTR records) are controlled by the ISP 652 and they point to the ISP's domain, e.g.: 654 p5B203EA1.dip.t-dialin.net. 656 dslb-084-056-144-100.pools.arcor-ip.net. 658 187-4-222-157.bnut3700.dsl.brasiltelecom.net.br. 660 65-154-39-69.ispnetbilling.com. 662 197-151-94-178.pool.ukrtel.net. 664 In this case, it would be the responsibility of the respective ISP to 665 provide U-NAPTR entries for the DNS suffix without the endhost part, 666 e.g.: 668 dip.t-dialin.net. 670 pools.arcor-ip.net. 672 bnut3700.dsl.brasiltelecom.net.br. 674 ispnetbilling.com. 676 pool.ukrtel.net. 678 5.1.2. Medium-size customer networks 680 The second class of customers have their own DNS domain but only one 681 single upstream ISP, e.g.: 683 (1) ISP my-isp.net assigns an IP address a.b.c.d to its customer 685 (2) The customer decides that reverse mapping for a.b.c.d should be 686 whatever.customerdomain.com 688 (3) If the customer wants to support ALTO, he has to ask the ISP for 689 the URI of the ISP's ALTO server which can give guidance to 690 a.b.c.d. Assume that ISP replies it is 691 http://altoserver.my-isp.net 693 (4) The customer establishes a U-NAPTR entry for his domain 695 customerdomain.com. IN NAPTR 200 10 "u" "ALTO:http" 696 "!.*!http://altoserver.my-isp.net!" "" 698 5.1.3. Large Customers 700 For very large customers with multiple upstream connections we assume 701 that they have their very own traffic optimization policies and thus 702 run their own ALTO server anyway. In this case they need to manage 703 their DNS entries accordingly. 705 5.2. Operational Considerations 707 A service discovery based on reverse DNS lookup results in several 708 limitations: 710 First, there is no established unique way of maintaining the DNS 711 tree, and there are different practices in different networks. 712 Furthermore, it is possible that a lookup fails or that the returned 713 value is not valid. For instance, it can point to a different 714 domain. As a result, users of the ALTO discovery mechanism must be 715 able to deal with failures of the reverse DNS lookup and react 716 accordingly. As the reverse DNS lookup is the least preferred 717 variant, failure of this discovery mechanism may imply that not ALTO 718 server can be discovered and ALTO guidance is thus not available. 720 Second, determining a domain name from IP addresses by tree climbing 721 is problematic, in particular for IPv6. [RFC4472] discusses the 722 issues for IPv6. 724 Third, populating a DNS name space what looks like a reverse tree is 725 a significant administrative DNS overhead. 727 Finally it must be emphasized that any tree walking procedure raises 728 several issues. In this draft we therefore intentionally allow only 729 one step for shortening domain names for any of the specified 730 methods. Nevertheless, implementers of this specification SHOULD 731 consider skipping this step. For instance, there are different 732 possible reasons why an ALTO NAPTR record cannot be found, including 733 a timeout or a lack of name or record, and the discovery client needs 734 heuristics to deal with all of them. 736 5.3. DHCP option for DNS Suffix 738 Section 3.1.2 describes the usage of a DHCP option which allows the 739 network operator of the network where the ALTO client is attached to, 740 to provide a DNS suffix. However, this assumes that this particular 741 DHCP option is correctly passed from the DHCP server to the actual 742 host with the ALTO client, and that the particular host understands 743 this DHCP option. This memo assumes the client to be able to 744 understand the proposed DHCP option, otherwise there is no further 745 use of the DHCP option, but the client has to use the other proposed 746 mechanisms. 748 There are well-known issues with the handling of DHCP options in home 749 gateways. One issue is that unkown DHCP options are not passed 750 through some home gateways, effectively eliminating the DHCP option. 752 Another well-known issues is the usage of home gateway specific DNS 753 suffixes which "override" the DNS suffix provided by the network 754 operator. For instance, a host behind a home gateway may receive a 755 DNS suffix ".local" instead of "example.com". This suffix is not 756 usuable for the server discovery procedure. 758 6. IANA Considerations 760 This document registers the following U-NAPTR application service 761 tag: 763 Application Service Tag: ALTO 765 Defining Publication: The specification contained within this 766 document. 768 This document registers the following U-NAPTR application protocol 769 tags: 771 o Application Protocol Tag: http 773 Defining Publication: RFC 2616 [RFC2616] 775 o Application Protocol Tag: https 777 Defining Publication: RFC 2818 [RFC2818] 779 7. Security Considerations 781 7.1. General 783 This section is still to be completed in later revision of this 784 draft, as the draft evolves heavily right now. 786 There are two different failures for the ALTO server discovery, which 787 can both be caused by malicious attacks or by configuration problems, 788 e. g., in case of DNS configuration errors or multi-homed hosts. 790 First, the discovery might not be able to discover an ALTO server, 791 even if a suitable ALTO server exists. In that case, ALTO guidance 792 will not be used. The resulting application performance and traffic 793 distribution will correspond to a deployment scenario without ALTO 794 guidance. But given that users cannot rely on the availability of an 795 ALTO server, this results in no significant additional security risk. 797 Second, the discovery procedure may discover a sub-optimal or wrong 798 ALTO server. Such an ALTO server may either not be able to provide 799 information for a given resource consumer (e. g., behind a NAT), thus 800 rendering the ALTO service useless. Alternatively, it may provide 801 sub-optimal or forged information. In the latter case, attackers 802 could try to use ALTO to affect the traffic distribution or the 803 performance of applications. Users may then observe performance 804 problems, and network operators could detect traffic anormalities. A 805 potential counter-measure is to disable the use of the ALTO service. 807 Security issues of ALTO in general and potential solutions are also 808 discussed in [I-D.ietf-alto-protocol]. 810 7.2. For U-NAPTR 812 The address of an ALTO server is usually well-known within an access 813 network; therefore, interception of messages does not introduce any 814 specific concerns. 816 The primary attack against the methods described in this document is 817 one that would lead to impersonation of an ALTO server since a device 818 does not necessarily have a prior relationship with an ALTO server. 820 An attacker could attempt to compromise ALTO discovery at any of 821 three stages: 823 1. providing a falsified domain name to be used as input to U-NAPTR 825 2. altering the DNS records used in U-NAPTR resolution 826 3. impersonation of the ALTO server 828 This document focuses on the U-NAPTR resolution process and hence 829 this section discusses the security considerations related to the DNS 830 handling. The security aspects of obtaining the domain name that is 831 used for input to the U-NAPTR process is described in respective 832 documents, such as [RFC5986]. 834 The domain name that is used to authenticated the ALTO server is the 835 domain name in the URI that is the result of the U-NAPTR resolution. 836 Therefore, if an attacker was able to modify or spoof any of the DNS 837 records used in the DDDS resolution, this URI could be replaced by an 838 invalid URI. The application of DNS security (DNSSEC) [RFC4033] 839 provides a means to limit attacks that rely on modification of the 840 DNS records used in U-NAPTR resolution. Security considerations 841 specific to U-NAPTR are described in more detail in [RFC4848]. 843 An "https:" URI is authenticated using the method described in 844 Section 3.1 of [RFC2818]. The domain name used for this 845 authentication is the domain name in the URI resulting from U-NAPTR 846 resolution, not the input domain name as in [RFC3958]. Using the 847 domain name in the URI is more compatible with existing HTTP client 848 software, which authenticate servers based on the domain name in the 849 URI. 851 An ALTO server that is identified by an "http:" URI cannot be 852 authenticated. If an "http:" URI is the product of the ALTO 853 discovery, this leaves devices vulnerable to several attacks. Lower 854 layer protections, such as layer 2 traffic separation might be used 855 to provide some guarantees. 857 8. Conclusion 859 This document describes a general ALTO server discovery process and 860 discusses how the process can be applied in different deployment 861 scenarios, including the resouce consumer discovery as well as the 862 third party discovery. 864 9. References 866 9.1. Normative References 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, March 1997. 871 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 872 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 873 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 875 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 877 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 878 Service Location Using SRV RRs and the Dynamic Delegation 879 Discovery Service (DDDS)", RFC 3958, January 2005. 881 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 882 Rose, "DNS Security Introduction and Requirements", 883 RFC 4033, March 2005. 885 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 886 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 887 October 2008. 889 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 890 Provisioning Domains Problem Statement", RFC 6418, 891 November 2011. 893 9.2. Informative References 895 [I-D.cheshire-nat-pmp] 896 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 897 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 899 [I-D.ietf-alto-deployments] 900 Stiemerling, M. and S. Kiesel, "ALTO Deployment 901 Considerations", draft-ietf-alto-deployments-03 (work in 902 progress), November 2011. 904 [I-D.ietf-alto-protocol] 905 Penno, R., Alimi, R., and Y. Yang, "ALTO Protocol", 906 draft-ietf-alto-protocol-10 (work in progress), 907 October 2011. 909 [I-D.ietf-alto-reqs] 910 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 911 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 912 Requirements", draft-ietf-alto-reqs-11 (work in progress), 913 July 2011. 915 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 916 Considerations and Issues with IPv6 DNS", RFC 4472, 917 April 2006. 919 [RFC4848] Daigle, L., "Domain-Based Application Service Location 920 Using URIs and the Dynamic Delegation Discovery Service 921 (DDDS)", RFC 4848, April 2007. 923 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 924 Optimization (ALTO) Problem Statement", RFC 5693, 925 October 2009. 927 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 928 Location Information Server (LIS)", RFC 5986, 929 September 2010. 931 [UPnP-IGD-WANIPConnection1] 932 UPnP Forum, "Internet Gateway Device (IGD) Standardized 933 Device Control Protocol V 1.0: WANIPConnection:1 Service 934 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 935 November 2001. 937 [bep24] Harrison, D., "Tracker Returns External IP", 938 BEP http://bittorrent.org/beps/bep_0024.html. 940 Appendix A. Contributors List and Acknowledgments 942 The initial version of this document was co-authored by Marco Tomsu 943 . 945 Hannes Tschofenig provided the initial input to the U-NAPTR solution 946 part. Hannes and Martin Thomson provided excellent feedback and 947 input to the server discovery. 949 The authors would also like to thank the following persons for their 950 contribution to this document or its predecessors: Richard Alimi, 951 David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang, 952 Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei 953 Zhang, Ning Zong. 955 Marco Tomsu and Nico Schwan are partially supported by the ENVISION 956 project (http://www.envision-project.org), a research project 957 supported by the European Commission under its 7th Framework Program 958 (contract no. 248565). The views and conclusions contained herein 959 are those of the authors and should not be interpreted as necessarily 960 representing the official policies or endorsements, either expressed 961 or implied, of the ENVISION project or the European Commission. 963 Michael Scharf is supported by the German-Lab project 964 (http://www.german-lab.de) funded by the German Federal Ministry of 965 Education and Research (BMBF). 967 Martin Stiemerling is partially supported by the COAST project 968 (COntent Aware Searching, retrieval and sTreaming, 969 http://www.coast-fp7.eu), a research project supported by the 970 European Commission under its 7th Framework Program (contract no. 971 248036). The views and conclusions contained herein are those of the 972 authors and should not be interpreted as necessarily representing the 973 official policies or endorsements, either expressed or implied, of 974 the COAST project or the European Commission. 976 Authors' Addresses 978 Sebastian Kiesel 979 University of Stuttgart Computing Center 980 Allmandring 30 981 Stuttgart 70550 982 Germany 984 Email: ietf-alto@skiesel.de 985 URI: http://www.rus.uni-stuttgart.de/nks/ 987 Martin Stiemerling 988 NEC Laboratories Europe 989 Kurfuerstenanlage 36 990 Heidelberg 69115 991 Germany 993 Phone: +49 6221 4342 113 994 Email: martin.stiemerling@neclab.eu 995 URI: http://ietf.stiemerling.org 997 Nico Schwan 998 Alcatel-Lucent Bell Labs 999 Lorenzstrasse 10 1000 Stuttgart 70435 1001 Germany 1003 Email: nico.schwan@alcatel-lucent.com 1004 URI: www.alcatel-lucent.com/bell-labs 1006 Michael Scharf 1007 Alcatel-Lucent Bell Labs 1008 Lorenzstrasse 10 1009 Stuttgart 70435 1010 Germany 1012 Email: michael.scharf@alcatel-lucent.com 1013 URI: www.alcatel-lucent.com/bell-labs 1015 Haibin Song 1016 Huawei 1018 Email: melodysong@huawei.com