idnits 2.17.1 draft-stiemerling-alto-deployments-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 145 has weird spacing: '...logical ser...' == Line 173 has weird spacing: '...logical ser...' -- The document date (July 12, 2010) is 5037 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 627, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3568 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-04 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-05 == Outdated reference: A later version (-09) exists of draft-kamei-p2p-experiments-japan-03 == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-03 == Outdated reference: A later version (-03) exists of draft-penno-alto-cdn-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Standards Track S. Kiesel 5 Expires: January 13, 2011 University of Stuttgart 6 July 12, 2010 8 ALTO Deployment Considerations 9 draft-stiemerling-alto-deployments-04 11 Abstract 13 Many Internet applications are used to access resources, such as 14 pieces of information or server processes, which are available in 15 several equivalent replicas on different hosts. This includes, but 16 is not limited to, peer-to-peer file sharing applications. The goal 17 of Application-Layer Traffic Optimization (ALTO) is to provide 18 guidance to these applications, which have to select one or several 19 hosts from a set of candidates, that are able to provide a desired 20 resource. The protocol is under specification in the ALTO working 21 group. This memo discusses deployment related issues of ALTO for 22 peer-to-peer and CDNs, some preliminary security considerations, and 23 also initial guidance for application designers using ALTO. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 13, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Using ALTO for Peer-to-Peer . . . . . . . . . . . . . . . . . 7 62 3.1. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 9 63 4. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 11 64 5. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 12 65 6. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 14 66 6.1. Limitations of Map-based Approaches . . . . . . . . . . . 14 67 6.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 15 68 6.3. General Challenges . . . . . . . . . . . . . . . . . . . . 15 69 7. API between ALTO Client and Application . . . . . . . . . . . 17 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 8.1. Information Leakage from the ALTO Server . . . . . . . . . 18 72 8.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 18 73 8.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 19 74 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 81 1. Introduction 83 Many Internet applications are used to access resources, such as 84 pieces of information or server processes, which are available in 85 several equivalent replicas on different hosts. This includes, but 86 is not limited to, peer-to-peer file sharing applications and Content 87 Delivery Networks (CDNs). The goal of Application-Layer Traffic 88 Optimization (ALTO) is to provide guidance to applications, which 89 have to select one or several hosts from a set of candidates, that 90 are able to provide a desired resource. The basic ideas of ALTO are 91 described in the problem space of ALTO is described in [RFC5693] and 92 the set of requirements is discussed in [I-D.ietf-alto-reqs]. 94 However, there are no considerations about what operational issues 95 are to be expected once ALTO will be deployed. This includes, but is 96 not limited to, location of the ALTO server, imposed load to the ALTO 97 server, or from whom the queries are performed. 99 Comments and discussions about this memo should be directed to the 100 ALTO working group: alto@ietf.org. 102 2. Overview 104 The ALTO protocol is a client/server protocol, operating between a 105 number of ALTO clients and an ALTO server, as sketched in Figure 1. 106 The ALTO working groups defines the ALTO protocol 107 [I-D.ietf-alto-protocol]. 109 +----------+ 110 | ALTO | 111 | Server | 112 +----------+ 113 ^ 114 _.-----|------. 115 ,-'' | `--. 116 ,' | `. 117 ( Network | ) 118 `. | ,' 119 `--. | _.-' 120 `------|-----'' 121 v 122 +----------+ +----------+ +----------+ 123 | ALTO | | ALTO |...| ALTO | 124 | Client | | Client | | Client | 125 +----------+ +----------+ +----------+ 127 Figure 1: Network Overview of ALTO Protocol 129 The ALTO server and ALTO clients can be situated at various entities 130 in a network deployment. The first differentiation is whether the 131 ALTO client is located on the actual host that runs the application, 132 as shown in Figure 2, (e.g., peer-to-peer filesharing application) or 133 if the ALTO client is located on resource directory, as shown in 134 Figure 3 (e.g., a tracker in peer-to-peer filesharing). 136 +-----+ 137 =====| |** 138 ==== +-----+ * 139 ==== * * 140 ==== * * 141 +-----+ +------+===== +-----+ * 142 | |.....| |======================| | * 143 +-----+ +------+===== +-----+ * 144 Source of ALTO ==== * * 145 topological service ==== * * 146 information ==== +-----+ * 147 =====| |** 148 +-----+ 149 Legend: 150 === ALTO client protocol 151 *** Application protocol 152 ... Provisioning protocol 154 Figure 2: Overview of protocol interaction between ALTO 155 elements,scenario without tracker 157 Figure 2 shows the operational model for applications that do not use 158 a tracker, such as, edonky, or in if the tracker should be the 159 querying party. This use case also holds true for CDNs. The ALTO 160 server can also be queried by CDNs to get a guidance about where the 161 a particular client accessing data in the CDN is exactly located in 162 the ISP's network. 164 +-----+ 165 **| |** 166 ** +-----+ * 167 ** * * 168 ** * * 169 +-----+ +------+ +-----+** +-----+ * 170 | |.....| |=====| |**********| | * 171 +-----+ +------+ +-----+** +-----+ * 172 Source of ALTO Resource ** * * 173 topological service directory ** * * 174 information ("tracker") ** +-----+ * 175 **| |** 176 +-----+ 177 Peers 178 Legend: 179 === ALTO client protocol 180 *** Application protocol 181 ... Provisioning protocol 183 Figure 3: Overview of protocol interaction between ALTO elements, 184 scenario with tracker 186 However, Figure 3 does not denote where the ALTO elements are 187 actually located, i.e., if the tracker and the ALTO server are in the 188 same ISP's domain, or if the tracker and the ALTO server are managed/ 189 owned/located in different domains. The latter is the typical use 190 case, e.g., taking Pirate Bay as example that serves Bittorrent peers 191 world-wide. 193 3. Using ALTO for Peer-to-Peer 195 This section discuss where the ALTO server can be placed and which 196 entities are querying the ALTO server from what ALTO client. The 197 section assumes a P2P system relying a tracker to initially find 198 other peers. However, the tracker can be replaced by any other 199 database that provides a rendezvous point for an application. The 200 limitation to a tracker is made for educational purpose, i.e. to ease 201 the general understanding. 202 ,-------. 203 ,---. ,-' `-. +-----------+ 204 ,-' `-. / ISP 1 \ | Peer 1 |***** 205 / \ / +-------------+ \ | | * 206 / ISP X \ +=====>+ ALTO Server | )+-----------+ * 207 / \ = \ +-------------+ / +-----------+ * 208 ; +-----------+ : = \ / | Peer 2 | * 209 | | Tracker |<====+ `-. ,-' | |***** 210 | |ALTO Client|<====+ `-------' +-----------+ ** 211 | +-----------+ | = ,-------. ** 212 : * ; = ,-' `-. +-----------+ ** 213 \ * / = / ISP 2 \ | Peer 3 | ** 214 \ * / = / +-------------+ \ | |***** 215 \ * / +=====>| ALTO Server | )+-----------+ *** 216 `-. * ,-' \ +-------------+ / +-----------+ *** 217 `-*-' \ / | Peer 4 |***** 218 * `-. ,-' | | **** 219 * `-------' +-----------+ **** 220 * **** 221 * **** 222 ***********************************************<****** 223 Legend: 224 === ALTO client protocol 225 *** Application protocol 227 Figure 4: Global tracker accessing ALTO server at various ISPs 229 Figure 4 depicts a tracker-based system, where the tracker embeds the 230 ALTO client. The tracker itself is hosted and operated by an entity 231 different than the ISP hosting and operating the ALTO server. 232 Initially, the tracker has to look-up the ALTO server in charge for 233 each peer where it receives a ALTO query for. Therefore, the ALTO 234 server has to discover the handling ALTO server, as described in 235 [I-D.kiesel-alto-3pdisc]. However, the peers do not have any way to 236 query the server themselves. This setting allows to give the peers a 237 better selection of candidate peers for their operation at an initial 238 time, but does not consider peers learned through direct peer-to-peer 239 knowledge exchange, AKA peer exchange in various peer-to-peer 240 protocols. 242 ,-------. +-----------+ 243 ,---. ,-' `-. +==>| Peer 1 |***** 244 ,-' `-. / ISP 1 \ = |ALTO Client| * 245 / \ / +-------------+<=+ +-----------+ * 246 / ISP X \ | + ALTO Server |<=+ +-----------+ * 247 / \ \ +-------------+ /= | Peer 2 | * 248 ; +---------+ : \ / +==>|ALTO Client|***** 249 | | Global | | `-. ,-' +-----------+ ** 250 | | Tracker | | `-------' ** 251 | +---------+ | ,-------. +-----------+ ** 252 : * ; ,-' `-. +==>| Peer 3 | ** 253 \ * / / ISP 2 \ = |ALTO Client|***** 254 \ * / / +-------------+<=+ +-----------+ *** 255 \ * / | | ALTO Server |<=+ +-----------+ *** 256 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 257 `-*-' \ / +==>|ALTO Client| **** 258 * `-. ,-' +-----------+ **** 259 * `-------' **** 260 * **** 261 ***********************************************<**** 262 Legend: 263 === ALTO client protocol 264 *** Application protocol 266 Figure 5: Global Tracker - Local ALTO Servers 268 The scenario in Figure 5 lets the peers directly communicate with 269 their ISP's ALTO server (i.e., ALTO client embedded in the peers), 270 giving thus the peers the most control on which information they 271 query for, as they can integrate information received from trackers 272 and through direct peer-to-peer knowledge exchange. 274 ,-------. +-----------+ 275 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 276 ,-' `-. /+-------------+\ * | | 277 / \ / + Tracker |<** +-----------+ 278 / ISP X \ | +-----===-----+<** +-----------+ 279 / \ \ +-----===-----+ /* | Peer 2 | 280 ; +---------+ : \+ ALTO Server |/ ***>| | 281 | | Global | | +-------------+ +-----------+ 282 | | Tracker | | `-------' 283 | +---------+ | +-----------+ 284 : ^ ; ,-------. | Peer 3 | 285 \ * / ,-' ISP 2 `-. ***>| | 286 \ * / /+-------------+\ * +-----------+ 287 \ * / / + Tracker |<** +-----------+ 288 `-. *,-' | +-----===-----+ | | Peer 4 |<* 289 `---* \ +-----===-----+ / | | * 290 * \+ ALTO Server |/ +-----------+ * 291 * +-------------+ * 292 * `-------' * 293 *********************************************** 294 Legend: 295 === ALTO client protocol 296 *** Application protocol 298 Figure 6: P4P approach with local tracker and local ALTO server 300 There are some attempts to let ISP's to deploy their own trackers, as 301 shown in Figure 6. In this case, the client has no chance to get 302 guidance from the ALTO server, other than talking to the ISP's 303 tracker. However, the peers would have still chance the contact 304 other trackers, deployed by entities other than the peer's ISP. 306 Figure 6 and Figure 4 ostensibly take peers the possibility to 307 directly query the ALTO server, if the communication with the ALTO 308 server is not permitted for any reason. However, considering the 309 plethora of different applications of ALTO, e.g., multiple tracker 310 and non-tracker based P2P systems and or applications searching for 311 relays, it seems to be beneficial for all participants to let the 312 peers directly query the ALTO server. The peers are also the single 313 point having all operational knowledge to decide whether to use the 314 ALTO guidance and how to use the ALTO guidance. This is a preference 315 for the scenario depicted in Figure Figure 5. 317 3.1. Expectations of ALTO 319 This section hints to some recent experiments conducted with ALTO- 320 like deployments in Internet Service Provider (ISP) network's. NTT 321 performed tests with their HINT server implementation and dummy nodes 322 to gain insight on how an ALTO-like service influence a peer-to-peer 323 systems [I-D.kamei-p2p-experiments-japan]. The results of an early 324 experiment conducted in the Comcast network are documented 325 here[RFC5632] 327 4. Using ALTO for CDNs 329 Section 3 discussed the placement and usage of ALTO for P2P systems, 330 but not beyond. This section discuss the usage of ALTO for Content 331 Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a 332 web page, videos, etc) closer to the location of the user - where 333 close refers to shorten the distance between the client and the 334 server in the IP topology. CDNs use several techniques to decide 335 which server is closest to a client requesting a service. One common 336 way to do so, is relying on the DNS system, but there are many other 337 ways, see [RFC3568]. 339 The general issue for CDNs, independent of DNS or HTTP Redirect based 340 approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN 341 logic has to match the client's IP address with the closest CDN 342 cache. This matching is not trivial, for instance, in DNS based 343 approaches, where the IP address of the DNS original requester is 344 unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of 345 this and a solution approach). 347 5. Cascading ALTO Servers 349 The main assumptions of ALTO seems to be each ISP operates its own 350 ALTO server independently, irrespectively of the ISP's situation. 351 This may true for most envisioned deployments of ALTO but there are 352 certain deployments that may have different settings. Figure 7 shows 353 such setting, were for example, a university network is connected to 354 two upstream providers. ISP2 if the national research network and 355 ISP1 is a commercial upstream provider to this university network. 356 The university, as well as ISP1, are operating their own ALTO server. 357 The ALTO clients, located on the peers will contact the ALTO server 358 located at the university. 360 +-----------+ 361 | ISP1 | 362 | ALTO | 363 | Server | 364 +----------=+ 365 ,-------= ,------. 366 ,-' =`-. ,-' `-. 367 / Upstream= \ / Upstream \ 368 ( ISP1 = ) ( ISP2 ) 369 \ = / \ / 370 `-. =,-' `-. ,-' 371 `---+---= `+------' 372 | = | 373 | ======================= 374 |,-------------. | = 375 ,-+ `-+ +-----------+ 376 ,' University `. |University | 377 ( Network ) | ALTO | 378 `. =======================| Server | 379 `-= +-' +-----------+ 380 =`+------------'| 381 = | | 382 +--------+-+ +-+--------+ 383 | Peer1 | | PeerN | 384 +----------+ +----------+ 386 Figure 7: Cascaded ALTO Server 388 In this setting all "destinations" useful for the peers within ISP2 389 are free-of-charge for the peers located in the university network 390 (i.e., they are preferred in the rating of the ALTO server). 391 However, all traffic that is not towards ISP2 will be handled by the 392 ISP1 upstream provider. Therefore, the ALTO server at the university 393 has also to include the guidance given by the ISP1 ALTO server in its 394 replies to the ALTO clients. This can be called cascaded ALTO 395 servers. 397 6. Known Limitations of ALTO 399 This section describes some known limitations of ALTO in general or 400 specific mechanisms in ALTO. 402 6.1. Limitations of Map-based Approaches 404 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 405 amongst others mechanism, so-called network maps. The network map 406 approach uses Host Group Descriptors that group one or multiple 407 subnetworks (i.e., IP prefixes) to a single Host Group Descriptor. A 408 set of IP prefixes is called partition and the associated Host Group 409 Descriptor is called partition ID. The "costs" between the various 410 partition IDs is stored in a second map, the cost map. Map-based 411 approaches are chosen as they lower the signaling load on the server, 412 as the maps have only to be retrieved if they are changed. 414 The main assumption for map-based approaches is that the information 415 provided in these maps is static for a longer period of time, where 416 this period of time refers to days, but not hours or even minutes. 417 This assumption is fine, as long as the network operator does not 418 change any parameter, e.g., routing within the network and to the 419 upstream peers, IP address assignment stays stable (and thus the 420 mapping to the partitions). However, there are several cases where 421 this assumption is not valid, as: 423 1. ISPs reallocate IPv4 subnets from time to time; 425 2. ISPs reallocate IPv4 subnets on short notice; 427 3. IP prefix blocks may be assigned to a single DSLAM which serves a 428 variety of access networks. 430 For 1): ISPs reallocate IPv4 subnets within their infrastructure from 431 time to time, partly to ensure the efficient usage of IPv4 addresses 432 (a scarce resource), and partly to enable efficient route tables 433 within their network routers. The frequency of these "renumbering 434 events" depend on the growth in number of subscribers and the 435 availability of address space within the ISP. As a result, a 436 subscriber's household device could retain an IPv4 address for as 437 short as a few minutes, or for months at a time or even longer. 439 Some folks have suggested that ISPs providing ALTO services could 440 sub-divide their subscribers' devices into different IPv4 subnets 441 (or certain IPv4 address ranges) based on the purchased service 442 tier, as well as based on the location in the network topology. 443 The problem is that this sub-allocation of IPv4 subnets tends to 444 decrease the efficiency of IPv4 address allocation. A growing ISP 445 that needs to maintain high efficiency of IPv4 address utilization 446 may be reluctant to jeopardize their future acquisition of IPv4 447 address space. 449 However, this is not an issue for map-based approaches if changes are 450 applied in the order of days. 452 For 2): ISPs can use techniques, such as ODAP (XXX) that allow the 453 reallocation of IP prefixes on very short notice, i.e., within 454 minutes. An IP prefix that has no IP address assignment to a host 455 anymore can be reallocate to areas where there is currently a high 456 demand for IP addresses. 458 For 3): In DSL-based access networks, IP prefixes are assigned to 459 DSLAMs which are the first IP-hop in the access-network between the 460 CPE and the Internet. The access-network between CPE and DSLAM 461 (called aggregation network) can have varying characteristics (and 462 thus associated costs), but still using the same IP prefix. For 463 instance one IP addresses IP11 out of a IP prefix IP1 can be assigned 464 to a VDSL (e.g., 2 MBit/s uplink) access-line while the subsequent IP 465 address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s 466 uplink). These IP addresses are assigned on a first come first 467 served basis, i.e., the a single IP address out of the same IP prefix 468 can change its associated costs quite fast. This may not be an issue 469 with respect to the used upstream provider (thus the cross ISP 470 traffic) but depending on the capacity of the aggregation-network 471 this may raise to an issue. 473 6.2. Limitiations of Non-Map-based Approaches 475 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 476 amongst others mechanism, a mechanism called Endpoint Cost Service. 477 ALTO clients can ask guidance for specific IP addresses to the ALTO 478 server. However, asking for IP addresses, asking with long lists of 479 IP addresses, and asking quite frequent may overload the ALTO server. 480 The server has to rank each received IP address which causes load at 481 the server. This may be amplified by the fact that not only a single 482 ALTO client is asking for guidance, but a larger number of them. 484 Caching of IP addresses at the ALTO client or the usage of the H12 485 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower 486 the query load on the ALTO server. 488 6.3. General Challenges 490 An ALTO server stores information about preferences (e.g., a list of 491 preferred autonomous systems, IP ranges, etc) and ALTO clients can 492 retrieve these preferences. However, there are basically two 493 different approaches on where the preferences are actually processed: 495 1. The ALTO server has a list of preferences and clients can 496 retrieve this list via the ALTO protocol. This preference list 497 can be partially updated by the server. The actual processing of 498 the data is done on the client and thus there is no data of the 499 client's operation revealed to the ALTO server . 501 2. The ALTO server has a list of preferences or preferences 502 calculated during runtime and the ALTO client is sending 503 information of its operation (e.g., a list of IP addresses) to 504 the server. The server is using this operational information to 505 determine its preferences and returns these preferences (e.g., a 506 sorted list of the IP addresses) back to the ALTO client. 508 Approach 1 (we call it H1) has the advantage (seen from the client) 509 that all operational information stays within the client and is not 510 revealed to the provider of the server. On the other hand, does 511 approach 1 require that the provider of the ALTO server, i.e., the 512 network operator, reveals information about its network structure 513 (e.g., AS numbers, IP ranges, topology information in general) to the 514 ALTO client. 516 Approach 2 (we call it H2) has the advantage (seen from the operator) 517 that all operational information stays with the ALTO server and is 518 not revealed to the ALTO client. On the other hand, does approach 2 519 require that the clients send their operational information to the 520 server. 522 Both approaches have their pros and cons and are extensively 523 discussed on the ALTO mailing list. But there is basically a 524 dilemma: Approach 1 is seen as the only working solution by peer-to- 525 peer software vendors and approach 2 is seen as the only working by 526 the network operators. But neither the software vendors nor the 527 operators seem to willing to change their position. However, there 528 is the need to get both sides on board, to come to a solution. 530 7. API between ALTO Client and Application 532 This sections gives some informational guidance on how the interface 533 between the actual application using the ALTO guidance and the ALTO 534 client can look like. 536 This is still TBD. 538 8. Security Considerations 540 The ALTO protocol itself, as well as, the ALTO client and server 541 raise new security issues beyond the one mentioned in 542 [I-D.ietf-alto-protocol] and issues related to message transport over 543 the Internet. For instance, Denial of Service (DoS) is of interest 544 for the ALTO server and also for the ALTO client. A server can get 545 overloaded if too many TCP requests hit the server, or if the query 546 load of the server surpasses the maximum computing capacity. An ALTO 547 client can get overloaded if the responses from the sever are, either 548 intentionally or due to an implementation mistake, too large to be 549 handled by that particular client. 551 8.1. Information Leakage from the ALTO Server 553 The ALTO server will be provisioned with information about the owning 554 ISP's network and very likely also with information about neighboring 555 ISPs. This information (e.g., network topology, business relations, 556 etc) is consider to be confidential to the ISP and must not be 557 revealed. 559 The ALTO server will naturally reveal parts of that information in 560 small doses to peers, as the guidance given will depend on the above 561 mentioned information. This is seen beneficial for both parties, 562 i.e., the ISP's and the peer's. However, there is the chance that 563 one or multiple peers are querying an ALTO server with the goal to 564 gather information about network topology or any other data 565 considered confidential or at least sensitive. It is unclear whether 566 this is a real technical security risk or whether this is more a 567 perceived security risk. 569 8.2. ALTO Server Access 571 Depending on the use case of ALTO, several access restrictions to an 572 ALTO server may or may not apply. For an ALTO server that is solely 573 accessible by peers from the ISP network (as shown in Figure 5), for 574 instance, the source IP address can be used to grant only access from 575 that ISP network to the server. This will "limit" the number of 576 peers able to attack the server to the user's of the ISP (however, 577 including botnet computers). 579 On the other hand, if the ALTO server has to be accessible by parties 580 not located in the ISP's network (see Figure Figure 4), e.g., by a 581 third-party tracker or by a CDN system outside the ISP's network, the 582 access restrictions have to be more loose. In the extreme case, 583 i.e., no access restrictions, each and every host in the Internet can 584 access the ALTO server. This might no the intention of the ISP, as 585 the server is not only subject to more possible attacks, but also on 586 the load imposed to the server, i.e., possibly more ALTO clients to 587 serve and thus more work load. 589 8.3. Faking ALTO Guidance 591 It has not yet been investigated how a faked or wrong ALTO guidance 592 by an ALTO server can impact the operation of the network and also 593 the peers. 595 Here is a list of examples how the ALTO guidance could be faked and 596 what possible consequences may arise: 598 Sorting An attacker could change to sorting order of the ALTO 599 guidance (given that the order is of importance, otherwise the 600 ranking mechanism is of interest), i.e., declaring peers located 601 outside the ISP as peers to be preferred. This will not pose a 602 big risk to the network or peers, as it would mimic the "regular" 603 peer operation without traffic localization, apart from the 604 communication/processing overhead for ALTO. However, it could 605 mean that ALTO is reaching the opposite goal of shuffling more 606 data across ISP boundaries, incurring more costs for the ISP. 608 Preference of a single peer A single IP address (thus a peer) could 609 be marked as to be preferred all over other peers. This peer can 610 be located within the local ISP or also in other parts of the 611 Internet (e.g., a web server). This could lead to the case that 612 quite a number of peers to trying to contact this IP address, 613 possibly causing a Denial of Service (DoS) attack. 615 This section is solely giving a first shot on security issues related 616 to ALTO deployments. 618 9. Conclusion 620 This is the first version of the deployment considerations and for 621 sure the considerations are yet incomplete and imprecise. 623 10. References 625 10.1. Normative References 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 631 Content Network (CN) Request-Routing Mechanisms", 632 RFC 3568, July 2003. 634 10.2. Informative References 636 [I-D.ietf-alto-protocol] 637 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 638 draft-ietf-alto-protocol-04 (work in progress), May 2010. 640 [I-D.ietf-alto-reqs] 641 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 642 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 643 Requirements", draft-ietf-alto-reqs-05 (work in progress), 644 June 2010. 646 [I-D.kamei-p2p-experiments-japan] 647 Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO- 648 Like Activities and Experiments in P2P Network Experiment 649 Council", draft-kamei-p2p-experiments-japan-03 (work in 650 progress), May 2010. 652 [I-D.kiesel-alto-3pdisc] 653 Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M. 654 Stiemerling, "Third-party ALTO server discovery", 655 draft-kiesel-alto-3pdisc-03 (work in progress), July 2010. 657 [I-D.kiesel-alto-h12] 658 Kiesel, S. and M. Stiemerling, "ALTO H12", 659 draft-kiesel-alto-h12-02 (work in progress), March 2010. 661 [I-D.penno-alto-cdn] 662 Penno, R., Raghunath, S., Medved, J., Bakshi, M., Alimi, 663 R., and S. Previdi, "ALTO and Content Delivery Networks", 664 draft-penno-alto-cdn-00 (work in progress), June 2010. 666 [I-D.vandergaast-edns-client-ip] 667 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 668 "Client IP information in DNS requests", 669 draft-vandergaast-edns-client-ip-01 (work in progress), 670 May 2010. 672 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 673 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 674 Provider Participation for P2P (P4P) Technical Trial", 675 RFC 5632, September 2009. 677 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 678 Optimization (ALTO) Problem Statement", RFC 5693, 679 October 2009. 681 Appendix A. Acknowledgments 683 Martin Stiemerling is partially supported by the NAPA-WINE project 684 (Network-Aware P2P-TV Application over Wise Networks, 685 http://www.napa-wine.org), a research project supported by the 686 European Commission under its 7th Framework Program (contract no. 687 214412). The views and conclusions contained herein are those of the 688 authors and should not be interpreted as necessarily representing the 689 official policies or endorsements, either expressed or implied, of 690 the NAPA-WINE project or the European Commission. 692 Authors' Addresses 694 Martin Stiemerling 695 NEC Laboratories Europe/University of Goettingen 696 Kurfuerstenanlage 36 697 Heidelberg 69115 698 Germany 700 Phone: +49 6221 4342 113 701 Fax: +49 6221 4342 155 702 Email: martin.stiemerling@neclab.eu 703 URI: http://www.nw.neclab.eu/ 705 Sebastian Kiesel 706 University of Stuttgart, Computing Center 707 Allmandring 30 708 Stuttgart 70550 709 Germany 711 Email: ietf-alto@skiesel.de