ALTO M. Stiemerling Internet-Draft NEC Europe Ltd. Intended status: Standards Track S. Kiesel Expires: September 2, 2010 March 1, 2010 ALTO Deployment Considerations draft-stiemerling-alto-deployments-01 Abstract Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to these applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. The protocol is under specification in the ALTO working group. However, this document discusses the deployment considerations of ALTO and also some preliminary security considerations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2010. Copyright Notice Stiemerling & Kiesel Expires September 2, 2010 [Page 1] Internet-Draft Deployment Considerations March 2010 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Placement of ALTO Server . . . . . . . . . . . . . . . . . . . 8 4. API between ALTO Client and Application . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.1. Information Leakage from the ALTO Server . . . . . . . . . 12 5.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 12 5.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Stiemerling & Kiesel Expires September 2, 2010 [Page 2] Internet-Draft Deployment Considerations March 2010 1. Introduction Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. The basic ideas of ALTO are described in the problem space of ALTO is described in [RFC5693] and the set of requirements is discussed in [I-D.kiesel-alto-reqs]. However, there are no considerations about what issues are to be expected once ALTO will be deployed. This includes, but is not limited to, location of the ALTO server, imposed load to the ALTO server, or from whom the queries are performed. Comments and discussions about this memo should be directed to the ALTO working group: alto@ietf.org. Stiemerling & Kiesel Expires September 2, 2010 [Page 3] Internet-Draft Deployment Considerations March 2010 2. Overview The ALTO protocol is a client/server protocol, operating between a number of ALTO clients and an ALTO server, as sketched in Figure 1. The ALTO working groups defines the ALTO protocol based on the P4P proposal [I-D.ietf-alto-protocol], but there are also other past and current protocol proposals, such as, H12 [I-D.kiesel-alto-h12], or the oracle approach [I-D.akonjang-alto-proxidor] the infoexport approach [I-D.shalunov-alto-infoexport]. Irrespectivelty of all mentioned protocols, the common set is always where the ALTO server is located an who is actually the querying entity to that ALTO server. +----------+ | ALTO | | Server | +----------+ ^ _.-----|------. ,-'' | `--. ,' | `. ( Network | ) `. | ,' `--. | _.-' `------|-----'' v +----------+ +----------+ +----------+ | ALTO | | ALTO |...| ALTO | | Client | | Client | | Client | +----------+ +----------+ +----------+ Figure 1: Network Overview of ALTO Protocol An ALTO server stores information about preferences (e.g., a list of preferred autonomous systems, IP ranges, etc) and ALTO clients can retrieve these preferences. However, there are basically two different approaches on where the preferences are actually processed: 1. The ALTO server has a list of preferences and clients can retrieve this list via the ALTO protocol. This preference list can be partially updated by the server. The actual processing of the data is done on the client and thus there is no data of the client's operation revealed to the ALTO server . This approach has been proposed by [I-D.shalunov-alto-infoexport]. 2. The ALTO server has a list of preferences or preferences calculated during runtime and the ALTO client is sending Stiemerling & Kiesel Expires September 2, 2010 [Page 4] Internet-Draft Deployment Considerations March 2010 information of its operation (e.g., a list of IP addresses) to the server. The server is using this operational information to determine its preferences and returns these preferences (e.g., a sorted list of the IP addresses) back to the ALTO client. This approach has been initially described in [ACM.ispp2p], but never been described on the protocol level. Approach 1 (we call it H1) has the advantage (seen from the client) that all operational information stays within the client and is not revealed to the provider of the server. On the other hand, does approach 1 require that the provider of the ALTO server, i.e., the network operator, reveals information about its network structure (e.g., AS numbers, IP ranges, topology information in general) to the ALTO client. Approach 2 (we call it H2) has the advantage (seen from the operator) that all operational information stays with the ALTO server and is not revealed to the ALTO client. On the other hand, does approach 2 require that the clients send their operational information to the server. Both approaches have their pros and cons and are extensively discussed on the ALTO mailing list. But there is basically a dilemma: Approach 1 is seen as the only working solution by peer-to- peer software vendors and approach 2 is seen as the only working by the network operators. But neither the software vendors nor the operators seem to willing to change their position. However, there is the need to get both sides on board, to come to a solution. Stiemerling & Kiesel Expires September 2, 2010 [Page 5] Internet-Draft Deployment Considerations March 2010 +-----+ **| |** ** +-----+ * ** * * ** * * +-----+ +------+ +-----+** +-----+ * | |.....| |=====| |**********| | * +-----+ +------+ +-----+** +-----+ * Source of ALTO Resource ** * * topological service directory ** * * information ("tracker") ** +-----+ * **| |** +-----+ Peers Legend: === ALTO client protocol *** Application protocol ... Provisioning protocol Figure 2: Overview of protocol interaction between ALTO elements, scenario with tracker However, Figure Figure 2does not denote where the ALTO elements are actually located, i.e., if the tracker and the ALTO server are in the same ISP's domain, or if the tracker and the ALTO server are managed/ owned/located in different domains. The latter is the typical use case, e.g., taking Pirate Bay as example that serves Bittorrent users world-wide. Stiemerling & Kiesel Expires September 2, 2010 [Page 6] Internet-Draft Deployment Considerations March 2010 +-----+ =====| |** ==== +-----+ * ==== * * ==== * * +-----+ +------+===== +-----+ * | |.....| |======================| | * +-----+ +------+===== +-----+ * Source of ALTO ==== * * topological service ==== * * information ==== +-----+ * =====| |** +-----+ Legend: === ALTO client protocol *** Application protocol ... Provisioning protocol Figure 3: Overview of protocol interaction between ALTO elements,scenario without tracker Figure Figure 3 shows the operational model for applications that do not use a tracker, such as, edonky, or in if the tracker should be the queriyng party. This use case also holds true for CDNs. The ALTO server can also be queried by CDNs to get a guidance about where the a particular client accessing data in the CDN is excatly located in the ISP's network. Stiemerling & Kiesel Expires September 2, 2010 [Page 7] Internet-Draft Deployment Considerations March 2010 3. Placement of ALTO Server This section discuss where the ALTO server can be placed and which entities are querying the ALTO server from what ALTO client. The section assumes a P2P system relying a tracker to initially find other peers. However, the tracker can be replaced by any other database that provides a rendezvous point for an application. The limitation to a tracker is made for educational purpose, i.e. to ease the general understanding. ,-------. ,---. ,-' `-. +-----------+ ,-' `-. / ISP 1 \ | Peer 1 |***** / \ / +-------------+ \ | | * / ISP X \ +=====>+ ALTO Server | )+-----------+ * / \ = \ +-------------+ / +-----------+ * ; +-----------+ : = \ / | Peer 2 | * | | Tracker |<====+ `-. ,-' | |***** | |ALTO Client|<====+ `-------' +-----------+ ** | +-----------+ | = ,-------. ** : * ; = ,-' `-. +-----------+ ** \ * / = / ISP 2 \ | Peer 3 | ** \ * / = / +-------------+ \ | |***** \ * / +=====>| ALTO Server | )+-----------+ *** `-. * ,-' \ +-------------+ / +-----------+ *** `-*-' \ / | Peer 4 |***** * `-. ,-' | | **** * `-------' +-----------+ **** * **** * **** ***********************************************<****** Legend: === ALTO client protocol *** Application protocol Figure 4: Global tracker accessing ALTO server at various ISPs Figure Figure 4 depicts a tracker-based system, where the tracker embeds the ALTO client. The tracker itself is hosted and operated by an entity different than the ISP hosting and operating the ALTO server. Initially, the tracker has to look-up the ALTO server in charge for each peer where it receives a ALTO query for. Therefore, the ALTO server has to discover the handling ALTO server, as described in [I-D.kiesel-alto-3pdisc]. However, the peers do not have any way to query the server themselves. This setting allows to give the peers a better selection of candidate peers for their operation at an initial time, but does not consider peers learned through direct peer-to-peer knowledge exchange, AKA peer exchange in various peer-to-peer protocols. Stiemerling & Kiesel Expires September 2, 2010 [Page 8] Internet-Draft Deployment Considerations March 2010 ,-------. +-----------+ ,---. ,-' `-. +==>| Peer 1 |***** ,-' `-. / ISP 1 \ = |ALTO Client| * / \ / +-------------+<=+ +-----------+ * / ISP X \ | + ALTO Server |<=+ +-----------+ * / \ \ +-------------+ /= | Peer 2 | * ; +---------+ : \ / +==>|ALTO Client|***** | | Global | | `-. ,-' +-----------+ ** | | Tracker | | `-------' ** | +---------+ | ,-------. +-----------+ ** : * ; ,-' `-. +==>| Peer 3 | ** \ * / / ISP 2 \ = |ALTO Client|***** \ * / / +-------------+<=+ +-----------+ *** \ * / | | ALTO Server |<=+ +-----------+ *** `-. * ,-' \ +-------------+ /= | Peer 4 |***** `-*-' \ / +==>|ALTO Client| **** * `-. ,-' +-----------+ **** * `-------' **** * **** ***********************************************<**** Legend: === ALTO client protocol *** Application protocol Figure 5: Global Tracker - Local ALTO Servers The scenario in Figure Figure 5 lets the peers directly communicate with their ISP's ALTO server (i.e., ALTO client embedded in the peers), giving thus the peers the most control on which information they query for, as they can integrate information received from trackers and through direct eer-to-peer knowledge exchange. Stiemerling & Kiesel Expires September 2, 2010 [Page 9] Internet-Draft Deployment Considerations March 2010 ,-------. +-----------+ ,---. ,-' ISP 1 `-. ***>| Peer 1 | ,-' `-. /+-------------+\ * | | / \ / + Tracker |<** +-----------+ / ISP X \ | +-----===-----+<** +-----------+ / \ \ +-----===-----+ /* | Peer 2 | ; +---------+ : \+ ALTO Server |/ ***>| | | | Global | | +-------------+ +-----------+ | | Tracker | | `-------' | +---------+ | +-----------+ : ^ ; ,-------. | Peer 3 | \ * / ,-' ISP 2 `-. ***>| | \ * / /+-------------+\ * +-----------+ \ * / / + Tracker |<** +-----------+ `-. *,-' | +-----===-----+ | | Peer 4 |<* `---* \ +-----===-----+ / | | * * \+ ALTO Server |/ +-----------+ * * +-------------+ * * `-------' * *********************************************** Legend: === ALTO client protocol *** Application protocol Figure 6: P4P approach with local tracker and local ALTO server There are some attempts to let ISP's to deploy their own trackers, as shown in Figure 6. In this case, the client has no chance to get guidance from the ALTO server, other than talking to the ISP's tracker. However, the peers would have still chance the contact other trackers, deployed by entities other than the peer's ISP. The figures Figure 6 and Figure 4 ostensibly take peers the possibility to directly query the ALTO server, if the communication with the ALTO server is not permitted for any reason. However, considering the plethora of different applications of ALTO, e.g., multiple tracker and non-tracker based P2P systems and or applications searching for relays, it seems to be beneficial for all participants to let the peers directly query the ALTO server. The peers are also the single point having all operational knowledge to decide whether to use the ALTO guidance and how to use the ALTO guidance. This is a preference for the scenario depicted in Figure Figure 5. Stiemerling & Kiesel Expires September 2, 2010 [Page 10] Internet-Draft Deployment Considerations March 2010 4. API between ALTO Client and Application This sections gives some informational guidance on how the interface between the actual application using the ALTO guidance and the ALTO client can look like. This is still TBD. Stiemerling & Kiesel Expires September 2, 2010 [Page 11] Internet-Draft Deployment Considerations March 2010 5. Security Considerations The ALTO protocol itself, as well as, the ALTO client and server raise new security issues beyond the one mentioned in [I-D.ietf-alto-protocol] and issues related to message transport over the Internet. For instance, Denial of Service (DoS) is of interest for the ALTO server and also for the ALTO client. A server can get overloaded if too many TCP requests hit the server, or if the query load of the server surpasses the maximum computing capacity. An ALTO client can get overloaded if the responses from the sever are, either intentionally or due to an implementation mistake, too large to be handled by that particular client. 5.1. Information Leakage from the ALTO Server The ALTO server will be provisioned with information about the owning ISP's network and very likely also with information about neighboring ISPs. This information (e.g., network topology, business relations, etc) is consider to be confidential to the ISP and must not be revealed. The ALTO server will naturally reveal parts of that information in small doses to peers, as the guidance given will depend on the above mentioned information. This is seen beneficial for both parties, i.e., the ISP's and the peer's. However, there is the chance that one or multipe peers are querying an ALTO server with the goal to gather information about network topology or any other data considered confidential or at least sensitive. It is unclear whether this is a real technical security risk or whether this is more a perceived security risk. 5.2. ALTO Server Access Depending on the use case of ALTO, several access restrictions to an ALTO server may or may not apply. For an ALTO server that is solely accessible by peers from the ISP network (as shown in Figure 5), for instance, the source IP address can be used to grant only access from that ISP network to the server. This will "limit" the number of peers able to attack the server to the user's of the ISP (however, including botnet computers). On the other hand, if the ALTO server has to be accessible by parties not located in the ISP's network (see Figure Figure 4), e.g., by a third-party tracker or by a CDN system outside the ISP's network, the access restrictions have to be more loose. In the extreme case, i.e., no access restrictions, each and every host in the Internet can access the ALTO server. This might no the intention of the ISP, as the server is not only subjec to more possible attacks, but also on Stiemerling & Kiesel Expires September 2, 2010 [Page 12] Internet-Draft Deployment Considerations March 2010 the load imposed to the server, i.e., possibly more ALTO clients to serve and thus more work load. 5.3. Faking ALTO Guidance It has not yet been investigated how a faked or wrong ALTO guidance by an ALTO server can impact the operation of the network and also the peers. Here is a list of examples how the ALTO guidance could be faked and what possible consequences may arise: Sorting An attacker could change to sorting order of the ALTO guidance (given that the order is of importance, otherwise the ranking mechanism is of interest), i.e., declaring peers located outside the ISP as peers to be preferred. This will not pose a big risk to the network or peers, as it would mimic the "regular" peer operation without traffic localization, apart from the communication/processing overhead for ALTO. However, it could mean that ALTO is reaching the opposite goal of shuffling more data across ISP boundaries, incurring more costs for the ISP. Preference of a single peer A single IP address (thus a peer) could be marked as to be preferred all over other peers. This peer can be located within the local ISP or also in other parts of the Internet (e.g., a web server). This could lead to the case that quite a number of peers to trying to contact this IP address, possibly causing a Denial of Service (DoS) attack. This section is solely giving a first shot on security issues related to ALTO deployments. Stiemerling & Kiesel Expires September 2, 2010 [Page 13] Internet-Draft Deployment Considerations March 2010 6. Conclusion This is the first version of the deployment considerations and for sure the considerations are yet incomplete and imprecise. The first two figures have been deliberately taken from the requirements draft. Stiemerling & Kiesel Expires September 2, 2010 [Page 14] Internet-Draft Deployment Considerations March 2010 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [ACM.ispp2p] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", In ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40. [I-D.akonjang-alto-proxidor] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 (work in progress), March 2009. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-01 (work in progress), December 2009. [I-D.kiesel-alto-3pdisc] Kiesel, S. and M. Tomsu, "Third-party ALTO server discovery", draft-kiesel-alto-3pdisc-01 (work in progress), October 2009. [I-D.kiesel-alto-h12] Kiesel, S. and M. Stiemerling, "ALTO H12", draft-kiesel-alto-h12-01 (work in progress), March 2010. [I-D.kiesel-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-kiesel-alto-reqs-02 (work in progress), March 2009. [I-D.penno-alto-protocol] Penno, R. and Y. Yang, "ALTO Protocol", draft-penno-alto-protocol-04 (work in progress), October 2009. [I-D.shalunov-alto-infoexport] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Stiemerling & Kiesel Expires September 2, 2010 [Page 15] Internet-Draft Deployment Considerations March 2010 Export Service", draft-shalunov-alto-infoexport-00 (work in progress), October 2008. [I-D.stiemerling-alto-h1h2-protocol] Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol", draft-stiemerling-alto-h1h2-protocol-00 (work in progress), March 2009. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. Stiemerling & Kiesel Expires September 2, 2010 [Page 16] Internet-Draft Deployment Considerations March 2010 Appendix A. Acknowledgments Martin Stiemerling is partially supported by the NAPA-WINE project (Network-Aware P2P-TV Application over Wise Networks, http://www.napa-wine.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 214412). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the NAPA-WINE project or the European Commission. Stiemerling & Kiesel Expires September 2, 2010 [Page 17] Internet-Draft Deployment Considerations March 2010 Authors' Addresses Martin Stiemerling NEC Laboratories Europe/University of Goettingen Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 Email: martin.stiemerling@neclab.eu URI: http://www.nw.neclab.eu/ Sebastian Kiesel Email: ietf-alto@skiesel.de Stiemerling & Kiesel Expires September 2, 2010 [Page 18]