idnits 2.17.1 draft-ietf-alto-reqs-16.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 15, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 17, 2012 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 15, 2012 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-16.txt 17 Abstract 19 Many Internet applications are used to access resources, such as 20 pieces of information or server processes that 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 that have to select one or several hosts 25 from a set of candidates capable of providing a desired resource. 26 This guidance shall be based on parameters that affect performance 27 and efficiency of the data transmission between the hosts, e.g., the 28 topological distance. The ultimate goal is to improve performance or 29 Quality of Experience in the application while reducing the 30 utilization of the underlying network infrastructure. 32 This document enumerates requirements for specifying, assessing, or 33 comparing protocols and implementations. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 17, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology and Architectural Framework . . . . . . . . . . . 5 70 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 71 2.2. ALTO Terminology . . . . . . . . . . . . . . . . . . . . . 5 72 2.3. Architectural Framework for ALTO . . . . . . . . . . . . . 6 73 3. ALTO Requirements . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1. ALTO Client Protocol . . . . . . . . . . . . . . . . . . . 8 75 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 8 76 3.1.2. Host Group Descriptor Support . . . . . . . . . . . . 8 77 3.1.3. Rating Criteria Support . . . . . . . . . . . . . . . 9 78 3.1.4. Placement of Entities and Timing of Transactions . . . 11 79 3.1.5. Protocol Extensibility . . . . . . . . . . . . . . . . 13 80 3.1.6. Error Handling and Overload Protection . . . . . . . . 13 81 3.2. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 14 82 3.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 15 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 5.1. High-level security considerations . . . . . . . . . . . . 18 86 5.2. Information Disclosure Scenarios . . . . . . . . . . . . . 18 87 5.2.1. Classification of Information Disclosure Scenarios . . 18 88 5.2.2. Discussion of Information Disclosure Scenarios . . . . 19 89 5.3. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 21 90 5.4. Security Requirements . . . . . . . . . . . . . . . . . . 21 91 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 6.1. Normative References . . . . . . . . . . . . . . . . . . . 22 93 6.2. Informative References . . . . . . . . . . . . . . . . . . 22 94 Appendix A. Contributors List and Acknowledgments . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 The motivation for Application-Layer Traffic Optimization (ALTO) is 100 described in the ALTO problem statement [RFC5693]. 102 The goal of ALTO is to provide information which can help peer-to- 103 peer (P2P) applications to make better decisions with respect to peer 104 selection. However, ALTO may be useful for non-P2P applications as 105 well. For example, clients of client-server applications may use 106 information provided by ALTO to select one of several servers or 107 information replicas. As another example, ALTO information could be 108 used to select a media relay needed for NAT traversal. The goal of 109 these informed decisions is to improve performance or Quality of 110 Experience in the application while reducing the utilization of the 111 underlying network infrastructure. 113 Usually, it would be difficult or even impossible for application 114 entities to acquire this information by other mechanisms, e.g., using 115 measurements between the peers of a P2P overlay, because of 116 complexity or because it is based on network topology information, 117 network operational costs, or network policies, which the respective 118 network provider does not want to disclose in detail. 120 The functional entities that provide the ALTO service do not take 121 part in the actual user data transport, i.e., they do not implement 122 functions for relaying user data. These functional entities may be 123 placed on various kinds of physical nodes, e.g., on dedicated 124 servers, as auxiliary processes in routers, on "trackers" or "super 125 peers" of a P2P application, etc. 127 2. Terminology and Architectural Framework 129 2.1. Requirements Notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2.2. ALTO Terminology 137 This document uses the following ALTO-related terms, which are 138 defined in [RFC5693]: 140 Application, Peer, P2P, Resource, Resource Identifier, Resource 141 Provider, Resource Consumer, Transport Address, Overlay Network, 142 Resource Directory, ALTO Service, ALTO Server, ALTO Client, ALTO 143 Query, ALTO Response, ALTO Transaction, Local Traffic, Peering 144 Traffic, Transit Traffic, Application protocol, ALTO Client Protocol, 145 Provisioning protocol. 147 Furthermore, the following additional terms will be used: 149 o Host Group Descriptor: Information used to describe one or more 150 Internet hosts (such as the resource consumer that seeks ALTO 151 guidance, or one or more candidate resource providers) and their 152 location within the network topology. There can be several 153 different types of host group descriptors, for example, a single 154 IP address, an address prefix or address range that contains the 155 host(s), or an autonomous system (AS) number. Different host 156 group descriptor types 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 Rating Criterion: The condition or relation that defines the 164 "better" in "better-than-random peer selection", which is the 165 ultimate goal of ALTO. Examples may include "host's Internet 166 access is not subject to volume based charging (flat rate)" or 167 "low topological distance". Some rating criteria, such as "low 168 topological distance", need to include a reference point, e. g., 169 "low topological distance from a given resource consumer". This 170 reference point can be described by means of a host group 171 descriptor. 173 o Host Characteristics Attribute: Properties of a host, other than 174 the host group descriptor. It may be evaluated according to one 175 or more rating criteria. This information may be stored in an 176 ALTO server and transmitted via an ALTO protocol. One example for 177 a host characteristics attribute would be a data field indicating 178 whether a host's Internet access is subject to volume based 179 charging or not (flat rate). 181 o Target-Aware Query Mode: In this mode of operation, an ALTO client 182 performs the ALTO query when the desired resource and a set of 183 candidate resource providers are already known, i. e., after 184 distributed hash table (DHT) lookups, queries to the resource 185 directory, etc. To this end the ALTO client transmits a list of 186 host group descriptors and optionally one or more rating criteria 187 to the ALTO server. The ALTO server evaluates the host group 188 descriptors according to the indicated criteria or a default 189 criterion. It returns a list of these host group descriptors to 190 the ALTO client, which is sorted according to the rating criteria 191 and/or enriched with host characteristic attributes. 193 o Target-Independent Query Mode: In this mode of operation, ALTO 194 queries are performed in advance or periodically, in order to 195 receive comprehensive guidance. The ALTO client indicates the 196 desired host characteristic attributes in the ALTO query. The 197 ALTO server answers with a list that indicates for all known host 198 group descriptors (possibly subject to the server's policies) the 199 desired host characteristic attributes. These lists will be 200 cached locally and evaluated later, when a resource is to be 201 accessed. 203 2.3. Architectural Framework for ALTO 205 There are various architectural options for how ALTO could be 206 implemented, and specifying or mandating one specific architecture is 207 out of the scope of this document. 209 In addition to the terminology (see Section 2 of [RFC5693] and 210 Section 2.2 of this document), [RFC5693] presents a figure that gives 211 a high-level overview of protocol interaction between these 212 components. 214 This document itemizes requirements for the following components: 215 ALTO client protocols, ALTO server discovery mechanisms, host group 216 descriptors, rating criteria, and host characteristics attributes. 217 Furthermore, requirements regarding the overall architecture, 218 especially with respect to security and privacy issues, are 219 presented. 221 Note that the detailed specification of such protocols and mechanisms 222 is out of the scope of this document. In fact, this document does 223 not even assume that there will be only one single specification for 224 each of these components, respectively. However, this document 225 enumerates requirements for ALTO, to be considered when specifying, 226 assessing, or comparing protocols and implementations. 228 3. ALTO Requirements 230 [*** Note to the RFC editor: before publication as an RFC, please 231 remove the draft version number from the requirements numbering, 232 i.e., change ARv16-1 to AR-1, and so on. Furthermore, remove this 233 note. ***] 235 3.1. ALTO Client Protocol 237 3.1.1. General Requirements 239 REQ. ARv16-1: The ALTO service is provided by one or more ALTO 240 servers. It may be queried by ALTO clients seeking guidance for 241 selecting appropriate resource providers. ALTO clients and ALTO 242 servers MUST implement an ALTO client protocol. An ALTO client 243 protocol MUST be able to transmit ALTO queries from an ALTO client to 244 an ALTO server, and it MUST be able to transmit the corresponding 245 ALTO replies from the ALTO server to the ALTO client. 247 The detailed specification of an ALTO client protocol is out of the 248 scope of this document. In fact, this document does not even assume 249 that there will be only one single protocol specification. However, 250 this document enumerates requirements for ALTO, to be considered when 251 specifying, assessing, or comparing protocols and implementations. 253 REQ. ARv16-2: An ALTO client protocol MUST provide adequate 254 mechanisms for operations and management support, as outlined in RFC 255 5706 [RFC5706]. 257 3.1.2. Host Group Descriptor Support 259 The ALTO guidance is based on the evaluation of several resource 260 providers or groups of resource providers, considering one or more 261 rating criteria. The resource providers or groups of resource 262 providers are characterized by means of host group descriptors. 264 REQ. ARv16-3: An ALTO client protocol MUST support the usage of 265 multiple host group descriptor types. 267 REQ. ARv16-4: ALTO clients and ALTO servers MUST clearly identify 268 the type of each host group descriptor sent in ALTO queries or 269 responses. An ALTO protocol specification MUST provide appropriate 270 protocol elements. 272 REQ. ARv16-5: An ALTO client protocol MUST support the host group 273 descriptor types "IPv4 address prefix" and "IPv6 address prefix". 274 They can be used to specify the IP address of one host, or an IP 275 address range (in CIDR notation) containing all hosts in question. 277 REQ. ARv16-6: An ALTO client protocol MUST be extensible to enable 278 support of other host group descriptor types in future. An ALTO 279 client protocol specification MUST define an appropriate procedure 280 for adding new host group descriptor types, e.g., by establishing an 281 IANA registry. 283 REQ. ARv16-7: For host group descriptor types other than "IPv4 284 address prefix" and "IPv6 address prefix", the host group descriptor 285 type identification MUST be supplemented by a reference to a facility 286 that can be used to translate host group descriptors of this type to 287 IPv4/IPv6 address prefixes, e.g., by means of a mapping table or an 288 algorithm. 290 REQ. ARv16-8: Protocol functions for mapping other host group 291 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 292 specified as part of an ALTO client protocol, and the corresponding 293 address mapping information SHOULD be made available by the same 294 entity that wants to use these host group descriptors within an ALTO 295 client protocol. However, an ALTO server or an ALTO client MAY also 296 send a reference to an external mapping facility, e.g., a translation 297 table to be obtained via an alternative mechanism. 299 Rationale for the previous two requirements: The preferred type of 300 host group descriptors are IPv4 and IPv6 prefixes. However, in 301 some situations one party may prefer to use another type, e.g., 302 Autonomous System (AS) numbers. Usually, applications seeking 303 ALTO guidance work with IP addresses, e.g., when establishing 304 connections. Understanding guiding information that is based on 305 other host group descriptor types, i.e., mapping from this other 306 types to IP prefixes and back, may be a non-trivial task. 307 Therefore, before a party may use other host group descriptor 308 types, they must provide a mapping mechanism to IP prefixes. 310 REQ. ARv16-9: An ALTO client protocol specification MUST define 311 mechanisms that can be used by the ALTO server to indicate that a 312 host group descriptor used by the ALTO client is of an unsupported 313 type, or that the indicated mapping mechanism could not be used. 315 REQ. ARv16-10: An ALTO client protocol specification MUST define 316 mechanisms that can be used by the ALTO client to indicate that a 317 host group descriptor used by the ALTO server is of an unsupported 318 type, or that the indicated mapping mechanism could not be used. 320 3.1.3. Rating Criteria Support 322 REQ. ARv16-11: An ALTO client protocol specification MUST define a 323 rating criterion that can be used to express and evaluate the 324 "relative operator's preference." This is a relative measure, i.e., 325 it is not associated with any unit of measurement. A more-preferred 326 rating according to this criterion indicates that the application 327 should prefer the respective candidate resource provider over others 328 with less-preferred ratings (unless information from non-ALTO sources 329 suggests a different choice, such as transmission attempts suggesting 330 that the path is currently congested). The operator of the ALTO 331 server does not have to disclose how and based on which data the 332 ratings are actually computed. Examples could be: cost for peering 333 or transit traffic, traffic engineering inside the network, and other 334 policies. 336 REQ. ARv16-12: An ALTO client protocol MUST be extensible to enable 337 support of other rating criteria types in future. An ALTO client 338 protocol specification MUST define an appropriate procedure for 339 adding new rating criteria types, e.g., by establishing an IANA 340 registry. 342 REQ. ARv16-13: ALTO client protocol specifications MUST NOT define 343 rating criteria closely related to the instantaneous network 344 congestion state, i. e., rating criteria that have the primary aim to 345 serve as an alternative to established congestion control strategies, 346 such as using TCP-based transport. 348 REQ. ARv16-14: Applications using ALTO guidance MUST NOT rely solely 349 on the ALTO guidance to avoid causing network congestion. Instead, 350 applications MUST use other appropriate means, such as TCP based 351 transport, to avoid causing excessive congestion. 353 Rationale for the previous requirement: One design assumption for 354 ALTO is that it is acceptable that the host characteristics 355 attributes, which are stored and processed in the ALTO servers for 356 giving the guidance, are updated rather infrequently. Typical 357 update intervals may be several orders of magnitude longer than 358 the typical network-layer packet round-trip time (RTT). 359 Therefore, ALTO cannot be a replacement for TCP-like congestion 360 control mechanisms. 362 REQ. ARv16-15: In the target-independent query mode, the ALTO query 363 message SHOULD allow the ALTO client to express which host 364 characteristics attributes should be returned. 366 REQ. ARv16-16: In the target-aware query mode, the ALTO query 367 message SHOULD allow the ALTO client to express which rating criteria 368 should be considered by the server, as well as their relative 369 relevance for the specific application that will eventually make use 370 of the guidance. The corresponding ALTO response message SHOULD 371 allow the ALTO server to express which rating criteria have been 372 considered when generating the response. 374 REQ. ARv16-17: An ALTO client protocol specification MUST define 375 mechanisms that can be used by the ALTO client and the ALTO server to 376 indicate that a rating criteria used by the other party is of an 377 unsupported type. 379 3.1.4. Placement of Entities and Timing of Transactions 381 With respect to the placement of ALTO clients, several modes of 382 operation exist: 384 o One mode of ALTO operation is that an ALTO client may be embedded 385 directly in the resource consumer, i.e., the application protocol 386 entity that will eventually initiate data transmission to/from the 387 selected resource provider(s) in order to access the desired 388 resource. For example, an ALTO client could be integrated into 389 the peer of a P2P application that uses a distributed algorithm 390 such as "query flooding" for resource discovery. 392 o Another mode of operation is to integrate the ALTO client into a 393 third party such as a resource directory. This third party may 394 issue ALTO queries to solicit preference on potential resource 395 providers, considering the respective resource consumer. For 396 example, an ALTO client could be integrated into the tracker of a 397 tracker-based P2P application, in order to request ALTO guidance 398 on behalf of the peers contacting the tracker. 400 REQ. ARv16-18: An ALTO client protocol MUST support the mode of 401 operation in which the ALTO client is directly embedded in the 402 resource consumer. 404 REQ. ARv16-19: An ALTO client protocol MUST support the mode of 405 operation in which the ALTO client is embedded in a third party. 406 This third party performs queries on behalf of resource consumers. 408 REQ. ARv16-20: An ALTO client protocol MUST be designed in a way 409 that the ALTO service can be provided by an entity that is not the 410 operator of the underlying IP network. 412 REQ. ARv16-21: An ALTO client protocol MUST be designed in a way 413 that different instances of the ALTO service operated by different 414 providers can coexist. 416 REQ. ARv16-22: An ALTO client protocol specification MUST specify at 417 least one query mode, either the target-aware or the target- 418 independent query mode. 420 Note that this requirements document does not assume that there will 421 be only one single protocol specification. 423 REQ. ARv16-23: An ALTO client protocol specification SHOULD specify 424 both the target-aware and the target-independent query mode. If an 425 ALTO client protocol specification specifies more than one query 426 mode, it MUST define at least one of these modes as REQUIRED to 427 implement by ALTO Clients and ALTO Servers. Furthermore, it MUST 428 specify an appropriate protocol mechanism for negotiating between 429 ALTO Client and ALTO Server, which query mode to use. 431 REQ. ARv16-24: An ALTO client protocol SHOULD support version 432 numbering, TTL (time-to-live) attributes, and/or similar mechanisms 433 in ALTO transactions, in order to enable time validity checking for 434 caching, and to enable comparisons of multiple recommendations 435 obtained through redistribution. 437 REQ. ARv16-25: An ALTO client protocol SHOULD allow the ALTO server 438 to add information about appropriate modes of re-use to its ALTO 439 responses. Re-use may include redistributing an ALTO response to 440 other parties, as well as using the same ALTO information in a 441 resource directory to improve the responses to different resource 442 consumers, within the specified lifetime of the ALTO response. The 443 ALTO server SHOULD be able to express that 445 o no re-use should occur 447 o re-use is appropriate for a specific "target audience", i.e., a 448 set of resource consumers explicitly defined by a list of host 449 group descriptors. The ALTO server MAY specify a "target 450 audience" in the ALTO response that is only a subset of the known 451 actual "target audience", e.g., if required by operator policies 453 o re-use is appropriate for any resource consumer that would send 454 (or cause a third party sending on behalf of it) the same ALTO 455 query (i.e., with the same query parameters, except for the 456 resource consumer ID, if applicable) to this ALTO server 458 o re-use is appropriate for any resource consumer that would send 459 (or cause a third party sending on behalf of it) the same ALTO 460 query (i.e., with the same query parameters, except for the 461 resource consumer ID, if applicable) to any other ALTO server that 462 was discovered (using an ALTO discovery mechanism) together with 463 this ALTO server 465 o re-use is appropriate for any resource consumer that would send 466 (or cause a third party sending on behalf of it) the same ALTO 467 query (i.e., with the same query parameters, except for the 468 resource consumer ID, if applicable) to any ALTO server in the 469 whole network 471 REQ. ARv16-26: An ALTO client protocol MUST support the transport of 472 ALTO transactions even if the ALTO client is located in the private 473 address realm behind a network address translator (NAT). There are 474 different types of NAT, see [RFC4787] and [RFC5382]. 476 3.1.5. Protocol Extensibility 478 REQ. ARv16-27: An ALTO client protocol MUST include support for 479 adding protocol extensions in a non-disruptive, backward-compatible 480 way. 482 REQ. ARv16-28: An ALTO client protocol MUST include protocol 483 versioning support, in order to clearly distinguish between 484 incompatible versions of the protocol. 486 3.1.6. Error Handling and Overload Protection 488 REQ. ARv16-29: An ALTO client protocol MUST use congestion-aware 489 transport, e.g., by using TCP. 491 REQ. ARv16-30: An ALTO client protocol specification MUST specify 492 mechanisms, or detail how to leverage appropriate mechanisms provided 493 by underlying protocol layers that can be used by an ALTO server to 494 inform clients about an impending or occurring overload situation, 495 and provide all of the following options to the server: 497 o terminate the conversation with the client, 499 o redirect the client to another ALTO server, and 501 o request the client to throttle its query rate. 503 In particular, a simple form of throttling is to let an ALTO 504 server answer a query with an error message advising the client to 505 retry the query later (e.g, using a protocol function such as 506 HTTP's Retry-After header ([RFC2616], section 14.37). Another 507 simple option is to actually answer the query with the desired 508 information, but adding an indication that the ALTO client should 509 not send further queries to this ALTO server before an indicated 510 period of time has elapsed. 512 REQ. ARv16-31: An ALTO client protocol specification MUST specify 513 mechanisms, or detail how to leverage appropriate mechanisms provided 514 by underlying protocol layers that can be used by an ALTO server to 515 inform clients about its inability to answer queries due to technical 516 problems or system maintenance, and provide all of the following 517 options to the server: 519 o terminate the conversation with the client, 521 o redirect the client to another ALTO server, and 523 o request the client to retry the query later. 525 Note: The existence of the above-mentioned protocol mechanisms does 526 not imply that an ALTO server must use them when facing an overload, 527 technical problem, or maintenance situation, respectively. Some 528 servers may be unable to use them in that situation, or they may 529 prefer to simply refuse the connection or not to send any answer at 530 all. 532 3.2. ALTO Server Discovery 534 An ALTO client protocol is supported by one or more ALTO server 535 discovery mechanisms, which may be used by ALTO clients in order to 536 determine one or more ALTO servers, to which ALTO requests can be 537 sent. This section enumerates requirements for an ALTO client, as 538 well as general requirements to be fulfilled by the ALTO server 539 discovery mechanisms. 541 REQ. ARv16-32: An ALTO server discovery mechanism MUST support 542 features allowing ALTO clients that are embedded in the resource 543 consumer to find one or several ALTO servers that can provide ALTO 544 guidance suitable for the resource consumer, using an ALTO protocol 545 version compatible with the ALTO client. This mode of operation is 546 called "resource consumer initiated ALTO server discovery". 548 REQ. ARv16-33: An ALTO server discovery mechanism MUST support 549 features allowing ALTO clients that are embedded in a resource 550 directory and perform third-party ALTO queries on behalf of a remote 551 resource consumer to find one or several ALTO servers that can 552 provide ALTO guidance suitable for the respective resource consumer, 553 using an ALTO protocol version compatible with the ALTO client. This 554 mode of operation is called "third-party ALTO server discovery". 556 REQ. ARv16-34: ALTO clients MUST be able to perform resource 557 consumer initiated ALTO server discovery, even if they are located 558 behind a network address translator (NAT). 560 REQ. ARv16-35: ALTO clients MUST be able to perform third-party ALTO 561 server discovery, even if they are located behind a network address 562 translator (NAT). 564 REQ. ARv16-36: ALTO clients MUST be able to perform third-party ALTO 565 server discovery, even if the resource consumer, on behalf of which 566 the ALTO query will be sent, is located behind a network address 567 translator (NAT). 569 REQ. ARv16-37: ALTO server discovery mechanisms SHOULD leverage an 570 existing protocol or mechanism, such as DNS, DHCP, or PPP based 571 automatic configuration, etc. A single mechanism with a broad 572 spectrum of applicability SHOULD be preferred over several different 573 mechanisms with narrower scopes. 575 REQ. ARv16-38: Every ALTO server discovery mechanism SHOULD be able 576 to return the respective contact information for multiple ALTO 577 servers. 579 REQ. ARv16-39: Every ALTO server discovery mechanism SHOULD be able 580 to indicate preferences for each returned ALTO server contact 581 information. 583 3.3. Security and Privacy 585 Note: The following requirements mandate the inclusion of certain 586 security mechanisms at a protocol specification level. Whether it 587 makes sense to enable these mechanisms in a given deployment scenario 588 depends on a threat analysis for this specific scenario. For a 589 classification of potential information disclosure risks refer to 590 Section 5.2. 592 REQ. ARv16-40: An ALTO client protocol specification MUST specify 593 mechanisms for the authentication of ALTO servers, or how to leverage 594 appropriate mechanisms provided by underlying protocol layers. 596 REQ. ARv16-41: An ALTO client protocol specification MUST specify 597 mechanisms for the authentication of ALTO clients, or how to leverage 598 appropriate mechanisms provided by underlying protocol layers. 600 REQ. ARv16-42: An ALTO client protocol specification MUST specify 601 mechanisms for the encryption of messages, or how to leverage 602 appropriate mechanisms provided by underlying protocol layers. 604 REQ. ARv16-43: An ALTO client is not required to implement 605 mechanisms or to comply with rules that limit its ability to 606 redistribute information retrieved from the ALTO server to third 607 parties. 609 REQ. ARv16-44: An ALTO client protocol MUST support different levels 610 of detail in queries and responses, in order to protect the privacy 611 of users, to ensure that the operators of ALTO servers and other 612 users of the same application cannot derive sensitive information. 614 REQ. ARv16-45: An ALTO client protocol MAY include mechanisms that 615 can be used by the ALTO client when requesting guidance to specify 616 the resource (e.g., content identifiers) it wants to access. An ALTO 617 server MUST provide adequate guidance even if the ALTO client prefers 618 not to specify the desired resource (e.g., keeps the data field 619 empty). The mechanism MUST be designed in a way that the operator of 620 the ALTO server cannot easily deduce the resource identifier (e.g., 621 file name in P2P file sharing) if the ALTO client prefers not to 622 specify it. 624 REQ. ARv16-46: An ALTO client protocol specification MUST specify 625 appropriate mechanisms for protecting the ALTO service against DoS 626 attacks, or how to leverage appropriate mechanisms provided by 627 underlying protocol layers. 629 4. IANA Considerations 631 This requirements document does not mandate any immediate IANA 632 actions. However, such IANA considerations may arise from future 633 ALTO specification documents, which try to meet the requirements 634 given here. 636 5. Security Considerations 638 5.1. High-level security considerations 640 High-level security considerations for the ALTO service can be found 641 in the "Security Considerations" section of the ALTO problem 642 statement document [RFC5693]. 644 5.2. Information Disclosure Scenarios 646 The unwanted disclosure of information is one key concern related to 647 ALTO. Neither the ALTO server nor a third party using or misusing 648 the ALTO service should be able to infer the application behavior or 649 correlate data in such a way that would violate user privacy, e.g., 650 who is exchanging which files with whom using a P2P file sharing 651 application. Furthermore, many network operators are concerned about 652 the amount of information related to their network infrastructure 653 (e.g., topology information, number of "premium customers", or 654 utilization statistics) that might be released through ALTO. This 655 section presents a classification and discussion of information 656 disclosure scenarios and potential countermeasures. 658 5.2.1. Classification of Information Disclosure Scenarios 660 The following issues may be considered a risk for the operator of an 661 ALTO server, depending on the specific deployment scenario: 663 o (1) Excess disclosure of ALTO server operator's data to an 664 authorized ALTO client. The operator of an ALTO server has to 665 feed information, such as tables mapping host group descriptors to 666 host characteristics attributes, into the server, thereby enabling 667 it to give guidance to ALTO clients. Some operators might 668 consider the full set of this information confidential (e.g., a 669 detailed map of the operator's network topology), and might want 670 to disclose only a subset of it or somehow obfuscated information 671 to an ALTO client. 673 o (2) Disclosure of ALTO server operator's data (e.g., network 674 topology information) to an unauthorized third party. There are a 675 three sub-cases here: 677 * (2a) An ALTO server receives and answers queries originating 678 from an unauthorized ALTO client. 680 * (2b) An unauthorized party snoops on the data transmission from 681 the ALTO server to an authorized ALTO client. 683 * (2c) An authorized ALTO client knowingly forwards the 684 information it had received from the ALTO server to an 685 unauthorized party. 687 o (3) Excess retrieval of ALTO server operator's data by 688 collaborating ALTO clients. Several authorized ALTO clients could 689 ask one or more ALTO servers for guidance, possibly several times 690 during an extended period of time, and redistribute the responses 691 among each other (see also case 2c). By aggregating and 692 correlating the ALTO responses they could find out more 693 information than intended to be disclosed by the ALTO server 694 operator(s). 696 The following issues may be considered a risk for the user of an ALTO 697 client, depending on the specific deployment scenario: 699 o (4) Disclosure of the application behavior or other user private 700 data to the (authorized) ALTO server. The operator of an ALTO 701 server could infer the application behavior (e.g., content 702 identifiers in P2P file sharing applications, or lists of resource 703 providers that are considered for establishing a connection) from 704 the ALTO queries sent by an ALTO client. 706 o (5) Disclosure of the application behavior or other user private 707 data to an unauthorized third party. There are a three sub-cases 708 here: 710 * (5a) An ALTO client willingly sends queries directly to an 711 untrusted or malicious ALTO server, possibly due to a forged 712 response of the ALTO server discovery mechanism. 714 * (5b) An unauthorized party snoops on the data transmission from 715 the ALTO client to an authorized ALTO server. 717 * (5c) An authorized ALTO server knowingly forwards the 718 information it had received from the ALTO client to an 719 unauthorized party. 721 o (6) One or several collaborating (see case 5c) ALTO servers could 722 try to infer the application behavior or other user private data 723 by aggregating and correlating queries from one or more ALTO 724 clients, possibly over an extended period of time. 726 5.2.2. Discussion of Information Disclosure Scenarios 728 An ALTO server operator should consider: 730 o Issue (1) may be addressed by the ALTO server operator choosing 731 the level of detail of the information to be populated into the 732 ALTO server and returned in the responses. For example, by 733 specifying a broader address range (i.e., a shorter prefix length) 734 than a group of hosts in question actually uses, an ALTO server 735 operator may control to some extent how much information about the 736 network topology is disclosed. Furthermore, access control 737 mechanisms for filtering ALTO responses according to the 738 authenticated ALTO client identity might be installed in the ALTO 739 server, although this might not be effective given the lack of 740 efficient mechanisms for addressing (2c) and (3), see below. 742 o (2a) and (2b) may be addressed by authentication, access control, 743 and encryption schemes for the ALTO client protocol. However, 744 deployment of encryption schemes might not be effective given the 745 lack of efficient mechanisms for addressing (2c) and (3), see 746 below. 748 o Straightforward authentication and encryption schemes will not 749 help solving (2c) and (3), and there is no other simple and 750 efficient mechanism known. The cost of complex approaches, e.g., 751 based on digital rights management (DRM), might easily outweigh 752 the benefits of the whole ALTO solution, and therefore they are 753 not considered as a viable solution. That is, ALTO server 754 operators must be aware that (2c) and (3) cannot be prevented from 755 happening, and therefore they should feed only such data into an 756 ALTO server that they do not consider sensitive with respect to 757 (2c) and (3). 759 A user of an ALTO client should consider: 761 o Issue (4) can and needs to be addressed in several ways: If the 762 ALTO client is embedded in the resource consumer, the resource 763 consumer's IP address (or the "public" IP address of the outermost 764 NAT in front of the resource consumer) is disclosed to the ALTO 765 server as a matter of principle, because it is in the source 766 address fields of the IP headers. By using a proxy, the 767 disclosure of source addresses to the ALTO server can be avoided 768 at the cost of disclosing them to said proxy. If, in contrast, 769 the ALTO client is embedded in a third party (e.g., a resource 770 directory), which issues ALTO requests on behalf of resource 771 consumers, it is possible to hide the exact addresses of the 772 resource consumers from the ALTO server, e.g., by zeroing-out or 773 randomizing the last few bits of IP addresses. However, there is 774 the potential side effect of yielding inaccurate results. 776 The disclosure of candidate resource providers' addresses to the 777 ALTO server can be avoided by allowing ALTO clients to use the 778 target-independent query mode. In this mode of operation, guiding 779 information (e.g., "maps") is retrieved from the ALTO server and 780 used entirely locally by the ALTO client, i.e., without sending 781 host location attributes of candidate resource providers to the 782 ALTO server. In the target-aware query mode, this issue can be 783 addressed by ALTO clients through obfuscating the identity of 784 candidate resource consumers, e.g., by specifying a broader 785 address range (i.e., a shorter prefix length) than a group of 786 hosts in question actually uses, or by zeroing-out or randomizing 787 the last few bits of IP addresses. However, there is the 788 potential side effect of yielding inaccurate results. 790 o (5a) may be addressed by mandating that the ALTO server discovery 791 procedure as a whole must be secure against spoofing. 793 Note: Given that this document does not mandate a specific system 794 architecture, it is difficult to specify more details than that 795 the discovery procedure as a whole should be secure against 796 spoofing. There are many different archtectural options, e.g., 797 have an insecure discovery mechanism and use server certificates 798 to later verify its response (c.f. the DNS + HTTPS security model 799 widely used in the World Wide Web). Therefore, at this 800 requirements stage, it is not mandatory for the discovery 801 mechanism itself to be secure against spoofing attacks. 803 o (5b) may be addressed by encryption schemes for the ALTO client 804 protocol. However, the effort vs. benefit should be evaluated for 805 any specific deployment scenario, while also considering the risks 806 and solution approaches for issues (4), (5c), and (6). 808 o Straightforward authentication and encryption schemes will not 809 help solving (5c) and (6). However, potential risks can be 810 mitigated using the same approaches as used for issue (4), see 811 above. 813 These insights are reflected in the requirements in this document. 815 5.3. ALTO Server Discovery 817 See discussion of (5a) above. 819 5.4. Security Requirements 821 For a set of specific security requirements please refer to 822 Section 3.3 of this document. 824 6. References 826 6.1. Normative References 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, March 1997. 831 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 832 Optimization (ALTO) Problem Statement", RFC 5693, 833 October 2009. 835 6.2. Informative References 837 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 838 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 839 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 841 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 842 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 843 RFC 4787, January 2007. 845 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 846 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 847 RFC 5382, October 2008. 849 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 850 Management of New Protocols and Protocol Extensions", 851 RFC 5706, November 2009. 853 Appendix A. Contributors List and Acknowledgments 855 The initial version of this document was co-authored by Laird Popkin. 857 The authors would like to thank 859 o Vijay K. Gurbani 861 o Enrico Marocco 863 for fostering discussions that lead to the creation of this document, 864 and for giving valuable comments on it. 866 The authors were supported by the following people, who have 867 contributed to this document: 869 o Richard Alimi 871 o Jason Livingood 873 o Michael Scharf 875 o Nico Schwan 877 o Jan Seedorf 879 The authors would like to thank the members of the P2PI and ALTO 880 mailing lists for their feedback. 882 Laird Popkin and Y. Richard Yang are grateful to the many 883 contributions made by the members of the P4P working group and Yale 884 Laboratory of Networked Systems. The P4P working group is hosted by 885 DCIA. 887 Martin Stiemerling is partially supported by the COAST project 888 (COntent Aware Searching, retrieval and sTreaming, 889 http://www.coast-fp7.eu), a research project supported by the 890 European Commission under its 7th Framework Program (contract no. 891 248036). The views and conclusions contained herein are those of the 892 authors and should not be interpreted as necessarily representing the 893 official policies or endorsements, either expressed or implied, of 894 the COAST project or the European Commission. 896 Authors' Addresses 898 Sebastian Kiesel (editor) 899 University of Stuttgart Computing Center 900 Networks and Communication Systems Department 901 Allmandring 30 902 70550 Stuttgart 903 Germany 905 Email: ietf-alto@skiesel.de 906 URI: http://www.rus.uni-stuttgart.de/nks/ 908 Stefano Previdi 909 Cisco Systems, Inc. 911 Email: sprevidi@cisco.com 913 Martin Stiemerling 914 NEC Laboratories Europe 916 Email: martin.stiemerling@neclab.eu 917 URI: http://ietf.stiemerling.org 919 Richard Woundy 920 Comcast Corporation 922 Email: Richard_Woundy@cable.comcast.com 924 Yang Richard Yang 925 Yale University 927 Email: yry@cs.yale.edu