idnits 2.17.1 draft-ietf-alto-reqs-10.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 (June 10, 2011) is 4704 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: December 12, 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 June 10, 2011 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-10.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 specifying, assessing, or 34 comparing protocols and implementations. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 12, 2011. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology and Architectural Framework . . . . . . . . . . . 5 72 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 73 2.2. ALTO Terminology . . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Architectural Framework for ALTO . . . . . . . . . . . . . 6 75 3. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1. ALTO Client Protocol . . . . . . . . . . . . . . . . . . . 7 77 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 7 78 3.1.2. Host Group Descriptor Support . . . . . . . . . . . . 7 79 3.1.3. Rating Criteria Support . . . . . . . . . . . . . . . 8 80 3.1.4. Placement of Entities and Timing of Transactions . . . 9 81 3.1.5. Protocol Extensibility . . . . . . . . . . . . . . . . 12 82 3.1.6. Error Handling and Overload Protection . . . . . . . . 12 83 3.2. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 12 84 3.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 13 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 5.1. High-level security considerations . . . . . . . . . . . . 16 88 5.2. Information Disclosure Scenarios . . . . . . . . . . . . . 16 89 5.2.1. Classification of Information Disclosure Scenarios . . 16 90 5.2.2. Discussion of Information Disclosure Scenarios . . . . 17 91 5.3. Security Requirements . . . . . . . . . . . . . . . . . . 18 92 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 94 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 95 Appendix A. Contributors List and Acknowledgments . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 The motivation for Application-Layer Traffic Optimization (ALTO) is 101 described in the ALTO problem statement [RFC5693]. 103 The goal of ALTO is to provide information which can help peer-to- 104 peer (P2P) applications to make better decisions with respect to peer 105 selection. However, ALTO may be useful for non-P2P applications as 106 well. For example, clients of client-server applications may use 107 information provided by ALTO to select one of several servers or 108 information replicas. As another example, ALTO information could be 109 used to select a media relay needed for NAT traversal. The goal of 110 these informed decisions is to improve performance (or Quality of 111 Experience) in the application while reducing resource consumption in 112 the underlying network infrastructure. 114 Usually, it would be difficult or even impossible for application 115 entities to acquire this information by other mechanisms (e.g., using 116 measurements between the peers of a P2P overlay), because of 117 complexity or because it is based on network topology information, 118 network operational costs, or network policies, which the respective 119 network provider does not want to disclose in detail. 121 The logical entities that provide the ALTO service do not take part 122 in the actual user data transport, i.e., they do not implement 123 functions for relaying user data. They may be placed on various 124 kinds of physical nodes, e.g., on dedicated servers, as auxiliary 125 processes in routers, on "trackers" or "super peers" of a P2P 126 application, etc. 128 2. Terminology and Architectural Framework 130 2.1. Requirements Notation 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2.2. ALTO Terminology 138 This document uses the following ALTO-related terms, which are 139 defined in [RFC5693]: 141 Application, Peer, P2P, Resource, Resource Identifier, Resource 142 Provider, Resource Consumer, Transport Address, Overlay Network, 143 Resource Directory, ALTO Service, ALTO Server, ALTO Client, ALTO 144 Query, ALTO Response, ALTO Transaction, Local Traffic, Peering 145 Traffic, Transit Traffic, Application protocol, ALTO Client Protocol, 146 Provisioning protocol. 148 Furthermore, the following additional terms will be used: 150 o Host Group Descriptor: Information used to describe one or more 151 Internet hosts (such as the resource consumer which seeks ALTO 152 guidance, or one or more candidate resource providers) and their 153 location within the network topology. This can be, for example, a 154 single IP address, an address prefix or address range that 155 contains the host(s), or an autonomous system (AS) number. 156 Different options may provide different levels of detail. 157 Depending on the system architecture, this may have implications 158 on the quality of the guidance ALTO is able to provide, on whether 159 recommendations can be aggregated, and on how much privacy- 160 sensitive information about users might be disclosed to additional 161 parties. 163 o Host Characteristics Attribute: Properties of a host (other than 164 the host group descriptor), in particular related to its 165 attachment to the network. This information may be stored in an 166 ALTO server and transmitted via an ALTO protocol. It may be 167 evaluated according to the rating criteria. 169 o Rating Criterion: The condition or relation that defines the 170 "better" in "better-than-random peer selection", which is the 171 ultimate goal of ALTO. Examples may include "host's Internet 172 access is not subject to volume based charging (flat rate)" or 173 "low topological distance". Some rating criteria, such as "low 174 topological distance", need to include a reference point, i. e., 175 "low topological distance from a given resource consumer", which 176 can be described by means of a host group descriptor. 178 2.3. Architectural Framework for ALTO 180 There are various architectural options for how ALTO could be 181 implemented, and specifying or mandating one specific architecture is 182 out of the scope of this document. 184 The ALTO Working Group Charter [ALTO-charter] itemizes several key 185 components, which shall be elaborated and specified by the ALTO 186 Working Group. The ALTO problem statement [RFC5693] defines a 187 terminology (see Section 2.2) and presents a figure that gives a 188 high-level overview of protocol interaction between ALTO elements. 190 This document itemizes requirements for the following components and 191 information elements that are part of the above-mentioned 192 architecture: 194 o An ALTO client protocol, which is used for sending ALTO queries 195 and ALTO responses between ALTO client and ALTO server. 197 o The discovery mechanism, which will be used by ALTO clients in 198 order to find out where to send ALTO requests. 200 o The overall architecture, especially with respect to security and 201 privacy issues. 203 o Host group descriptors, which are used to describe the location of 204 a host in the network topology. 206 o Rating criteria, i. e., conditions or relations that shall be 207 evaluated in order to generate the ALTO guidance. 209 3. ALTO Requirements 211 [*** Note to the RFC editor: before publication as an RFC, please 212 remove the draft version number from the requirements numbering, 213 i.e., change ARv10-1 to AR-1, and so on. Furthermore, remove this 214 note. ***] 216 3.1. ALTO Client Protocol 218 3.1.1. General Requirements 220 REQ. ARv10-1: The ALTO service is provided by one or more ALTO 221 servers. ALTO servers MUST implement an ALTO client protocol, for 222 receiving ALTO queries from ALTO clients and for sending the 223 corresponding ALTO responses. 225 REQ. ARv10-2: ALTO clients MUST implement an ALTO client protocol, 226 for sending ALTO queries to ALTO servers and for receiving the 227 corresponding ALTO responses. 229 REQ. ARv10-3: The format of the ALTO query message MUST allow the 230 ALTO client to solicit guidance for selecting appropriate resource 231 providers. 233 REQ. ARv10-4: The format of the ALTO response message MUST allow the 234 ALTO server to express its guidance for selecting appropriate 235 resource providers. 237 REQ. ARv10-5: The detailed specification of a protocol is out of the 238 scope of this document. However, any protocol specification that 239 claims to implement an ALTO client protocol MUST be compliant to the 240 requirements itemized in this document. 242 3.1.2. Host Group Descriptor Support 244 The ALTO guidance is based on the evaluation of several resource 245 providers or groups of resource providers, which are characterized by 246 means of host group descriptors, considering one or more rating 247 criteria. 249 REQ. ARv10-6: An ALTO client protocol MUST support the host group 250 descriptor types "IPv4 address prefix" and "IPv6 address prefix". 251 They can be used to specify the IP address of one host, or an IP 252 address range (in CIDR notation), which contains all hosts in 253 question. 255 REQ. ARv10-7: An ALTO client protocol MUST be extensible to enable 256 support of other host group descriptor types in future. An ALTO 257 client protocol specification MUST define an appropriate procedure 258 for adding new host group descriptor types, e.g., by establishing an 259 IANA registry. 261 REQ. ARv10-8: ALTO clients and ALTO servers MUST clearly identify 262 the type of each host group descriptor sent in ALTO queries or 263 responses. 265 REQ. ARv10-9: For host group descriptor types other than "IPv4 266 address prefix" and "IPv6 address prefix", the host group descriptor 267 type identification MUST be supplemented by a reference to a 268 facility, which can be used to translate host group descriptors of 269 that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping 270 table or an algorithm. 272 REQ. ARv10-10: Protocol functions for mapping other host group 273 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 274 specified as part of an ALTO client protocol, and the corresponding 275 address mapping information SHOULD be made available by the same 276 entity that wants to use these host group descriptors within an ALTO 277 client protocol. However, an ALTO server or an ALTO client MAY also 278 send a reference to an external mapping facility, e.g., a translation 279 table to be obtained via an alternative mechanism. 281 REQ. ARv10-11: An ALTO client protocol specification MUST define 282 mechanisms, which can be used by the ALTO server to indicate that a 283 host group descriptor used by the ALTO client is of an unsupported 284 type, or that the indicated mapping mechanism could not be used. 286 REQ. ARv10-12: An ALTO client protocol specification MUST define 287 mechanisms, which can be used by the ALTO client to indicate that a 288 host group descriptor used by the ALTO server is of an unsupported 289 type, or that the indicated mapping mechanism could not be used. 291 3.1.3. Rating Criteria Support 293 REQ. ARv10-13: An ALTO client protocol specification MUST define a 294 rating criterion that can be used to express and evaluate the 295 "relative operator's preference." This is a relative measure, i.e., 296 it is not associated with any unit of measurement. A more-preferred 297 rating according to this criterion indicates that the application 298 should prefer the respective candidate resource provider over others 299 with less-preferred ratings (unless information from non-ALTO sources 300 suggests a different choice, such as transmission attempts suggesting 301 that the path is currently congested). The operator of the ALTO 302 server does not have to disclose how and based on which data the 303 ratings are actually computed. Examples could be: cost for peering 304 or transit traffic, traffic engineering inside the network, and other 305 policies. 307 REQ. ARv10-14: An ALTO client protocol MUST be extensible to enable 308 support of other rating criteria types in future. An ALTO client 309 protocol specification MUST define an appropriate procedure for 310 adding new rating criteria types, e.g., by establishing an IANA 311 registry. 313 REQ. ARv10-15: ALTO client protocol specifications MUST NOT define 314 rating criteria closely related to the instantaneous network 315 congestion state, whose primary aim is to serve an alternative to 316 established congestion control strategies, such as using TCP-based 317 transport. 319 One design assumption for ALTO is that it is acceptable that the 320 host characteristics attributes, which are stored and processed in 321 the ALTO servers for giving the guidance, are updated rather 322 infrequently. Typical update intervals may be several orders of 323 magnitude longer than the typical network-layer packet round-trip 324 time (RTT). Therefore, ALTO cannot be a replacement for TCP-like 325 congestion control mechanisms. The definition of alternate 326 approaches for congestion control is explicitly a non-goal for the 327 ALTO working group [ALTO-charter]. 329 REQ. ARv10-16: Applications using ALTO guidance MUST NOT rely on the 330 ALTO guidance to avoid causing network congestion. Instead, 331 applications MUST use other appropriate means, such as TCP based 332 transport, to avoid causing excessive congestion. 334 REQ. ARv10-17: The ALTO query message SHOULD allow the ALTO client 335 to express which rating criteria should be considered, as well as 336 their relative relevance for the specific application that will 337 eventually make use of the guidance. 339 REQ. ARv10-18: The ALTO response message SHOULD allow the ALTO 340 server to express which rating criteria have been considered when 341 generating the response. 343 REQ. ARv10-19: An ALTO client protocol specification MUST define 344 mechanisms, which can be used by the ALTO client and the ALTO server 345 to indicate that a rating criteria used by the other party is of an 346 unsupported type. 348 3.1.4. Placement of Entities and Timing of Transactions 350 With respect to the placement of ALTO clients, several modes of 351 operation exist: 353 o One mode of ALTO operation is that an ALTO client may be embedded 354 directly in the resource consumer, i.e., the application protocol 355 entity that will eventually initiate data transmission to/from the 356 selected resource provider(s) in order to access the desired 357 resource. For example, an ALTO client could be integrated into 358 the peer of a P2P application that uses a distributed algorithm 359 such as "query flooding" for resource discovery. 361 o Another mode of operation is to integrate the ALTO client into a 362 third party such as a resource directory, which may issue ALTO 363 queries to solicit preference on potential resource providers, 364 considering the respective resource consumer. For example, an 365 ALTO client could be integrated into the tracker of a tracker- 366 based P2P application, in order to request ALTO guidance on behalf 367 of the peers contacting the tracker. 369 REQ. ARv10-20: An ALTO client protocol MUST support the mode of 370 operation in which the ALTO client is directly embedded in the 371 resource consumer. 373 REQ. ARv10-21: An ALTO client protocol MUST support the mode of 374 operation in which the ALTO client is embedded in a third party, 375 which performs queries on behalf of resource consumers. 377 REQ. ARv10-22: An ALTO client protocol MUST be designed in a way 378 that the ALTO service can be provided by an entity which is not the 379 operator of the underlying IP network. 381 REQ. ARv10-23: An ALTO client protocol MUST be designed in a way 382 that different instances of the ALTO service operated by different 383 providers can coexist. 385 With respect to the timing of ALTO queries, several modes of 386 operation exist: 388 o In target-aware query mode, an ALTO client performs the ALTO query 389 when the desired resource and a set of candidate resource 390 providers are already known, i. e., after DHT lookups, queries to 391 the resource directory, etc. 393 o In target-independent query mode, ALTO queries are performed in 394 advance or periodically, in order to receive comprehensive, 395 "target-independent" guidance, which will be cached locally and 396 evaluated later, when a resource is to be accessed. 398 REQ. ARv10-24: An ALTO client protocol MUST support at least one of 399 these two modes, either the target-aware or the target-independent 400 query mode. 402 REQ. ARv10-25: An ALTO client protocol SHOULD support both the 403 target-aware and the target-independent query mode. 405 REQ. ARv10-26: An ALTO client protocol SHOULD support version 406 numbering, TTL (time-to-live) attributes, and/or similar mechanisms 407 in ALTO transactions, in order to enable time validity checking for 408 caching, and to enable comparisons of multiple recommendations 409 obtained through redistribution. 411 REQ. ARv10-27: An ALTO client protocol SHOULD allow the ALTO server 412 to add information about appropriate modes of re-use to its ALTO 413 responses. Re-use may include redistributing an ALTO response to 414 other parties, as well as using the same ALTO information in a 415 resource directory to improve the responses to different resource 416 consumers, within the specified lifetime of the ALTO response. The 417 ALTO server SHOULD be able to express that 419 o no re-use should occur 421 o re-use is appropriate for a specific "target audience", i.e., a 422 set of resource consumers explicitly defined by a list of host 423 group descriptors. The ALTO server MAY specify a "target 424 audience" in the ALTO response, which is only a subset of the 425 known actual "target audience", e.g., if required by operator 426 policies 428 o re-use is appropriate for any resource consumer that would send 429 (or cause a third party sending on behalf of it) the same ALTO 430 query (i.e., with the same query parameters, except for the 431 resource consumer ID, if applicable) to this ALTO server 433 o re-use is appropriate for any resource consumer that would send 434 (or cause a third party sending on behalf of it) the same ALTO 435 query (i.e., with the same query parameters, except for the 436 resource consumer ID, if applicable) to any other ALTO server, 437 which was discovered (using an ALTO discovery mechanism) together 438 with 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 ALTO server in the 444 whole network 446 REQ. ARv10-28: An ALTO client protocol MUST support the exchange of 447 ALTO transactions even if the ALTO client is located in the private 448 address realm behind a network address translator (NAT). There are 449 different types of NAT, see [RFC4787] and [RFC5382]. 451 3.1.5. Protocol Extensibility 453 REQ. ARv10-29: An ALTO client protocol MUST include support for 454 adding protocol extensions in a non-disruptive, backward-compatible 455 way. 457 REQ. ARv10-30: An ALTO client protocol MUST include protocol 458 versioning support, in order to clearly distinguish between 459 incompatible versions of the protocol. 461 3.1.6. Error Handling and Overload Protection 463 REQ. ARv10-31: An ALTO client protocol MUST use TCP based transport. 465 REQ. ARv10-32: An ALTO client protocol specification MUST specify 466 mechanisms, or detail how to leverage appropriate mechanisms provided 467 by underlying protocol layers, which can be used by an ALTO server 468 operating close to its capacity limit, to inform clients about its 469 impending overload situation, and require them to throttle their 470 query rate. 472 REQ. ARv10-33: An ALTO client protocol specification MUST specify 473 mechanisms, or detail how to leverage appropriate mechanisms provided 474 by underlying protocol layers, which can be used by an ALTO server 475 operating close to its capacity limit, to inform clients about its 476 impending overload situation, and redirect them to another ALTO 477 server. 479 REQ. ARv10-34: An ALTO client protocol specification MUST specify 480 mechanisms, or detail how to leverage appropriate mechanisms provided 481 by underlying protocol layers, which can be used by an ALTO server 482 operating close to its capacity limit, to inform clients about its 483 impending overload situation, and terminate the conversation with the 484 ALTO client. 486 3.2. ALTO Server Discovery 488 An ALTO client protocol is supported by one or more ALTO server 489 discovery mechanisms, which may be used by ALTO clients in order to 490 determine one or more ALTO servers, to which ALTO requests can be 491 sent. This section enumerates requirements for an ALTO client 492 protocol, as well as general requirements to be fulfilled by the ALTO 493 server discovery mechanisms. 495 REQ. ARv10-35: 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. ARv10-36: 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. ARv10-37: 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. ARv10-38: 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. ARv10-39: 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. ARv10-40: 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. ARv10-41: Every ALTO server discovery mechanism SHOULD be able 528 to return the respective contact information for multiple ALTO 529 servers. 531 REQ. ARv10-42: 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. ARv10-43: An ALTO client protocol specification MUST specify 538 mechanisms for the authentication of ALTO servers, or how to leverage 539 appropriate mechanisms provided by underlying protocol layers. 541 REQ. ARv10-44: An ALTO client protocol specification MUST specify 542 mechanisms for the authentication of ALTO clients, or how to leverage 543 appropriate mechanisms provided by underlying protocol layers. 545 REQ. ARv10-45: An ALTO client protocol specification MUST specify 546 mechanisms for the encryption of messages, or how to leverage 547 appropriate mechanisms provided by underlying protocol layers. 549 REQ. ARv10-46: The operator of an ALTO server MUST NOT assume that 550 an ALTO client will implement mechanisms or comply with rules that 551 limit the ALTO client's ability to redistribute information retrieved 552 from the ALTO server to third parties. 554 REQ. ARv10-47: An ALTO client protocol MUST support different levels 555 of detail in queries and responses, in order to protect the privacy 556 of users, to ensure that the operators of ALTO servers and other 557 users of the same application cannot derive sensitive information. 559 REQ. ARv10-48: An ALTO client protocol MAY include mechanisms that 560 can be used by the ALTO client when requesting guidance to specify 561 the resource (e.g., content identifiers) it wants to access. An ALTO 562 server MUST provide adequate guidance even if the ALTO client prefers 563 not to specify the desired resource (e.g., keeps the data field 564 empty). The mechanism MUST be designed in a way that the operator of 565 the ALTO server cannot easily deduce the resource identifier (e.g., 566 file name in P2P file sharing) if the ALTO client prefers not to 567 specify it. 569 REQ. ARv10-49: An ALTO client protocol specification MUST specify 570 appropriate mechanisms for protecting the ALTO service against DoS 571 attacks, or how to leverage appropriate mechanisms provided by 572 underlying protocol layers. 574 4. IANA Considerations 576 This requirements document does not mandate any immediate IANA 577 actions. However, such IANA considerations may arise from future 578 ALTO specification documents which try to meet the requirements given 579 here. 581 5. Security Considerations 583 5.1. High-level security considerations 585 High-level security considerations for the ALTO service can be found 586 in the "Security Considerations" section of the ALTO problem 587 statement document [RFC5693]. 589 5.2. Information Disclosure Scenarios 591 The unwanted disclosure of information is one key concern related to 592 ALTO. This section presents a classification and discussion of 593 information disclosure scenarios and potential countermeasures. 595 5.2.1. Classification of Information Disclosure Scenarios 597 o (1) Excess disclosure of ALTO server operator's data to an 598 authorized ALTO client. The operator of an ALTO server has to 599 feed information, such as tables mapping host group descriptors to 600 host characteristics attributes, into the server, thereby enabling 601 it to give guidance to ALTO clients. Some operators might 602 consider the full set of this information confidential (e.g., a 603 detailed map of the operator's network topology), and might want 604 to disclose only a subset of it or somehow obfuscated information 605 to an ALTO client. 607 o (2) Disclosure of the application behavior to the ALTO server. 608 The operator of an ALTO server could infer the application 609 behavior (e.g., content identifiers in P2P file sharing 610 applications, or lists of resource providers that are considered 611 for establishing a connection) from the ALTO queries sent by an 612 ALTO client. 614 o (3) Disclosure of ALTO server operator's data (e.g., network 615 topology information) to an unauthorized third party. There are a 616 three sub-cases here: 618 * (3a) An ALTO server sends the information directly to an 619 unauthorized ALTO client. 621 * (3b) An unauthorized party snoops on the data transmission from 622 the ALTO server to an authorized ALTO client. 624 * (3c) An authorized ALTO client knowingly forwards the 625 information it had received from the ALTO server to an 626 unauthorized party. 628 o (4) Disclosure of the application behavior to an unauthorized 629 third party. 631 o (5) Excess retrieval of ALTO server operator's data by 632 collaborating ALTO clients. Several authorized ALTO clients could 633 ask an ALTO server for guidance, and redistribute the responses 634 among each other (see also case 3c). By correlating the ALTO 635 responses they could find out more information than intended to be 636 disclosed by the ALTO server operator. 638 5.2.2. Discussion of Information Disclosure Scenarios 640 Scenario (1) may be addressed by the ALTO server operator choosing 641 the level of detail of the information to be populated into the ALTO 642 server and returned in the responses. For example, by specifying a 643 broader address range (i.e., a shorter prefix length) than a group of 644 hosts in question actually uses, an ALTO server operator may control 645 to some extent how much information about the network topology is 646 disclosed. Furthermore, access control mechanisms for filtering ALTO 647 responses according to the authenticated ALTO client identity might 648 be installed in the ALTO server, although this might not be effective 649 given the lack of efficient mechanisms for addressing (3c) and (5), 650 see below. 652 (2) can and needs to be addressed in several ways: If the ALTO client 653 is embedded in the resource consumer, the resource consumer's IP 654 address (or the "public" IP address of the outermost NAT in front of 655 the resource consumer) is disclosed to the ALTO server as a matter of 656 principle, because it is in the source address fields of the IP 657 headers. By using a proxy, the disclosure of source addresses to the 658 ALTO server can be avoided at the cost of disclosing them to said 659 proxy. If, in contrast, the ALTO client is embedded in a third party 660 (e.g., a resource directory) which issues ALTO requests on behalf of 661 resource consumers, it is possible to hide the exact addresses of the 662 resource consumers from the ALTO server, e.g., by zeroing-out or 663 randomizing the last few bits of IP addresses. However, there is the 664 potential side effect of yielding inaccurate results. 666 The disclosure of candidate resource providers' addresses to the ALTO 667 server can be avoided by allowing ALTO clients to use the target- 668 independent query mode. In this mode of operation, guiding 669 information (e.g., "maps") is retrieved from the ALTO server and used 670 entirely locally by the ALTO client, i.e., without sending host 671 location attributes of candidate resource providers to the ALTO 672 server. In the target-aware query mode, this issue can be addressed 673 by ALTO clients through obfuscating the identity of candidate 674 resource consumers, e.g., by specifying a broader address range 675 (i.e., a shorter prefix length) than a group of hosts in question 676 actually uses, or by zeroing-out or randomizing the last few bits of 677 IP addresses. However, there is the potential side effect of 678 yielding inaccurate results. 680 (3a), (3b), and (4) may be addressed by authentication, access 681 control, and encryption schemes for the ALTO client protocol. 682 However, deployment of encryption schemes might not be effective 683 given the lack of efficient mechanisms for addressing (3c) and (5), 684 see below. 686 Straightforward authentication and encryption schemes will not help 687 solving (3c) and (5), and there is no other simple and efficient 688 mechanism known. The cost of complex approaches, e.g., based on 689 digital rights management (DRM), might easily outweigh the benefits 690 of the whole ALTO solution, and therefore they are not considered as 691 a viable solution. That is, ALTO server operators must be aware that 692 (3c) and (5) cannot be prevented from happening, and therefore they 693 should feed only such data into an ALTO server, which they do not 694 consider sensitive with respect to (3c) and (5). 696 These insights are reflected in the requirements in this document. 698 5.3. Security Requirements 700 For a set of specific security requirements please refer to 701 Section 3.3 of this document. 703 6. References 705 6.1. Normative References 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, March 1997. 710 6.2. Informative References 712 [ALTO-charter] 713 Marocco, E. and V. Gurbani, "Application-Layer Traffic 714 Optimization (ALTO) Working Group Charter (http:// 715 tools.ietf.org/wg/alto/ 716 charters?item=charter-alto-2011-04-28.txt)", April 2011. 718 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 719 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 720 RFC 4787, January 2007. 722 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 723 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 724 RFC 5382, October 2008. 726 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 727 Optimization (ALTO) Problem Statement", RFC 5693, 728 October 2009. 730 Appendix A. Contributors List and Acknowledgments 732 The initial version of this document was co-authored by Laird Popkin. 734 The authors would like to thank 736 o Vijay K. Gurbani 738 o Enrico Marocco 740 for fostering discussions that lead to the creation of this document, 741 and for giving valuable comments on it. 743 The authors were supported by the following people, who have 744 contributed to this document: 746 o Richard Alimi 748 o Zoran Despotovic 750 o Jason Livingood 752 o Saverio Niccolini 754 o Michael Scharf 756 o Nico Schwan 758 o Jan Seedorf 760 The authors would like to thank the members of the P2PI and ALTO 761 mailing lists for their feedback. 763 Laird Popkin and Y. Richard Yang are grateful to the many 764 contributions made by the members of the P4P working group and Yale 765 Laboratory of Networked Systems. The P4P working group is hosted by 766 DCIA. 768 Martin Stiemerling is partially supported by the COAST project 769 (COntent Aware Searching, retrieval and sTreaming, 770 http://www.coast-fp7.eu), a research project supported by the 771 European Commission under its 7th Framework Program (contract no. 772 248036). The views and conclusions contained herein are those of the 773 authors and should not be interpreted as necessarily representing the 774 official policies or endorsements, either expressed or implied, of 775 the COAST project or the European Commission. 777 Authors' Addresses 779 Sebastian Kiesel (editor) 780 University of Stuttgart Computing Center 781 Networks and Communication Systems Department 782 Allmandring 30 783 70550 Stuttgart 784 Germany 786 Email: ietf-alto@skiesel.de 787 URI: http://www.rus.uni-stuttgart.de/nks/ 789 Stefano Previdi 790 Cisco Systems, Inc. 792 Email: sprevidi@cisco.com 794 Martin Stiemerling 795 NEC Laboratories Europe 797 Email: martin.stiemerling@neclab.eu 798 URI: http://ietf.stiemerling.org 800 Richard Woundy 801 Comcast Corporation 803 Email: Richard_Woundy@cable.comcast.com 805 Yang Richard Yang 806 Yale University 808 Email: yry@cs.yale.edu