idnits 2.17.1 draft-stiemerling-alto-deployments-00.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 184 has weird spacing: '...logical ser...' == Line 213 has weird spacing: '...logical ser...' -- The document date (March 1, 2010) is 5171 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 457, but no explicit reference was found in the text == Unused Reference: 'I-D.penno-alto-protocol' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'I-D.stiemerling-alto-h1h2-protocol' is defined on line 504, 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-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: September 2, 2010 March 1, 2010 7 ALTO Deployment Considerations 8 draft-stiemerling-alto-deployments-00 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Many Internet applications are used to access resources, such as 80 pieces of information or server processes, which are available in 81 several equivalent replicas on different hosts. This includes, but 82 is not limited to, peer-to-peer file sharing applications. The goal 83 of Application-Layer Traffic Optimization (ALTO) is to provide 84 guidance to applications, which have to select one or several hosts 85 from a set of candidates, that are able to provide a desired 86 resource. The basic ideas of ALTO are described in the problem space 87 of ALTO is described in [RFC5693] and the set of requirements is 88 discussed in [I-D.kiesel-alto-reqs]. 90 However, there are no considerations about what issues are to be 91 expected once ALTO will be deployed. This includes, but is not 92 limited to, location of the ALTO server, imposed load to the ALTO 93 server, or from whom the queries are performed. 95 Comments and discussions about this memo should be directed to the 96 ALTO working group: alto@ietf.org. 98 2. Overview 100 The ALTO protocol is a client/server protocol, operating between a 101 number of ALTO clients and an ALTO server, as sketched in Figure 1. 103 The ALTO working groups defines the ALTO protocol based on the P4P 104 proposal [I-D.ietf-alto-protocol], but there are also other past and 105 current protocol proposals, such as, H12 [I-D.kiesel-alto-h12], or 106 the oracle approach [I-D.akonjang-alto-proxidor] the infoexport 107 approach [I-D.shalunov-alto-infoexport]. Irrespectivelty of all 108 mentioned protocols, the common set is always where the ALTO server 109 is located an who is actually the querying entity to that ALTO 110 server. 112 +----------+ 113 | ALTO | 114 | Server | 115 +----------+ 116 ^ 117 _.-----|------. 118 ,-'' | `--. 119 ,' | `. 120 ( Network | ) 121 `. | ,' 122 `--. | _.-' 123 `------|-----'' 124 v 125 +----------+ +----------+ +----------+ 126 | ALTO | | ALTO |...| ALTO | 127 | Client | | Client | | Client | 128 +----------+ +----------+ +----------+ 130 Figure 1: Network Overview of ALTO Protocol 132 An ALTO server stores information about preferences (e.g., a list of 133 preferred autonomous systems, IP ranges, etc) and ALTO clients can 134 retrieve these preferences. However, there are basically two 135 different approaches on where the preferences are actually processed: 137 1. The ALTO server has a list of preferences and clients can 138 retrieve this list via the ALTO protocol. This preference list 139 can be partially updated by the server. The actual processing of 140 the data is done on the client and thus there is no data of the 141 client's operation revealed to the ALTO server . This approach 142 has been proposed by [I-D.shalunov-alto-infoexport]. 144 2. The ALTO server has a list of preferences or preferences 145 calculated during runtime and the ALTO client is sending 146 information of its operation (e.g., a list of IP addresses) to 147 the server. The server is using this operational information to 148 determine its preferences and returns these preferences (e.g., a 149 sorted list of the IP addresses) back to the ALTO client. This 150 approach has been initially described in [ACM.ispp2p], but never 151 been described on the protocol level. 153 Approach 1 (we call it H1) has the advantage (seen from the client) 154 that all operational information stays within the client and is not 155 revealed to the provider of the server. On the other hand, does 156 approach 1 require that the provider of the ALTO server, i.e., the 157 network operator, reveals information about its network structure 158 (e.g., AS numbers, IP ranges, topology information in general) to the 159 ALTO client. 161 Approach 2 (we call it H2) has the advantage (seen from the operator) 162 that all operational information stays with the ALTO server and is 163 not revealed to the ALTO client. On the other hand, does approach 2 164 require that the clients send their operational information to the 165 server. 167 Both approaches have their pros and cons and are extensively 168 discussed on the ALTO mailing list. But there is basically a 169 dilemma: Approach 1 is seen as the only working solution by peer-to- 170 peer software vendors and approach 2 is seen as the only working by 171 the network operators. But neither the software vendors nor the 172 operators seem to willing to change their position. However, there 173 is the need to get both sides on board, to come to a solution. 175 +-----+ 176 **| |** 177 ** +-----+ * 178 ** * * 179 ** * * 180 +-----+ +------+ +-----+** +-----+ * 181 | |.....| |=====| |**********| | * 182 +-----+ +------+ +-----+** +-----+ * 183 Source of ALTO Resource ** * * 184 topological service directory ** * * 185 information ("tracker") ** +-----+ * 186 **| |** 187 +-----+ 188 Peers 189 Legend: 190 === ALTO client protocol 191 *** Application protocol 192 ... Provisioning protocol 194 Figure 2: Overview of protocol interaction between ALTO elements, 195 scenario with tracker 197 However, Figure Figure 2does not denote where the ALTO elements are 198 actually located, i.e., if the tracker and the ALTO server are in the 199 same ISP's domain, or if the tracker and the ALTO server are managed/ 200 owned/located in different domains. The latter is the typical use 201 case, e.g., taking Pirate Bay as example that serves Bittorrent users 202 world-wide. 204 +-----+ 205 =====| |** 206 ==== +-----+ * 207 ==== * * 208 ==== * * 209 +-----+ +------+===== +-----+ * 210 | |.....| |======================| | * 211 +-----+ +------+===== +-----+ * 212 Source of ALTO ==== * * 213 topological service ==== * * 214 information ==== +-----+ * 215 =====| |** 216 +-----+ 217 Legend: 218 === ALTO client protocol 219 *** Application protocol 220 ... Provisioning protocol 222 Figure 3: Overview of protocol interaction between ALTO 223 elements,scenario without tracker 225 Figure Figure 3 shows the operational model for applications that do 226 not use a tracker, such as, edonky, or in if the tracker should be 227 the queriyng party. This use case also holds true for CDNs. The 228 ALTO server can also be queried by CDNs to get a guidance about where 229 the a particular client accessing data in the CDN is excatly located 230 in the ISP's network. 232 3. Placement of ALTO Server 234 This section discuss where the ALTO server can be placed and which 235 entities are querying the ALTO server from what ALTO client. The 236 section assumes a P2P system relying a tracker to initially find 237 other peers. However, the tracker can be replaced by any other 238 database that provides a rendezvous point for an application. The 239 limitation to a tracker is made for educational purpose, i.e. to ease 240 the general understanding. 241 ,-------. 242 ,---. ,-' `-. +-----------+ 243 ,-' `-. / ISP 1 \ | Peer 1 |***** 244 / \ / +-------------+ \ | | * 245 / ISP X \ +=====>+ ALTO Server | )+-----------+ * 246 / \ = \ +-------------+ / +-----------+ * 247 ; +-----------+ : = \ / | Peer 2 | * 248 | | Tracker |<====+ `-. ,-' | |***** 249 | |ALTO Client|<====+ `-------' +-----------+ ** 250 | +-----------+ | = ,-------. ** 251 : * ; = ,-' `-. +-----------+ ** 252 \ * / = / ISP 2 \ | Peer 3 | ** 253 \ * / = / +-------------+ \ | |***** 254 \ * / +=====>| ALTO Server | )+-----------+ *** 255 `-. * ,-' \ +-------------+ / +-----------+ *** 256 `-*-' \ / | Peer 4 |***** 257 * `-. ,-' | | **** 258 * `-------' +-----------+ **** 259 * **** 260 * **** 261 ***********************************************<****** 262 Legend: 263 === ALTO client protocol 264 *** Application protocol 266 Figure 4: Global tracker accessing ALTO server at various ISPs 268 Figure Figure 4 depicts a tracker-based system, where the tracker 269 embeds the ALTO client. The tracker itself is hosted and operated by 270 an entity different than the ISP hosting and operating the ALTO 271 server. Initially, the tracker has to look-up the ALTO server in 272 charge for each peer where it receives a ALTO query for. Therefore, 273 the ALTO server has to discover the handling ALTO server, as 274 described in [I-D.kiesel-alto-3pdisc]. However, the peers do not 275 have any way to query the server themselves. This setting allows to 276 give the peers a better selection of candidate peers for their 277 operation at an initial time, but does not consider peers learned 278 through direct peer-to-peer knowledge exchange, AKA peer exchange in 279 various peer-to-peer protocols. 281 ,-------. +-----------+ 282 ,---. ,-' `-. +==>| Peer 1 |***** 283 ,-' `-. / ISP 1 \ = |ALTO Client| * 284 / \ / +-------------+<=+ +-----------+ * 285 / ISP X \ | + ALTO Server |<=+ +-----------+ * 286 / \ \ +-------------+ /= | Peer 2 | * 287 ; +---------+ : \ / +==>|ALTO Client|***** 288 | | Global | | `-. ,-' +-----------+ ** 289 | | Tracker | | `-------' ** 290 | +---------+ | ,-------. +-----------+ ** 291 : * ; ,-' `-. +==>| Peer 3 | ** 292 \ * / / ISP 2 \ = |ALTO Client|***** 293 \ * / / +-------------+<=+ +-----------+ *** 294 \ * / | | ALTO Server |<=+ +-----------+ *** 295 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 296 `-*-' \ / +==>|ALTO Client| **** 297 * `-. ,-' +-----------+ **** 298 * `-------' **** 299 * **** 300 ***********************************************<**** 301 Legend: 302 === ALTO client protocol 303 *** Application protocol 305 Figure 5: Global Tracker - Local ALTO Servers 307 The scenario in Figure Figure 5 lets the peers directly communicate 308 with their ISP's ALTO server (i.e., ALTO client embedded in the 309 peers), giving thus the peers the most control on which information 310 they query for, as they can integrate information received from 311 trackers and through direct eer-to-peer knowledge exchange. 313 ,-------. +-----------+ 314 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 315 ,-' `-. /+-------------+\ * | | 316 / \ / + Tracker |<** +-----------+ 317 / ISP X \ | +-----===-----+<** +-----------+ 318 / \ \ +-----===-----+ /* | Peer 2 | 319 ; +---------+ : \+ ALTO Server |/ ***>| | 320 | | Global | | +-------------+ +-----------+ 321 | | Tracker | | `-------' 322 | +---------+ | +-----------+ 323 : ^ ; ,-------. | Peer 3 | 324 \ * / ,-' ISP 2 `-. ***>| | 325 \ * / /+-------------+\ * +-----------+ 326 \ * / / + Tracker |<** +-----------+ 327 `-. *,-' | +-----===-----+ | | Peer 4 |<* 328 `---* \ +-----===-----+ / | | * 329 * \+ ALTO Server |/ +-----------+ * 330 * +-------------+ * 331 * `-------' * 332 *********************************************** 333 Legend: 334 === ALTO client protocol 335 *** Application protocol 337 Figure 6: P4P approach with local tracker and local ALTO server 339 There are some attempts to let ISP's to deploy their own trackers, as 340 shown in Figure 6. In this case, the client has no chance to get 341 guidance from the ALTO server, other than talking to the ISP's 342 tracker. However, the peers would have still chance the contact 343 other trackers, deployed by entities other than the peer's ISP. 345 The figures Figure 6 and Figure 4 ostensibly take peers the 346 possibility to directly query the ALTO server, if the communication 347 with the ALTO server is not permitted for any reason. However, 348 considering the plethora of different applications of ALTO, e.g., 349 multiple tracker and non-tracker based P2P systems and or 350 applications searching for relays, it seems to be beneficial for all 351 participants to let the peers directly query the ALTO server. The 352 peers are also the single point having all operational knowledge to 353 decide whether to use the ALTO guidance and how to use the ALTO 354 guidance. This is a preference for the scenario depicted in Figure 355 Figure 5. 357 4. API between ALTO Client and Application 359 This sections gives some informational guidance on how the interface 360 between the actual application using the ALTO guidance and the ALTO 361 client can look like. 363 This is still TBD. 365 5. Security Considerations 367 The ALTO protocol itself, as well as, the ALTO client and server 368 raise new security issues beyond the one mentioned in 369 [I-D.ietf-alto-protocol] and issues related to message transport over 370 the Internet. For instance, Denial of Service (DoS) is of interest 371 for the ALTO server and also for the ALTO client. A server can get 372 overloaded if too many TCP requests hit the server, or if the query 373 load of the server surpasses the maximum computing capacity. An ALTO 374 client can get overloaded if the responses from the sever are, either 375 intentionally or due to an implementation mistake, too large to be 376 handled by that particular client. 378 5.1. Information Leakage from the ALTO Server 380 The ALTO server will be provisioned with information about the owning 381 ISP's network and very likely also with information about neighboring 382 ISPs. This information (e.g., network topology, business relations, 383 etc) is consider to be confidential to the ISP and must not be 384 revealed. 386 The ALTO server will naturally reveal parts of that information in 387 small doses to peers, as the guidance given will depend on the above 388 mentioned information. This is seen beneficial for both parties, 389 i.e., the ISP's and the peer's. However, there is the chance that 390 one or multipe peers are querying an ALTO server with the goal to 391 gather information about network topology or any other data 392 considered confidential or at least sensitive. It is unclear whether 393 this is a real technical security risk or whether this is more a 394 perceived security risk. 396 5.2. ALTO Server Access 398 Depending on the use case of ALTO, several access restrictions to an 399 ALTO server may or may not apply. For an ALTO server that is solely 400 accessible by peers from the ISP network (as shown in Figure 5), for 401 instance, the source IP address can be used to grant only access from 402 that ISP network to the server. This will "limit" the number of 403 peers able to attack the server to the user's of the ISP (however, 404 including botnet computers). 406 On the other hand, if the ALTO server has to be accessible by parties 407 not located in the ISP's network (see Figure Figure 4), e.g., by a 408 third-party tracker or by a CDN system outside the ISP's network, the 409 access restrictions have to be more loose. In the extreme case, 410 i.e., no access restrictions, each and every host in the Internet can 411 access the ALTO server. This might no the intention of the ISP, as 412 the server is not only subjec to more possible attacks, but also on 413 the load imposed to the server, i.e., possibly more ALTO clients to 414 serve and thus more work load. 416 5.3. Faking ALTO Guidance 418 It has not yet been investigated how a faked or wrong ALTO guidance 419 by an ALTO server can impact the operation of the network and also 420 the peers. 422 Here is a list of examples how the ALTO guidance could be faked and 423 what possible consequences may arise: 425 Sorting An attacker could change to sorting order of the ALTO 426 guidance (given that the order is of importance, otherwise the 427 ranking mechanism is of interest), i.e., declaring peers located 428 outside the ISP as peers to be preferred. This will not pose a 429 big risk to the network or peers, as it would mimic the "regular" 430 peer operation without traffic localization, apart from the 431 communication/processing overhead for ALTO. However, it could 432 mean that ALTO is reaching the opposite goal of shuffling more 433 data across ISP boundaries, incurring more costs for the ISP. 435 Preference of a single peer A single IP address (thus a peer) could 436 be marked as to be preferred all over other peers. This peer can 437 be located within the local ISP or also in other parts of the 438 Internet (e.g., a web server). This could lead to the case that 439 quite a number of peers to trying to contact this IP address, 440 possibly causing a Denial of Service (DoS) attack. 442 This section is solely giving a first shot on security issues related 443 to ALTO deployments. 445 6. Conclusion 447 This is the first version of the deployment considerations and for 448 sure the considerations are yet incomplete and imprecise. 450 The first two figures have been deliberately taken from the 451 requirements draft. 453 7. References 455 7.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 7.2. Informative References 462 [ACM.ispp2p] 463 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 464 and P2P systems co-operate for improved performance?", In 465 ACM SIGCOMM Computer Communications Review 466 (CCR), 37:3, pp. 29-40. 468 [I-D.akonjang-alto-proxidor] 469 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 470 Saucez, "The PROXIDOR Service", 471 draft-akonjang-alto-proxidor-00 (work in progress), 472 March 2009. 474 [I-D.ietf-alto-protocol] 475 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 476 draft-ietf-alto-protocol-01 (work in progress), 477 December 2009. 479 [I-D.kiesel-alto-3pdisc] 480 Kiesel, S. and M. Tomsu, "Third-party ALTO server 481 discovery", draft-kiesel-alto-3pdisc-01 (work in 482 progress), October 2009. 484 [I-D.kiesel-alto-h12] 485 Kiesel, S. and M. Stiemerling, "ALTO H12", 486 draft-kiesel-alto-h12-00 (work in progress), March 2009. 488 [I-D.kiesel-alto-reqs] 489 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 490 Yang, "Application-Layer Traffic Optimization (ALTO) 491 Requirements", draft-kiesel-alto-reqs-02 (work in 492 progress), March 2009. 494 [I-D.penno-alto-protocol] 495 Penno, R. and Y. Yang, "ALTO Protocol", 496 draft-penno-alto-protocol-04 (work in progress), 497 October 2009. 499 [I-D.shalunov-alto-infoexport] 500 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 501 Export Service", draft-shalunov-alto-infoexport-00 (work 502 in progress), October 2008. 504 [I-D.stiemerling-alto-h1h2-protocol] 505 Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol", 506 draft-stiemerling-alto-h1h2-protocol-00 (work in 507 progress), March 2009. 509 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 510 Optimization (ALTO) Problem Statement", RFC 5693, 511 October 2009. 513 Authors' Addresses 515 Martin Stiemerling 516 NEC Laboratories Europe/University of Goettingen 517 Kurfuerstenanlage 36 518 Heidelberg 69115 519 Germany 521 Phone: +49 6221 4342 113 522 Fax: +49 6221 4342 155 523 Email: martin.stiemerling@neclab.eu 524 URI: http://www.nw.neclab.eu/ 526 Sebastian Kiesel 528 Email: ietf-alto@skiesel.de