< draft-stiemerling-alto-deployments-03.txt   draft-stiemerling-alto-deployments-04.txt >
ALTO M. Stiemerling ALTO M. Stiemerling
Internet-Draft NEC Europe Ltd. Internet-Draft NEC Europe Ltd.
Intended status: Standards Track S. Kiesel Intended status: Standards Track S. Kiesel
Expires: December 11, 2010 University of Stuttgart Expires: January 13, 2011 University of Stuttgart
June 9, 2010 July 12, 2010
ALTO Deployment Considerations ALTO Deployment Considerations
draft-stiemerling-alto-deployments-03 draft-stiemerling-alto-deployments-04
Abstract Abstract
Many Internet applications are used to access resources, such as Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to these applications, which have to select one or several guidance to these applications, which have to select one or several
hosts from a set of candidates, that are able to provide a desired hosts from a set of candidates, that are able to provide a desired
resource. The protocol is under specification in the ALTO working resource. The protocol is under specification in the ALTO working
group. However, this document discusses the deployment group. This memo discusses deployment related issues of ALTO for
considerations of ALTO and also some preliminary security peer-to-peer and CDNs, some preliminary security considerations, and
considerations. also initial guidance for application designers using ALTO.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 11, 2010. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Placement of ALTO Server for P2P . . . . . . . . . . . . . . . 8 3. Using ALTO for Peer-to-Peer . . . . . . . . . . . . . . . . . 7
4. Placement of ALTO Server for CDNs . . . . . . . . . . . . . . 11 3.1. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 9
4. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 11
5. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 12 5. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 12
6. API between ALTO Client and Application . . . . . . . . . . . 14 6. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.1. Limitations of Map-based Approaches . . . . . . . . . . . 14
7.1. Information Leakage from the ALTO Server . . . . . . . . . 15 6.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 15
7.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 15 6.3. General Challenges . . . . . . . . . . . . . . . . . . . . 15
7.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 16 7. API between ALTO Client and Application . . . . . . . . . . . 17
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Information Leakage from the ALTO Server . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Many Internet applications are used to access resources, such as Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal is not limited to, peer-to-peer file sharing applications and Content
of Application-Layer Traffic Optimization (ALTO) is to provide Delivery Networks (CDNs). The goal of Application-Layer Traffic
guidance to applications, which have to select one or several hosts Optimization (ALTO) is to provide guidance to applications, which
from a set of candidates, that are able to provide a desired have to select one or several hosts from a set of candidates, that
resource. The basic ideas of ALTO are described in the problem space are able to provide a desired resource. The basic ideas of ALTO are
of ALTO is described in [RFC5693] and the set of requirements is described in the problem space of ALTO is described in [RFC5693] and
discussed in [I-D.kiesel-alto-reqs]. the set of requirements is discussed in [I-D.ietf-alto-reqs].
However, there are no considerations about what issues are to be However, there are no considerations about what operational issues
expected once ALTO will be deployed. This includes, but is not are to be expected once ALTO will be deployed. This includes, but is
limited to, location of the ALTO server, imposed load to the ALTO not limited to, location of the ALTO server, imposed load to the ALTO
server, or from whom the queries are performed. server, or from whom the queries are performed.
Comments and discussions about this memo should be directed to the Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org. ALTO working group: alto@ietf.org.
2. Overview 2. Overview
The ALTO protocol is a client/server protocol, operating between a The ALTO protocol is a client/server protocol, operating between a
number of ALTO clients and an ALTO server, as sketched in Figure 1. number of ALTO clients and an ALTO server, as sketched in Figure 1.
The ALTO working groups defines the ALTO protocol
The ALTO working groups defines the ALTO protocol based on the P4P [I-D.ietf-alto-protocol].
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]. Irrespectively 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 | | ALTO |
| Server | | Server |
+----------+ +----------+
^ ^
_.-----|------. _.-----|------.
,-'' | `--. ,-'' | `--.
,' | `. ,' | `.
( Network | ) ( Network | )
skipping to change at page 4, line 39 skipping to change at page 4, line 32
`--. | _.-' `--. | _.-'
`------|-----'' `------|-----''
v v
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO | | ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client | | Client | | Client | | Client |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 1: Network Overview of ALTO Protocol Figure 1: Network Overview of ALTO Protocol
An ALTO server stores information about preferences (e.g., a list of The ALTO server and ALTO clients can be situated at various entities
preferred autonomous systems, IP ranges, etc) and ALTO clients can in a network deployment. The first differentiation is whether the
retrieve these preferences. However, there are basically two ALTO client is located on the actual host that runs the application,
different approaches on where the preferences are actually processed: as shown in Figure 2, (e.g., peer-to-peer filesharing application) or
if the ALTO client is located on resource directory, as shown in
1. The ALTO server has a list of preferences and clients can Figure 3 (e.g., a tracker in peer-to-peer filesharing).
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
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. | |.....| |======================| | *
+-----+ +------+===== +-----+ *
Source of ALTO ==== * *
topological service ==== * *
information ==== +-----+ *
=====| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol
Approach 2 (we call it H2) has the advantage (seen from the operator) Figure 2: Overview of protocol interaction between ALTO
that all operational information stays with the ALTO server and is elements,scenario without tracker
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 Figure 2 shows the operational model for applications that do not use
discussed on the ALTO mailing list. But there is basically a a tracker, such as, edonky, or in if the tracker should be the
dilemma: Approach 1 is seen as the only working solution by peer-to- querying party. This use case also holds true for CDNs. The ALTO
peer software vendors and approach 2 is seen as the only working by server can also be queried by CDNs to get a guidance about where the
the network operators. But neither the software vendors nor the a particular client accessing data in the CDN is exactly located in
operators seem to willing to change their position. However, there the ISP's network.
is the need to get both sides on board, to come to a solution.
+-----+ +-----+
**| |** **| |**
** +-----+ * ** +-----+ *
** * * ** * *
** * * ** * *
+-----+ +------+ +-----+** +-----+ * +-----+ +------+ +-----+** +-----+ *
| |.....| |=====| |**********| | * | |.....| |=====| |**********| | *
+-----+ +------+ +-----+** +-----+ * +-----+ +------+ +-----+** +-----+ *
Source of ALTO Resource ** * * Source of ALTO Resource ** * *
topological service directory ** * * topological service directory ** * *
information ("tracker") ** +-----+ * information ("tracker") ** +-----+ *
**| |** **| |**
+-----+ +-----+
Peers Peers
Legend: Legend:
=== ALTO client protocol === ALTO client protocol
*** Application protocol *** Application protocol
... Provisioning protocol ... Provisioning protocol
Figure 2: Overview of protocol interaction between ALTO elements, Figure 3: Overview of protocol interaction between ALTO elements,
scenario with tracker scenario with tracker
However, Figure 2 does not denote where the ALTO elements are However, Figure 3 does not denote where the ALTO elements are
actually located, i.e., if the tracker and the ALTO server are in the 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/ 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 owned/located in different domains. The latter is the typical use
case, e.g., taking Pirate Bay as example that serves Bittorrent users case, e.g., taking Pirate Bay as example that serves Bittorrent peers
world-wide. world-wide.
+-----+ 3. Using ALTO for Peer-to-Peer
=====| |**
==== +-----+ *
==== * *
==== * *
+-----+ +------+===== +-----+ *
| |.....| |======================| | *
+-----+ +------+===== +-----+ *
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 3 shows the operational model for applications that do not use
a tracker, such as, edonky, or in if the tracker should be the
querying 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 exactly located in
the ISP's network.
3. Placement of ALTO Server for P2P
This section discuss where the ALTO server can be placed and which This section discuss where the ALTO server can be placed and which
entities are querying the ALTO server from what ALTO client. The entities are querying the ALTO server from what ALTO client. The
section assumes a P2P system relying a tracker to initially find section assumes a P2P system relying a tracker to initially find
other peers. However, the tracker can be replaced by any other other peers. However, the tracker can be replaced by any other
database that provides a rendezvous point for an application. The database that provides a rendezvous point for an application. The
limitation to a tracker is made for educational purpose, i.e. to ease limitation to a tracker is made for educational purpose, i.e. to ease
the general understanding. the general understanding.
,-------. ,-------.
,---. ,-' `-. +-----------+ ,---. ,-' `-. +-----------+
skipping to change at page 11, line 5 skipping to change at page 9, line 48
directly query the ALTO server, if the communication with the ALTO directly query the ALTO server, if the communication with the ALTO
server is not permitted for any reason. However, considering the server is not permitted for any reason. However, considering the
plethora of different applications of ALTO, e.g., multiple tracker plethora of different applications of ALTO, e.g., multiple tracker
and non-tracker based P2P systems and or applications searching for and non-tracker based P2P systems and or applications searching for
relays, it seems to be beneficial for all participants to let the relays, it seems to be beneficial for all participants to let the
peers directly query the ALTO server. The peers are also the single peers directly query the ALTO server. The peers are also the single
point having all operational knowledge to decide whether to use the point having all operational knowledge to decide whether to use the
ALTO guidance and how to use the ALTO guidance. This is a preference ALTO guidance and how to use the ALTO guidance. This is a preference
for the scenario depicted in Figure Figure 5. for the scenario depicted in Figure Figure 5.
4. Placement of ALTO Server for CDNs 3.1. Expectations of ALTO
This section hints to some recent experiments conducted with ALTO-
like deployments in Internet Service Provider (ISP) network's. NTT
performed tests with their HINT server implementation and dummy nodes
to gain insight on how an ALTO-like service influence a peer-to-peer
systems [I-D.kamei-p2p-experiments-japan]. The results of an early
experiment conducted in the Comcast network are documented
here[RFC5632]
4. Using ALTO for CDNs
Section 3 discussed the placement and usage of ALTO for P2P systems, Section 3 discussed the placement and usage of ALTO for P2P systems,
but not beyond. This section discuss the usage of ALTO for Content but not beyond. This section discuss the usage of ALTO for Content
Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a
web page, videos, etc) closer to location of the user - where close web page, videos, etc) closer to the location of the user - where
refers to shorten the distance between the client and the server in close refers to shorten the distance between the client and the
the IP topology. CDNs use several techniques to decide which server server in the IP topology. CDNs use several techniques to decide
is closest to a client requesting a service. One common way to do which server is closest to a client requesting a service. One common
so, is relying on the DNS system, but there are many other ways, see way to do so, is relying on the DNS system, but there are many other
[RFC3568], and has some issues as detailed in ways, see [RFC3568].
[I-D.vandergaast-edns-client-ip].
This section refers to [I-D.penno-alto-cdn] as a initial step. The general issue for CDNs, independent of DNS or HTTP Redirect based
approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN
logic has to match the client's IP address with the closest CDN
cache. This matching is not trivial, for instance, in DNS based
approaches, where the IP address of the DNS original requester is
unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of
this and a solution approach).
5. Cascading ALTO Servers 5. Cascading ALTO Servers
The main assumptions of ALTO seems to be each ISP operates its own The main assumptions of ALTO seems to be each ISP operates its own
ALTO server independently, irrespectively of the ISP's situation. ALTO server independently, irrespectively of the ISP's situation.
This may true for most envisioned deployments of ALTO but there are This may true for most envisioned deployments of ALTO but there are
certain deployments that may have different settings. Figure 7 shows certain deployments that may have different settings. Figure 7 shows
such setting, were for example, a university network is connected to such setting, were for example, a university network is connected to
two upstream providers. ISP2 if the national research network and two upstream providers. ISP2 if the national research network and
ISP1 is a commercial upstream provider to this university network. ISP1 is a commercial upstream provider to this university network.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
In this setting all "destinations" useful for the peers within ISP2 In this setting all "destinations" useful for the peers within ISP2
are free-of-charge for the peers located in the university network are free-of-charge for the peers located in the university network
(i.e., they are preferred in the rating of the ALTO server). (i.e., they are preferred in the rating of the ALTO server).
However, all traffic that is not towards ISP2 will be handled by the However, all traffic that is not towards ISP2 will be handled by the
ISP1 upstream provider. Therefore, the ALTO server at the university ISP1 upstream provider. Therefore, the ALTO server at the university
has also to include the guidance given by the ISP1 ALTO server in its has also to include the guidance given by the ISP1 ALTO server in its
replies to the ALTO clients. This can be called cascaded ALTO replies to the ALTO clients. This can be called cascaded ALTO
servers. servers.
6. API between ALTO Client and Application 6. Known Limitations of ALTO
This section describes some known limitations of ALTO in general or
specific mechanisms in ALTO.
6.1. Limitations of Map-based Approaches
The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,
amongst others mechanism, so-called network maps. The network map
approach uses Host Group Descriptors that group one or multiple
subnetworks (i.e., IP prefixes) to a single Host Group Descriptor. A
set of IP prefixes is called partition and the associated Host Group
Descriptor is called partition ID. The "costs" between the various
partition IDs is stored in a second map, the cost map. Map-based
approaches are chosen as they lower the signaling load on the server,
as the maps have only to be retrieved if they are changed.
The main assumption for map-based approaches is that the information
provided in these maps is static for a longer period of time, where
this period of time refers to days, but not hours or even minutes.
This assumption is fine, as long as the network operator does not
change any parameter, e.g., routing within the network and to the
upstream peers, IP address assignment stays stable (and thus the
mapping to the partitions). However, there are several cases where
this assumption is not valid, as:
1. ISPs reallocate IPv4 subnets from time to time;
2. ISPs reallocate IPv4 subnets on short notice;
3. IP prefix blocks may be assigned to a single DSLAM which serves a
variety of access networks.
For 1): ISPs reallocate IPv4 subnets within their infrastructure from
time to time, partly to ensure the efficient usage of IPv4 addresses
(a scarce resource), and partly to enable efficient route tables
within their network routers. The frequency of these "renumbering
events" depend on the growth in number of subscribers and the
availability of address space within the ISP. As a result, a
subscriber's household device could retain an IPv4 address for as
short as a few minutes, or for months at a time or even longer.
Some folks have suggested that ISPs providing ALTO services could
sub-divide their subscribers' devices into different IPv4 subnets
(or certain IPv4 address ranges) based on the purchased service
tier, as well as based on the location in the network topology.
The problem is that this sub-allocation of IPv4 subnets tends to
decrease the efficiency of IPv4 address allocation. A growing ISP
that needs to maintain high efficiency of IPv4 address utilization
may be reluctant to jeopardize their future acquisition of IPv4
address space.
However, this is not an issue for map-based approaches if changes are
applied in the order of days.
For 2): ISPs can use techniques, such as ODAP (XXX) that allow the
reallocation of IP prefixes on very short notice, i.e., within
minutes. An IP prefix that has no IP address assignment to a host
anymore can be reallocate to areas where there is currently a high
demand for IP addresses.
For 3): In DSL-based access networks, IP prefixes are assigned to
DSLAMs which are the first IP-hop in the access-network between the
CPE and the Internet. The access-network between CPE and DSLAM
(called aggregation network) can have varying characteristics (and
thus associated costs), but still using the same IP prefix. For
instance one IP addresses IP11 out of a IP prefix IP1 can be assigned
to a VDSL (e.g., 2 MBit/s uplink) access-line while the subsequent IP
address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s
uplink). These IP addresses are assigned on a first come first
served basis, i.e., the a single IP address out of the same IP prefix
can change its associated costs quite fast. This may not be an issue
with respect to the used upstream provider (thus the cross ISP
traffic) but depending on the capacity of the aggregation-network
this may raise to an issue.
6.2. Limitiations of Non-Map-based Approaches
The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,
amongst others mechanism, a mechanism called Endpoint Cost Service.
ALTO clients can ask guidance for specific IP addresses to the ALTO
server. However, asking for IP addresses, asking with long lists of
IP addresses, and asking quite frequent may overload the ALTO server.
The server has to rank each received IP address which causes load at
the server. This may be amplified by the fact that not only a single
ALTO client is asking for guidance, but a larger number of them.
Caching of IP addresses at the ALTO client or the usage of the H12
approach [I-D.kiesel-alto-h12] in conjunction with caching may lower
the query load on the ALTO server.
6.3. General Challenges
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 .
2. The ALTO server has a list of preferences or preferences
calculated during runtime and the ALTO client is sending
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.
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.
7. API between ALTO Client and Application
This sections gives some informational guidance on how the interface This sections gives some informational guidance on how the interface
between the actual application using the ALTO guidance and the ALTO between the actual application using the ALTO guidance and the ALTO
client can look like. client can look like.
This is still TBD. This is still TBD.
7. Security Considerations 8. Security Considerations
The ALTO protocol itself, as well as, the ALTO client and server The ALTO protocol itself, as well as, the ALTO client and server
raise new security issues beyond the one mentioned in raise new security issues beyond the one mentioned in
[I-D.ietf-alto-protocol] and issues related to message transport over [I-D.ietf-alto-protocol] and issues related to message transport over
the Internet. For instance, Denial of Service (DoS) is of interest 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 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 overloaded if too many TCP requests hit the server, or if the query
load of the server surpasses the maximum computing capacity. An ALTO load of the server surpasses the maximum computing capacity. An ALTO
client can get overloaded if the responses from the sever are, either client can get overloaded if the responses from the sever are, either
intentionally or due to an implementation mistake, too large to be intentionally or due to an implementation mistake, too large to be
handled by that particular client. handled by that particular client.
7.1. Information Leakage from the ALTO Server 8.1. Information Leakage from the ALTO Server
The ALTO server will be provisioned with information about the owning The ALTO server will be provisioned with information about the owning
ISP's network and very likely also with information about neighboring ISP's network and very likely also with information about neighboring
ISPs. This information (e.g., network topology, business relations, ISPs. This information (e.g., network topology, business relations,
etc) is consider to be confidential to the ISP and must not be etc) is consider to be confidential to the ISP and must not be
revealed. revealed.
The ALTO server will naturally reveal parts of that information in The ALTO server will naturally reveal parts of that information in
small doses to peers, as the guidance given will depend on the above small doses to peers, as the guidance given will depend on the above
mentioned information. This is seen beneficial for both parties, mentioned information. This is seen beneficial for both parties,
i.e., the ISP's and the peer's. However, there is the chance that i.e., the ISP's and the peer's. However, there is the chance that
one or multiple peers are querying an ALTO server with the goal to one or multiple peers are querying an ALTO server with the goal to
gather information about network topology or any other data gather information about network topology or any other data
considered confidential or at least sensitive. It is unclear whether considered confidential or at least sensitive. It is unclear whether
this is a real technical security risk or whether this is more a this is a real technical security risk or whether this is more a
perceived security risk. perceived security risk.
7.2. ALTO Server Access 8.2. ALTO Server Access
Depending on the use case of ALTO, several access restrictions to an 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 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 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 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 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, peers able to attack the server to the user's of the ISP (however,
including botnet computers). including botnet computers).
On the other hand, if the ALTO server has to be accessible by parties 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 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 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, access restrictions have to be more loose. In the extreme case,
i.e., no access restrictions, each and every host in the Internet can 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 access the ALTO server. This might no the intention of the ISP, as
the server is not only subject to more possible attacks, but also on the server is not only subject to more possible attacks, but also on
the load imposed to the server, i.e., possibly more ALTO clients to the load imposed to the server, i.e., possibly more ALTO clients to
serve and thus more work load. serve and thus more work load.
7.3. Faking ALTO Guidance 8.3. Faking ALTO Guidance
It has not yet been investigated how a faked or wrong 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 by an ALTO server can impact the operation of the network and also
the peers. the peers.
Here is a list of examples how the ALTO guidance could be faked and Here is a list of examples how the ALTO guidance could be faked and
what possible consequences may arise: what possible consequences may arise:
Sorting An attacker could change to sorting order of the ALTO Sorting An attacker could change to sorting order of the ALTO
guidance (given that the order is of importance, otherwise the guidance (given that the order is of importance, otherwise the
skipping to change at page 17, line 5 skipping to change at page 20, line 5
Preference of a single peer A single IP address (thus a peer) could 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 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 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 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, quite a number of peers to trying to contact this IP address,
possibly causing a Denial of Service (DoS) attack. possibly causing a Denial of Service (DoS) attack.
This section is solely giving a first shot on security issues related This section is solely giving a first shot on security issues related
to ALTO deployments. to ALTO deployments.
8. Conclusion 9. Conclusion
This is the first version of the deployment considerations and for This is the first version of the deployment considerations and for
sure the considerations are yet incomplete and imprecise. sure the considerations are yet incomplete and imprecise.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
9.2. Informative References 10.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] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-04 (work in progress), May 2010. draft-ietf-alto-protocol-04 (work in progress), May 2010.
[I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-05 (work in progress),
June 2010.
[I-D.kamei-p2p-experiments-japan]
Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO-
Like Activities and Experiments in P2P Network Experiment
Council", draft-kamei-p2p-experiments-japan-03 (work in
progress), May 2010.
[I-D.kiesel-alto-3pdisc] [I-D.kiesel-alto-3pdisc]
Kiesel, S., Tomsu, M., Schwan, N., and M. Scharf, "Third- Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.
party ALTO server discovery", draft-kiesel-alto-3pdisc-02 Stiemerling, "Third-party ALTO server discovery",
(work in progress), March 2010. draft-kiesel-alto-3pdisc-03 (work in progress), July 2010.
[I-D.kiesel-alto-h12] [I-D.kiesel-alto-h12]
Kiesel, S. and M. Stiemerling, "ALTO H12", Kiesel, S. and M. Stiemerling, "ALTO H12",
draft-kiesel-alto-h12-02 (work in progress), March 2010. draft-kiesel-alto-h12-02 (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-cdn] [I-D.penno-alto-cdn]
Penno, R., Raghunath, S., Medved, J., Bakshi, M., Alimi, Penno, R., Raghunath, S., Medved, J., Bakshi, M., Alimi,
R., and S. Previdi, "ALTO and Content Delivery Networks", R., and S. Previdi, "ALTO and Content Delivery Networks",
draft-penno-alto-cdn-00 (work in progress), June 2010. draft-penno-alto-cdn-00 (work in progress), June 2010.
[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
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.
[I-D.vandergaast-edns-client-ip] [I-D.vandergaast-edns-client-ip]
Contavalli, C., Gaast, W., Leach, S., and D. Rodden, Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
"Client IP information in DNS requests", "Client IP information in DNS requests",
draft-vandergaast-edns-client-ip-01 (work in progress), draft-vandergaast-edns-client-ip-01 (work in progress),
May 2010. May 2010.
[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
Y. Yang, "Comcast's ISP Experiences in a Proactive Network
Provider Participation for P2P (P4P) Technical Trial",
RFC 5632, September 2009.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. October 2009.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Martin Stiemerling is partially supported by the NAPA-WINE project Martin Stiemerling is partially supported by the NAPA-WINE project
(Network-Aware P2P-TV Application over Wise Networks, (Network-Aware P2P-TV Application over Wise Networks,
http://www.napa-wine.org), a research project supported by the http://www.napa-wine.org), a research project supported by the
European Commission under its 7th Framework Program (contract no. European Commission under its 7th Framework Program (contract no.
 End of changes. 34 change blocks. 
164 lines changed or deleted 258 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/