idnits 2.17.1 draft-ietf-alto-reqs-14.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 (April 19, 2012) is 4389 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: October 21, 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 April 19, 2012 14 Application-Layer Traffic Optimization (ALTO) Requirements 15 draft-ietf-alto-reqs-14.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 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 29 (or Quality of Experience) in the application while reducing resource 30 consumption in 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 October 21, 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 . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. ALTO Client Protocol . . . . . . . . . . . . . . . . . . . 7 75 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 7 76 3.1.2. Host Group Descriptor Support . . . . . . . . . . . . 7 77 3.1.3. Rating Criteria Support . . . . . . . . . . . . . . . 8 78 3.1.4. Placement of Entities and Timing of Transactions . . . 9 79 3.1.5. Protocol Extensibility . . . . . . . . . . . . . . . . 11 80 3.1.6. Error Handling and Overload Protection . . . . . . . . 12 81 3.2. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 13 82 3.3. Security and Privacy . . . . . . . . . . . . . . . . . . . 14 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 5.1. High-level security considerations . . . . . . . . . . . . 17 86 5.2. Information Disclosure Scenarios . . . . . . . . . . . . . 17 87 5.2.1. Classification of Information Disclosure Scenarios . . 17 88 5.2.2. Discussion of Information Disclosure Scenarios . . . . 18 89 5.3. Security Requirements . . . . . . . . . . . . . . . . . . 19 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 92 6.2. Informative References . . . . . . . . . . . . . . . . . . 20 93 Appendix A. Contributors List and Acknowledgments . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 The motivation for Application-Layer Traffic Optimization (ALTO) is 99 described in the ALTO problem statement [RFC5693]. 101 The goal of ALTO is to provide information which can help peer-to- 102 peer (P2P) applications to make better decisions with respect to peer 103 selection. However, ALTO may be useful for non-P2P applications as 104 well. For example, clients of client-server applications may use 105 information provided by ALTO to select one of several servers or 106 information replicas. As another example, ALTO information could be 107 used to select a media relay needed for NAT traversal. The goal of 108 these informed decisions is to improve performance or Quality of 109 Experience in the application while reducing resource consumption in 110 the underlying network infrastructure. 112 Usually, it would be difficult or even impossible for application 113 entities to acquire this information by other mechanisms, e.g., using 114 measurements between the peers of a P2P overlay, because of 115 complexity or because it is based on network topology information, 116 network operational costs, or network policies, which the respective 117 network provider does not want to disclose in detail. 119 The functional entities that provide the ALTO service do not take 120 part in the actual user data transport, i.e., they do not implement 121 functions for relaying user data. These functional entities may be 122 placed on various kinds of physical nodes, e.g., on dedicated 123 servers, as auxiliary processes in routers, on "trackers" or "super 124 peers" of a P2P application, etc. 126 2. Terminology and Architectural Framework 128 2.1. Requirements Notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2.2. ALTO Terminology 136 This document uses the following ALTO-related terms, which are 137 defined in [RFC5693]: 139 Application, Peer, P2P, Resource, Resource Identifier, Resource 140 Provider, Resource Consumer, Transport Address, Overlay Network, 141 Resource Directory, ALTO Service, ALTO Server, ALTO Client, ALTO 142 Query, ALTO Response, ALTO Transaction, Local Traffic, Peering 143 Traffic, Transit Traffic, Application protocol, ALTO Client Protocol, 144 Provisioning protocol. 146 Furthermore, the following additional terms will be used: 148 o Host Group Descriptor: Information used to describe one or more 149 Internet hosts (such as the resource consumer which seeks ALTO 150 guidance, or one or more candidate resource providers) and their 151 location within the network topology. There can be several 152 different types of host group descriptors, for example, a single 153 IP address, an address prefix or address range that contains the 154 host(s), or an autonomous system (AS) number. Different host 155 group descriptor types may provide different levels of detail. 156 Depending on the system architecture, this may have implications 157 on the quality of the guidance ALTO is able to provide, on whether 158 recommendations can be aggregated, and on how much privacy- 159 sensitive information about users might be disclosed to additional 160 parties. 162 o Rating Criterion: The condition or relation that defines the 163 "better" in "better-than-random peer selection", which is the 164 ultimate goal of ALTO. Examples may include "host's Internet 165 access is not subject to volume based charging (flat rate)" or 166 "low topological distance". Some rating criteria, such as "low 167 topological distance", need to include a reference point, i. e., 168 "low topological distance from a given resource consumer". This 169 reference point can be described by means of a host group 170 descriptor. 172 o Host Characteristics Attribute: Properties of a host, other than 173 the host group descriptor. It may be evaluated according to one 174 or more rating criteria. This information may be stored in an 175 ALTO server and transmitted via an ALTO protocol. One example for 176 a host characteristics attribute would be a data field indicating 177 whether a host's Internet access is subject to volume based 178 charging or not (flat rate). 180 o Target-Aware Query Mode: In this mode of operation, an ALTO client 181 performs the ALTO query when the desired resource and a set of 182 candidate resource providers are already known, i. e., after DHT 183 lookups, queries to the resource directory, etc. To this end the 184 ALTO client transmits a list of host group descriptors and 185 optionally one or more rating criteria to the ALTO server. The 186 ALTO server evaluates the host group descriptors according to the 187 indicated criteria or a default criterion. It returns a list of 188 these host group descriptors to the ALTO client, which is sorted 189 according to the rating criteria and/or enriched with host 190 characteristic attributes. 192 o Target-Independent Query Mode: In this mode of operation, ALTO 193 queries are performed in advance or periodically, in order to 194 receive comprehensive guidance. The ALTO client indicates the 195 desired host characteristic attributes in the ALTO query. The 196 ALTO server answers with a list that indicates for all known host 197 group descriptors (possibly subject to the server's policies) the 198 desired host characteristic attributes. These lists will be 199 cached locally and evaluated later, when a resource is to be 200 accessed. 202 2.3. Architectural Framework for ALTO 204 There are various architectural options for how ALTO could be 205 implemented, and specifying or mandating one specific architecture is 206 out of the scope of this document. 208 The ALTO problem statement [RFC5693] defines a terminology (see 209 Section 2 of [RFC5693] and Section 2.2 of this document), introduces 210 several components. It presents a figure that gives a high-level 211 overview of protocol interaction between these components. 213 This document itemizes requirements for the following components: 214 ALTO client protocols, ALTO server discovery mechanisms, host group 215 descriptors, rating criteria, and host characteristics attributes. 216 Furthermore, requirements regarding the overall architecture, 217 especially with respect to security and privacy issues, are 218 presented. 220 3. ALTO Requirements 222 [*** Note to the RFC editor: before publication as an RFC, please 223 remove the draft version number from the requirements numbering, 224 i.e., change ARv14-1 to AR-1, and so on. Furthermore, remove this 225 note. ***] 227 3.1. ALTO Client Protocol 229 3.1.1. General Requirements 231 REQ. ARv14-1: The ALTO service is provided by one or more ALTO 232 servers. It may be queried by ALTO clients seeking guidance for 233 selecting appropriate resource providers. ALTO clients and ALTO 234 servers MUST implement an ALTO client protocol. An ALTO client 235 protocol MUST be able to transmit ALTO queries from an ALTO client to 236 an ALTO server, and it MUST be able to transmit the corresponding 237 ALTO replies from the ALTO server to the ALTO client. 239 The detailed specification of an ALTO client protocol is out of the 240 scope of this document. In fact, this document does not even assume 241 that there is only one single protocol specification. However, this 242 document enumerates requirements for ALTO, to be considered when 243 specifying, assessing, or comparing protocols and implementations. 245 3.1.2. Host Group Descriptor Support 247 The ALTO guidance is based on the evaluation of several resource 248 providers or groups of resource providers, considering one or more 249 rating criteria. The resource providers or groups of resource 250 providers are characterized by means of host group descriptors. 252 REQ. ARv14-2: The ALTO client protocol MUST support the usage of 253 multiple host group descriptor types. 255 REQ. ARv14-3: ALTO clients and ALTO servers MUST clearly identify 256 the type of each host group descriptor sent in ALTO queries or 257 responses. 259 REQ. ARv14-4: An ALTO client protocol MUST support the host group 260 descriptor types "IPv4 address prefix" and "IPv6 address prefix". 261 They can be used to specify the IP address of one host, or an IP 262 address range (in CIDR notation) containing all hosts in question. 264 REQ. ARv14-5: An ALTO client protocol MUST be extensible to enable 265 support of other host group descriptor types in future. An ALTO 266 client protocol specification MUST define an appropriate procedure 267 for adding new host group descriptor types, e.g., by establishing an 268 IANA registry. 270 REQ. ARv14-6: For host group descriptor types other than "IPv4 271 address prefix" and "IPv6 address prefix", the host group descriptor 272 type identification MUST be supplemented by a reference to a 273 facility, which can be used to translate host group descriptors of 274 that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping 275 table or an algorithm. 277 REQ. ARv14-7: Protocol functions for mapping other host group 278 descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and 279 specified as part of an ALTO client protocol, and the corresponding 280 address mapping information SHOULD be made available by the same 281 entity that wants to use these host group descriptors within an ALTO 282 client protocol. However, an ALTO server or an ALTO client MAY also 283 send a reference to an external mapping facility, e.g., a translation 284 table to be obtained via an alternative mechanism. 286 REQ. ARv14-8: An ALTO client protocol specification MUST define 287 mechanisms that can be used by the ALTO server to indicate that a 288 host group descriptor used by the ALTO client is of an unsupported 289 type, or that the indicated mapping mechanism could not be used. 291 REQ. ARv14-9: An ALTO client protocol specification MUST define 292 mechanisms, which can be used by the ALTO client to indicate that a 293 host group descriptor used by the ALTO server is of an unsupported 294 type, or that the indicated mapping mechanism could not be used. 296 3.1.3. Rating Criteria Support 298 REQ. ARv14-10: An ALTO client protocol specification MUST define a 299 rating criterion that can be used to express and evaluate the 300 "relative operator's preference." This is a relative measure, i.e., 301 it is not associated with any unit of measurement. A more-preferred 302 rating according to this criterion indicates that the application 303 should prefer the respective candidate resource provider over others 304 with less-preferred ratings (unless information from non-ALTO sources 305 suggests a different choice, such as transmission attempts suggesting 306 that the path is currently congested). The operator of the ALTO 307 server does not have to disclose how and based on which data the 308 ratings are actually computed. Examples could be: cost for peering 309 or transit traffic, traffic engineering inside the network, and other 310 policies. 312 REQ. ARv14-11: An ALTO client protocol MUST be extensible to enable 313 support of other rating criteria types in future. An ALTO client 314 protocol specification MUST define an appropriate procedure for 315 adding new rating criteria types, e.g., by establishing an IANA 316 registry. 318 REQ. ARv14-12: ALTO client protocol specifications MUST NOT define 319 rating criteria closely related to the instantaneous network 320 congestion state, i. e., rating criteria that have the primary aim to 321 serve as an alternative to established congestion control strategies, 322 such as using TCP-based transport. 324 One design assumption for ALTO is that it is acceptable that the 325 host characteristics attributes, which are stored and processed in 326 the ALTO servers for giving the guidance, are updated rather 327 infrequently. Typical update intervals may be several orders of 328 magnitude longer than the typical network-layer packet round-trip 329 time (RTT). Therefore, ALTO cannot be a replacement for TCP-like 330 congestion control mechanisms. 332 REQ. ARv14-13: Applications using ALTO guidance MUST NOT rely solely 333 on the ALTO guidance to avoid causing network congestion. Instead, 334 applications MUST use other appropriate means, such as TCP based 335 transport, to avoid causing excessive congestion. 337 REQ. ARv14-14: In the target-independent query mode, the ALTO query 338 message SHOULD allow the ALTO client to express which host 339 characteristics attributes should be returned. 341 REQ. ARv14-15: In the target-aware query mode, the ALTO query 342 message SHOULD allow the ALTO client to express which rating criteria 343 should be considered by the server, as well as their relative 344 relevance for the specific application that will eventually make use 345 of the guidance. The corresponding ALTO response message SHOULD 346 allow the ALTO server to express which rating criteria have been 347 considered when generating the response. 349 REQ. ARv14-16: An 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. This third party may 369 issue ALTO queries to solicit preference on potential resource 370 providers, considering the respective resource consumer. For 371 example, an ALTO client could be integrated into the tracker of a 372 tracker-based P2P application, in order to request ALTO guidance 373 on behalf of the peers contacting the tracker. 375 REQ. ARv14-17: An 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. ARv14-18: An ALTO client protocol MUST support the mode of 380 operation in which the ALTO client is embedded in a third party. 381 This third party performs queries on behalf of resource consumers. 383 REQ. ARv14-19: An 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 underlying IP network. 387 REQ. ARv14-20: An 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 REQ. ARv14-21: An ALTO client protocol specification MUST specify at 392 least one query mode, either the target-aware or the target- 393 independent query mode. 395 Note that this requirements document does not assume that there is 396 only one single protocol specification. 398 REQ. ARv14-22: An ALTO client protocol specification SHOULD specify 399 both the target-aware and the target-independent query mode. If an 400 ALTO client protocol specification specifies more than one query 401 mode, it MUST define at least one of these modes as REQUIRED to 402 implement by ALTO Clients and ALTO Servers. Furthermore, it MUST 403 specify an appropriate protocol mechanism for negotiating between 404 ALTO Client and ALTO Server, which query mode to use. 406 REQ. ARv14-23: An ALTO client protocol SHOULD support version 407 numbering, TTL (time-to-live) attributes, and/or similar mechanisms 408 in ALTO transactions, in order to enable time validity checking for 409 caching, and to enable comparisons of multiple recommendations 410 obtained through redistribution. 412 REQ. ARv14-24: An ALTO client protocol SHOULD allow the ALTO server 413 to add information about appropriate modes of re-use to its ALTO 414 responses. Re-use may include redistributing an ALTO response to 415 other parties, as well as using the same ALTO information in a 416 resource directory to improve the responses to different resource 417 consumers, within the specified lifetime of the ALTO response. The 418 ALTO server SHOULD be able to express that 420 o no re-use should occur 422 o re-use is appropriate for a specific "target audience", i.e., a 423 set of resource consumers explicitly defined by a list of host 424 group descriptors. The ALTO server MAY specify a "target 425 audience" in the ALTO response, which is only a subset of the 426 known actual "target audience", e.g., if required by operator 427 policies 429 o re-use is appropriate for any resource consumer that would send 430 (or cause a third party sending on behalf of it) the same ALTO 431 query (i.e., with the same query parameters, except for the 432 resource consumer ID, if applicable) to this ALTO server 434 o re-use is appropriate for any resource consumer that would send 435 (or cause a third party sending on behalf of it) the same ALTO 436 query (i.e., with the same query parameters, except for the 437 resource consumer ID, if applicable) to any other ALTO server, 438 which was discovered (using an ALTO discovery mechanism) together 439 with this ALTO server 441 o re-use is appropriate for any resource consumer that would send 442 (or cause a third party sending on behalf of it) the same ALTO 443 query (i.e., with the same query parameters, except for the 444 resource consumer ID, if applicable) to any ALTO server in the 445 whole network 447 REQ. ARv14-25: An ALTO client protocol MUST support the transport of 448 ALTO transactions even if the ALTO client is located in the private 449 address realm behind a network address translator (NAT). There are 450 different types of NAT, see [RFC4787] and [RFC5382]. 452 3.1.5. Protocol Extensibility 454 REQ. ARv14-26: An ALTO client protocol MUST include support for 455 adding protocol extensions in a non-disruptive, backward-compatible 456 way. 458 REQ. ARv14-27: An ALTO client protocol MUST include protocol 459 versioning support, in order to clearly distinguish between 460 incompatible versions of the protocol. 462 3.1.6. Error Handling and Overload Protection 464 REQ. ARv14-28: An ALTO client protocol MUST use TCP based transport. 466 REQ. ARv14-29: An ALTO client protocol specification MUST specify 467 mechanisms, or detail how to leverage appropriate mechanisms provided 468 by underlying protocol layers, which can be used by an ALTO server to 469 inform clients about an impending or occurring overload situation, 470 and request them to throttle their query rate. 472 In particular, a simple form of throttling is to let an ALTO server 473 answer a query with an error message advising the client to retry the 474 query later (e.g, using a protocol function such as HTTP's Retry- 475 After header ([RFC2616], section 14.37). Another simple option is to 476 actually answer the query with the desired information, but adding an 477 indication that the ALTO client should not send further queries to 478 this ALTO server before an indicated period of time has elapsed. 480 REQ. ARv14-30: An ALTO client protocol specification MUST specify 481 mechanisms, or detail how to leverage appropriate mechanisms provided 482 by underlying protocol layers, which can be used by an ALTO server to 483 inform clients about an impending or occurring overload situation, 484 and redirect them to another ALTO server. 486 REQ. ARv14-31: An ALTO client protocol specification MUST specify 487 mechanisms, or detail how to leverage appropriate mechanisms provided 488 by underlying protocol layers, which can be used by an ALTO server to 489 inform clients about an impending or occurring overload situation, 490 and terminate the conversation with the ALTO client. 492 REQ. ARv14-32: An ALTO client protocol specification MUST specify 493 mechanisms, or detail how to leverage appropriate mechanisms provided 494 by underlying protocol layers, which can be used by an ALTO server to 495 inform clients about its inability to answer queries due to technical 496 problems or system maintenance, and advise them to retry the query 497 later. 499 REQ. ARv14-33: An ALTO client protocol specification MUST specify 500 mechanisms, or detail how to leverage appropriate mechanisms provided 501 by underlying protocol layers, which can be used by an ALTO server to 502 inform clients about its inability to answer queries due to technical 503 problems or system maintenance, and redirect them to another ALTO 504 server. 506 REQ. ARv14-34: An ALTO client protocol specification MUST specify 507 mechanisms, or detail how to leverage appropriate mechanisms provided 508 by underlying protocol layers, which can be used by an ALTO server to 509 inform clients about its inability to answer queries due to technical 510 problems or system maintenance, and terminate the conversation with 511 the ALTO client. 513 Note: The existence of the above-mentioned protocol mechanisms does 514 not imply that an ALTO server must use them when facing an overload, 515 technical problem, or maintenance situation, respectively. Some 516 servers may be unable to use them in that situation, or they may 517 prefer to simply refuse the connection or not to send any answer at 518 all. 520 3.2. ALTO Server Discovery 522 An ALTO client protocol is supported by one or more ALTO server 523 discovery mechanisms, which may be used by ALTO clients in order to 524 determine one or more ALTO servers, to which ALTO requests can be 525 sent. This section enumerates requirements for an ALTO client, as 526 well as general requirements to be fulfilled by the ALTO server 527 discovery mechanisms. 529 REQ. ARv14-35: ALTO clients which are embedded in the resource 530 consumer MUST be able to use an ALTO server discovery mechanism, in 531 order to find one or several ALTO servers that can provide ALTO 532 guidance suitable for the resource consumer. This mode of operation 533 is called "resource consumer initiated ALTO server discovery". 535 REQ. ARv14-36: ALTO clients which are embedded in a resource 536 directory and perform third-party ALTO queries on behalf of a remote 537 resource consumer MUST be able to use an ALTO server discovery 538 mechanism, in order to find one or several ALTO servers that can 539 provide ALTO guidance suitable for the respective resource consumer. 540 This mode of operation is called "third-party ALTO server discovery". 542 REQ. ARv14-37: ALTO clients MUST be able to perform resource 543 consumer initiated ALTO server discovery, even if they are located 544 behind a network address translator (NAT). 546 REQ. ARv14-38: ALTO clients MUST be able to perform third-party ALTO 547 server discovery, even if they are located behind a network address 548 translator (NAT). 550 REQ. ARv14-39: ALTO clients MUST be able to perform third-party ALTO 551 server discovery, even if the resource consumer, on behalf of which 552 the ALTO query will be sent, is located behind a network address 553 translator (NAT). 555 REQ. ARv14-40: ALTO server discovery mechanisms SHOULD leverage an 556 existing protocol or mechanism, such as DNS, DHCP, or PPP based 557 automatic configuration, etc. A single mechanism with a broad 558 spectrum of applicability SHOULD be preferred over several different 559 mechanisms with narrower scopes. 561 REQ. ARv14-41: Every ALTO server discovery mechanism SHOULD be able 562 to return the respective contact information for multiple ALTO 563 servers. 565 REQ. ARv14-42: Every ALTO server discovery mechanism SHOULD be able 566 to indicate preferences for each returned ALTO server contact 567 information. 569 3.3. Security and Privacy 571 Note: The following requirements mandate the inclusion of certain 572 security mechanisms at a protocol specification level. Whether it 573 makes sense to enable these mechanisms in a given deployment scenario 574 depends on a threat analysis for this specific scenario. 576 REQ. ARv14-43: An ALTO client protocol specification MUST specify 577 mechanisms for the authentication of ALTO servers, or how to leverage 578 appropriate mechanisms provided by underlying protocol layers. 580 REQ. ARv14-44: An ALTO client protocol specification MUST specify 581 mechanisms for the authentication of ALTO clients, or how to leverage 582 appropriate mechanisms provided by underlying protocol layers. 584 REQ. ARv14-45: An ALTO client protocol specification MUST specify 585 mechanisms for the encryption of messages, or how to leverage 586 appropriate mechanisms provided by underlying protocol layers. 588 REQ. ARv14-46: An ALTO client is not required to implement 589 mechanisms or to comply with rules that limit its ability to 590 redistribute information retrieved from the ALTO server to third 591 parties. 593 REQ. ARv14-47: An ALTO client protocol MUST support different levels 594 of detail in queries and responses, in order to protect the privacy 595 of users, to ensure that the operators of ALTO servers and other 596 users of the same application cannot derive sensitive information. 598 REQ. ARv14-48: An ALTO client protocol MAY include mechanisms that 599 can be used by the ALTO client when requesting guidance to specify 600 the resource (e.g., content identifiers) it wants to access. An ALTO 601 server MUST provide adequate guidance even if the ALTO client prefers 602 not to specify the desired resource (e.g., keeps the data field 603 empty). The mechanism MUST be designed in a way that the operator of 604 the ALTO server cannot easily deduce the resource identifier (e.g., 605 file name in P2P file sharing) if the ALTO client prefers not to 606 specify it. 608 REQ. ARv14-49: An ALTO client protocol specification MUST specify 609 appropriate mechanisms for protecting the ALTO service against DoS 610 attacks, or how to leverage appropriate mechanisms provided by 611 underlying protocol layers. 613 4. IANA Considerations 615 This requirements document does not mandate any immediate IANA 616 actions. However, such IANA considerations may arise from future 617 ALTO specification documents which try to meet the requirements given 618 here. 620 5. Security Considerations 622 5.1. High-level security considerations 624 High-level security considerations for the ALTO service can be found 625 in the "Security Considerations" section of the ALTO problem 626 statement document [RFC5693]. 628 5.2. Information Disclosure Scenarios 630 The unwanted disclosure of information is one key concern related to 631 ALTO. From a user privacy perspective, neither the ALTO server nor a 632 third party using or misusing the ALTO service should be able to 633 infer the application behavior, e.g., who is exchanging which files 634 with whom using a P2P file sharing application. Many network 635 operators, in contrast, are concerned about the amount of information 636 related to their network infrastructure (e.g., topology information, 637 number of "premium customers", or utilization statistics) that might 638 be released through ALTO. This section presents a classification and 639 discussion of information disclosure scenarios and potential 640 countermeasures. 642 5.2.1. Classification of Information Disclosure Scenarios 644 o (1) Excess disclosure of ALTO server operator's data to an 645 authorized ALTO client. The operator of an ALTO server has to 646 feed information, such as tables mapping host group descriptors to 647 host characteristics attributes, into the server, thereby enabling 648 it to give guidance to ALTO clients. Some operators might 649 consider the full set of this information confidential (e.g., a 650 detailed map of the operator's network topology), and might want 651 to disclose only a subset of it or somehow obfuscated information 652 to an ALTO client. 654 o (2) Disclosure of the application behavior to the ALTO server. 655 The operator of an ALTO server could infer the application 656 behavior (e.g., content identifiers in P2P file sharing 657 applications, or lists of resource providers that are considered 658 for establishing a connection) from the ALTO queries sent by an 659 ALTO client. 661 o (3) Disclosure of ALTO server operator's data (e.g., network 662 topology information) to an unauthorized third party. There are a 663 three sub-cases here: 665 * (3a) An ALTO server sends the information directly to an 666 unauthorized ALTO client. 668 * (3b) An unauthorized party snoops on the data transmission from 669 the ALTO server to an authorized ALTO client. 671 * (3c) An authorized ALTO client knowingly forwards the 672 information it had received from the ALTO server to an 673 unauthorized party. 675 o (4) Disclosure of the application behavior to an unauthorized 676 third party. 678 o (5) Excess retrieval of ALTO server operator's data by 679 collaborating ALTO clients. Several authorized ALTO clients could 680 ask an ALTO server for guidance, and redistribute the responses 681 among each other (see also case 3c). By correlating the ALTO 682 responses they could find out more information than intended to be 683 disclosed by the ALTO server operator. 685 5.2.2. Discussion of Information Disclosure Scenarios 687 Scenario (1) may be addressed by the ALTO server operator choosing 688 the level of detail of the information to be populated into the ALTO 689 server and returned in the responses. For example, by specifying a 690 broader address range (i.e., a shorter prefix length) than a group of 691 hosts in question actually uses, an ALTO server operator may control 692 to some extent how much information about the network topology is 693 disclosed. Furthermore, access control mechanisms for filtering ALTO 694 responses according to the authenticated ALTO client identity might 695 be installed in the ALTO server, although this might not be effective 696 given the lack of efficient mechanisms for addressing (3c) and (5), 697 see below. 699 (2) can and needs to be addressed in several ways: If the ALTO client 700 is embedded in the resource consumer, the resource consumer's IP 701 address (or the "public" IP address of the outermost NAT in front of 702 the resource consumer) is disclosed to the ALTO server as a matter of 703 principle, because it is in the source address fields of the IP 704 headers. By using a proxy, the disclosure of source addresses to the 705 ALTO server can be avoided at the cost of disclosing them to said 706 proxy. If, in contrast, the ALTO client is embedded in a third party 707 (e.g., a resource directory) which issues ALTO requests on behalf of 708 resource consumers, it is possible to hide the exact addresses of the 709 resource consumers from the ALTO server, e.g., by zeroing-out or 710 randomizing the last few bits of IP addresses. However, there is the 711 potential side effect of yielding inaccurate results. 713 The disclosure of candidate resource providers' addresses to the ALTO 714 server can be avoided by allowing ALTO clients to use the target- 715 independent query mode. In this mode of operation, guiding 716 information (e.g., "maps") is retrieved from the ALTO server and used 717 entirely locally by the ALTO client, i.e., without sending host 718 location attributes of candidate resource providers to the ALTO 719 server. In the target-aware query mode, this issue can be addressed 720 by ALTO clients through obfuscating the identity of candidate 721 resource consumers, e.g., by specifying a broader address range 722 (i.e., a shorter prefix length) than a group of hosts in question 723 actually uses, or by zeroing-out or randomizing the last few bits of 724 IP addresses. However, there is the potential side effect of 725 yielding inaccurate results. 727 (3a), (3b), and (4) may be addressed by authentication, access 728 control, and encryption schemes for the ALTO client protocol. 729 However, deployment of encryption schemes might not be effective 730 given the lack of efficient mechanisms for addressing (3c) and (5), 731 see below. 733 Straightforward authentication and encryption schemes will not help 734 solving (3c) and (5), and there is no other simple and efficient 735 mechanism known. The cost of complex approaches, e.g., based on 736 digital rights management (DRM), might easily outweigh the benefits 737 of the whole ALTO solution, and therefore they are not considered as 738 a viable solution. That is, ALTO server operators must be aware that 739 (3c) and (5) cannot be prevented from happening, and therefore they 740 should feed only such data into an ALTO server, which they do not 741 consider sensitive with respect to (3c) and (5). 743 These insights are reflected in the requirements in this document. 745 5.3. Security Requirements 747 For a set of specific security requirements please refer to 748 Section 3.3 of this document. 750 6. References 752 6.1. Normative References 754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 755 Requirement Levels", BCP 14, RFC 2119, March 1997. 757 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 758 Optimization (ALTO) Problem Statement", RFC 5693, 759 October 2009. 761 6.2. Informative References 763 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 764 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 765 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 767 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 768 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 769 RFC 4787, January 2007. 771 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 772 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 773 RFC 5382, October 2008. 775 Appendix A. Contributors List and Acknowledgments 777 The initial version of this document was co-authored by Laird Popkin. 779 The authors would like to thank 781 o Vijay K. Gurbani 783 o Enrico Marocco 785 for fostering discussions that lead to the creation of this document, 786 and for giving valuable comments on it. 788 The authors were supported by the following people, who have 789 contributed to this document: 791 o Richard Alimi 793 o Zoran Despotovic 795 o Jason Livingood 797 o Saverio Niccolini 799 o Michael Scharf 801 o Nico Schwan 803 o Jan Seedorf 805 The authors would like to thank the members of the P2PI and ALTO 806 mailing lists for their feedback. 808 Laird Popkin and Y. Richard Yang are grateful to the many 809 contributions made by the members of the P4P working group and Yale 810 Laboratory of Networked Systems. The P4P working group is hosted by 811 DCIA. 813 Martin Stiemerling is partially supported by the COAST project 814 (COntent Aware Searching, retrieval and sTreaming, 815 http://www.coast-fp7.eu), a research project supported by the 816 European Commission under its 7th Framework Program (contract no. 817 248036). The views and conclusions contained herein are those of the 818 authors and should not be interpreted as necessarily representing the 819 official policies or endorsements, either expressed or implied, of 820 the COAST project or the European Commission. 822 Authors' Addresses 824 Sebastian Kiesel (editor) 825 University of Stuttgart Computing Center 826 Networks and Communication Systems Department 827 Allmandring 30 828 70550 Stuttgart 829 Germany 831 Email: ietf-alto@skiesel.de 832 URI: http://www.rus.uni-stuttgart.de/nks/ 834 Stefano Previdi 835 Cisco Systems, Inc. 837 Email: sprevidi@cisco.com 839 Martin Stiemerling 840 NEC Laboratories Europe 842 Email: martin.stiemerling@neclab.eu 843 URI: http://ietf.stiemerling.org 845 Richard Woundy 846 Comcast Corporation 848 Email: Richard_Woundy@cable.comcast.com 850 Yang Richard Yang 851 Yale University 853 Email: yry@cs.yale.edu