idnits 2.17.1 draft-ietf-alto-reqs-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 15, 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 March 14, 2011 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-08.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. 37 Status of this Memo 39 This Internet-Draft is submitted 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). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 15, 2011. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology and Architectural Framework . . . . . . . . . . . 5 73 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 74 2.2. ALTO Terminology . . . . . . . . . . . . . . . . . . . . . 5 75 2.3. Architectural Framework for ALTO . . . . . . . . . . . . . 6 76 3. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 7 77 3.1. ALTO Client Protocol . . . . . . . . . . . . . . . . . . . 7 78 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 7 79 3.1.2. Host Group Descriptor Support . . . . . . . . . . . . 7 80 3.1.3. Rating Criteria Support . . . . . . . . . . . . . . . 8 81 3.1.4. Placement of Entities and Timing of Transactions . . . 10 82 3.1.5. Protocol Extensibility . . . . . . . . . . . . . . . . 12 83 3.1.6. Error Handling and Overload Protection . . . . . . . . 12 84 3.2. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 12 85 3.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 13 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 5.1. High-level security considerations . . . . . . . . . . . . 16 89 5.2. Information Disclosure Scenarios . . . . . . . . . . . . . 16 90 5.2.1. Classification of Information Disclosure Scenarios . . 16 91 5.2.2. Discussion of Information Disclosure Scenarios . . . . 17 92 5.3. Security Requirements . . . . . . . . . . . . . . . . . . 18 93 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 95 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 96 Appendix A. Contributors List and Acknowledgments . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 The motivation for Application-Layer Traffic Optimization (ALTO) is 102 described in the ALTO problem statement [RFC5693]. 104 The goal of ALTO is to provide information which can help peer-to- 105 peer (P2P) applications to make better decisions with respect to peer 106 selection. However, ALTO may be useful for non-P2P applications as 107 well. For example, clients of client-server applications may use 108 information provided by ALTO to select one of several servers or 109 information replicas. As another example, ALTO information could be 110 used to select a media relay needed for NAT traversal. The goal of 111 these informed decisions is to improve performance (or Quality of 112 Experience) in the application while reducing resource consumption in 113 the underlying network infrastructure. 115 Usually, it would be difficult or even impossible for application 116 entities to acquire this information by other mechanisms (e.g., using 117 measurements between the peers of a P2P overlay), because of 118 complexity or because it is based on network topology information, 119 network operational costs, or network policies, which the respective 120 network provider does not want to disclose in detail. 122 The logical entities that provide the ALTO service do not take part 123 in the actual user data transport, i.e., they do not implement 124 functions for relaying user data. They may be placed on various 125 kinds of physical nodes, e.g., on dedicated servers, as auxiliary 126 processes in routers, on "trackers" or "super peers" of a P2P 127 application, etc. 129 2. Terminology and Architectural Framework 131 2.1. Requirements Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2.2. ALTO Terminology 139 This document uses the following ALTO-related terms, which are 140 defined in [RFC5693]: 142 Application, Peer, P2P, Resource, Resource Identifier, Resource 143 Provider, Resource Consumer, Transport Address, Overlay Network, 144 Resource Directory, ALTO Service, ALTO Server, ALTO Client, ALTO 145 Query, ALTO Response, ALTO Transaction, Local Traffic, Peering 146 Traffic, Transit Traffic, Application protocol, ALTO Client Protocol, 147 Provisioning protocol. 149 Furthermore, the following additional terms will be used: 151 o Host Group Descriptor: Information used to describe the resource 152 consumer which seeks ALTO guidance, or one or several candidate 153 resource providers. This can be, for example, a single IP 154 address, an address prefix or address range that contains the 155 host(s), or an autonomous system (AS) number. Different options 156 may provide different levels of detail. Depending on the system 157 architecture, this may have implications on the quality of the 158 guidance ALTO is able to provide, on whether recommendations can 159 be aggregated, and on how much privacy-sensitive information about 160 users might be disclosed to additional parties. 162 o Host Characteristics Attribute: Properties of a host (other than 163 the host group descriptor), in particular related to its 164 attachment to the network. This information may be stored in the 165 ALTO server and transmitted in the ALTO protocol. It may be 166 evaluated according to the rating criteria. 168 o Rating Criterion: The condition or relation that defines the 169 "better" in "better-than-random peer selection", which is the 170 ultimate goal of ALTO. Examples may include "host's Internet 171 access is not subject to volume based charging (flat rate)" or 172 "low topological distance". Some rating criteria, such as "low 173 topological distance", need to include a reference point, i. e., 174 "low topological distance from a given resource consumer", which 175 can be described by means of a host group descriptor. 177 2.3. Architectural Framework for ALTO 179 There are various architectural options for how ALTO could be 180 implemented, and specifying or mandating one specific architecture is 181 out of the scope of this document. 183 The ALTO Working Group Charter [ALTO-charter] itemizes several key 184 components, which shall be elaborated and specified by the ALTO 185 Working Group. The ALTO problem statement [RFC5693] defines a 186 terminology (see Section 2.2) and presents a figure that gives a 187 high-level overview of protocol interaction between ALTO elements. 189 This document itemizes requirements for the following components and 190 information elements that are part of the above-mentioned 191 architecture: 193 o The ALTO client protocol, which is used for sending ALTO queries 194 and ALTO responses between ALTO client and ALTO server. 196 o The discovery mechanism, which will be used by ALTO clients in 197 order to find out where to send ALTO requests. 199 o The overall architecture, especially with respect to security and 200 privacy issues. 202 o Host group descriptors, which are used to describe the location of 203 a host in the network topology. 205 o Rating criteria, i. e., conditions or relations that shall be 206 evaluated in order to generate the ALTO guidance. 208 3. ALTO Requirements 210 3.1. ALTO Client Protocol 212 3.1.1. General Requirements 214 REQ. ARv08-1: The ALTO service is provided by one or more ALTO 215 servers. ALTO servers MUST implement the ALTO client protocol, for 216 receiving ALTO queries from ALTO clients and for sending the 217 corresponding ALTO responses. 219 REQ. ARv08-2: ALTO clients MUST implement the ALTO client protocol, 220 for sending ALTO queries to ALTO servers and for receiving the 221 corresponding ALTO responses. 223 REQ. ARv08-3: The format of the ALTO query message MUST allow the 224 ALTO client to solicit guidance for selecting appropriate resource 225 providers. 227 REQ. ARv08-4: The format of the ALTO response message MUST allow the 228 ALTO server to express its guidance for selecting appropriate 229 resource providers. 231 REQ. ARv08-5: The detailed specification of a protocol is out of the 232 scope of this document. However, any protocol specification that 233 claims to implement the ALTO client protocol MUST be compliant to the 234 requirements itemized in this document. 236 3.1.2. Host Group Descriptor Support 238 The ALTO guidance is based on the evaluation of several resource 239 providers or groups of resource providers, which are characterized by 240 means of host group descriptors, considering one or more rating 241 criteria. 243 REQ. ARv08-6: The ALTO client protocol MUST support the usage of 244 several different host group descriptor types. 246 REQ. ARv08-7: The ALTO client protocol specification MUST define a 247 basic set of host group descriptor types, which MUST be supported by 248 all implementations of the ALTO client protocol. 250 REQ. ARv08-8: The ALTO client protocol MUST support the host group 251 descriptor types "IPv4 address prefix" and "IPv6 address prefix". 252 They can be used to specify the IP address of one host, or an IP 253 address range (in CIDR notation), which contains all hosts in 254 question. It is also possible to specify a broader address range 255 (i.e., a shorter prefix length) than the intended group of hosts 256 actually uses, in order to conceal their exact identity. 258 REQ. ARv08-9: The ALTO client protocol specification MUST define an 259 appropriate procedure for adding new host group descriptor types, 260 e.g., by establishing an IANA registry. 262 REQ. ARv08-10: ALTO clients and ALTO servers MUST clearly identify 263 the type of each host group descriptor sent in ALTO queries or 264 responses. 266 REQ. ARv08-11: For host group descriptor types other than "IPv4 267 address prefix" and "IPv6 address prefix", the host group descriptor 268 type identification MUST be supplemented by a reference to a 269 facility, which can be used to translate host group descriptors of 270 that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping 271 table or an algorithm. 273 REQ. ARv08-12: Protocol functions for mapping other host group 274 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 275 specified as part of the ALTO client protocol, and the corresponding 276 address mapping information SHOULD be made available by the same 277 entity that wants to use these host group descriptors within the ALTO 278 client protocol. However, an ALTO server or an ALTO client MAY also 279 send a reference to an external mapping facility, e.g., a translation 280 table to be downloaded as file via HTTP. 282 REQ. ARv08-13: The ALTO client protocol specification MUST define 283 mechanisms, which can be used by the ALTO server to indicate that a 284 host group descriptor used by the ALTO client is of an unsupported 285 type, or that the indicated mapping mechanism could not be used. 287 REQ. ARv08-14: The ALTO client protocol specification MUST define 288 mechanisms, which can be used by the ALTO client to indicate that a 289 host group descriptor used by the ALTO server is of an unsupported 290 type, or that the indicated mapping mechanism could not be used. 292 3.1.3. Rating Criteria Support 294 REQ. ARv08-15: The ALTO client protocol MUST support the usage of 295 several different rating criteria types. 297 REQ. ARv08-16: The ALTO client protocol specification MUST define a 298 basic set of rating criteria types, which MUST be supported by all 299 implementations of the ALTO client protocol. 301 REQ. ARv08-17: The ALTO client protocol specification MUST define a 302 rating criterion that can be used to express and evaluate the 303 "relative operator's preference." This is a relative measure, i.e., 304 it is not associated with any unit of measurement. A more-preferred 305 rating according to this criterion indicates that the application 306 should prefer the respective candidate resource provider over others 307 with less-preferred ratings (unless information from non-ALTO sources 308 suggests a different choice, such as transmission attempts suggesting 309 that the path is currently congested). The operator of the ALTO 310 server does not have to disclose how and based on which data the 311 ratings are actually computed. Examples could be: cost for peering 312 or transit traffic, traffic engineering inside the network, and other 313 policies. 315 REQ. ARv08-18: The ALTO client protocol specification MUST define an 316 appropriate procedure for adding new rating criteria types, e.g., by 317 establishing an IANA registry. 319 REQ. ARv08-19: ALTO client protocol specifications MUST NOT define 320 rating criteria closely related to the instantaneous network 321 congestion state, whose primary aim is to serve an alternative to 322 established congestion control strategies, such as using TCP-based 323 transport. 325 One design assumption for ALTO is that it is acceptable that the 326 host characteristics attributes, which are stored and processed in 327 the ALTO servers for giving the guidance, are updated rather 328 infrequently. Typical update intervals may be several orders of 329 magnitude longer than the typical network-layer packet round-trip 330 time (RTT). Therefore, ALTO cannot be a replacement for TCP-like 331 congestion control mechanisms. The definition of alternate 332 approaches for congestion control is explicitly a non-goal for the 333 ALTO working group [ALTO-charter]. 335 REQ. ARv08-20: Applications using ALTO guidance MUST NOT rely on the 336 ALTO guidance to avoid network congestion. Instead, applications 337 MUST use other appropriate means, such as TCP based transport, to 338 avoid causing excessive congestion. 340 REQ. ARv08-21: The ALTO query message SHOULD allow the ALTO client 341 to express which rating criteria should be considered, as well as 342 their relative relevance for the specific application that will 343 eventually make use of the guidance. 345 REQ. ARv08-22: The ALTO response message SHOULD allow the ALTO 346 server to express which rating criteria have been considered when 347 generating the response. 349 REQ. ARv08-23: The ALTO client protocol specification MUST define 350 mechanisms, which can be used by the ALTO client and the ALTO server 351 to indicate that a rating criteria used by the other party is of an 352 unsupported type. 354 3.1.4. Placement of Entities and Timing of Transactions 356 With respect to the placement of ALTO clients, several modes of 357 operation exist: 359 o One mode of ALTO operation is that an ALTO client may be embedded 360 directly in the resource consumer, i.e., the application protocol 361 entity that will eventually initiate data transmission to/from the 362 selected resource provider(s) in order to access the desired 363 resource. For example, an ALTO client could be integrated into 364 the peer of a P2P application that uses a distributed algorithm 365 such as "query flooding" for resource discovery. 367 o Another mode of operation is to integrate the ALTO client into a 368 third party such as a resource directory, which may issue ALTO 369 queries to solicit preference on potential resource providers, 370 considering the respective resource consumer. For example, an 371 ALTO client could be integrated into the tracker of a tracker- 372 based P2P application, in order to request ALTO guidance on behalf 373 of the peers contacting the tracker. 375 REQ. ARv08-24: The ALTO client protocol MUST support the mode of 376 operation in which the ALTO client is directly embedded in the 377 resource consumer. 379 REQ. ARv08-25: The ALTO client protocol MUST support the mode of 380 operation in which the ALTO client is embedded in a third party, 381 which performs queries on behalf of resource consumers. 383 REQ. ARv08-26: The ALTO client protocol MUST be designed in a way 384 that the ALTO service can be provided by an entity which is not the 385 operator of the IP access network. 387 REQ. ARv08-27: The ALTO client protocol MUST be designed in a way 388 that different instances of the ALTO service operated by different 389 providers can coexist. 391 With respect to the timing of ALTO queries, several modes of 392 operation exist: 394 o In target-aware query mode, an ALTO client performs the ALTO query 395 when the desired resource and a set of candidate resource 396 providers are already known, i. e., after DHT lookups, queries to 397 the resource directory, etc. 399 o In target-independent query mode, ALTO queries are performed in 400 advance or periodically, in order to receive comprehensive, 401 "target-independent" guidance, which will be cached locally and 402 evaluated later, when a resource is to be accessed. 404 REQ. ARv08-28: The ALTO client protocol MUST support at least one of 405 these two modes, either the target-aware or the target-independent 406 query mode. 408 REQ. ARv08-29: The ALTO client protocol SHOULD support both the 409 target-aware and the target-independent query mode. 411 REQ. ARv08-30: The ALTO client protocol SHOULD support lifetime 412 attributes, to enable caching of recommendations at ALTO clients. 414 REQ. ARv08-31: The ALTO client protocol SHOULD specify an aging 415 mechanism, which allows to give newer recommendations precedence over 416 older ones. 418 REQ. ARv08-32: The ALTO client protocol SHOULD allow the ALTO server 419 to add information about appropriate modes of re-use to its ALTO 420 responses. Re-use may include redistributing an ALTO response to 421 other parties, as well as using the same ALTO information in a 422 resource directory to improve the responses to different resource 423 consumers, within the specified lifetime of the ALTO response. The 424 ALTO server SHOULD be able to express that 426 o no re-use should occur 428 o re-use is appropriate for a specific "target audience", i.e., a 429 set of resource consumers explicitly defined by a list of host 430 group descriptors. The ALTO server MAY specify a "target 431 audience" in the ALTO response, which is only a subset of the 432 known actual "target audience", e.g., if required by operator 433 policies 435 o re-use is appropriate for any resource consumer that would send 436 (or cause a third party sending on behalf of it) the same ALTO 437 query (i.e., with the same query parameters, except for the 438 resource consumer ID, if applicable) to this ALTO server 440 o re-use is appropriate for any resource consumer that would send 441 (or cause a third party sending on behalf of it) the same ALTO 442 query (i.e., with the same query parameters, except for the 443 resource consumer ID, if applicable) to any other ALTO server, 444 which was discovered (using an ALTO discovery mechanism) together 445 with this ALTO server 447 o re-use is appropriate for any resource consumer that would send 448 (or cause a third party sending on behalf of it) the same ALTO 449 query (i.e., with the same query parameters, except for the 450 resource consumer ID, if applicable) to any ALTO server in the 451 whole network 453 REQ. ARv08-33: The ALTO client protocol MUST support scenarios with 454 the ALTO client located in the private address realm behind a network 455 address translator (NAT). There are different types of NAT, see 456 [RFC4787] and [RFC5382]. 458 3.1.5. Protocol Extensibility 460 REQ. ARv08-34: The ALTO client protocol MUST include support for 461 adding protocol extensions in a non-disruptive, backward-compatible 462 way. 464 REQ. ARv08-35: The ALTO client protocol MUST include protocol 465 versioning support, in order to clearly distinguish between 466 incompatible versions of the protocol. 468 3.1.6. Error Handling and Overload Protection 470 REQ. ARv08-36: The ALTO client protocol MUST use TCP based 471 transport. 473 REQ. ARv08-37: An ALTO server, which is operating close to its 474 capacity limit, MUST be able to inform clients about its impending 475 overload situation, and require them to throttle their query rate. 477 REQ. ARv08-38: An ALTO server, which is operating close to its 478 capacity limit, MUST be able to inform clients about its impending 479 overload situation, and redirect them to another ALTO server. 481 REQ. ARv08-39: An ALTO server, which is operating close to its 482 capacity limit, MUST be able to inform clients about its impending 483 overload situation, and terminate the conversation with the ALTO 484 client. 486 REQ. ARv08-40: An ALTO server, which is operating close to its 487 capacity limit, MUST be able to inform clients about its impending 488 overload situation, and reject new conversation attempts. 490 3.2. ALTO Server Discovery 492 The ALTO client protocol is supported by one or several ALTO server 493 discovery mechanisms, which may be used by ALTO clients in order to 494 determine one or more ALTO servers to which ALTO requests can be sent 495 REQ. ARv08-41: ALTO clients which are embedded in the resource 496 consumer MUST be able to use an ALTO server discovery mechanism, in 497 order to find one or several ALTO servers that can provide ALTO 498 guidance suitable for the resource consumer. This mode of operation 499 is called "resource consumer initiated ALTO server discovery". 501 REQ. ARv08-42: ALTO clients which are embedded in a resource 502 directory and perform third-party ALTO queries on behalf of a remote 503 resource consumer MUST be able to use an ALTO server discovery 504 mechanism, in order to find one or several ALTO servers that can 505 provide ALTO guidance suitable for the respective resource consumer. 506 This mode of operation is called "third-party ALTO server discovery". 508 REQ. ARv08-43: ALTO clients MUST be able to perform resource 509 consumer initiated ALTO server discovery, even if they are located 510 behind a network address translator (NAT). 512 REQ. ARv08-44: ALTO clients MUST be able to perform third-party ALTO 513 server discovery, even if they are located behind a network address 514 translator (NAT). 516 REQ. ARv08-45: ALTO clients MUST be able to perform third-party ALTO 517 server discovery, even if the resource consumer, on behalf of which 518 the ALTO query will be sent, is located behind a network address 519 translator (NAT). 521 REQ. ARv08-46: ALTO server discovery mechanisms SHOULD leverage an 522 existing protocol or mechanism, such as DNS, DHCP, or PPP based 523 automatic configuration, etc. A single mechanism with a broad 524 spectrum of applicability SHOULD be preferred over several different 525 mechanisms with narrower scopes. 527 REQ. ARv08-47: Every ALTO server discovery mechanism SHOULD be able 528 to return the respective contact information for multiple ALTO 529 servers. 531 REQ. ARv08-48: Every ALTO server discovery mechanism SHOULD be able 532 to indicate preferences for each returned ALTO server contact 533 information. 535 3.3. Security and Privacy 537 REQ. ARv08-49: The ALTO client protocol MUST support mechanisms for 538 the authentication of ALTO servers. 540 REQ. ARv08-50: The ALTO client protocol MUST support mechanisms for 541 the authentication of ALTO clients. 543 REQ. ARv08-51: The ALTO client protocol MUST support mechanisms for 544 the encryption of messages. 546 REQ. ARv08-52: The ALTO client protocol MUST support different 547 levels of detail in queries and responses, in order for the operator 548 of an ALTO service to be able to control how much information (e.g., 549 about the network topology) is disclosed. 551 REQ. ARv08-53: The operator of an ALTO server MUST NOT assume that 552 an ALTO client will implement mechanisms or comply with rules that 553 limit the ALTO client's ability to redistribute information retrieved 554 from the ALTO server to third parties. 556 REQ. ARv08-54: The ALTO client protocol MUST support different 557 levels of detail in queries and responses, in order to protect the 558 privacy of users, to ensure that the operators of ALTO servers and 559 other users of the same application cannot derive sensitive 560 information. 562 REQ. ARv08-55: The ALTO client protocol SHOULD be defined in a way, 563 that the operator of one ALTO server cannot easily deduce the 564 resource identifier (e.g., file name in P2P file sharing) which the 565 resource consumer seeking ALTO guidance wants to access. 567 REQ. ARv08-56: The ALTO client protocol MUST support appropriate 568 mechanisms to protect the ALTO service against DoS attacks. 570 4. IANA Considerations 572 This requirements document does not mandate any immediate IANA 573 actions. However, such IANA considerations may arise from future 574 ALTO specification documents which try to meet the requirements given 575 here. 577 5. Security Considerations 579 5.1. High-level security considerations 581 High-level security considerations for the ALTO service can be found 582 in the "Security Considerations" section of the ALTO problem 583 statement document [RFC5693]. 585 5.2. Information Disclosure Scenarios 587 The unwanted disclosure of information is one key concern related to 588 ALTO. This section presents a classification and discussion of 589 information disclosure scenarios and potential countermeasures. 591 5.2.1. Classification of Information Disclosure Scenarios 593 o (1) Excess disclosure of ALTO server operator's data to an 594 authorized ALTO client. The operator of an ALTO server has to 595 feed information, such as tables mapping host group descriptors to 596 host characteristics attributes, into the server, thereby enabling 597 it to give guidance to ALTO clients. Some operators might 598 consider the full set of this information confidential (e.g., a 599 detailed map of the operator's network topology), and might want 600 to disclose only a subset of it or somehow obfuscated information 601 to an ALTO client. 603 o (2) Disclosure of the application behavior to the ALTO server. 604 The operator of an ALTO server could infer the application 605 behavior (e.g., content identifiers in P2P file sharing 606 applications, or lists of resource providers that are considered 607 for establishing a connection) from the ALTO queries sent by an 608 ALTO client. 610 o (3) Disclosure of ALTO server operator's data (e.g., network 611 topology information) to an unauthorized third party. There are a 612 three sub-cases here: 614 * (3a) An ALTO server sends the information directly to an 615 unauthorized ALTO client. 617 * (3b) An unauthorized party snoops on the data transmission from 618 the ALTO server to an authorized ALTO client. 620 * (3c) An authorized ALTO client knowingly forwards the 621 information it had received from the ALTO server to an 622 unauthorized party. 624 o (4) Disclosure of the application behavior to an unauthorized 625 third party. 627 o (5) Excess retrieval of ALTO server operator's data by 628 collaborating ALTO clients. Several authorized ALTO clients could 629 ask an ALTO server for guidance, and redistribute the responses 630 among each other (see also case 3c). By correlating the ALTO 631 responses they could find out more information than intended to be 632 disclosed by the ALTO server operator. 634 5.2.2. Discussion of Information Disclosure Scenarios 636 Scenario (1) may be addressed by the ALTO server operator choosing 637 the level of detail of the information to be populated into the ALTO 638 server. Furthermore, access control mechanisms for filtering ALTO 639 responses according to the authenticated ALTO client identity might 640 be installed in the ALTO server, although this might not be effective 641 given the lack of efficient mechanisms for addressing (3c) and (5), 642 see below. 644 (2) can and needs to be addressed in several ways: If the ALTO client 645 is embedded in the resource consumer, the resource consumer's IP 646 address (or the "public" IP address of the outermost NAT in front of 647 the resource consumer) is disclosed to the ALTO server as a matter of 648 principle, because it is in the source address fields of the IP 649 headers. By using a proxy, the disclosure of source addresses to the 650 ALTO server can be avoided at the cost of disclosing them to said 651 proxy. If, in contrast, the ALTO client is embedded in a third party 652 (e.g., a resource directory) which issues ALTO requests on behalf of 653 resource consumers, it is possible to hide the exact addresses of the 654 resource consumers from the ALTO server, e.g., by zeroing-out or 655 randomizing the last few bits of the IP addresses. However, there is 656 the potential side effect of yielding inaccurate results. 658 The disclosure of candidate resource providers' addresses to the ALTO 659 server can be avoided by allowing ALTO clients to use the target- 660 independent query mode. In this mode of operation, guiding 661 information (e.g., "maps") is retrieved from the ALTO server and used 662 entirely locally by the ALTO client, i.e., without sending host 663 location attributes of candidate resource providers to the ALTO 664 server. In the target-aware query mode, this issue can be addressed 665 by ALTO clients by obfuscating the identity of candidate resource 666 consumers, e.g., by zeroing-out or randomizing the last few bits of 667 the IP addresses. However, there is the potential side effect of 668 yielding inaccurate results. 670 (3a), (3b), and (4) may be addressed by authentication, access 671 control, and encryption schemes for the ALTO client protocol. 673 However, deployment of encryption schemes might not be effective 674 given the lack of efficient mechanisms for addressing (3c) and (5), 675 see below. 677 Straightforward authentication and encryption schemes will not help 678 solving (3c) and (5), and there is no other simple and efficient 679 mechanism known. The cost of complex approaches, e.g., based on 680 digital rights management (DRM), might easily outweigh the benefits 681 of the whole ALTO solution, and therefore they are not considered as 682 a viable solution. That is, ALTO server operators must be aware that 683 (3c) and (5) cannot be prevented from happening, and therefore they 684 should feed only such data into an ALTO server, which they do not 685 consider sensitive with respect to (3c) and (5). 687 These insights are reflected in the requirements in this document. 689 5.3. Security Requirements 691 For a set of specific security requirements please refer to 692 Section 3.3 of this document. 694 6. References 696 6.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 6.2. Informative References 703 [ALTO-charter] 704 Marocco, E. and V. Gurbani, "Application-Layer Traffic 705 Optimization (ALTO) Working Group Charter", February 2009. 707 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 708 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 709 RFC 4787, January 2007. 711 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 712 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 713 RFC 5382, October 2008. 715 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 716 Optimization (ALTO) Problem Statement", RFC 5693, 717 October 2009. 719 Appendix A. Contributors List and Acknowledgments 721 The initial version of this document was co-authored by Laird Popkin. 723 The authors would like to thank 725 o Vijay K. Gurbani 727 o Enrico Marocco 729 for fostering discussions that lead to the creation of this document, 730 and for giving valuable comments on it. 732 The authors were supported by the following people, who have 733 contributed to this document: 735 o Richard Alimi 737 o Zoran Despotovic 739 o Jason Livingood 741 o Saverio Niccolini 743 o Michael Scharf 745 o Nico Schwan 747 o Jan Seedorf 749 The authors would like to thank the members of the P2PI and ALTO 750 mailing lists for their feedback. 752 Laird Popkin and Y. Richard Yang are grateful to the many 753 contributions made by the members of the P4P working group and Yale 754 Laboratory of Networked Systems. The P4P working group is hosted by 755 DCIA. 757 Martin Stiemerling, Saverio Niccolini, and Jan Seedorf are partially 758 supported by the NAPA-WINE project (Network-Aware P2P-TV Application 759 over Wise Networks, http://www.napa-wine.org), a research project 760 supported by the European Commission under its 7th Framework Program 761 (contract no. 214412). The views and conclusions contained herein 762 are those of the authors and should not be interpreted as necessarily 763 representing the official policies or endorsements, either expressed 764 or implied, of the NAPA-WINE project or the European Commission. 766 Authors' Addresses 768 Sebastian Kiesel (editor) 769 University of Stuttgart Computing Center 770 Networks and Communication Systems Department 771 Allmandring 30 772 70550 Stuttgart 773 Germany 775 Email: ietf-alto@skiesel.de 776 URI: http://www.rus.uni-stuttgart.de/nks/ 778 Stefano Previdi 779 Cisco Systems, Inc. 781 Email: sprevidi@cisco.com 783 Martin Stiemerling 784 NEC Laboratories Europe/University of Goettingen 786 Email: martin.stiemerling@neclab.eu 787 URI: http://ietf.stiemerling.org 789 Richard Woundy 790 Comcast Corporation 792 Email: Richard_Woundy@cable.comcast.com 794 Yang Richard Yang 795 Yale University 797 Email: yry@cs.yale.edu