idnits 2.17.1 draft-stiemerling-alto-deployments-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 185 has weird spacing: '...logical ser...' == Line 214 has weird spacing: '...logical ser...' -- The document date (March 1, 2010) is 5168 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 458, but no explicit reference was found in the text == Unused Reference: 'I-D.penno-alto-protocol' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'I-D.stiemerling-alto-h1h2-protocol' is defined on line 505, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-01 == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-01 == Outdated reference: A later version (-02) exists of draft-kiesel-alto-h12-01 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: September 2, 2010 March 1, 2010 7 ALTO Deployment Considerations 8 draft-stiemerling-alto-deployments-01 10 Abstract 12 Many Internet applications are used to access resources, such as 13 pieces of information or server processes, which are available in 14 several equivalent replicas on different hosts. This includes, but 15 is not limited to, peer-to-peer file sharing applications. The goal 16 of Application-Layer Traffic Optimization (ALTO) is to provide 17 guidance to these applications, which have to select one or several 18 hosts from a set of candidates, that are able to provide a desired 19 resource. The protocol is under specification in the ALTO working 20 group. However, this document discusses the deployment 21 considerations of ALTO and also some preliminary security 22 considerations. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 2, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Placement of ALTO Server . . . . . . . . . . . . . . . . . . . 8 66 4. API between ALTO Client and Application . . . . . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 5.1. Information Leakage from the ALTO Server . . . . . . . . . 12 69 5.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 12 70 5.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 13 71 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 Many Internet applications are used to access resources, such as 81 pieces of information or server processes, which are available in 82 several equivalent replicas on different hosts. This includes, but 83 is not limited to, peer-to-peer file sharing applications. The goal 84 of Application-Layer Traffic Optimization (ALTO) is to provide 85 guidance to applications, which have to select one or several hosts 86 from a set of candidates, that are able to provide a desired 87 resource. The basic ideas of ALTO are described in the problem space 88 of ALTO is described in [RFC5693] and the set of requirements is 89 discussed in [I-D.kiesel-alto-reqs]. 91 However, there are no considerations about what issues are to be 92 expected once ALTO will be deployed. This includes, but is not 93 limited to, location of the ALTO server, imposed load to the ALTO 94 server, or from whom the queries are performed. 96 Comments and discussions about this memo should be directed to the 97 ALTO working group: alto@ietf.org. 99 2. Overview 101 The ALTO protocol is a client/server protocol, operating between a 102 number of ALTO clients and an ALTO server, as sketched in Figure 1. 104 The ALTO working groups defines the ALTO protocol based on the P4P 105 proposal [I-D.ietf-alto-protocol], but there are also other past and 106 current protocol proposals, such as, H12 [I-D.kiesel-alto-h12], or 107 the oracle approach [I-D.akonjang-alto-proxidor] the infoexport 108 approach [I-D.shalunov-alto-infoexport]. Irrespectivelty of all 109 mentioned protocols, the common set is always where the ALTO server 110 is located an who is actually the querying entity to that ALTO 111 server. 113 +----------+ 114 | ALTO | 115 | Server | 116 +----------+ 117 ^ 118 _.-----|------. 119 ,-'' | `--. 120 ,' | `. 121 ( Network | ) 122 `. | ,' 123 `--. | _.-' 124 `------|-----'' 125 v 126 +----------+ +----------+ +----------+ 127 | ALTO | | ALTO |...| ALTO | 128 | Client | | Client | | Client | 129 +----------+ +----------+ +----------+ 131 Figure 1: Network Overview of ALTO Protocol 133 An ALTO server stores information about preferences (e.g., a list of 134 preferred autonomous systems, IP ranges, etc) and ALTO clients can 135 retrieve these preferences. However, there are basically two 136 different approaches on where the preferences are actually processed: 138 1. The ALTO server has a list of preferences and clients can 139 retrieve this list via the ALTO protocol. This preference list 140 can be partially updated by the server. The actual processing of 141 the data is done on the client and thus there is no data of the 142 client's operation revealed to the ALTO server . This approach 143 has been proposed by [I-D.shalunov-alto-infoexport]. 145 2. The ALTO server has a list of preferences or preferences 146 calculated during runtime and the ALTO client is sending 147 information of its operation (e.g., a list of IP addresses) to 148 the server. The server is using this operational information to 149 determine its preferences and returns these preferences (e.g., a 150 sorted list of the IP addresses) back to the ALTO client. This 151 approach has been initially described in [ACM.ispp2p], but never 152 been described on the protocol level. 154 Approach 1 (we call it H1) has the advantage (seen from the client) 155 that all operational information stays within the client and is not 156 revealed to the provider of the server. On the other hand, does 157 approach 1 require that the provider of the ALTO server, i.e., the 158 network operator, reveals information about its network structure 159 (e.g., AS numbers, IP ranges, topology information in general) to the 160 ALTO client. 162 Approach 2 (we call it H2) has the advantage (seen from the operator) 163 that all operational information stays with the ALTO server and is 164 not revealed to the ALTO client. On the other hand, does approach 2 165 require that the clients send their operational information to the 166 server. 168 Both approaches have their pros and cons and are extensively 169 discussed on the ALTO mailing list. But there is basically a 170 dilemma: Approach 1 is seen as the only working solution by peer-to- 171 peer software vendors and approach 2 is seen as the only working by 172 the network operators. But neither the software vendors nor the 173 operators seem to willing to change their position. However, there 174 is the need to get both sides on board, to come to a solution. 176 +-----+ 177 **| |** 178 ** +-----+ * 179 ** * * 180 ** * * 181 +-----+ +------+ +-----+** +-----+ * 182 | |.....| |=====| |**********| | * 183 +-----+ +------+ +-----+** +-----+ * 184 Source of ALTO Resource ** * * 185 topological service directory ** * * 186 information ("tracker") ** +-----+ * 187 **| |** 188 +-----+ 189 Peers 190 Legend: 191 === ALTO client protocol 192 *** Application protocol 193 ... Provisioning protocol 195 Figure 2: Overview of protocol interaction between ALTO elements, 196 scenario with tracker 198 However, Figure Figure 2does not denote where the ALTO elements are 199 actually located, i.e., if the tracker and the ALTO server are in the 200 same ISP's domain, or if the tracker and the ALTO server are managed/ 201 owned/located in different domains. The latter is the typical use 202 case, e.g., taking Pirate Bay as example that serves Bittorrent users 203 world-wide. 205 +-----+ 206 =====| |** 207 ==== +-----+ * 208 ==== * * 209 ==== * * 210 +-----+ +------+===== +-----+ * 211 | |.....| |======================| | * 212 +-----+ +------+===== +-----+ * 213 Source of ALTO ==== * * 214 topological service ==== * * 215 information ==== +-----+ * 216 =====| |** 217 +-----+ 218 Legend: 219 === ALTO client protocol 220 *** Application protocol 221 ... Provisioning protocol 223 Figure 3: Overview of protocol interaction between ALTO 224 elements,scenario without tracker 226 Figure Figure 3 shows the operational model for applications that do 227 not use a tracker, such as, edonky, or in if the tracker should be 228 the queriyng party. This use case also holds true for CDNs. The 229 ALTO server can also be queried by CDNs to get a guidance about where 230 the a particular client accessing data in the CDN is excatly located 231 in the ISP's network. 233 3. Placement of ALTO Server 235 This section discuss where the ALTO server can be placed and which 236 entities are querying the ALTO server from what ALTO client. The 237 section assumes a P2P system relying a tracker to initially find 238 other peers. However, the tracker can be replaced by any other 239 database that provides a rendezvous point for an application. The 240 limitation to a tracker is made for educational purpose, i.e. to ease 241 the general understanding. 242 ,-------. 243 ,---. ,-' `-. +-----------+ 244 ,-' `-. / ISP 1 \ | Peer 1 |***** 245 / \ / +-------------+ \ | | * 246 / ISP X \ +=====>+ ALTO Server | )+-----------+ * 247 / \ = \ +-------------+ / +-----------+ * 248 ; +-----------+ : = \ / | Peer 2 | * 249 | | Tracker |<====+ `-. ,-' | |***** 250 | |ALTO Client|<====+ `-------' +-----------+ ** 251 | +-----------+ | = ,-------. ** 252 : * ; = ,-' `-. +-----------+ ** 253 \ * / = / ISP 2 \ | Peer 3 | ** 254 \ * / = / +-------------+ \ | |***** 255 \ * / +=====>| ALTO Server | )+-----------+ *** 256 `-. * ,-' \ +-------------+ / +-----------+ *** 257 `-*-' \ / | Peer 4 |***** 258 * `-. ,-' | | **** 259 * `-------' +-----------+ **** 260 * **** 261 * **** 262 ***********************************************<****** 263 Legend: 264 === ALTO client protocol 265 *** Application protocol 267 Figure 4: Global tracker accessing ALTO server at various ISPs 269 Figure Figure 4 depicts a tracker-based system, where the tracker 270 embeds the ALTO client. The tracker itself is hosted and operated by 271 an entity different than the ISP hosting and operating the ALTO 272 server. Initially, the tracker has to look-up the ALTO server in 273 charge for each peer where it receives a ALTO query for. Therefore, 274 the ALTO server has to discover the handling ALTO server, as 275 described in [I-D.kiesel-alto-3pdisc]. However, the peers do not 276 have any way to query the server themselves. This setting allows to 277 give the peers a better selection of candidate peers for their 278 operation at an initial time, but does not consider peers learned 279 through direct peer-to-peer knowledge exchange, AKA peer exchange in 280 various peer-to-peer protocols. 282 ,-------. +-----------+ 283 ,---. ,-' `-. +==>| Peer 1 |***** 284 ,-' `-. / ISP 1 \ = |ALTO Client| * 285 / \ / +-------------+<=+ +-----------+ * 286 / ISP X \ | + ALTO Server |<=+ +-----------+ * 287 / \ \ +-------------+ /= | Peer 2 | * 288 ; +---------+ : \ / +==>|ALTO Client|***** 289 | | Global | | `-. ,-' +-----------+ ** 290 | | Tracker | | `-------' ** 291 | +---------+ | ,-------. +-----------+ ** 292 : * ; ,-' `-. +==>| Peer 3 | ** 293 \ * / / ISP 2 \ = |ALTO Client|***** 294 \ * / / +-------------+<=+ +-----------+ *** 295 \ * / | | ALTO Server |<=+ +-----------+ *** 296 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 297 `-*-' \ / +==>|ALTO Client| **** 298 * `-. ,-' +-----------+ **** 299 * `-------' **** 300 * **** 301 ***********************************************<**** 302 Legend: 303 === ALTO client protocol 304 *** Application protocol 306 Figure 5: Global Tracker - Local ALTO Servers 308 The scenario in Figure Figure 5 lets the peers directly communicate 309 with their ISP's ALTO server (i.e., ALTO client embedded in the 310 peers), giving thus the peers the most control on which information 311 they query for, as they can integrate information received from 312 trackers and through direct eer-to-peer knowledge exchange. 314 ,-------. +-----------+ 315 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 316 ,-' `-. /+-------------+\ * | | 317 / \ / + Tracker |<** +-----------+ 318 / ISP X \ | +-----===-----+<** +-----------+ 319 / \ \ +-----===-----+ /* | Peer 2 | 320 ; +---------+ : \+ ALTO Server |/ ***>| | 321 | | Global | | +-------------+ +-----------+ 322 | | Tracker | | `-------' 323 | +---------+ | +-----------+ 324 : ^ ; ,-------. | Peer 3 | 325 \ * / ,-' ISP 2 `-. ***>| | 326 \ * / /+-------------+\ * +-----------+ 327 \ * / / + Tracker |<** +-----------+ 328 `-. *,-' | +-----===-----+ | | Peer 4 |<* 329 `---* \ +-----===-----+ / | | * 330 * \+ ALTO Server |/ +-----------+ * 331 * +-------------+ * 332 * `-------' * 333 *********************************************** 334 Legend: 335 === ALTO client protocol 336 *** Application protocol 338 Figure 6: P4P approach with local tracker and local ALTO server 340 There are some attempts to let ISP's to deploy their own trackers, as 341 shown in Figure 6. In this case, the client has no chance to get 342 guidance from the ALTO server, other than talking to the ISP's 343 tracker. However, the peers would have still chance the contact 344 other trackers, deployed by entities other than the peer's ISP. 346 The figures Figure 6 and Figure 4 ostensibly take peers the 347 possibility to directly query the ALTO server, if the communication 348 with the ALTO server is not permitted for any reason. However, 349 considering the plethora of different applications of ALTO, e.g., 350 multiple tracker and non-tracker based P2P systems and or 351 applications searching for relays, it seems to be beneficial for all 352 participants to let the peers directly query the ALTO server. The 353 peers are also the single point having all operational knowledge to 354 decide whether to use the ALTO guidance and how to use the ALTO 355 guidance. This is a preference for the scenario depicted in Figure 356 Figure 5. 358 4. API between ALTO Client and Application 360 This sections gives some informational guidance on how the interface 361 between the actual application using the ALTO guidance and the ALTO 362 client can look like. 364 This is still TBD. 366 5. Security Considerations 368 The ALTO protocol itself, as well as, the ALTO client and server 369 raise new security issues beyond the one mentioned in 370 [I-D.ietf-alto-protocol] and issues related to message transport over 371 the Internet. For instance, Denial of Service (DoS) is of interest 372 for the ALTO server and also for the ALTO client. A server can get 373 overloaded if too many TCP requests hit the server, or if the query 374 load of the server surpasses the maximum computing capacity. An ALTO 375 client can get overloaded if the responses from the sever are, either 376 intentionally or due to an implementation mistake, too large to be 377 handled by that particular client. 379 5.1. Information Leakage from the ALTO Server 381 The ALTO server will be provisioned with information about the owning 382 ISP's network and very likely also with information about neighboring 383 ISPs. This information (e.g., network topology, business relations, 384 etc) is consider to be confidential to the ISP and must not be 385 revealed. 387 The ALTO server will naturally reveal parts of that information in 388 small doses to peers, as the guidance given will depend on the above 389 mentioned information. This is seen beneficial for both parties, 390 i.e., the ISP's and the peer's. However, there is the chance that 391 one or multipe peers are querying an ALTO server with the goal to 392 gather information about network topology or any other data 393 considered confidential or at least sensitive. It is unclear whether 394 this is a real technical security risk or whether this is more a 395 perceived security risk. 397 5.2. ALTO Server Access 399 Depending on the use case of ALTO, several access restrictions to an 400 ALTO server may or may not apply. For an ALTO server that is solely 401 accessible by peers from the ISP network (as shown in Figure 5), for 402 instance, the source IP address can be used to grant only access from 403 that ISP network to the server. This will "limit" the number of 404 peers able to attack the server to the user's of the ISP (however, 405 including botnet computers). 407 On the other hand, if the ALTO server has to be accessible by parties 408 not located in the ISP's network (see Figure Figure 4), e.g., by a 409 third-party tracker or by a CDN system outside the ISP's network, the 410 access restrictions have to be more loose. In the extreme case, 411 i.e., no access restrictions, each and every host in the Internet can 412 access the ALTO server. This might no the intention of the ISP, as 413 the server is not only subjec to more possible attacks, but also on 414 the load imposed to the server, i.e., possibly more ALTO clients to 415 serve and thus more work load. 417 5.3. Faking ALTO Guidance 419 It has not yet been investigated how a faked or wrong ALTO guidance 420 by an ALTO server can impact the operation of the network and also 421 the peers. 423 Here is a list of examples how the ALTO guidance could be faked and 424 what possible consequences may arise: 426 Sorting An attacker could change to sorting order of the ALTO 427 guidance (given that the order is of importance, otherwise the 428 ranking mechanism is of interest), i.e., declaring peers located 429 outside the ISP as peers to be preferred. This will not pose a 430 big risk to the network or peers, as it would mimic the "regular" 431 peer operation without traffic localization, apart from the 432 communication/processing overhead for ALTO. However, it could 433 mean that ALTO is reaching the opposite goal of shuffling more 434 data across ISP boundaries, incurring more costs for the ISP. 436 Preference of a single peer A single IP address (thus a peer) could 437 be marked as to be preferred all over other peers. This peer can 438 be located within the local ISP or also in other parts of the 439 Internet (e.g., a web server). This could lead to the case that 440 quite a number of peers to trying to contact this IP address, 441 possibly causing a Denial of Service (DoS) attack. 443 This section is solely giving a first shot on security issues related 444 to ALTO deployments. 446 6. Conclusion 448 This is the first version of the deployment considerations and for 449 sure the considerations are yet incomplete and imprecise. 451 The first two figures have been deliberately taken from the 452 requirements draft. 454 7. References 456 7.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 7.2. Informative References 463 [ACM.ispp2p] 464 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 465 and P2P systems co-operate for improved performance?", In 466 ACM SIGCOMM Computer Communications Review 467 (CCR), 37:3, pp. 29-40. 469 [I-D.akonjang-alto-proxidor] 470 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 471 Saucez, "The PROXIDOR Service", 472 draft-akonjang-alto-proxidor-00 (work in progress), 473 March 2009. 475 [I-D.ietf-alto-protocol] 476 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 477 draft-ietf-alto-protocol-01 (work in progress), 478 December 2009. 480 [I-D.kiesel-alto-3pdisc] 481 Kiesel, S. and M. Tomsu, "Third-party ALTO server 482 discovery", draft-kiesel-alto-3pdisc-01 (work in 483 progress), October 2009. 485 [I-D.kiesel-alto-h12] 486 Kiesel, S. and M. Stiemerling, "ALTO H12", 487 draft-kiesel-alto-h12-01 (work in progress), March 2010. 489 [I-D.kiesel-alto-reqs] 490 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 491 Yang, "Application-Layer Traffic Optimization (ALTO) 492 Requirements", draft-kiesel-alto-reqs-02 (work in 493 progress), March 2009. 495 [I-D.penno-alto-protocol] 496 Penno, R. and Y. Yang, "ALTO Protocol", 497 draft-penno-alto-protocol-04 (work in progress), 498 October 2009. 500 [I-D.shalunov-alto-infoexport] 501 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 502 Export Service", draft-shalunov-alto-infoexport-00 (work 503 in progress), October 2008. 505 [I-D.stiemerling-alto-h1h2-protocol] 506 Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol", 507 draft-stiemerling-alto-h1h2-protocol-00 (work in 508 progress), March 2009. 510 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 511 Optimization (ALTO) Problem Statement", RFC 5693, 512 October 2009. 514 Appendix A. Acknowledgments 516 Martin Stiemerling is partially supported by the NAPA-WINE project 517 (Network-Aware P2P-TV Application over Wise Networks, 518 http://www.napa-wine.org), a research project supported by the 519 European Commission under its 7th Framework Program (contract no. 520 214412). The views and conclusions contained herein are those of the 521 authors and should not be interpreted as necessarily representing the 522 official policies or endorsements, either expressed or implied, of 523 the NAPA-WINE project or the European Commission. 525 Authors' Addresses 527 Martin Stiemerling 528 NEC Laboratories Europe/University of Goettingen 529 Kurfuerstenanlage 36 530 Heidelberg 69115 531 Germany 533 Phone: +49 6221 4342 113 534 Fax: +49 6221 4342 155 535 Email: martin.stiemerling@neclab.eu 536 URI: http://www.nw.neclab.eu/ 538 Sebastian Kiesel 540 Email: ietf-alto@skiesel.de