idnits 2.17.1 draft-kiesel-alto-3pdisc-04.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 5 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 283: '...two bits of every length octet MUST be...' RFC 2119 keyword, line 318: '... A DHCPv4 client MAY request a ALTO se...' RFC 2119 keyword, line 323: '...domain name and, as such, MUST contain...' RFC 2119 keyword, line 351: '... A DHCPv6 client MAY request a ALTO se...' RFC 2119 keyword, line 356: '...domain name and, as such, MUST contain...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4930 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) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-05 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-06 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-05 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track M. Tomsu 5 Expires: April 28, 2011 Alcatel-Lucent 6 N. Schwan 7 M. Scharf 8 Alcatel-Lucent Bell Labs 9 M. Stiemerling 10 NEC Europe Ltd. 11 October 25, 2010 13 ALTO Server Discovery Protocol 14 draft-kiesel-alto-3pdisc-04 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 deployments. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 28, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Retrieving the URI by DHCP . . . . . . . . . . . . . . . . . . 7 68 3.1. ALTO Server Domain Name Encoding . . . . . . . . . . . . . 7 69 3.2. ALTO Server DHCPv4 Option . . . . . . . . . . . . . . . . 7 70 3.3. ALTO Server DHCPv6 Option . . . . . . . . . . . . . . . . 8 71 4. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10 72 4.1. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10 73 4.2. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10 74 4.2.1. Option 1: User input . . . . . . . . . . . . . . . . . 11 75 4.2.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 12 76 4.2.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12 77 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. Applicability for Resource Consumer Server Discovery . . . 13 79 5.2. Applicability for Third Party Server Discovery . . . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 89 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 The goal of Application-Layer Traffic Optimization (ALTO) is to 95 provide guidance to applications, which have to select one or several 96 hosts from a set of candidates, that are able to provide a desired 97 resource [RFC5693]. The requirements for ALTO are itemized in 98 [I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol. 99 ALTO clients send queries to ALTO servers, in order to solicit 100 guidance. 102 ALTO clients have to discover suitable ALTO servers. Therefore the 103 output of the herein defined ALTO discovery procedure tells the ALTO 104 client which ALTO servers to send the queries to. The ALTO discovery 105 procedure, as part of the the ALTO client, can be embedded in the 106 resource consumer, which will eventually access the desired resource. 107 As an alternative, they can be embedded in a resource directory, 108 which assists resource consumers in finding appropriate resource 109 providers. In some specific peer-to-peer application protocols these 110 resource directories are called "trackers". Finally the ALTO server 111 discovery procedure can be embedded in the resource consumer, whereas 112 the ALTO client is embedded in the resource directory. ALTO queries, 113 which are issued by a resource directory on behalf of a resource 114 consumer, are referred to as third-party ALTO queries. The various 115 possibilities to place ALTO servers and the placement of ALTO clients 116 is discussed in [I-D.stiemerling-alto-deployments]. 117 [I-D.song-alto-server-discovery] compares different protocol options 118 and identifies DHCP and DNS as two approaches for the ALTO server 119 discovery without detailing on the exact solution. 121 No matter where ALTO server and client are located, clients have to 122 first find out if there is an ALTO server deployed that is in charge 123 for them, and second they have to get the contact information of that 124 server, i.e., the IP address, port number, and probably transport 125 protocol (which defaults to TCP for [I-D.ietf-alto-protocol]). 127 The goal of this memo is to propose a uniform mechanism for all types 128 of ALTO client deployments that is implementable and deployable at a 129 fast pace, i.e., without creating other deployment dependecies for 130 ALTO. We propose to use a combination of DHCP and DNS to retrieve 131 the URL of the resposnsible ALTO server. 133 Comments and discussions about this memo should be directed to the 134 ALTO working group: alto@ietf.org. 136 1.1. Requirements 138 There is other related works on server discovery, for instance 139 GEOPRIV has rather strong security requirements (for good reasons), 140 which are documented in [I-D.ietf-geopriv-lis-discovery]. However, 141 these requirements do not apply for the ALTO server discovery, as 142 ALTO as such has very different requirements (see 143 [I-D.ietf-alto-reqs]). 145 The result of the guidance provided to the application via the ALTO 146 protocol is input to improve the initial peer selection process for 147 peer-to-peer applications, or any other application applicable. A 148 missing ALTO server, i.e., no result returned as part of the ALTO 149 server discovery procedure, does not prevent the application to 150 operate. A wrong or forged guidance from the ALTO server may only 151 impact the overall operational result of the peer-to-peer system for 152 a limited time, as these systems fine-tune their behavior depending 153 on the experience network behavior. 155 This means that a wrong, missing, or forged ALTO guidance will not 156 cause damage to the application or peer-to-peer system. This is in 157 sharp contrast to the GEOPRIV use case, where a failure may have 158 severe impact, including loss of human life. This is not the case 159 for ALTO, as it is intended to be used today and as it is explored 160 right now from the networking community. 162 1.2. Pre-Conditions 164 The whole document assumes certain pre-conditions, such as: 166 o The ALTO server discovery procedure is executed on a per IP 167 address base. Multiple IP addresses per interface or multiple IP 168 addresses assigned to different IP interfaces require to repeat 169 the procedure for every IP address. It may be fine to group IP 170 addresses according their domain suffixes and to perfom the 171 procedure for such a group. However, this is out of scope of this 172 document. 174 o The ALTO server discovery procedure is executed on a per IP family 175 base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO 176 client to decide which of the possible multiple results of 177 different IP address families to use. The choice of whether to 178 use IPv4 or IPv6 is out of scope of this document. 180 o A change of the IP address at an interface invalidates the result 181 of the ALTO server discovery procedure. For instance, if the IP 182 address assigned to a mobile host changes due to host mobility, it 183 is required to run the ALTO server discovery procedure for the new 184 IP address without relying on earlier gained information. 186 2. Protocol Overview 188 We define multiple alternatives to discover the IP address of the 189 ALTO server, as there are a number of ways possible how such 190 information can be provided to the ALTO client. The choice of method 191 is up to the local network deployment. For instance, there can be 192 deployments where the ALTO server in charge for ALTO client is 193 provisioned by the network operator and communicated to the ALTO 194 client's host via a DHCP option, while in other deployments no such 195 means may exist. 197 The following figure illustrates the different protocols that are 198 used to find the URI of a suitable ALTO server. 200 Descending order of Preference 201 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> 203 -------- -------------- -------- --------------- 204 | DHCP | | User Input | | DHCP | | Reverse DNS | 205 -------- -------------- -------- --------------- 206 | | | | 207 | \ | / 208 | Retrieving the DNS suffix 209 | \ | / 210 | --------+---------- 211 \ | 212 \ Determine own IP address 213 \ | 214 \ ----------- 215 \ | U-NAPTR | 216 \ ----------- 217 \ | 218 Retrieving ALTO Server URI 219 \ | 220 ---------+---------- 221 | 222 Final DNS lookup 224 Figure 1: Protocol Overview 226 One option to retrieve the URI directly from the access network 227 provider is DHCP. However for DHCP there are problems with 228 residential gateways or broadband routers with NAT. If the network 229 operator gives information about ALTO serves to the residential 230 gateway via DHCP, the residential gateway would have to forward this 231 information to the hosts with the (P2P) applications within the local 232 network. This is not supported by already deployed residential 233 gateways. Also DHCP poorly supports third-party ALTO server 234 discovery, i.e., in scenarios where the ALTO client is co-located 235 with a resource directory ("tracker"), which is located in a 236 different administrative domain than the client which will eventually 237 access the ressource. 239 Thus in deployment scenarios where DHCP is not possible, we specify a 240 U-NAPTR based resolution process as a second option to retrieve the 241 URL. As a precondition for resolution the U-NAPTR process needs the 242 right domain name as input. This domain name is determined by the IP 243 address of the client and the DNS suffix of the access network where 244 the client is registered in. In order to retrieve the DNS suffix we 245 specify three options: 247 User input: a user may manually specify the DNS suffix on its own, 248 either to access a 3rd party ALTO service provider or as it does 249 know such information. 251 DHCP: a network provider provides the DNS suffix through a DHCP 252 option. 254 Reverse DNS: the DNS system can be used to retrieve the DNS suffix 255 through reverse lookup of an FQDN associated with an IP address. 256 This is the last resort if all other options failed. 258 3. Retrieving the URI by DHCP 260 One way of directly configuring the ALTO server URI for an access 261 network provider is the DHCP protocol. The ALTO server URI consists 262 of a domain name and the protocol the client should use to contact 263 the server. While the domain name can vary and is configured by 264 DHCP, the protocol is always HTTP. 266 For example a client may retrieve the domain name 267 altoserver.example.com by the DHCP option as described in the 268 remaining section. The client uses this domain name to contact the 269 ALTO server under 271 http://altoserver.example.com/ 273 3.1. ALTO Server Domain Name Encoding 275 This section describes the encoding of the domain name used in the 276 DHCPv4 option shown in Section 3.2 and also used in the DHCPv6 option 277 shown in Section 3.3. 279 The domain name is encoded according to Section 3.1 of [RFC1035] 280 whereby each label is represented as a one-octet length field 281 followed by that number of octets. Since every domain name ends with 282 the null label of the root, a domain name is terminated by a length 283 byte of zero. The high-order two bits of every length octet MUST be 284 zero, and the remaining six bits of the length field limit the label 285 to 63 octets or less. To simplify implementations, the total length 286 of a domain name (i.e., label octets and label length octets) is 287 restricted to 255 octets or less. 289 3.2. ALTO Server DHCPv4 Option 291 The ALTO server DHCPv4 option carries a DNS ([RFC1035]) fully- 292 qualified domain name (FQDN) to be used by the ALTO client to locate 293 a ALTO server. 295 The DHCP option for this encoding has the following format: 297 Code Len ALTO Server Domain Name 298 +-----+-----+-----+-----+-----+-----+-----+---- 299 | tba | n | s1 | s2 | s3 | s4 | s5 | ... 300 +-----+-----+-----+-----+-----+-----+-----+---- 302 Figure 2: ALTO FQDN DHCPv4 Option 304 The values s1, s2, s3, etc. represent the domain name labels in the 305 domain name encoding. Note that the length field in the DHCPv4 306 option represents the length of the entire domain name encoding, 307 whereas the length fields in the domain name encoding (see 308 Section 3.1) is the length of a single domain name label. 310 Code: to be assigned by IANA 312 Len: Length of the 'ALTO Server Domain Name' field in octets; 313 variable. 315 ALTO Server Domain Name: The domain name of the ALTO server for the 316 client to use. 318 A DHCPv4 client MAY request a ALTO server domain name in a Parameter 319 Request List option, as described in [RFC2131]. 321 The encoding of the domain name is described in Section 3.1. 323 This option contains a single domain name and, as such, MUST contain 324 precisely one root label. 326 3.3. ALTO Server DHCPv6 Option 328 This section specifies the DHCP option for IPv6 (DHCPv6) to carry the 329 domain name of the ALTO server. It is similar formatted to the 330 DHCPv4 option 332 0 1 2 3 333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | TBA: OPTION CODE | option-length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 . ALTO Server Domain Name . 338 . ... . 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 3: ALTO Server Domain Name DHCPv4 Option 343 option-code: to be assigned by IANA 345 option-length: The length of the 'ALTO Server Domain Name' field in 346 octets; variable. 348 ALTO Server Domain Name: The domain name of the ALTO server for the 349 client to use. 351 A DHCPv6 client MAY request a ALTO server domain name in an Options 352 Request Option (ORO), as described in [RFC3315]. 354 The encoding of the domain name is described in Section 3.1. 356 This option contains a single domain name and, as such, MUST contain 357 precisely one root label. 359 4. Retrieving the URI by U-NAPTR 361 As already described a direct DHCP configuration may not always be 362 possible, for example due to deployment restrictions of the access 363 network. Alternatively the ALTO server URI can be discovered by a 364 U-NAPTR resolution process, as specified in this section. 366 The section is devided in two parts: Section 4.1 describes the 367 U-NAPTR resolution process itself. As a precondition this process 368 requires the domain name of the access network where the resouce 369 consumer is registered in. How the client identifies this DNS suffix 370 is described in Section 4.2. 372 4.1. U-NAPTR Resolution 374 ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ 375 Dynamic Delegation Discovery Service) [RFC4848] application unique 376 strings, in the form of a DNS name. An example is 377 'altoserver.example.com'. 379 Clients need to use the U-NAPTR [RFC4848] specification described 380 below to obtain a URI (indicating host and protocol) for the 381 applicable ALTO service. In this document, only the HTTP and HTTPS 382 URL schemes are defined. Note that the HTTP URL can be any valid 383 HTTP URL, including those containing path elements. 385 The following two DNS entries show the U-NAPTR resolution for 386 "example.com" to the HTTPS URL https://altoserver.example.com/secure 387 or the HTTP URL http://altoserver.example.com, with the former being 388 preferred. 390 example.com. 392 IN NAPTR 100 10 "u" "ALTO:https" 393 "!.*!https://altoserver.example.com/secure!" "" 395 IN NAPTR 200 10 "u" "ALTO:http" 396 "!.*!http://altoserver.example.com!" "" 398 4.2. Retrieving the Domain Name 400 The U-NAPTR resolution process requires a domain name as input. The 401 algorithm that is applied to determine this domain name is described 402 in this section. We specify three different options. In option 1 403 the user manually configures a specific ALTO service instance that he 404 wants to use. Option 2 defines a DHCP option to allow the network 405 service provider a remote configuration of the client. In option 3 406 the client tries to get the domain name by performing a reverse DNS 407 lookup on its IP address. 409 The resource consumer may have private IP addresses and public IP 410 addresses and depending on the deployment it might be necessary to 411 determine for all IP addresses the ALTO server in charge of. To 412 determine its public IP address the resource consumer may need to use 413 STUN[RFC5389] or BEP24[bep24]. For the following examples we assume 414 that the IP address of the resource consumer is a.b.c.d. 416 4.2.1. Option 1: User input 418 A user may want to use a third party ALTO service instance. 419 Therefore we allow the user to specify a DNS suffix on its own, for 420 example in a config file option. The DNS suffix given by the user is 421 combined with the IP address of the resource consumer to allow the 422 third party ALTO service to direct the client to a suitable ALTO 423 server based on the location of the client. A possible DNS suffix 424 entered by the user may be: 426 myaltoprovider.org 428 This DNS suffix is prepended with the IP address of the resource 429 consumer in reverse order to compose the domain name used for the 430 final U-NAPTR lookup Section 4.1. In case there are multiple ALTO 431 servers deployed, the third party ALTO service instance can direct 432 the ALTO client to the ALTO server closest to the client based on the 433 IP address. 435 Multiple lookups with different domain names might be necessary to 436 complete the U-NAPTR resolution process. If there is no response for 437 a lookup the domain name is shortened by one part for the succeeding 438 lookup, until a lookup is successful, as for example 440 d.c.b.a.myaltoprovider.org. 442 c.b.a.myaltoprovider.org. 444 b.a.myaltoprovider.org. 446 a.myaltoprovider.org. 448 myaltoprovider.org. 450 4.2.2. Option 2: DHCP 452 As a second option network operators can configure the domain name to 453 be used for service discovery within an access network. RFC 454 5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain name 455 options that identify a domain name that is suitable for service 456 discovery within the access network. The ALTO server discovery 457 procedure uses these DHCP options to retrieve the domain name as an 458 input for the U-NAPTR resolution. One example could be: 460 example.com 462 4.2.3. Option 3: Reverse DNS Lookup 464 The last option to get the domain name is to use a DNS PTR query for 465 the IP address of the resource consumer. The local DNS server 466 resolves the IP address to the FQDN that also contains the DNS suffix 467 for the respective IP address. A possible answer for a PTR lookup 468 for d.c.b.a.in-addr.apra might be, for example: 470 d-c-b-a.dsl.westcoast.myisp.net 472 This domain name can be used for the final U-NAPTR lookup 473 Section 4.1. Again, if there is no response to the lookup the domain 474 name is shortened by one part for the succeeding lookup. The domain 475 names used for the example as described above are: 477 d-c-b-a.dsl.westcoast.myisp.net. 479 dsl.westcoast.myisp.net. 481 westcoast.myisp.net. 483 myisp.net. 485 5. Applicability 487 This section discusses the applicability of the proposed solution 488 with respect to the resource consumer server discovery and the third 489 party deployment scenarios. Each section discusses the proposed 490 steps that are needed to determine the ALTO Server URI. 492 5.1. Applicability for Resource Consumer Server Discovery 494 In this scenario the ALTO server discovery procedure is performed by 495 the resource consumer, for example a peer in a P2P system. After the 496 discovery the peer does the ALTO query on its own, or it might share 497 the ALTO server contact information with a third party, for example a 498 tracker, which then does the ALTO query on behalf of the peer. 500 The access network provider has two options based on DHCP to remotely 501 configure the ALTO client to use its ALTO server. The first option 502 is to provide the ALTO server URI directly by a DHCP option as 503 described in Section 3, the second option is to provide the access 504 network domain name as described in Section 4.2.2. It is up to the 505 access network provider to choose one of both options. 507 To complete the ALTO server discovery process the resource consumer 508 first SHOULD try to retrieve the ALTO server URI by the DHCP option 509 as described in Section 3. In case this is successful the discovery 510 process is finished, in case it fails, either as the access network 511 provider has not configured the specified option or through 512 deployment restrictions, the resource consumer SHOULD subsequently 513 check whether the user has provider the domain name through manual 514 configuration. If this is also not the case the next step SHOULD be 515 to check for the access network domain name DHCP option 516 (Section 4.2.2). Finally the client SHOULD try to retrieve the 517 domain name by the last option, the DNS reverse lookup on its IP 518 address as described in Section 4.2.3. 520 In case the ALTO discovery client has determined the domain name 521 through one of the described options it proceedes with the U-NAPTR 522 lookup as described in Section 4.1. 524 If the ALTO server URI could not be retrieved either through direct 525 configuration by the access network provider through DHCP nor through 526 the U-NAPTR lookup the discovery process fails. 528 5.2. Applicability for Third Party Server Discovery 530 In case of the third party server discovery deployment scenario the 531 entity performing the ALTO server discovery process is different from 532 the resource consumer. Typically the resource consumer is a peer 533 whereas the ALTO client is a resource directory which seeks for ALTO 534 guidance on behalf of the peer. Another use case for the third party 535 discovery is an application that looks for ALTO guidance 536 transparently for the resource consumer, for example a CDN. 538 Here the ALTO server discovery process can also retrieve guidance 539 through one of the DHCP options or manual user configuration, but 540 only if the provided discovery information is forwarded by the 541 resource consumer to the third party entity. In this case, 542 additional mechanisms for the forwarding of this discovery 543 information need to be specified. However these mechanisms are out 544 of scope of this doument. 546 If the third party entity cannot obtain this discovery information, 547 the ALTO server discovery process relies on retrieving the domain 548 name used as input to the U-NAPTR lookup through reverse DNS lookup 549 of the IP address of the resource consumer as described in 550 Section 4.2.3. Usually the third party entity already knows the IP 551 address of the resource consumer which was used to establish the 552 initial connection. In general this IP address is a public address, 553 either of the resource consumer or of the last NAT on the path to the 554 ALTO client. This makes the IP address a good candidate for the DNS 555 PTR query. Thus, we expect that the DNS query will be successfully 556 resolved to the FQDN of the domain where the resource consumer is 557 registered in. 559 In case the resource consumer needs guidance for a different IP 560 address, for example one from a private network, we recommend that 561 the resource consumer discovers the server itself and forwards the 562 ALTO server contact information directly to the third party entity, 563 which in turn can then do the third party ALTO query. Again, 564 forwarding the contact information from the resource consumer to the 565 third party entity is out of scope of this document. 567 6. IANA Considerations 569 This document registers the following U-NAPTR application service 570 tag: 572 Application Service Tag: ALTO 574 Defining Publication: The specification contained within this 575 document. 577 This document registers the following U-NAPTR application protocol 578 tags: 580 o Application Protocol Tag: http 582 Defining Publication: RFC 2616 [RFC2616] 584 o Application Protocol Tag: https 586 Defining Publication: RFC 2818 [RFC2818] 588 7. Security Considerations 590 7.1. General 592 This is still to be done in later revision of this draft, as the 593 draft evolves heavily right now. 595 7.2. For U-NAPTR 597 The address of an ALTO server is usually well-known within an access 598 network; therefore, interception of messages does not introduce any 599 specific concerns. 601 The primary attack against the methods described in this document is 602 one that would lead to impersonation of a ALTO server since a device 603 does not necessarily have a prior relationship with a ALTO server. 605 An attacker could attempt to compromise ALTO discovery at any of 606 three stages: 608 1. providing a falsified domain name to be used as input to U-NAPTR 610 2. altering the DNS records used in U-NAPTR resolution 612 3. impersonation of the ALTO 614 This document focuses on the U-NAPTR resolution process and hence 615 this section discusses the security considerations related to the DNS 616 handling. The security aspects of obtaining the domain name that is 617 used for input to the U-NAPTR process is described in respective 618 documents, such as [I-D.ietf-geopriv-lis-discovery]. 620 The domain name that is used to authenticated the ALTO server is the 621 domain name in the URI that is the result of the U-NAPTR resolution. 622 Therefore, if an attacker were able to modify or spoof any of the DNS 623 records used in the DDDS resolution, this URI could be replaced by an 624 invalid URI. The application of DNS security (DNSSEC) [RFC4033] 625 provides a means to limit attacks that rely on modification of the 626 DNS records used in U-NAPTR resolution. Security considerations 627 specific to U-NAPTR are described in more detail in [RFC4848]. 629 An "https:" URI is authenticated using the method described in 630 Section 3.1 of [RFC2818]. The domain name used for this 631 authentication is the domain name in the URI resulting from U-NAPTR 632 resolution, not the input domain name as in [RFC3958]. Using the 633 domain name in the URI is more compatible with existing HTTP client 634 software, which authenticate servers based on the domain name in the 635 URI. 637 An ALTO server that is identified by an "http:" URI cannot be 638 authenticated. If an "http:" URI is the product of the ALTO 639 discovery, this leaves devices vulnerable to several attacks. Lower 640 layer protections, such as layer 2 traffic separation might be used 641 to provide some guarantees. 643 8. Open Issues 645 Here are a few open issues to be clarified: 647 Handling of reverse DNS lookups for IPv6: Refer to [RFC4472] for a 648 discussion about the issues. 650 Missing reverse DNS entries for an IP address: There may be cases 651 where the reverse DNS lookup does not yield any result. However, 652 this will leave the ALTO client with no choice, other than giving 653 up. This needs better documentation. 655 How to handled multiple results: For instance, a host behind a NAT 656 that yields an ALTO server in the private IP address domain and 657 one in the public IP address domain. Whom to ask? 659 Suffix Issues Document issues with suffix information provided by 660 DHCP or by other means. For instance, a host behind a NAT may 661 have a configured DNS suffix ".local". This suffix is not usuable 662 for the server discovery procedure. 664 9. Conclusion 666 This document describes a general ALTO server discovery process and 667 discusses how the process can be applied in different deployment 668 scenarios, including the resouce consumer discovery as well as the 669 third party discovery. 671 10. References 673 10.1. Normative References 675 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 676 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 677 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 679 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 681 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 682 Service Location Using SRV RRs and the Dynamic Delegation 683 Discovery Service (DDDS)", RFC 3958, January 2005. 685 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 686 Rose, "DNS Security Introduction and Requirements", 687 RFC 4033, March 2005. 689 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 690 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 691 October 2008. 693 10.2. Informative References 695 [I-D.ietf-alto-protocol] 696 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 697 draft-ietf-alto-protocol-05 (work in progress), July 2010. 699 [I-D.ietf-alto-reqs] 700 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 701 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 702 Requirements", draft-ietf-alto-reqs-06 (work in progress), 703 October 2010. 705 [I-D.ietf-geopriv-lis-discovery] 706 Thomson, M. and J. Winterbottom, "Discovering the Local 707 Location Information Server (LIS)", 708 draft-ietf-geopriv-lis-discovery-15 (work in progress), 709 March 2010. 711 [I-D.song-alto-server-discovery] 712 Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V. 713 Avila, "ALTO Service Discovery", 714 draft-song-alto-server-discovery-03 (work in progress), 715 July 2010. 717 [I-D.stiemerling-alto-deployments] 718 Stiemerling, M. and S. Kiesel, "ALTO Deployment 719 Considerations", draft-stiemerling-alto-deployments-05 720 (work in progress), October 2010. 722 [RFC1035] Mockapetris, P., "Domain names - implementation and 723 specification", STD 13, RFC 1035, November 1987. 725 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 726 RFC 2131, March 1997. 728 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 729 and M. Carney, "Dynamic Host Configuration Protocol for 730 IPv6 (DHCPv6)", RFC 3315, July 2003. 732 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 733 Considerations and Issues with IPv6 DNS", RFC 4472, 734 April 2006. 736 [RFC4848] Daigle, L., "Domain-Based Application Service Location 737 Using URIs and the Dynamic Delegation Discovery Service 738 (DDDS)", RFC 4848, April 2007. 740 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 741 Optimization (ALTO) Problem Statement", RFC 5693, 742 October 2009. 744 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 745 Location Information Server (LIS)", RFC 5986, 746 September 2010. 748 [bep24] Harrison, D., "Tracker Returns External IP", 749 BEP http://bittorrent.org/beps/bep_0024.html. 751 Appendix A. Acknowledgments 753 The authors would like to thank Haibin Song, Richard Alimi, and Roni 754 Even for fruitful discussions during the 75th IETF meeting. 756 Hannes Tschofenig provided the initial input to the U-NAPTR solution 757 part. Hannes and Martin Thomson provided excellent feedback and 758 input to the server discovery. 760 Marco Tomsu and Nico Schwan are partially supported by the ENVISION 761 project (http://www.envision-project.org), a research project 762 supported by the European Commission under its 7th Framework Program 763 (contract no. 248565). The views and conclusions contained herein 764 are those of the authors and should not be interpreted as necessarily 765 representing the official policies or endorsements, either expressed 766 or implied, of the ENVISION project or the European Commission. 768 Michael Scharf is supported by the German-Lab project 769 (http://www.german-lab.de) funded by the German Federal Ministry of 770 Education and Research (BMBF). 772 Martin Stiemerling is partially supported by the COAST project 773 (COntent Aware Searching, retrieval and sTreaming, 774 http://www.coast-fp7.eu), a research project supported by the 775 European Commission under its 7th Framework Program (contract no. 776 248036). The views and conclusions contained herein are those of the 777 authors and should not be interpreted as necessarily representing the 778 official policies or endorsements, either expressed or implied, of 779 the COAST project or the European Commission. 781 Authors' Addresses 783 Sebastian Kiesel 784 University of Stuttgart Computing Center 785 Allmandring 30 786 Stuttgart 70550 787 Germany 789 Email: ietf-alto@skiesel.de 790 URI: http://www.rus.uni-stuttgart.de/nks/ 792 Marco Tomsu 793 Alcatel-Lucent 794 Lorenzstrasse 10 795 Stuttgart 70435 796 Germany 798 Email: marco.tomsu@alcatel-lucent.com 799 URI: www.alcatel-lucent.com/bell-labs 801 Nico Schwan 802 Alcatel-Lucent Bell Labs 803 Lorenzstrasse 10 804 Stuttgart 70435 805 Germany 807 Email: nico.schwan@alcatel-lucent.com 808 URI: www.alcatel-lucent.com/bell-labs 810 Michael Scharf 811 Alcatel-Lucent Bell Labs 812 Lorenzstrasse 10 813 Stuttgart 70435 814 Germany 816 Email: michael.scharf@alcatel-lucent.com 817 URI: www.alcatel-lucent.com/bell-labs 818 Martin Stiemerling 819 NEC Laboratories Europe/University of Goettingen 820 Kurfuerstenanlage 36 821 Heidelberg 69115 822 Germany 824 Phone: +49 6221 4342 113 825 Email: martin.stiemerling@neclab.eu 826 URI: http://ietf.stiemerling.org