idnits 2.17.1 draft-kiesel-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 : ---------------------------------------------------------------------------- == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 488: '... first SHOULD check whether the user...' RFC 2119 keyword, line 490: '... SHOULD be to check for the access n...' RFC 2119 keyword, line 491: '...nally the client SHOULD try to retriev...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '...Service o ...' -- The document date (March 14, 2011) is 4789 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) == Unused Reference: 'I-D.song-alto-server-discovery' is defined on line 779, but no explicit reference was found in the text ** 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) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-04 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-08 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-03 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 15, 2011 NEC Europe Ltd. 6 N. Schwan 7 M. Scharf 8 Alcatel-Lucent Bell Labs 9 M. Tomsu 10 Alcatel-Lucent 11 H. Song 12 Huawei 13 March 14, 2011 15 ALTO Server Discovery Protocol 16 draft-kiesel-alto-3pdisc-05 18 Abstract 20 The goal of Application-Layer Traffic Optimization (ALTO) is to 21 provide guidance to applications, which have to select one or several 22 hosts from a set of candidates that are able to provide a desired 23 resource. 25 Entities seeking guidance need to discover and possibly select an 26 ALTO server to ask. This is called ALTO server discovery. This memo 27 describes an ALTO server discovery mechanism based on several 28 alternative mechanisms that are applicable in a diverse set of ALTO 29 deployments. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 15, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 4 67 1.2.1. ALTO Server Discovery by Resource Consumers . . . . . 4 68 1.2.2. ALTO Server Discovery by a Third Party . . . . . . . . 5 69 1.3. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 6 70 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10 72 3.1. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10 73 3.2. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10 74 3.2.1. Option 1: User input . . . . . . . . . . . . . . . . . 11 75 3.2.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 11 76 3.2.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12 77 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.1. Applicability for Resource Consumer Server Discovery . . . 13 79 4.2. Applicability for Third Party Server Discovery . . . . . . 13 80 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 81 5.1. Private customers or very small businesses . . . . . . . . 15 82 5.2. Medium-size customer networks . . . . . . . . . . . . . . 15 83 5.3. Large Customers . . . . . . . . . . . . . . . . . . . . . 16 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 18 88 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 The goal of Application-Layer Traffic Optimization (ALTO) is to 100 provide guidance to applications, which have to select one or several 101 hosts from a set of candidates, that are able to provide a desired 102 resource [RFC5693]. The requirements for ALTO are itemized in 103 [I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol. 104 ALTO clients send queries to ALTO servers, in order to solicit 105 guidance. 107 ALTO clients have to discover suitable ALTO servers. Therefore the 108 output of the herein defined ALTO discovery procedure tells the ALTO 109 client which ALTO servers to send the queries to. The ALTO discovery 110 procedure, as part of the the ALTO client, can be embedded in the 111 resource consumer, which will eventually access the desired resource. 112 As an alternative, they can be embedded in a resource directory, 113 which assists resource consumers in finding appropriate resource 114 providers. In some specific peer-to-peer application protocols these 115 resource directories are called "trackers". Finally the ALTO server 116 discovery procedure can be embedded in the resource consumer, whereas 117 the ALTO client is embedded in the resource directory. ALTO queries, 118 which are issued by a resource directory on behalf of a resource 119 consumer, are referred to as third-party ALTO queries. The various 120 possibilities to place ALTO servers and the placement of ALTO clients 121 is discussed in [I-D.stiemerling-alto-deployments]. 123 No matter where ALTO server and client are located, clients have to 124 first find out if there is an ALTO server deployed that is in charge 125 for them, and second they have to get the contact information of that 126 server, i.e., the IP address, port number, and probably transport 127 protocol (which defaults to TCP for [I-D.ietf-alto-protocol]). 129 The goal of this memo is to propose a uniform mechanism for all types 130 of ALTO client deployments that is implementable and deployable at a 131 fast pace, i.e., without creating other deployment dependecies for 132 ALTO. We propose to use a combination of DHCP and DNS to retrieve 133 the URL of the resposnsible ALTO server. 135 Comments and discussions about this memo should be directed to the 136 ALTO working group: alto@ietf.org. 138 1.1. History 140 This document represents a merge of features from two previous 141 drafts: 143 o draft-kiesel-alto-3pdisc-04 144 o draft-song-alto-server-discovery-03 146 1.2. Discovery Scenarios 148 Figure 1 below shows an overview on the different entities of a 149 generic ALTO framework. The ALTO Server discovery mechanism is used 150 by the p2p application in order retrieve the point of contact of the 151 ALTO Service. 153 +------+ 154 +-----+ | Peers 155 +-----+ +------+ +=====| |--+-oo 156 | |......| |====+ oo+--*--+ o 157 +-----+ +------+ | o * ooooooo 158 Source of ALTO | o * 159 Topological Service | o +--*--+ 160 information +===o=| | Tracker 161 o +-----+ /Super-peer 162 ALTO Discovery o o 163 Service o o 164 +------+ o o 165 | |oooooooooo 166 +------+ 168 Legend: 170 === ALTO query protocol 171 ooo ALTO service discovery protocol 172 *** Application protocol (out of scope) 173 ... Provisioning or initialization (out of scope) 175 Figure 1: ALTO Discovery Overview 177 Hereby the ALTO service discovery scenarios are classified into two 178 types: one is the ALTO server discovery by the resource consumer, and 179 the other is the ALTO server discovery by a third party, such as 180 application trackers. Before the specification of the discovery 181 mechanism the following section illustrates and discusses both 182 scenarios. 184 1.2.1. ALTO Server Discovery by Resource Consumers 186 The ALTO service discovery in some scenarios needs to be performed by 187 the resource consumer itself. In particular in p2p applications 188 without a tracker like DHTs and other conventional client/server 189 applications. 191 In addition also p2p application which are tracker based may embed 192 the ALTO client into the resurce consumer to allow peers a peer 193 selection after retrieving peer list from the application tracker. 194 Another option is that the reource consumer peer sends its ALTO 195 server address information to the application tracker or any other 196 third party entity, which in turn will contact the specific ALTO 197 server and in order to retrieve ALTO guidance on behalf of the 198 resource consumer. 200 The following figure illustrates this scenario, showing the 201 relationship between the different entities as discussed before. 203 +---------------+ 204 | ALTO Server | 205 +---------------+ 206 ^ ^ +-----------+ 207 | | | ALTO | 208 | +---+---+ | Service | 209 | |tracker| | Discovery | 210 | +-------+ +---------+-+ 211 | | o o 212 +------------+--+ | o o 213 |P2P Application|ooooo|oooooooooooo o 214 | Client A | | o 215 +---------------+ | o 216 | o 217 +--+-------------+ o 218 | P2P Application|oooooo 219 | Client B | 220 +----------------+ 222 Figure 2: Resource Consumer ALTO Server Discovery (Example) 224 1.2.2. ALTO Server Discovery by a Third Party 226 Some p2p applications have trackers, and these applications might not 227 need to have their clients looking for the ALTO server guidance. In 228 these scenarios trackers query the ALTO servers for guidance 229 themselves, and then return the final ranked result to the 230 application clients. However, application clients are distributed 231 among different network operators and autonomous systems. Trackers 232 thus need to find different ALTO servers for the clients located in 233 different operator networks or autonomous systems. In such scenarios 234 the discuvery is thus not performed by the resource consumer, but a 235 third party entity on behalf of the resource consumer. 237 Figure 3 shows an example for a third party ALTO server discovery. 238 For client 1, the tracker has not cached yet the mapping between 239 client 1's network operator and its ALTO server address, so it 240 queries the DNS server for the ALTO server address in that operator's 241 domain. And then the tracker interacts with the ALTO server on 242 behalf of client 1(to get the network map and cost map), finally, the 243 ranked list is sent back to client 1. For client 2, the tracker has 244 cached the mapping between client 2's network operator and its ALTO 245 server address, so it does not need to query the DNS for the address 246 of ALTO server 2. If the Application tracker already has the network 247 map and cost map from ALTO Server2, then it does not to query the 248 ALTO Server for network map and cost map frequently. 250 +-------------+ +-------------+ 251 | ALTO Server1| | ALTO Server2| 252 +-------------+ +-------------+ 253 ^ | ^ | 254 3| 4| b| |c 255 | | | | 256 v /----------+-\ v 257 +---+ ////// \\\\\ 258 | | ||| ||| 259 | |<===>| | 260 |DNS| 2 | Application Tracker | 261 | | ||| ||| 262 | | \\\\\\ ///// 263 +---+ ^ | \------------/ | 264 | |5 ^ |d 265 1| | a| | 266 | v | v 267 +-+---------+ +---+--------+ 268 |Application| |Application | 269 |client1 | |client2 | 270 +-----------+ +------------+ 272 Figure 3: Third Party ALTO Server Discovery (Example) 274 1.3. Pre-Conditions 276 The whole document assumes certain pre-conditions, such as: 278 o The ALTO server discovery procedure is executed on a per IP 279 address base. Multiple IP addresses per interface or multiple IP 280 addresses assigned to different IP interfaces require to repeat 281 the procedure for every IP address. It may be fine to group IP 282 addresses according their domain suffixes and to perfom the 283 procedure for such a group. However, this is out of scope of this 284 document. 286 o The ALTO server discovery procedure is executed on a per IP family 287 base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO 288 client to decide which of the possible multiple results of 289 different IP address families to use. The choice of whether to 290 use IPv4 or IPv6 is out of scope of this document. 292 o A change of the IP address at an interface invalidates the result 293 of the ALTO server discovery procedure. For instance, if the IP 294 address assigned to a mobile host changes due to host mobility, it 295 is required to run the ALTO server discovery procedure for the new 296 IP address without relying on earlier gained information. 298 2. Protocol Overview 300 We define multiple alternatives to discover the IP address of the 301 ALTO server, as there are a number of ways possible how such 302 information can be provided to the ALTO client. The choice of method 303 is up to the local network deployment. For instance, there can be 304 deployments where the ALTO server in charge for ALTO client is 305 provisioned by the network operator and communicated to the ALTO 306 client's host via a DHCP option, while in other deployments no such 307 means may exist. 309 The following figure illustrates the different protocols that are 310 used to find the URI of a suitable ALTO server. 312 Descending order of Preference 313 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 315 -------------- -------- --------------- 316 | User Input | | DHCP | | Reverse DNS | 317 -------------- -------- --------------- 318 | | | 319 \ | / 320 Retrieving the DNS suffix 321 \ | / 322 --------+---------- 323 | 324 ----------- 325 | U-NAPTR | 326 ----------- 327 | 328 Retrieving ALTO Server URI 329 | 330 | 331 Final DNS lookup 333 Figure 1: Protocol Overview 335 The figure above illustrates the U-NAPTR based resolution process to 336 retrieve the ALTO Server URL. As a precondition for resolution the 337 U-NAPTR process needs the right domain name as input. This domain 338 name is determined by the IP address of the client and the DNS suffix 339 of the access network where the client is registered in. In order to 340 retrieve the DNS suffix we specify three options: 342 User input: a user may manually specify the DNS suffix on its own, 343 either to access a 3rd party ALTO service provider or as it does 344 know such information. 346 DHCP: a network provider provides the DNS suffix through a DHCP 347 option. 349 Reverse DNS: the DNS system can be used to retrieve the DNS suffix 350 through reverse lookup of an FQDN associated with an IP address. 351 This is the last resort if all other options failed. 353 3. Retrieving the URI by U-NAPTR 355 This section specifies the U-NAPTR based resolution process. To 356 start the U-NAPTR resolution process a domain name as input is 357 needed. Thus the section is devided into two parts: Section 3.1 358 describes the U-NAPTR resolution process itself. How the client 359 identifies this DNS suffix of the access network where the resource 360 consumer is registered in is described in Section 3.2. 362 3.1. U-NAPTR Resolution 364 ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ 365 Dynamic Delegation Discovery Service) [RFC4848] application unique 366 strings, in the form of a DNS name. An example is 367 'altoserver.example.com'. 369 Clients need to use the U-NAPTR [RFC4848] specification described 370 below to obtain a URI (indicating host and protocol) for the 371 applicable ALTO service. In this document, only the HTTP and HTTPS 372 URL schemes are defined. Note that the HTTP URL can be any valid 373 HTTP URL, including those containing path elements. 375 The following two DNS entries show the U-NAPTR resolution for 376 "example.com" to the HTTPS URL https://altoserver.example.com/secure 377 or the HTTP URL http://altoserver.example.com, with the former being 378 preferred. 380 example.com. 382 IN NAPTR 100 10 "u" "ALTO:https" 383 "!.*!https://altoserver.example.com/secure!" "" 385 IN NAPTR 200 10 "u" "ALTO:http" 386 "!.*!http://altoserver.example.com!" "" 388 3.2. Retrieving the Domain Name 390 The U-NAPTR resolution process requires a domain name as input. The 391 algorithm that is applied to determine this domain name is described 392 in this section. We specify three different options. In option 1 393 the user manually configures a specific ALTO service instance that he 394 wants to use. Option 2 defines a DHCP option to allow the network 395 service provider a remote configuration of the client. In option 3 396 the client tries to get the domain name by performing a reverse DNS 397 lookup on its IP address. 399 The resource consumer may have private IP addresses and public IP 400 addresses and depending on the deployment it might be necessary to 401 determine for all IP addresses the ALTO server in charge of. To 402 determine its public IP address the resource consumer may need to use 403 STUN[RFC5389] or BEP24[bep24]. For the following examples we assume 404 that the IP address of the resource consumer is a.b.c.d. 406 3.2.1. Option 1: User input 408 A user may want to use a third party ALTO service instance. 409 Therefore we allow the user to specify a DNS suffix on its own, for 410 example in a config file option. The DNS suffix given by the user is 411 combined with the IP address of the resource consumer to allow the 412 third party ALTO service to direct the client to a suitable ALTO 413 server based on the location of the client. A possible DNS suffix 414 entered by the user may be: 416 myaltoprovider.org 418 This DNS suffix is prepended with the IP address of the resource 419 consumer in reverse order to compose the domain name used for the 420 final U-NAPTR lookup Section 3.1. In case there are multiple ALTO 421 servers deployed, the third party ALTO service instance can direct 422 the ALTO client to the ALTO server closest to the client based on the 423 IP address. 425 Multiple lookups with different domain names might be necessary to 426 complete the U-NAPTR resolution process. If there is no response for 427 a lookup the domain name is shortened by one part for the succeeding 428 lookup, until a lookup is successful, as for example 430 d.c.b.a.myaltoprovider.org. 432 c.b.a.myaltoprovider.org. 434 b.a.myaltoprovider.org. 436 a.myaltoprovider.org. 438 myaltoprovider.org. 440 3.2.2. Option 2: DHCP 442 As a second option network operators can configure the domain name to 443 be used for service discovery within an access network. RFC 444 5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain name 445 options that identify a domain name that is suitable for service 446 discovery within the access network. The ALTO server discovery 447 procedure uses these DHCP options to retrieve the domain name as an 448 input for the U-NAPTR resolution. One example could be: 450 example.com 452 3.2.3. Option 3: Reverse DNS Lookup 454 The last option to get the domain name is to use a DNS PTR query for 455 the IP address of the resource consumer. The local DNS server 456 resolves the IP address to the FQDN that also contains the DNS suffix 457 for the respective IP address. A possible answer for a PTR lookup 458 for d.c.b.a.in-addr.apra might be, for example: 460 d-c-b-a.dsl.westcoast.myisp.net 462 This domain name can be used for the final U-NAPTR lookup 463 Section 3.1. If there is no response to the lookup the domain name 464 is shortened by one part for one succeeding lookup. If there is 465 still no response we consider the reverse lookup being failed. The 466 domain names used for the example as described above are: 468 d-c-b-a.dsl.westcoast.myisp.net. 470 dsl.westcoast.myisp.net. 472 4. Applicability 474 This section discusses the applicability of the proposed solution 475 with respect to the resource consumer server discovery and the third 476 party deployment scenarios. Each section discusses the proposed 477 steps that are needed to determine the ALTO Server URI. 479 4.1. Applicability for Resource Consumer Server Discovery 481 In this scenario the ALTO server discovery procedure is performed by 482 the resource consumer, for example a peer in a P2P system. After the 483 discovery the peer does the ALTO query on its own, or it might share 484 the ALTO server contact information with a third party, for example a 485 tracker, which then does the ALTO query on behalf of the peer. 487 To complete the ALTO server discovery process the resource consumer 488 first SHOULD check whether the user has provider the domain name 489 through manual configuration. If this is not the case the next step 490 SHOULD be to check for the access network domain name DHCP option 491 (Section 3.2.2). Finally the client SHOULD try to retrieve the 492 domain name by the last option, the DNS reverse lookup on its IP 493 address as described in Section 3.2.3. 495 In case the ALTO discovery client has determined the domain name 496 through one of the described options it proceedes with the U-NAPTR 497 lookup as described in Section 3.1. 499 4.2. Applicability for Third Party Server Discovery 501 In case of the third party server discovery deployment scenario the 502 entity performing the ALTO server discovery process is different from 503 the resource consumer. Typically the resource consumer is a peer 504 whereas the ALTO client is a resource directory which seeks for ALTO 505 guidance on behalf of the peer. Another use case for the third party 506 discovery is an application that looks for ALTO guidance 507 transparently for the resource consumer, for example a CDN. 509 Here the ALTO server discovery process can also retrieve guidance 510 through the DHCP option or manual user configuration, but only if the 511 provided discovery information is forwarded by the resource consumer 512 to the third party entity. In this case, additional mechanisms for 513 the forwarding of this discovery information need to be specified. 514 However these mechanisms are out of scope of this doument. 516 If the third party entity cannot obtain this discovery information, 517 the ALTO server discovery process relies on retrieving the domain 518 name used as input to the U-NAPTR lookup through reverse DNS lookup 519 of the IP address of the resource consumer as described in 520 Section 3.2.3. Usually the third party entity already knows the IP 521 address of the resource consumer which was used to establish the 522 initial connection. In general this IP address is a public address, 523 either of the resource consumer or of the last NAT on the path to the 524 ALTO client. This makes the IP address a good candidate for the DNS 525 PTR query. Thus, we expect that the DNS query will be successfully 526 resolved to the FQDN of the domain where the resource consumer is 527 registered in. 529 In case the resource consumer needs guidance for a different IP 530 address, for example one from a private network, we recommend that 531 the resource consumer discovers the server itself and forwards the 532 ALTO server contact information directly to the third party entity, 533 which in turn can then do the third party ALTO query. Again, 534 forwarding the contact information from the resource consumer to the 535 third party entity is out of scope of this document. 537 5. Deployment Considerations 539 The mechanism specified in this document needs some configuration 540 effort in order to work properly. Especially the domain name 541 retrieved through the reverse DNS lookup (PTR records) and the 542 U-NAPTR entry need to be coordinated. In this section we discuss 543 this configuration for different scenarios. 545 5.1. Private customers or very small businesses 547 For private customers and very small businesses that are DSL or cable 548 customers often a dynamically assigned IP address is provisioned. 549 Here, the reverse DNS lookup (PTR records) are controlled by the ISP 550 and they point to the ISP's domain, e.g.: 552 p5B203EA1.dip.t-dialin.net. 554 dslb-084-056-144-100.pools.arcor-ip.net. 556 187-4-222-157.bnut3700.dsl.brasiltelecom.net.br. 558 65-154-39-69.ispnetbilling.com. 560 197-151-94-178.pool.ukrtel.net. 562 In this case, it would be the responsibility of the respective ISP to 563 provide U-NAPTR entries for the DNS suffix without the endhost part, 564 e.g.: 566 dip.t-dialin.net. 568 pools.arcor-ip.net. 570 bnut3700.dsl.brasiltelecom.net.br. 572 ispnetbilling.com. 574 pool.ukrtel.net. 576 5.2. Medium-size customer networks 578 The second class of customers have their own DNS domain but only one 579 single upstream ISP, e.g.: 581 (1) ISP my-isp.net assigns an IP address a.b.c.d to its customer 582 (2) The customer decides that reverse mapping for a.b.c.d should be 583 whatever.customerdomain.com 585 (3) If the customer wants to support ALTO, he has to ask the ISP for 586 the URI of the ISP's ALTO server which can give guidance to 587 a.b.c.d. Assume that ISP replies it is 588 http://altoserver.my-isp.net 590 (4) The customer establishes a U-NAPTR entry for his domain 592 customerdomain.com. IN NAPTR 200 10 "u" "ALTO:http" 593 "!.*!http://altoserver.my-isp.net!" "" 595 5.3. Large Customers 597 For very large customers with multiple upstream connections we assume 598 that they have their very own traffic optimization policies and thus 599 run their own ALTO server anyway. In this case they need to manage 600 their DNS entries accordingly. 602 6. IANA Considerations 604 This document registers the following U-NAPTR application service 605 tag: 607 Application Service Tag: ALTO 609 Defining Publication: The specification contained within this 610 document. 612 This document registers the following U-NAPTR application protocol 613 tags: 615 o Application Protocol Tag: http 617 Defining Publication: RFC 2616 [RFC2616] 619 o Application Protocol Tag: https 621 Defining Publication: RFC 2818 [RFC2818] 623 7. Security Considerations 625 7.1. General 627 This is still to be done in later revision of this draft, as the 628 draft evolves heavily right now. 630 7.2. For U-NAPTR 632 The address of an ALTO server is usually well-known within an access 633 network; therefore, interception of messages does not introduce any 634 specific concerns. 636 The primary attack against the methods described in this document is 637 one that would lead to impersonation of a ALTO server since a device 638 does not necessarily have a prior relationship with a ALTO server. 640 An attacker could attempt to compromise ALTO discovery at any of 641 three stages: 643 1. providing a falsified domain name to be used as input to U-NAPTR 645 2. altering the DNS records used in U-NAPTR resolution 647 3. impersonation of the ALTO 649 This document focuses on the U-NAPTR resolution process and hence 650 this section discusses the security considerations related to the DNS 651 handling. The security aspects of obtaining the domain name that is 652 used for input to the U-NAPTR process is described in respective 653 documents, such as [I-D.ietf-geopriv-lis-discovery]. 655 The domain name that is used to authenticated the ALTO server is the 656 domain name in the URI that is the result of the U-NAPTR resolution. 657 Therefore, if an attacker were able to modify or spoof any of the DNS 658 records used in the DDDS resolution, this URI could be replaced by an 659 invalid URI. The application of DNS security (DNSSEC) [RFC4033] 660 provides a means to limit attacks that rely on modification of the 661 DNS records used in U-NAPTR resolution. Security considerations 662 specific to U-NAPTR are described in more detail in [RFC4848]. 664 An "https:" URI is authenticated using the method described in 665 Section 3.1 of [RFC2818]. The domain name used for this 666 authentication is the domain name in the URI resulting from U-NAPTR 667 resolution, not the input domain name as in [RFC3958]. Using the 668 domain name in the URI is more compatible with existing HTTP client 669 software, which authenticate servers based on the domain name in the 670 URI. 672 An ALTO server that is identified by an "http:" URI cannot be 673 authenticated. If an "http:" URI is the product of the ALTO 674 discovery, this leaves devices vulnerable to several attacks. Lower 675 layer protections, such as layer 2 traffic separation might be used 676 to provide some guarantees. 678 8. Open Issues 680 Here are a few open issues to be clarified: 682 Handling of reverse DNS lookups for IPv6: Refer to [RFC4472] for a 683 discussion about the issues. 685 Missing reverse DNS entries for an IP address: There may be cases 686 where the reverse DNS lookup does not yield any result. However, 687 this will leave the ALTO client with no choice, other than giving 688 up. This needs better documentation. 690 How to handled multiple results: For instance, a host behind a NAT 691 that yields an ALTO server in the private IP address domain and 692 one in the public IP address domain. Whom to ask? 694 Suffix Issues Document issues with suffix information provided by 695 DHCP or by other means. For instance, a host behind a NAT may 696 have a configured DNS suffix ".local". This suffix is not usuable 697 for the server discovery procedure. 699 9. Contributors 701 Hannes Tschofenig provided the initial input to the U-NAPTR solution 702 part. Hannes and Martin Thomson provided excellent feedback and 703 input to the server discovery. 705 The authors would also like to thank the following persons for their 706 contribution to this document or predecessors: 708 Roni Even 710 Gustavo Garcia 712 Yu-Shun Wang 714 Victor Pascual 716 Richard Alimi 718 Yunfei Zhang 720 Y. Richard Yang 722 Xingfeng Jiang 724 Jay Gu 726 Ning Zong 728 David Bryan 730 Enrico Marocco 732 10. Conclusion 734 This document describes a general ALTO server discovery process and 735 discusses how the process can be applied in different deployment 736 scenarios, including the resouce consumer discovery as well as the 737 third party discovery. 739 11. References 741 11.1. Normative References 743 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 744 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 745 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 747 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 749 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 750 Service Location Using SRV RRs and the Dynamic Delegation 751 Discovery Service (DDDS)", RFC 3958, January 2005. 753 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 754 Rose, "DNS Security Introduction and Requirements", 755 RFC 4033, March 2005. 757 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 758 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 759 October 2008. 761 11.2. Informative References 763 [I-D.ietf-alto-protocol] 764 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 765 draft-ietf-alto-protocol-04 (work in progress), May 2010. 767 [I-D.ietf-alto-reqs] 768 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 769 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 770 Requirements", draft-ietf-alto-reqs-08 (work in progress), 771 March 2011. 773 [I-D.ietf-geopriv-lis-discovery] 774 Thomson, M. and J. Winterbottom, "Discovering the Local 775 Location Information Server (LIS)", 776 draft-ietf-geopriv-lis-discovery-15 (work in progress), 777 March 2010. 779 [I-D.song-alto-server-discovery] 780 Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V. 781 Avila, "ALTO Service Discovery", 782 draft-song-alto-server-discovery-03 (work in progress), 783 July 2010. 785 [I-D.stiemerling-alto-deployments] 786 Stiemerling, M. and S. Kiesel, "ALTO Deployment 787 Considerations", draft-stiemerling-alto-deployments-03 788 (work in progress), June 2010. 790 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 791 Considerations and Issues with IPv6 DNS", RFC 4472, 792 April 2006. 794 [RFC4848] Daigle, L., "Domain-Based Application Service Location 795 Using URIs and the Dynamic Delegation Discovery Service 796 (DDDS)", RFC 4848, April 2007. 798 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 799 Optimization (ALTO) Problem Statement", RFC 5693, 800 October 2009. 802 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 803 Location Information Server (LIS)", RFC 5986, 804 September 2010. 806 [bep24] Harrison, D., "Tracker Returns External IP", 807 BEP http://bittorrent.org/beps/bep_0024.html. 809 Appendix A. Acknowledgments 811 The authors would like to thank Haibin Song, Richard Alimi, and Roni 812 Even for fruitful discussions during the 75th IETF meeting. 814 Hannes Tschofenig provided the initial input to the U-NAPTR solution 815 part. Hannes and Martin Thomson provided excellent feedback and 816 input to the server discovery. 818 Marco Tomsu and Nico Schwan are partially supported by the ENVISION 819 project (http://www.envision-project.org), a research project 820 supported by the European Commission under its 7th Framework Program 821 (contract no. 248565). The views and conclusions contained herein 822 are those of the authors and should not be interpreted as necessarily 823 representing the official policies or endorsements, either expressed 824 or implied, of the ENVISION project or the European Commission. 826 Michael Scharf is supported by the German-Lab project 827 (http://www.german-lab.de) funded by the German Federal Ministry of 828 Education and Research (BMBF). 830 Martin Stiemerling is partially supported by the COAST project 831 (COntent Aware Searching, retrieval and sTreaming, 832 http://www.coast-fp7.eu), a research project supported by the 833 European Commission under its 7th Framework Program (contract no. 834 248036). The views and conclusions contained herein are those of the 835 authors and should not be interpreted as necessarily representing the 836 official policies or endorsements, either expressed or implied, of 837 the COAST project or the European Commission. 839 Authors' Addresses 841 Sebastian Kiesel 842 University of Stuttgart Computing Center 843 Allmandring 30 844 Stuttgart 70550 845 Germany 847 Email: ietf-alto@skiesel.de 848 URI: http://www.rus.uni-stuttgart.de/nks/ 850 Martin Stiemerling 851 NEC Laboratories Europe 852 Kurfuerstenanlage 36 853 Heidelberg 69115 854 Germany 856 Phone: +49 6221 4342 113 857 Email: martin.stiemerling@neclab.eu 858 URI: http://ietf.stiemerling.org 860 Nico Schwan 861 Alcatel-Lucent Bell Labs 862 Lorenzstrasse 10 863 Stuttgart 70435 864 Germany 866 Email: nico.schwan@alcatel-lucent.com 867 URI: www.alcatel-lucent.com/bell-labs 869 Michael Scharf 870 Alcatel-Lucent Bell Labs 871 Lorenzstrasse 10 872 Stuttgart 70435 873 Germany 875 Email: michael.scharf@alcatel-lucent.com 876 URI: www.alcatel-lucent.com/bell-labs 877 Marco Tomsu 878 Alcatel-Lucent 879 Lorenzstrasse 10 880 Stuttgart 70435 881 Germany 883 Email: marco.tomsu@alcatel-lucent.com 884 URI: www.alcatel-lucent.com/bell-labs 886 Haibin Song 887 Huawei 889 Email: melodysong@huawei.com