idnits 2.17.1 draft-ietf-alto-reqs-03.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 269 has weird spacing: '...logical ser...' == Line 289 has weird spacing: '...logical ser...' -- The document date (February 17, 2010) is 5182 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-00 Summary: 1 error (**), 0 flaws (~~), 4 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 NEC 4 Intended status: Informational L. Popkin 5 Expires: August 21, 2010 Pando Networks, Inc. 6 S. Previdi 7 Cisco Systems, Inc. 8 R. Woundy 9 Comcast Corporation 10 Y R. Yang 11 Yale University 12 February 17, 2010 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-03.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 August 21, 2010. 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 . . . . . . . . . . . . . . . . 12 90 3.1.6. Error handling and overload protection . . . . . . . . 13 91 3.2. ALTO server discovery . . . . . . . . . . . . . . . . . . 13 92 3.3. Security and privacy . . . . . . . . . . . . . . . . . . . 14 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 additonal terms will be used: 163 o Host Group Descriptor: Information used to describe the resouce 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. 174 o Host Characteristics Attribute: Properties of a host (other than 175 the host group descriptor), in particular related to its 176 attachment to the network. This information may be stored in the 177 ALTO server and transmitted in the ALTO protocol. It may be 178 evaluated according to the rating criteria. 180 o Rating Criterion: The condition or relation that defines the 181 "better" in "better-than-random peer selection", which is the 182 ultimate goal of ALTO. Examples may include "host's Internet 183 access is not subject to volume based charging (flat rate)" or 184 "low topological distance". Some rating criteria, such as "low 185 topological distance", need to include a reference point, i. e., 186 "low topological distance from a given resource consumer", which 187 can be described by means of a host group descriptor. 189 2.3. Architectural framework for ALTO 191 There are various architectural options how ALTO could be 192 implemented, and specifying or mandating one specific architecture is 193 out of the scope of this document. 195 The ALTO Working Group Charter [ALTO-charter] itemizes several key 196 components, which shall be elaborated and specified by the ALTO 197 Working Group. The ALTO problem statement [RFC5693] defines a 198 terminology (see Section 2.2) and presents a figure that gives a 199 high-level overview of protocol interaction between ALTO elements. 201 This document itemizes requirements for the following components of 202 the abovementioned architecture: 204 o The ALTO client protocol, which is used for sending ALTO queries 205 and ALTO replies between ALTO client and ALTO server. 207 o The discovery mechanism, which will be used by ALTO clients in 208 order to find out where to send ALTO requests. 210 o The overall architecture, especially with respect to security and 211 privacy issues. 213 Furthermore, this document describes the following data structures, 214 which might be used in the ALTO client protocol: 216 o Host group descriptors, which are used to describe the location of 217 a host in the network topology. 219 o Rating criteria, i. e., conditions that shall be evaluated in 220 order to generate the ALTO guidance. 222 Requirements regarding other components are not considered in the 223 current version of this document, but may be added later. 225 2.4. Sample use cases 227 The ALTO problem statement [RFC5693] presents a figure that gives a 228 high-level overview of protocol interaction between ALTO elements. 229 The following figures are somewhat more elaborated and extended 230 versions of it, in order to give some non-normative examples of ALTO 231 usage. It can also be seen that, in some use cases, some of the 232 requirements presented in later sections are more relevant than in 233 others. 235 Figure 1 shows an ALTO use case with a DHT-based P2P application. 236 Using this distributed lookup mechanism, a peer can figure out which 237 other peers are candidate resource providers for a desired resource. 238 Every peer software includes an ALTO client, in order to request and 239 receive guidance on peer selection from the ALTO servers. 241 From an ALTO perspective this means that the ALTO servers will 242 receive ALTO queries from a rather large number of different ALTO 243 clients. The performance of many clients and their Internet 244 connectivity may be rather limited and therefore, this puts certain 245 restrictions on the amount of guiding data that can be sent to them. 246 Furthermore, the privacy-sensitive IP addresses of the peers are 247 visible to the (operators of the) ALTO servers, as these are also the 248 source addresses of the ALTO query messages. 250 Figure 2 shows an ALTO use case with a P2P application that makes use 251 of a centralized resource directory (in some specific P2P 252 implementations called a "tracker"). In this scenario the ALTO 253 servers receive queries only from few entities, i.e., the resource 254 directories. As these resource directories must be powerful machines 255 anyway, it may be reasonable to send large amounts of ALTO guidance 256 data to them, which will be cached there. Furthermore, in this 257 scenario it may be possible to hide the exact addresses of the peers 258 from the ALTO server. 260 +-----+ 261 =====| |** 262 ==== +-----+ * 263 ==== * * 264 ==== * * 265 +-----+ +------+===== +-----+ * 266 | |.....| |======================| | * 267 +-----+ +------+===== +-----+ * 268 Source of ALTO ==== * * 269 topological service ==== * * 270 information ==== +-----+ * 271 =====| |** 272 +-----+ 273 Legend: 274 === ALTO client protocol 275 *** Application protocol 276 ... Provisioning protocol 278 Figure 1: Overview of protocol interaction between ALTO elements, 279 scenario without resource directory 280 +-----+ 281 **| |** 282 ** +-----+ * 283 ** * * 284 ** * * 285 +-----+ +------+ +-----+** +-----+ * 286 | |.....| |=====| |**********| | * 287 +-----+ +------+ +-----+** +-----+ * 288 Source of ALTO Resource ** * * 289 topological service directory ** * * 290 information ("tracker") ** +-----+ * 291 **| |** 292 +-----+ 293 Peers 294 Legend: 295 === ALTO client protocol 296 *** Application protocol 297 ... Provisioning protocol 299 Figure 2: Overview of protocol interaction between ALTO elements, 300 scenario with resource directory 302 3. ALTO requirements 304 3.1. ALTO client protocol 306 3.1.1. General requirements 308 REQ. ARv03-1: The ALTO service is provided by one or more ALTO 309 servers. ALTO servers MUST implement the ALTO client protocol, for 310 receiving ALTO queries from ALTO clients and for sending the 311 corresponding ALTO replies. 313 REQ. ARv03-2: ALTO clients MUST implement the ALTO client protocol, 314 for sending ALTO queries to ALTO servers and for receiving the 315 corresponding ALTO replies. 317 REQ. ARv03-3: The format of the ALTO query message MUST allow the 318 ALTO client to solicit guidance for selecting appropriate resource 319 providers. 321 REQ. ARv03-4: The format of the ALTO reply message MUST allow the 322 ALTO server to express its guidance for selecting appropriate 323 resource providers. 325 REQ. ARv03-5: The detailed specification of a protocol is out of the 326 scope of this document. However, any protocol specification that 327 claims to implement the ALTO client protocol MUST be compliant to the 328 requirements itemized in this document. 330 3.1.2. Host group descriptor support 332 The ALTO guidance is based on the evaluation of several resource 333 providers or groups of resource providers, which are characterized by 334 means of host group descriptors, considering one or several rating 335 criteria. 337 REQ. ARv03-6: The ALTO client protocol MUST support the usage of 338 several different host group descriptor types. 340 REQ. ARv03-7: The ALTO client protocol specification MUST define a 341 basic set of host group descriptor types, which MUST be supported by 342 all implementations of the ALTO client protocol. 344 REQ. ARv03-8: The ALTO client protocol MUST support the host group 345 descriptor types "IPv4 address prefix" and "IPv6 address prefix." 346 They can be used to specify the IP address of one host, or an IP 347 address range (in CIDR notation), which contains all hosts in 348 question. It is also possible to specify a broader address range 349 (i.e., a shorter prefix length) than the intended group of hosts 350 actually uses, in order to conceal their exact identity. 352 REQ. ARv03-9: The ALTO client protocol specification MUST define an 353 appropriate procedure for adding new host group descriptor types, 354 e.g., by establishing an IANA registry. 356 See Section 4 for a discussion of possible other host group 357 descriptor types. 359 REQ. ARv03-10: ALTO clients and ALTO servers MUST clearly identify 360 the type of each host group descriptor sent in ALTO queries or 361 replies. 363 REQ. ARv03-11: For host group descriptor types other than "IPv4 364 address prefix" and "IPv6 address prefix", the host group descriptor 365 type identification MUST be supplemented by a reference to a 366 facility, which can be used to translate host group descriptors of 367 that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping 368 table or an algorithm. 370 REQ. ARv03-12: Protocol functions for mapping other host group 371 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 372 specified as part of the ALTO client protocol, and the corresponding 373 address mapping information SHOULD be made available by the same 374 entity that wants to use these host group descriptors within the ALTO 375 client protocol. However, an ALTO server or an ALTO client MAY also 376 send a reference to an external mapping facility, e.g., a translation 377 table to be downloaded as file via HTTP. 379 REQ. ARv03-13: The ALTO client protocol specification MUST define 380 mechanisms, which can be used by the ALTO client and the ALTO server 381 to indicate that a host group descriptor used by the other party is 382 of an unsupported type, or that the indicated mapping mechanism could 383 not be used. 385 3.1.3. Rating criteria support 387 REQ. ARv03-14: The ALTO client protocol MUST support the usage of 388 several different rating criteria types. 390 REQ. ARv03-15: The ALTO client protocol specification MUST define a 391 basic set of rating criteria types, which MUST be supported by all 392 implementations of the ALTO client protocol. 394 REQ. ARv03-16: The ALTO client protocol specification MUST support 395 the rating criteria type "relative operator's preference." This is a 396 relative measure, i.e., it is not associtated with any unit of 397 measurement. A higher rating according to this criterion indicates 398 that the application should prefer the respective candidate resource 399 provider over others with lower ratings (if no other reasons speak 400 against it, such as transmission attempts suggesting that the path is 401 currently congested). The operator of the ALTO server does not have 402 to disclose how and based on which data the ratings are actually 403 computed. Examples could be: cost for peering or transit traffic, 404 traffic engineering inside the network, and other policies. 406 REQ. ARv03-17: The ALTO client protocol specification MUST define an 407 appropriate procedure for adding new rating criteria types, e.g., by 408 establishing an IANA registry. 410 See Section 5 for a discussion of possible other rating criteria. 412 REQ. ARv03-18:The ALTO query message SHOULD allow the ALTO client to 413 express which rating criteria should be considered, as well as their 414 relative relevance for the specific application that will eventually 415 make use of the guidance. 417 REQ. ARv03-19:The ALTO reply message SHOULD allow the ALTO server to 418 express which rating criteria have been considered when generating 419 the reply. 421 REQ. ARv03-20: The ALTO client protocol specification MUST define 422 mechanisms, which can be used by the ALTO client and the ALTO server 423 to indicate that a rating criteria used by the other party is of an 424 unsupported type. 426 3.1.4. Placement of entities and timing of transactions 428 With respect to the placement of ALTO clients, several modes of 429 operation exist: 431 o One mode of ALTO operation is that ALTO clients may be embedded 432 directly in the resource consumer (e.g., peer of a DHT-based P2P 433 application), which wants to access a resource. 435 o Another mode of operation is to perform ALTO queries indirectly, 436 via resource directories (e.g., tracker of a P2P application), 437 which may issue ALTO queries to solicit preference on potential 438 resource providers, considering the respective resource consumer. 440 REQ. ARv03-21: The ALTO client protocol MUST support the mode of 441 operation, in which the ALTO client is directly embedded in the 442 resource consumer. 444 REQ. ARv03-22: The ALTO client protocol MUST support the mode of 445 operation, in which the ALTO client is embedded in the resource 446 directory. 448 REQ. ARv03-23: The ALTO client protocol MUST be designed in a way 449 that the ALTO service can be provided by an operator which is not the 450 operator of the IP access network. 452 REQ. ARv03-24: The ALTO client protocol MUST be designed in a way 453 that different instances of the ALTO service operated by different 454 providers can coexist. 456 With respect to the timing of ALTO queries, several modes of 457 operation exist: 459 o In target-aware query mode, an ALTO client performs the ALTO query 460 when the desired resource and a set of candidate resource 461 providers are already known, i. e., after DHT lookups, queries to 462 the resource directory, etc. 464 o In target-independent query mode, ALTO queries are performed in 465 advance or periodically, in order to receive comprehensive, 466 "target-independent" guidance, which will be cached locally and 467 evaluated later, when a resource is to be accessed. 469 REQ. ARv03-25: The ALTO client protocol MUST support at least one of 470 these two modes, either the target-aware or the target-independent 471 query mode. 473 REQ. ARv03-26: The ALTO client protocol SHOULD support both the 474 target-aware and the target-independent query mode. 476 REQ. ARv03-27: The ALTO client protocol SHOULD support lifetime 477 attributes, to enable caching of recommendations at ALTO clients. 479 REQ. ARv03-28: The ALTO client protocol SHOULD specify an aging 480 mechanism, which allows to give newer recommendations precedence over 481 older ones. 483 REQ. ARv03-29: The ALTO client protocol MUST support scenarios with 484 the ALTO client located in the private address realm behind a network 485 address translator (NAT). There are different types of NAT, see 486 [RFC4787] and [RFC5382]. 488 3.1.5. Protocol extensibility 490 REQ. ARv03-30: The ALTO client protocol MUST include support for 491 adding protocol extensions in a non-disruptive, backward-compatible 492 way. 494 REQ. ARv03-31: The ALTO client protocol MUST include protocol 495 versioning support, in order to clearly distinguish between 496 incompatible major versions of the protocol. 498 3.1.6. Error handling and overload protection 500 REQ. ARv03-32: Any application designed to use ALTO MUST also work 501 if no ALTO servers can be found or if no responses to ALTO queries 502 are received, e.g., due to connectivity problems or overload 503 situation. 505 REQ. ARv03-33: The ALTO client protocol MUST use TCP based 506 transport. 508 REQ. ARv03-34: An ALTO server, which is operating close to its 509 capacity limit, MUST be able to inform clients about its impending 510 overload situation, and require them to throttle their query rate. 512 REQ. ARv03-35: An ALTO server, which is operating close to its 513 capacity limit, MUST be able to inform clients about its impending 514 overload situation, and redirect them to another ALTO server. 516 REQ. ARv03-36: An ALTO server, which is operating close to its 517 capacity limit, MUST be able to inform clients about its impending 518 overload situation, and terminate the conversation with the ALTO 519 client. 521 REQ. ARv03-37: An ALTO server, which is operating close to its 522 capacity limit, MUST be able to inform clients about its impending 523 overload situation, and reject new conversation attempts. 525 3.2. ALTO server discovery 527 The ALTO client protocol is supported by one or several ALTO server 528 discovery mechanisms, which will be used by ALTO clients in order to 529 find out where to send ALTO requests. 531 REQ. ARv03-38: ALTO clients which are embedded in the resource 532 consumer MUST be able to use the ALTO server discovery mechanism, in 533 order to find one or several ALTO servers that can provide ALTO 534 guidance suitable for the resource consumer. This mode of operation 535 is called "resource consumer initiated ALTO server discovery". 537 REQ. ARv03-39: ALTO clients which are embedded in a resource 538 directory and perform third-party ALTO queries on behalf of a remote 539 resource consumer MUST be able to use the ALTO server discovery 540 mechanism, in order to find one or several ALTO servers that can 541 provide ALTO guidance suitable for the respective resource consumer. 543 This mode of operation is called "third-party ALTO server discovery". 544 A classification and evaluation of architectural options for third- 545 party ALTO server discovery can be found in [I-D.kiesel-alto-3pdisc]. 547 REQ. ARv03-40: ALTO clients MUST be able to perform resource 548 consumer initiated ALTO server discovery, even if they are located 549 behind a network address translator (NAT). 551 REQ. ARv03-41: ALTO clients MUST be able to perform third-party ALTO 552 server discovery, even if they are located behind a network address 553 translator (NAT). 555 REQ. ARv03-42: ALTO clients MUST be able to perform third-party ALTO 556 server discovery, even if the resource consumer, on behalf of which 557 the ALTO query will be sent, is located behind a network address 558 translator (NAT). 560 REQ. ARv03-43: The ALTO server discovery mechanism may be specified 561 and provided using an existing protocol or mechanism, such as DNS, 562 DHCP, or PPP based automatic configuration, etc. These candidate 563 "base protocols" differ with respect to their availability in various 564 access network archtitectures and their suitability for third-party 565 queries. When evaluating different options this should be taken into 566 account, in order to limit the total number of ALTO server discovery 567 mechanisms that have to be specified for supporting a reasonably wide 568 range of deployment scenarios. 570 REQ. ARv03-44: The ALTO server discovery mechanism SHOULD be able to 571 return the respective contact information for several ALTO servers. 573 REQ. ARv03-45: The ALTO server discovery mechanism SHOULD be able to 574 indicate preferences for each returned ALTO server contact 575 information. 577 3.3. Security and privacy 579 REQ. ARv03-46: The ALTO client protocol MUST support mechanisms for 580 the authentication of ALTO servers. 582 REQ. ARv03-47: The ALTO client protocol MUST support mechanisms for 583 the authentication of ALTO clients. 585 REQ. ARv03-48: The ALTO client protocol MUST support different 586 levels of detail in queries and responses, in order for the operator 587 of an ALTO service to be able to control how much information (e.g., 588 about the network topology) is disclosed. 590 REQ. ARv03-49: The ALTO client protocol MUST support different 591 levels of detail in queries and responses, in order to protect the 592 privacy of users, to ensure that the operators of ALTO servers and 593 other users of the same application cannot derive sensitive 594 information. 596 REQ. ARv03-50: The ALTO client protocol SHOULD be defined in a way, 597 that the operator of one ALTO server cannot easily deduce the 598 resource identifier (e.g., file name in P2P file sharing) which the 599 resource consumer seeking ALTO guidance wants to access. 601 REQ. ARv03-51: The ALTO client protocol MUST include appropriate 602 mechanisms to protect the ALTO service against DoS attacks. 604 4. Host group descriptors 606 Host group descriptors are used in the ALTO client protocol to 607 describe the location of a host in the network topology. The ALTO 608 client protocol specification defines a basic set of host group 609 descriptor types, which have to be suported by all implementations, 610 and an extension procedure for adding new descriptor types (see 611 Section 3.1.2). The following list gives an overview on further host 612 group descriptor types that have been proposed in the past, or which 613 are in use by by ALTO-related prototype implementations. This list 614 is not intended as normative text. Instead, the only purpose of the 615 following list is to document the descriptor types that have been 616 proposed so far, and to solicit further feedback and discussion: 618 o Autonomous System (AS) number 620 o Protocol-specific group identifiers, which expand to a set of IP 621 address ranges (CIDR) and/or AS numbers. In one specific solution 622 proposal, these are called Partition ID (PID). 624 5. Rating criteria 626 Rating criteria are used in the ALTO client protocol to express 627 topology- or connectivity-related properties, which are evaluated in 628 order to generate the ALTO guidance. The ALTO client protocol 629 specification defines a basic set of rating criteria, which have to 630 be suported by all implementations, and an extension procedure for 631 adding new criteria (see Section 3.1.3). The following list gives an 632 overview on further rating criteria that have been proposed in the 633 past, or which are in use by by ALTO-related prototype 634 implementations. This list is not intended as normative text. 635 Instead, the only purpose of the following list is to document the 636 rating criteria that have been proposed so far, and to solicit 637 further feedback and discussion: 639 5.1. Distance-related rating criteria 641 o Relative topological distance: relative means that a larger 642 numerical value means greater distance, but it is up to the ALTO 643 service how to compute the values, and the ALTO client will not be 644 informed about the nature of the information. One way of 645 generating this kind of information MAY be counting AS hops, but 646 when querying this parameter, the ALTO client MUST NOT assume that 647 the numbers actually are AS hops. 649 o Absolute topological distance, expressed in the number of 650 traversed autonomous systems (AS). 652 o Absolute topological distance, expressed in the number of router 653 hops (i.e., how much the TTL value of an IP packet will be 654 decreased during transit). 656 o Absolute physical distance, based on knowledge of the approximate 657 geolocation (continent, country) of an IP address. 659 5.2. Charging-related rating criteria 661 o Traffic volume caps, in case the Internet access of the resource 662 consumer is not charged by "flat rate". For each candidate 663 resource provider, the ALTO service could indicate the amount of 664 data that may be transferred from/to this resource provider until 665 a given point in time, and how much of this amount has already 666 been consumed. Furthermore, it would have to be indicated how 667 excess traffic would be handled (e.g., blocked, throttled, or 668 charged separately at an indicated price). The interaction of 669 several applications running on a host, out of which some use this 670 criterion while others don't, as well as the evaluation of this 671 criterion in resource directories, which issue ALTO queries on 672 behalf of other peers, are for further study. 674 5.3. Performance-related rating criteria 676 The following rating criteria are subject to the remarks below. 678 o The minimum achievable throughput between the resource consumer 679 and the candidate resource provider, which is considered useful by 680 the application (only in ALTO queries), or 682 o An arbitrary upper bound for the throughput from/to the candidate 683 resource provider (only in ALTO replies). This may be, but is not 684 necessarily the provisioned access bandwidth of the candidate 685 resource provider. 687 o The maximum round-trip time (RTT) between resource consumer and 688 the candidate resource provider, which is acceptable for the 689 application for useful communication with the candidate resource 690 provider (only in ALTO queries), or 692 o An arbitrary lower bound for the RTT between resource consumer and 693 the candidate resource provider (only in ALTO replies). This may 694 be, for example, based on measurements of the propagation delay in 695 a completely unloaded network. 697 The ALTO client MUST be aware, that with high probability, the actual 698 performance values differ significantly from these upper and lower 699 bounds. In particular, an ALTO client MUST NOT consider the "upper 700 bound for throughput" parameter as a permission to send data at the 701 indicated rate without using congestion control mechanisms. 703 The discrepancies are due to various reasons, including, but not 704 limited to the facts that 706 o the ALTO service is not an admission control system 708 o the ALTO service may not know the instantaneous congestion status 709 of the network 711 o the ALTO service may not know all link bandwidths, i.e., where the 712 bottleneck really is, and there may be shared bottlenecks 714 o the ALTO service may not know whether the candidate peer itself is 715 overloaded 717 o the ALTO service may not know whether the candidate peer throttles 718 the bandwidth it devotes for the considered application 720 o the ALTO service may not know whether the candidate peer will 721 throttle the data it sends to us (e.g., because of some fairness 722 algorithm, such as tit-for-tat) 724 Because of these inaccuracies and the lack of complete, instantaneous 725 state information, which are inherent to the ALTO service, the 726 application must use other mechanisms (such as passive measurements 727 on actual data transmissions) to assess the currently achievable 728 throughput, and it MUST use appropriate congestion control mechanisms 729 in order to avoid a congestion collapse. Nevertheless, these rating 730 criteria may provide a useful shortcut for quickly excluding 731 candidate resource providers from such probing, if it is known in 732 advance that connectivity is in any case worse than what is 733 considered the minimum useful value by the respective application. 735 5.4. Inappropriate rating criteria 737 Rating criteria that SHOULD NOT be defined for and used by the ALTO 738 service include: 740 o Performance metrics that are closely related to the instantaneous 741 congestion status. The definition of alternate approaches for 742 congestion control is explicitly out of the scope of ALTO. 743 Instead, other appropriate means, such as using TCP based 744 transport, have to be used to avoid congestion. 746 6. IANA Considerations 748 This requirements document does not mandate any immediate IANA 749 actions. However, such IANA considerations may arise from future 750 ALTO specification documents which try to meet the requirements given 751 here. 753 7. Security Considerations 755 7.1. High-level security considerations 757 High-level security considerations for the ALTO service can be found 758 in the "Security Considerations" section of the ALTO problem 759 statement document [RFC5693]. 761 7.2. Classification of information disclosure scenarios 763 The unwanted disclosure of information is one key concern related to 764 ALTO. The following list gives a classification of information 765 disclosure scenarios, which may be considered more or less critical 766 by different parties: 768 o (1) Excess disclosure of ALTO server operator's data to an 769 authorized ALTO client. The operator of an ALTO server has to 770 feed information, such as tables mapping host group descriptors to 771 host characteristics attributes, into the server, thereby enabling 772 it to give guidance to ALTO clients. Some operators might 773 consider the full set of this information confidential (e.g., a 774 detailed map of the operator's network topology), and might want 775 to disclose only a subset of it or somehow obfuscated information 776 to an ALTO client. 778 o (2) Disclosure of the application behavior to the ALTO server. 779 The operator of an ALTO server could infer the application 780 behavior (e.g., content identifiers in P2P file sharing 781 applications, or lists of resource providers that are considered 782 for establishing a connection) from the ALTO queries sent by an 783 ALTO client. 785 o (3) Disclosure of ALTO server operator's data (e.g., network 786 topology information) to an unauthorized third party. There are a 787 couple of sub-cases here: 789 * (3a) An ALTO server sends the information directly to an 790 unauthorized ALTO client. 792 * (3b) An unauthorized party snoops on the data transmission from 793 the ALTO server to an authorized ALTO client. 795 * (3c) An authorized ALTO client knowingly forwards the 796 information it had received from the ALTO server to an 797 unauthorized party. 799 o (4) Disclosure of the application behavior to an unauthorized 800 third party. 802 o (5) Excess retrieval of ALTO server operator's data by 803 collaborating ALTO clients. Several authorized ALTO clients could 804 ask an ALTO server for guidance, and redistribute the replies 805 among each other (see also case 3c). By correlating the ALTO 806 replies they could find out more information than intended to be 807 disclosed by the ALTO server operator. 809 (1) may be addressed by the ALTO server operator choosing the level 810 of detail of the information to be populated into the ALTO server. 811 Furhermore, access control mechanisms for filtering ALTO replies 812 according to the authenticated ALTO client identity might be 813 installed in the ALTO server, although this might not be effective 814 given the lack of efficient mechanisms for addressing (3c) and (5), 815 see below. 817 (2) is addressed by allowing ALTO clients to use the target- 818 independent query mode. In this mode of operation, guiding 819 information (e.g., "maps") is retrieved from the ALTO server and used 820 entirely locally by the ALTO client, i.e., without sending host 821 location attributes of candidate resource providers to the ALTO 822 server. In the target-aware query mode, (2) can be addressed by ALTO 823 clients by obfuscating the identity of candidate resource consumers, 824 e.g., by zeroing-out or randomizing the last few bits of the IP 825 addresses. However, there is the potential side effect of yielding 826 inaccurate results. 828 (3a), (3b), and (4) may be addressed by authentication, access 829 control, and encryption schemes for the ALTO client protocol. 830 However, deployment of encryption schemes might not be effective 831 given the lack of efficient mechanisms for addressing (3c) and (5), 832 see below. 834 Straightforward authentication and encryption schemes won't help 835 solving (3c) and (5), and there is no other simple and efficient 836 mechanism known. The cost of complex approaches, e.g., based on 837 digital rights management (DRM), might easily outweigh the benefits 838 of the whole ALTO solution, and therefore they are not considered as 839 a viable solution. That is, ALTO server operators must be aware that 840 (3c) and (5) cannot be prevented from happening, and therefore they 841 should feed only such data into an ALTO server, which they do not 842 consider sensitive with respect to (3c) and (5). 844 These insights are reflected by the requirements presented in this 845 document. 847 7.3. Security requirements 849 For a set of specific security requirements please refer to 850 Section 3.3 of this document. 852 8. References 854 8.1. Normative References 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, March 1997. 859 8.2. Informative References 861 [ALTO-charter] 862 Marocco, E. and V. Gurbani, "Application-Layer Traffic 863 Optimization (ALTO) Working Group Charter", February 2009. 865 [I-D.kiesel-alto-3pdisc] 866 Kiesel, S. and M. Tomsu, "Third-party ALTO server 867 discovery", draft-kiesel-alto-3pdisc-00 (work in 868 progress), August 2009. 870 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 871 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 872 RFC 4787, January 2007. 874 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 875 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 876 RFC 5382, October 2008. 878 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 879 Optimization (ALTO) Problem Statement", RFC 5693, 880 October 2009. 882 Appendix A. Contributors 884 The authors were supported by the following people, who have 885 contributed to this document: 887 o Richard Alimi 889 o Zoran Despotovic 891 o Jason Livingood 893 o Saverio Niccolini 895 o Jan Seedorf 897 o Martin Stiemerling 899 The authors would like to thank the members of the P2PI and ALTO 900 mailing lists for their feedback. 902 Appendix B. Acknowledgments 904 The authors would like to thank 906 o Vijay K. Gurbani 908 o Enrico Marocco 910 for fostering discussions that lead to the creation of this document, 911 and for giving valuable comments on it. 913 Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin 914 Stiemerling were partially supported by the NAPA-WINE project 915 (Network-Aware P2P-TV Application over Wise Networks, 916 http://www.napa-wine.org), a research project supported by the 917 European Commission under its 7th Framework Program (contract no. 918 214412). The views and conclusions contained herein are those of the 919 authors and should not be interpreted as necessarily representing the 920 official policies or endorsements, either expressed or implied, of 921 the NAPA-WINE project or the European Commission. 923 Laird Popkin and Y. Richard Yang are grateful to the many 924 contributions made by the members of the P4P working group and Yale 925 Laboratory of Networked Systems. The P4P working group is hosted by 926 DCIA. 928 Authors' Addresses 930 Sebastian Kiesel (editor) 931 NEC Europe Ltd., Network Laboratories Europe 932 Kurfuersten-Anlage 36 933 Heidelberg 69115 934 Germany 936 Email: ietf-alto@skiesel.de 938 Laird Popkin 939 Pando Networks, Inc. 941 Email: laird@pando.com 943 Stefano Previdi 944 Cisco Systems, Inc. 946 Email: sprevidi@cisco.com 948 Richard Woundy 949 Comcast Corporation 951 Email: Richard_Woundy@cable.comcast.com 953 Yang Richard Yang 954 Yale University 956 Email: yry@cs.yale.edu