ALTO M. Stiemerling Internet-Draft NEC Europe Ltd. Intended status: Standards Track August 7, 2009 Expires: February 8, 2010 ALTO Information Redistribution Considered Harmful draft-stiemerling-alto-info-redist-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 February 8, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stiemerling Expires February 8, 2010 [Page 1] Internet-Draft ALTO August 2009 Abstract The merged ALTO protocol proposal proposes several mechanisms to increase scalability of the protocol. One of the proposed mechanisms is the distribution of ALTO information directly between the peers without any involvement of the server. This memo discusses why the proposed mechanism is considered harmful and why the proposed security framework is deployable. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Considered Harmful . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Stiemerling Expires February 8, 2010 [Page 2] Internet-Draft ALTO August 2009 1. Introduction Scalabilty for the ALTO protocol is of major concern, as a single ALTO server potentially has to serve a large number of ALTO clients. The order of magnitude of how many clients will be served by a single ALTO server is not yet clear, but it can be expected that a single server must be able server a multiple of 10,000 clients simultaneously. The merged ALTO protocol proposal [I-D.penno-alto-protocol] proposes several mechanisms to increase scalability of the protocol. One of the proposed mechanisms is the distribution of ALTO information directly between the peers without any involvement of the server and any need to contact the server when having received the information. The next section explores why the proposal is considered harmful. Comments and discussions about this memo should be directed to the ALTO working group: alto@ietf.org. Stiemerling Expires February 8, 2010 [Page 3] Internet-Draft ALTO August 2009 2. Considered Harmful Section 10.4 in [I-D.penno-alto-protocol] proposes this: It is possible for applications to redistribute ALTO information to improve scalability. Even with such a distribution scheme, ALTO Clients obtaining ALTO information must be able to validate the received ALTO information to ensure that it was actually generated by the correct ALTO Server. Further, to prevent the ALTO Server from being a target of attack, the verification scheme must not require ALTO Clients to contact the ALTO Server. This paragraph calls for the ability to distribute ALTO information obtained via the ALTO protocol directly between the peers (called applications in the above text) without any ALTO server involvement. This approach looks promising as it allows to reach more potential clients with the ALTO information. However, there is no mean for the peers to verify whether the information provided is actually intended for their usage nor if the information is actually accurate at their current topological position in the Internet. For instance, peer A located in ISP1 obtains ALTO information from a peer B. Peer B is located in ISP2 and provides the information is has obtained from its local ALTO server. Peer B and peer A do not have an easy way to determine whether they are located in the same ISP's network and thus they share ALTO information across ISP domains. Sharing of ALTO information across domains does not seem to be a natural goal of ALTO. This is considered harmful, as ALTO information that is usual intended to be used within a single ISP is re-distributed. The draft proposes furthermore an assumed security solution that aims at preventing tampering with ALTO information: To fulfill these requirements, ALTO Information meant to be redistributable contains a digital signature which includes a hash of the ALTO information encrypted by the ALTO Server's private key. The corresponding public key should either be part of the ALTO information itself, or it could be included in the interface descriptor. The public key SHOULD include the hostname of the ALTO Server and it SHOULD be signed by a trusted authority. First of all does this require public/private key pair, where the public key is known to each peer and a trusted third party is required. These requirements are possible to be fulfilled in certain deployments but are not in the general Internet deployment case, which in turn limits the applicability of this protocol. Second, the receiving peer needs to contact the ALTO server at least once to Stiemerling Expires February 8, 2010 [Page 4] Internet-Draft ALTO August 2009 obtain the public key part, or it does need to contact another server that provides the public key pair. Stiemerling Expires February 8, 2010 [Page 5] Internet-Draft ALTO August 2009 3. Security Considerations This initial version of this memo does not yet have any security considerations, even though it tackles security issues. Stiemerling Expires February 8, 2010 [Page 6] Internet-Draft ALTO August 2009 4. Conclusion Martin Stiemerling is partially supported by the NAPA-WINE project (http://www.napa-wine.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 214412). Stiemerling Expires February 8, 2010 [Page 7] Internet-Draft ALTO August 2009 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References [I-D.penno-alto-protocol] Penno, R. and Y. Yang, "ALTO Protocol", draft-penno-alto-protocol-03 (work in progress), July 2009. Stiemerling Expires February 8, 2010 [Page 8] Internet-Draft ALTO August 2009 Author's Address Martin Stiemerling NEC Laboratories Europe/University of Goettingen Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 Email: stiemerling@nw.neclab.eu URI: http://www.net.informatik.uni-goettingen.de/people/martin_stiemerling Stiemerling Expires February 8, 2010 [Page 9]