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]