idnits 2.17.1 draft-ietf-alto-reqs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 270 has weird spacing: '...logical ser...' == Line 290 has weird spacing: '...logical ser...' -- The document date (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kiesel, Ed. 3 Internet-Draft University of Stuttgart 4 Intended status: Informational S. Previdi 5 Expires: April 28, 2011 Cisco Systems, Inc. 6 M. Stiemerling 7 NEC Europe Ltd. 8 R. Woundy 9 Comcast Corporation 10 Y R. Yang 11 Yale University 12 October 25, 2010 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-06.txt 17 Abstract 19 Many Internet applications are used to access resources, such as 20 pieces of information or server processes, which are available in 21 several equivalent replicas on different hosts. This includes, but 22 is not limited to, peer-to-peer file sharing applications. The goal 23 of Application-Layer Traffic Optimization (ALTO) is to provide 24 guidance to applications, which have to select one or several hosts 25 from a set of candidates, that are able to provide a desired 26 resource. This guidance shall be based on parameters that affect 27 performance and efficiency of the data transmission between the 28 hosts, e.g., the topological distance. The ultimate goal is to 29 improve performance (or Quality of Experience) in the application 30 while reducing resource consumption in the underlying network 31 infrastructure. 33 This document enumerates requirements for ALTO, which should be 34 considered when specifying, assessing, or comparing protocols and 35 implementations, and it solicits feedback and discussion. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on April 28, 2011. 60 Copyright Notice 62 Copyright (c) 2010 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology and Architectural Framework . . . . . . . . . . . 5 79 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 80 2.2. ALTO Terminology . . . . . . . . . . . . . . . . . . . . . 5 81 2.3. Architectural Framework for ALTO . . . . . . . . . . . . . 6 82 2.4. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . 6 83 3. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 9 84 3.1. ALTO Client Protocol . . . . . . . . . . . . . . . . . . . 9 85 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 9 86 3.1.2. Host Group Descriptor Support . . . . . . . . . . . . 9 87 3.1.3. Rating Criteria Support . . . . . . . . . . . . . . . 10 88 3.1.4. Placement of Entities and Timing of Transactions . . . 11 89 3.1.5. Protocol Extensibility . . . . . . . . . . . . . . . . 13 90 3.1.6. Error Handling and Overload Protection . . . . . . . . 13 91 3.2. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 14 92 3.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 15 93 4. Host Group Descriptors . . . . . . . . . . . . . . . . . . . . 16 94 5. Rating Criteria . . . . . . . . . . . . . . . . . . . . . . . 17 95 5.1. Distance-related Rating Criteria . . . . . . . . . . . . . 17 96 5.2. Charging-related Rating Criteria . . . . . . . . . . . . . 17 97 5.3. Performance-related Rating Criteria . . . . . . . . . . . 18 98 5.4. Inappropriate Rating Criteria . . . . . . . . . . . . . . 19 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 101 7.1. High-level security considerations . . . . . . . . . . . . 21 102 7.2. Classification of Information Disclosure Scenarios . . . . 21 103 7.3. Security Requirements . . . . . . . . . . . . . . . . . . 23 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 106 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 107 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 108 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 111 1. Introduction 113 The motivation for Application-Layer Traffic Optimization (ALTO) is 114 described in the ALTO problem statement [RFC5693]. 116 The goal of ALTO is to provide information which can help peer-to- 117 peer (P2P) applications to make better decisions with respect to peer 118 selection. However, ALTO may be useful for non-P2P applications as 119 well. For example, clients of client-server applications may use 120 information provided by ALTO to select one of several servers or 121 information replicas. As another example, ALTO information could be 122 used to select a media relay needed for NAT traversal. The goal of 123 these informed decisions is to improve performance (or Quality of 124 Experience) in the application while reducing resource consumption in 125 the underlying network infrastructure. 127 Usually, it would be difficult or even impossible for application 128 entities to acquire this information by other mechanisms (e.g., using 129 measurements between the peers of a P2P overlay), because of 130 complexity or because it is based on network topology information, 131 network operational costs, or network policies, which the respective 132 network provider does not want to disclose in detail. 134 The logical entities that provide the ALTO service do not take part 135 in the actual user data transport, i.e., they do not implement 136 functions for relaying user data. They may be placed on various 137 kinds of physical nodes, e.g., on dedicated servers, as auxiliary 138 processes in routers, on "trackers" or "super peers" of a P2P 139 application operated by the network provider, etc. 141 2. Terminology and Architectural Framework 143 2.1. Requirements Notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2.2. ALTO Terminology 151 This document uses the following ALTO-related terms, which are 152 defined in [RFC5693]: 154 Application, Overlay Network, Application protocol, Peer, P2P, 155 Resource, Resource Identifier, Resource Provider, Resource Consumer, 156 Resource Directory, Transport Address, ALTO Service, ALTO Server, 157 ALTO Client, ALTO Client Protocol, ALTO Query, ALTO Reply, ALTO 158 Transaction, Provisioning protocol, Inter ALTO-Server Protocol, Local 159 Traffic, Peering Traffic, Transit Traffic. 161 Furthermore, the following additional terms will be used: 163 o Host Group Descriptor: Information used to describe the resource 164 consumer which seeks ALTO guidance, or one or several candidate 165 resource providers. This can be, for example, a single IP 166 address, an address prefix or address range that contains the 167 host(s), or an autonomous system (AS) number. Different options 168 may provide different levels of detail. Depending on the system 169 architecture, this may have implications on the quality of the 170 guidance ALTO is able to provide, on whether recommendations can 171 be aggregated, and on how much privacy-sensitive information about 172 users might be disclosed to additional parties. For a discussion, 173 see Section 4. 175 o Host Characteristics Attribute: Properties of a host (other than 176 the host group descriptor), in particular related to its 177 attachment to the network. This information may be stored in the 178 ALTO server and transmitted in the ALTO protocol. It may be 179 evaluated according to the rating criteria. 181 o Rating Criterion: The condition or relation that defines the 182 "better" in "better-than-random peer selection", which is the 183 ultimate goal of ALTO. Examples may include "host's Internet 184 access is not subject to volume based charging (flat rate)" or 185 "low topological distance". Some rating criteria, such as "low 186 topological distance", need to include a reference point, i. e., 187 "low topological distance from a given resource consumer", which 188 can be described by means of a host group descriptor. 190 2.3. Architectural Framework for ALTO 192 There are various architectural options how ALTO could be 193 implemented, and specifying or mandating one specific architecture is 194 out of the scope of this document. 196 The ALTO Working Group Charter [ALTO-charter] itemizes several key 197 components, which shall be elaborated and specified by the ALTO 198 Working Group. The ALTO problem statement [RFC5693] defines a 199 terminology (see Section 2.2) and presents a figure that gives a 200 high-level overview of protocol interaction between ALTO elements. 202 This document itemizes requirements for the following components of 203 the abovementioned architecture: 205 o The ALTO client protocol, which is used for sending ALTO queries 206 and ALTO replies between ALTO client and ALTO server. 208 o The discovery mechanism, which will be used by ALTO clients in 209 order to find out where to send ALTO requests. 211 o The overall architecture, especially with respect to security and 212 privacy issues. 214 Furthermore, this document describes the following data structures, 215 which might be used in the ALTO client protocol: 217 o Host group descriptors, which are used to describe the location of 218 a host in the network topology. 220 o Rating criteria, i. e., conditions that shall be evaluated in 221 order to generate the ALTO guidance. 223 Requirements regarding other components are not considered in the 224 current version of this document, but may be added later. 226 2.4. Sample Use Cases 228 The ALTO problem statement [RFC5693] presents a figure that gives a 229 high-level overview of protocol interaction between ALTO elements. 230 The following figures are somewhat more elaborated and extended 231 versions of it, in order to give some non-normative examples of ALTO 232 usage. It can also be seen that, in some use cases, some of the 233 requirements presented in later sections are more relevant than in 234 others. 236 Figure 1 shows an ALTO use case with a DHT-based P2P application. 237 Using this distributed lookup mechanism, a peer can figure out which 238 other peers are candidate resource providers for a desired resource. 239 Every peer software includes an ALTO client, in order to request and 240 receive guidance on peer selection from the ALTO servers. 242 From an ALTO perspective this means that the ALTO servers will 243 receive ALTO queries from a rather large number of different ALTO 244 clients. The performance of many clients and their Internet 245 connectivity may be rather limited and therefore, this puts certain 246 restrictions on the amount of guiding data that can be sent to them. 247 Furthermore, the privacy-sensitive IP addresses of the peers are 248 visible to the (operators of the) ALTO servers, as these are also the 249 source addresses of the ALTO query messages. 251 Figure 2 shows an ALTO use case with a P2P application that makes use 252 of a centralized resource directory (in some specific P2P 253 implementations called a "tracker"). In this scenario the ALTO 254 servers receive queries only from few entities, i.e., the resource 255 directories. As these resource directories must be powerful machines 256 anyway, it may be reasonable to send large amounts of ALTO guidance 257 data to them, which will be cached there. Furthermore, in this 258 scenario it may be possible to hide the exact addresses of the peers 259 from the ALTO server. 261 +-----+ 262 =====| |** 263 ==== +-----+ * 264 ==== * * 265 ==== * * 266 +-----+ +------+===== +-----+ * 267 | |.....| |======================| | * 268 +-----+ +------+===== +-----+ * 269 Source of ALTO ==== * * 270 topological service ==== * * 271 information ==== +-----+ * 272 =====| |** 273 +-----+ 274 Legend: 275 === ALTO client protocol 276 *** Application protocol 277 ... Provisioning protocol 279 Figure 1: Overview of protocol interaction between ALTO elements, 280 scenario without resource directory 281 +-----+ 282 **| |** 283 ** +-----+ * 284 ** * * 285 ** * * 286 +-----+ +------+ +-----+** +-----+ * 287 | |.....| |=====| |**********| | * 288 +-----+ +------+ +-----+** +-----+ * 289 Source of ALTO Resource ** * * 290 topological service directory ** * * 291 information ("tracker") ** +-----+ * 292 **| |** 293 +-----+ 294 Peers 295 Legend: 296 === ALTO client protocol 297 *** Application protocol 298 ... Provisioning protocol 300 Figure 2: Overview of protocol interaction between ALTO elements, 301 scenario with resource directory 303 3. ALTO Requirements 305 3.1. ALTO Client Protocol 307 3.1.1. General Requirements 309 REQ. ARv06-1: The ALTO service is provided by one or more ALTO 310 servers. ALTO servers MUST implement the ALTO client protocol, for 311 receiving ALTO queries from ALTO clients and for sending the 312 corresponding ALTO replies. 314 REQ. ARv06-2: ALTO clients MUST implement the ALTO client protocol, 315 for sending ALTO queries to ALTO servers and for receiving the 316 corresponding ALTO replies. 318 REQ. ARv06-3: The format of the ALTO query message MUST allow the 319 ALTO client to solicit guidance for selecting appropriate resource 320 providers. 322 REQ. ARv06-4: The format of the ALTO reply message MUST allow the 323 ALTO server to express its guidance for selecting appropriate 324 resource providers. 326 REQ. ARv06-5: The detailed specification of a protocol is out of the 327 scope of this document. However, any protocol specification that 328 claims to implement the ALTO client protocol MUST be compliant to the 329 requirements itemized in this document. 331 3.1.2. Host Group Descriptor Support 333 The ALTO guidance is based on the evaluation of several resource 334 providers or groups of resource providers, which are characterized by 335 means of host group descriptors, considering one or several rating 336 criteria. 338 REQ. ARv06-6: The ALTO client protocol MUST support the usage of 339 several different host group descriptor types. 341 REQ. ARv06-7: The ALTO client protocol specification MUST define a 342 basic set of host group descriptor types, which MUST be supported by 343 all implementations of the ALTO client protocol. 345 REQ. ARv06-8: The ALTO client protocol MUST support the host group 346 descriptor types "IPv4 address prefix" and "IPv6 address prefix." 347 They can be used to specify the IP address of one host, or an IP 348 address range (in CIDR notation), which contains all hosts in 349 question. It is also possible to specify a broader address range 350 (i.e., a shorter prefix length) than the intended group of hosts 351 actually uses, in order to conceal their exact identity. 353 REQ. ARv06-9: The ALTO client protocol specification MUST define an 354 appropriate procedure for adding new host group descriptor types, 355 e.g., by establishing an IANA registry. 357 See Section 4 for a discussion of possible other host group 358 descriptor types. 360 REQ. ARv06-10: ALTO clients and ALTO servers MUST clearly identify 361 the type of each host group descriptor sent in ALTO queries or 362 replies. 364 REQ. ARv06-11: For host group descriptor types other than "IPv4 365 address prefix" and "IPv6 address prefix", the host group descriptor 366 type identification MUST be supplemented by a reference to a 367 facility, which can be used to translate host group descriptors of 368 that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping 369 table or an algorithm. 371 REQ. ARv06-12: Protocol functions for mapping other host group 372 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 373 specified as part of the ALTO client protocol, and the corresponding 374 address mapping information SHOULD be made available by the same 375 entity that wants to use these host group descriptors within the ALTO 376 client protocol. However, an ALTO server or an ALTO client MAY also 377 send a reference to an external mapping facility, e.g., a translation 378 table to be downloaded as file via HTTP. 380 REQ. ARv06-13: The ALTO client protocol specification MUST define 381 mechanisms, which can be used by the ALTO client and the ALTO server 382 to indicate that a host group descriptor used by the other party is 383 of an unsupported type, or that the indicated mapping mechanism could 384 not be used. 386 3.1.3. Rating Criteria Support 388 REQ. ARv06-14: The ALTO client protocol MUST support the usage of 389 several different rating criteria types. 391 REQ. ARv06-15: The ALTO client protocol specification MUST define a 392 basic set of rating criteria types, which MUST be supported by all 393 implementations of the ALTO client protocol. 395 REQ. ARv06-16: The ALTO client protocol specification MUST support 396 the rating criteria type "relative operator's preference." This is a 397 relative measure, i.e., it is not associated with any unit of 398 measurement. A higher rating according to this criterion indicates 399 that the application should prefer the respective candidate resource 400 provider over others with lower ratings (if no other reasons speak 401 against it, such as transmission attempts suggesting that the path is 402 currently congested). The operator of the ALTO server does not have 403 to disclose how and based on which data the ratings are actually 404 computed. Examples could be: cost for peering or transit traffic, 405 traffic engineering inside the network, and other policies. 407 REQ. ARv06-17: The ALTO client protocol specification MUST define an 408 appropriate procedure for adding new rating criteria types, e.g., by 409 establishing an IANA registry. 411 See Section 5 for a discussion of possible other rating criteria. 413 REQ. ARv06-18:The ALTO query message SHOULD allow the ALTO client to 414 express which rating criteria should be considered, as well as their 415 relative relevance for the specific application that will eventually 416 make use of the guidance. 418 REQ. ARv06-19:The ALTO reply message SHOULD allow the ALTO server to 419 express which rating criteria have been considered when generating 420 the reply. 422 REQ. ARv06-20: The ALTO client protocol specification MUST define 423 mechanisms, which can be used by the ALTO client and the ALTO server 424 to indicate that a rating criteria used by the other party is of an 425 unsupported type. 427 3.1.4. Placement of Entities and Timing of Transactions 429 With respect to the placement of ALTO clients, several modes of 430 operation exist: 432 o One mode of ALTO operation is that ALTO clients may be embedded 433 directly in the resource consumer (e.g., peer of a DHT-based P2P 434 application), which wants to access a resource. 436 o Another mode of operation is to perform ALTO queries indirectly, 437 via resource directories (e.g., tracker of a P2P application), 438 which may issue ALTO queries to solicit preference on potential 439 resource providers, considering the respective resource consumer. 441 REQ. ARv06-21: The ALTO client protocol MUST support the mode of 442 operation, in which the ALTO client is directly embedded in the 443 resource consumer. 445 REQ. ARv06-22: The ALTO client protocol MUST support the mode of 446 operation, in which the ALTO client is embedded in the resource 447 directory. 449 REQ. ARv06-23: The ALTO client protocol MUST be designed in a way 450 that the ALTO service can be provided by an entity which is not the 451 operator of the IP access network. 453 REQ. ARv06-24: The ALTO client protocol MUST be designed in a way 454 that different instances of the ALTO service operated by different 455 providers can coexist. 457 With respect to the timing of ALTO queries, several modes of 458 operation exist: 460 o In target-aware query mode, an ALTO client performs the ALTO query 461 when the desired resource and a set of candidate resource 462 providers are already known, i. e., after DHT lookups, queries to 463 the resource directory, etc. 465 o In target-independent query mode, ALTO queries are performed in 466 advance or periodically, in order to receive comprehensive, 467 "target-independent" guidance, which will be cached locally and 468 evaluated later, when a resource is to be accessed. 470 REQ. ARv06-25: The ALTO client protocol MUST support at least one of 471 these two modes, either the target-aware or the target-independent 472 query mode. 474 REQ. ARv06-26: The ALTO client protocol SHOULD support both the 475 target-aware and the target-independent query mode. 477 REQ. ARv06-27: The ALTO client protocol SHOULD support lifetime 478 attributes, to enable caching of recommendations at ALTO clients. 480 REQ. ARv06-28: The ALTO client protocol SHOULD specify an aging 481 mechanism, which allows to give newer recommendations precedence over 482 older ones. 484 REQ. ARv06-30: The ALTO client protocol SHOULD allow the ALTO server 485 to add information about appropriate modes of re-use to its ALTO 486 replies. Re-use may include redistributing an ALTO reply to other 487 parties, as well as using the same ALTO information in a resource 488 directory to improve the replies to different resource consumers, 489 within the specified lifetime of the ALTO reply. The ALTO server 490 SHOULD be able to express that 492 o no re-use should occur 493 o re-use is appropriate for a specific "target audience", i.e., a 494 set of resource consumers explicitly defined by a list of host 495 group descriptors. The ALTO server MAY specify a "target 496 audience" in the ALTO reply, which is only a subset of the known 497 actual "target audience", e.g., if required by operator policies 499 o re-use is appropriate for any resource consumer that would send 500 (or cause a third party sending on behalf of it) the same ALTO 501 query (i.e., with the same query parameters, except for the 502 resource consumer ID, if applicable) to this ALTO server 504 o re-use is appropriate for any resource consumer that would send 505 (or cause a third party sending on behalf of it) the same ALTO 506 query (i.e., with the same query parameters, except for the 507 resource consumer ID, if applicable) to any ALTO server 509 REQ. ARv06-31: The ALTO client protocol MUST support scenarios with 510 the ALTO client located in the private address realm behind a network 511 address translator (NAT). There are different types of NAT, see 512 [RFC4787] and [RFC5382]. 514 3.1.5. Protocol Extensibility 516 REQ. ARv06-32: The ALTO client protocol MUST include support for 517 adding protocol extensions in a non-disruptive, backward-compatible 518 way. 520 REQ. ARv06-33: The ALTO client protocol MUST include protocol 521 versioning support, in order to clearly distinguish between 522 incompatible versions of the protocol. 524 3.1.6. Error Handling and Overload Protection 526 REQ. ARv06-34: Any application designed to use ALTO MUST also work 527 if no ALTO servers can be found or if no responses to ALTO queries 528 are received, e.g., due to connectivity problems or overload 529 situation. 531 REQ. ARv06-35: The ALTO client protocol MUST use TCP based 532 transport. 534 REQ. ARv06-36: An ALTO server, which is operating close to its 535 capacity limit, MUST be able to inform clients about its impending 536 overload situation, and require them to throttle their query rate. 538 REQ. ARv06-37: An ALTO server, which is operating close to its 539 capacity limit, MUST be able to inform clients about its impending 540 overload situation, and redirect them to another ALTO server. 542 REQ. ARv06-38: An ALTO server, which is operating close to its 543 capacity limit, MUST be able to inform clients about its impending 544 overload situation, and terminate the conversation with the ALTO 545 client. 547 REQ. ARv06-39: An ALTO server, which is operating close to its 548 capacity limit, MUST be able to inform clients about its impending 549 overload situation, and reject new conversation attempts. 551 3.2. ALTO Server Discovery 553 The ALTO client protocol is supported by one or several ALTO server 554 discovery mechanisms, which will be used by ALTO clients in order to 555 find out where to send ALTO requests. 557 REQ. ARv06-40: ALTO clients which are embedded in the resource 558 consumer MUST be able to use the ALTO server discovery mechanism, in 559 order to find one or several ALTO servers that can provide ALTO 560 guidance suitable for the resource consumer. This mode of operation 561 is called "resource consumer initiated ALTO server discovery". 563 REQ. ARv06-41: ALTO clients which are embedded in a resource 564 directory and perform third-party ALTO queries on behalf of a remote 565 resource consumer MUST be able to use the ALTO server discovery 566 mechanism, in order to find one or several ALTO servers that can 567 provide ALTO guidance suitable for the respective resource consumer. 568 This mode of operation is called "third-party ALTO server discovery". 570 REQ. ARv06-42: ALTO clients MUST be able to perform resource 571 consumer initiated ALTO server discovery, even if they are located 572 behind a network address translator (NAT). 574 REQ. ARv06-43: ALTO clients MUST be able to perform third-party ALTO 575 server discovery, even if they are located behind a network address 576 translator (NAT). 578 REQ. ARv06-44: ALTO clients MUST be able to perform third-party ALTO 579 server discovery, even if the resource consumer, on behalf of which 580 the ALTO query will be sent, is located behind a network address 581 translator (NAT). 583 REQ. ARv06-45: The ALTO server discovery mechanism may be specified 584 and provided using an existing protocol or mechanism, such as DNS, 585 DHCP, or PPP based automatic configuration, etc. These candidate 586 "base protocols" differ with respect to their availability in various 587 access network architectures and their suitability for third-party 588 queries. When evaluating different options this should be taken into 589 account, in order to limit the total number of ALTO server discovery 590 mechanisms that have to be specified for supporting a reasonably wide 591 range of deployment scenarios. 593 REQ. ARv06-46: The ALTO server discovery mechanism SHOULD be able to 594 return the respective contact information for several ALTO servers. 596 REQ. ARv06-47: The ALTO server discovery mechanism SHOULD be able to 597 indicate preferences for each returned ALTO server contact 598 information. 600 3.3. Security and Privacy 602 REQ. ARv06-48: The ALTO client protocol MUST support mechanisms for 603 the authentication of ALTO servers. 605 REQ. ARv06-49: The ALTO client protocol MUST support mechanisms for 606 the authentication of ALTO clients. 608 REQ. ARv06-50: The ALTO client protocol MUST support different 609 levels of detail in queries and responses, in order for the operator 610 of an ALTO service to be able to control how much information (e.g., 611 about the network topology) is disclosed. 613 REQ. ARv06-51: The operator of an ALTO server MUST NOT assume that 614 an ALTO client will implement mechanisms or comply with rules that 615 limit the ALTO client's ability to redistribute information retrieved 616 from the ALTO server to third parties. 618 REQ. ARv06-52: The ALTO client protocol MUST support different 619 levels of detail in queries and responses, in order to protect the 620 privacy of users, to ensure that the operators of ALTO servers and 621 other users of the same application cannot derive sensitive 622 information. 624 REQ. ARv06-53: The ALTO client protocol SHOULD be defined in a way, 625 that the operator of one ALTO server cannot easily deduce the 626 resource identifier (e.g., file name in P2P file sharing) which the 627 resource consumer seeking ALTO guidance wants to access. 629 REQ. ARv06-54: The ALTO client protocol MUST include appropriate 630 mechanisms to protect the ALTO service against DoS attacks. 632 4. Host Group Descriptors 634 Host group descriptors are used in the ALTO client protocol to 635 describe the location of a host in the network topology. The ALTO 636 client protocol specification defines a basic set of host group 637 descriptor types, which have to be supported by all implementations, 638 and an extension procedure for adding new descriptor types (see 639 Section 3.1.2). The following list gives an overview on further host 640 group descriptor types that have been proposed in the past, or which 641 are in use by ALTO-related prototype implementations. This list is 642 not intended as normative text. Instead, the only purpose of the 643 following list is to document the descriptor types that have been 644 proposed so far, and to solicit further feedback and discussion: 646 o Autonomous System (AS) number 648 o Protocol-specific group identifiers, which expand to a set of IP 649 address ranges (CIDR) and/or AS numbers. In one specific solution 650 proposal, these are called Partition ID (PID). 652 5. Rating Criteria 654 Rating criteria are used in the ALTO client protocol to express 655 topology- or connectivity-related properties, which are evaluated in 656 order to generate the ALTO guidance. The ALTO client protocol 657 specification defines a basic set of rating criteria, which have to 658 be supported by all implementations, and an extension procedure for 659 adding new criteria (see Section 3.1.3). The following list gives an 660 overview on further rating criteria that have been proposed in the 661 past, or which are in use by ALTO-related prototype implementations. 662 This list is not intended as normative text. Instead, the only 663 purpose of the following list is to document the rating criteria that 664 have been proposed so far, and to solicit further feedback and 665 discussion: 667 5.1. Distance-related Rating Criteria 669 o Relative topological distance: relative means that a larger 670 numerical value means greater distance, but it is up to the ALTO 671 service how to compute the values, and the ALTO client will not be 672 informed about the nature of the information. One way of 673 generating this kind of information MAY be counting AS hops, but 674 when querying this parameter, the ALTO client MUST NOT assume that 675 the numbers actually are AS hops. 677 o Absolute topological distance, expressed in the number of 678 traversed autonomous systems (AS). 680 o Absolute topological distance, expressed in the number of router 681 hops (i.e., how much the TTL value of an IP packet will be 682 decreased during transit). 684 o Absolute physical distance, based on knowledge of the approximate 685 geolocation (continent, country) of an IP address. 687 5.2. Charging-related Rating Criteria 689 o Traffic volume caps, in case the Internet access of the resource 690 consumer is not charged by "flat rate". For each candidate 691 resource provider, the ALTO service could indicate the amount of 692 data that may be transferred from/to this resource provider until 693 a given point in time, and how much of this amount has already 694 been consumed. Furthermore, it would have to be indicated how 695 excess traffic would be handled (e.g., blocked, throttled, or 696 charged separately at an indicated price). The interaction of 697 several applications running on a host, out of which some use this 698 criterion while others don't, as well as the evaluation of this 699 criterion in resource directories, which issue ALTO queries on 700 behalf of other peers, are for further study. 702 5.3. Performance-related Rating Criteria 704 The following rating criteria are subject to the remarks below. 706 o The minimum achievable throughput between the resource consumer 707 and the candidate resource provider, which is considered useful by 708 the application (only in ALTO queries), or 710 o An arbitrary upper bound for the throughput from/to the candidate 711 resource provider (only in ALTO replies). This may be, but is not 712 necessarily the provisioned access bandwidth of the candidate 713 resource provider. 715 o The maximum round-trip time (RTT) between resource consumer and 716 the candidate resource provider, which is acceptable for the 717 application for useful communication with the candidate resource 718 provider (only in ALTO queries), or 720 o An arbitrary lower bound for the RTT between resource consumer and 721 the candidate resource provider (only in ALTO replies). This may 722 be, for example, based on measurements of the propagation delay in 723 a completely unloaded network. 725 The ALTO client MUST be aware, that with high probability, the actual 726 performance values differ significantly from these upper and lower 727 bounds. In particular, an ALTO client MUST NOT consider the "upper 728 bound for throughput" parameter as a permission to send data at the 729 indicated rate without using congestion control mechanisms. 731 The discrepancies are due to various reasons, including, but not 732 limited to the facts that 734 o the ALTO service is not an admission control system 736 o the ALTO service may not know the instantaneous congestion status 737 of the network 739 o the ALTO service may not know all link bandwidths, i.e., where the 740 bottleneck really is, and there may be shared bottlenecks 742 o the ALTO service may not know whether the candidate peer itself is 743 overloaded 745 o the ALTO service may not know whether the candidate peer throttles 746 the bandwidth it devotes for the considered application 748 o the ALTO service may not know whether the candidate peer will 749 throttle the data it sends to us (e.g., because of some fairness 750 algorithm, such as tit-for-tat) 752 Because of these inaccuracies and the lack of complete, instantaneous 753 state information, which are inherent to the ALTO service, the 754 application must use other mechanisms (such as passive measurements 755 on actual data transmissions) to assess the currently achievable 756 throughput, and it MUST use appropriate congestion control mechanisms 757 in order to avoid a congestion collapse. Nevertheless, these rating 758 criteria may provide a useful shortcut for quickly excluding 759 candidate resource providers from such probing, if it is known in 760 advance that connectivity is in any case worse than what is 761 considered the minimum useful value by the respective application. 763 5.4. Inappropriate Rating Criteria 765 Rating criteria that SHOULD NOT be defined for and used by the ALTO 766 service include: 768 o Performance metrics that are closely related to the instantaneous 769 congestion status. The definition of alternate approaches for 770 congestion control is explicitly out of the scope of ALTO. 771 Instead, other appropriate means, such as using TCP based 772 transport, have to be used to avoid congestion. 774 6. IANA Considerations 776 This requirements document does not mandate any immediate IANA 777 actions. However, such IANA considerations may arise from future 778 ALTO specification documents which try to meet the requirements given 779 here. 781 7. Security Considerations 783 7.1. High-level security considerations 785 High-level security considerations for the ALTO service can be found 786 in the "Security Considerations" section of the ALTO problem 787 statement document [RFC5693]. 789 7.2. Classification of Information Disclosure Scenarios 791 The unwanted disclosure of information is one key concern related to 792 ALTO. The following list gives a classification of information 793 disclosure scenarios, which may be considered more or less critical 794 by different parties: 796 o (1) Excess disclosure of ALTO server operator's data to an 797 authorized ALTO client. The operator of an ALTO server has to 798 feed information, such as tables mapping host group descriptors to 799 host characteristics attributes, into the server, thereby enabling 800 it to give guidance to ALTO clients. Some operators might 801 consider the full set of this information confidential (e.g., a 802 detailed map of the operator's network topology), and might want 803 to disclose only a subset of it or somehow obfuscated information 804 to an ALTO client. 806 o (2) Disclosure of the application behavior to the ALTO server. 807 The operator of an ALTO server could infer the application 808 behavior (e.g., content identifiers in P2P file sharing 809 applications, or lists of resource providers that are considered 810 for establishing a connection) from the ALTO queries sent by an 811 ALTO client. 813 o (3) Disclosure of ALTO server operator's data (e.g., network 814 topology information) to an unauthorized third party. There are a 815 couple of sub-cases here: 817 * (3a) An ALTO server sends the information directly to an 818 unauthorized ALTO client. 820 * (3b) An unauthorized party snoops on the data transmission from 821 the ALTO server to an authorized ALTO client. 823 * (3c) An authorized ALTO client knowingly forwards the 824 information it had received from the ALTO server to an 825 unauthorized party. 827 o (4) Disclosure of the application behavior to an unauthorized 828 third party. 830 o (5) Excess retrieval of ALTO server operator's data by 831 collaborating ALTO clients. Several authorized ALTO clients could 832 ask an ALTO server for guidance, and redistribute the replies 833 among each other (see also case 3c). By correlating the ALTO 834 replies they could find out more information than intended to be 835 disclosed by the ALTO server operator. 837 (1) may be addressed by the ALTO server operator choosing the level 838 of detail of the information to be populated into the ALTO server. 839 Furthermore, access control mechanisms for filtering ALTO replies 840 according to the authenticated ALTO client identity might be 841 installed in the ALTO server, although this might not be effective 842 given the lack of efficient mechanisms for addressing (3c) and (5), 843 see below. 845 (2) is addressed by allowing ALTO clients to use the target- 846 independent query mode. In this mode of operation, guiding 847 information (e.g., "maps") is retrieved from the ALTO server and used 848 entirely locally by the ALTO client, i.e., without sending host 849 location attributes of candidate resource providers to the ALTO 850 server. In the target-aware query mode, (2) can be addressed by ALTO 851 clients by obfuscating the identity of candidate resource consumers, 852 e.g., by zeroing-out or randomizing the last few bits of the IP 853 addresses. However, there is the potential side effect of yielding 854 inaccurate results. 856 (3a), (3b), and (4) may be addressed by authentication, access 857 control, and encryption schemes for the ALTO client protocol. 858 However, deployment of encryption schemes might not be effective 859 given the lack of efficient mechanisms for addressing (3c) and (5), 860 see below. 862 Straightforward authentication and encryption schemes won't help 863 solving (3c) and (5), and there is no other simple and efficient 864 mechanism known. The cost of complex approaches, e.g., based on 865 digital rights management (DRM), might easily outweigh the benefits 866 of the whole ALTO solution, and therefore they are not considered as 867 a viable solution. That is, ALTO server operators must be aware that 868 (3c) and (5) cannot be prevented from happening, and therefore they 869 should feed only such data into an ALTO server, which they do not 870 consider sensitive with respect to (3c) and (5). 872 These insights are reflected by the requirements presented in this 873 document. 875 7.3. Security Requirements 877 For a set of specific security requirements please refer to 878 Section 3.3 of this document. 880 8. References 882 8.1. Normative References 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, March 1997. 887 8.2. Informative References 889 [ALTO-charter] 890 Marocco, E. and V. Gurbani, "Application-Layer Traffic 891 Optimization (ALTO) Working Group Charter", February 2009. 893 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 894 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 895 RFC 4787, January 2007. 897 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 898 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 899 RFC 5382, October 2008. 901 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 902 Optimization (ALTO) Problem Statement", RFC 5693, 903 October 2009. 905 Appendix A. Contributors 907 The authors were supported by the following people, who have 908 contributed to this document: 910 o Richard Alimi 912 o Zoran Despotovic 914 o Jason Livingood 916 o Saverio Niccolini 918 o Jan Seedorf 920 The authors would like to thank the members of the P2PI and ALTO 921 mailing lists for their feedback. 923 Appendix B. Acknowledgments 925 The initial version of this document was co-authored by Laird Popkin. 927 The authors would like to thank 929 o Vijay K. Gurbani 931 o Enrico Marocco 933 for fostering discussions that lead to the creation of this document, 934 and for giving valuable comments on it. 936 Laird Popkin and Y. Richard Yang are grateful to the many 937 contributions made by the members of the P4P working group and Yale 938 Laboratory of Networked Systems. The P4P working group is hosted by 939 DCIA. 941 Saverio Niccolini, Jan Seedorf, and Martin Stiemerling are partially 942 supported by the NAPA-WINE project (Network-Aware P2P-TV Application 943 over Wise Networks, http://www.napa-wine.org), a research project 944 supported by the European Commission under its 7th Framework Program 945 (contract no. 214412). The views and conclusions contained herein 946 are those of the authors and should not be interpreted as necessarily 947 representing the official policies or endorsements, either expressed 948 or implied, of the NAPA-WINE project or the European Commission. 950 Authors' Addresses 952 Sebastian Kiesel (editor) 953 University of Stuttgart Computing Center 954 Allmandring 30 955 Stuttgart 70550 956 Germany 958 Email: ietf-alto@skiesel.de 959 URI: http://www.rus.uni-stuttgart.de/nks/ 961 Stefano Previdi 962 Cisco Systems, Inc. 964 Email: sprevidi@cisco.com 966 Martin Stiemerling 967 NEC Laboratories Europe/University of Goettingen 969 Email: martin.stiemerling@neclab.eu 970 URI: http://ietf.stiemerling.org 972 Richard Woundy 973 Comcast Corporation 975 Email: Richard_Woundy@cable.comcast.com 977 Yang Richard Yang 978 Yale University 980 Email: yry@cs.yale.edu