[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06
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]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/