[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kiesel-alto-reqs) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6708

Network Working Group                                     S. Kiesel, Ed.
Internet-Draft                                   University of Stuttgart
Intended status: Informational                                S. Previdi
Expires: July 28, 2011                               Cisco Systems, Inc.
                                                          M. Stiemerling
                                                         NEC Europe Ltd.
                                                               R. Woundy
                                                     Comcast Corporation
                                                               Y R. Yang
                                                         Yale University
                                                        January 24, 2011


       Application-Layer Traffic Optimization (ALTO) Requirements
                      draft-ietf-alto-reqs-07.txt

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 applications, which have to select one or several hosts
   from a set of candidates, that are able to provide a desired
   resource.  This guidance shall be based on parameters that affect
   performance and efficiency of the data transmission between the
   hosts, e.g., the topological distance.  The ultimate goal is to
   improve performance (or Quality of Experience) in the application
   while reducing resource consumption in the underlying network
   infrastructure.

   This document enumerates requirements for ALTO, which should be
   considered when specifying, assessing, or comparing protocols and
   implementations.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Kiesel, et al.            Expires July 28, 2011                 [Page 1]

Internet-Draft              ALTO Requirements               January 2011


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 28, 2011.

Copyright Notice

   Copyright (c) 2011 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 Simplified BSD License.
































Kiesel, et al.            Expires July 28, 2011                 [Page 2]

Internet-Draft              ALTO Requirements               January 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Architectural Framework  . . . . . . . . . . .  5
     2.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  5
     2.2.  ALTO Terminology . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Architectural Framework for ALTO . . . . . . . . . . . . .  6
   3.  ALTO Requirements  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  ALTO Client Protocol . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  General Requirements . . . . . . . . . . . . . . . . .  7
       3.1.2.  Host Group Descriptor Support  . . . . . . . . . . . .  7
       3.1.3.  Rating Criteria Support  . . . . . . . . . . . . . . .  8
       3.1.4.  Placement of Entities and Timing of Transactions . . . 10
       3.1.5.  Protocol Extensibility . . . . . . . . . . . . . . . . 12
       3.1.6.  Error Handling and Overload Protection . . . . . . . . 12
     3.2.  ALTO Server Discovery  . . . . . . . . . . . . . . . . . . 12
     3.3.  Security and Privacy . . . . . . . . . . . . . . . . . . . 13
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
     5.1.  High-level security considerations . . . . . . . . . . . . 16
     5.2.  Information Disclosure Scenarios . . . . . . . . . . . . . 16
       5.2.1.  Classification of Information Disclosure Scenarios . . 16
       5.2.2.  Discussion of Information Disclosure Scenarios . . . . 17
     5.3.  Security Requirements  . . . . . . . . . . . . . . . . . . 18
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Contributors List and Acknowledgments . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21






















Kiesel, et al.            Expires July 28, 2011                 [Page 3]

Internet-Draft              ALTO Requirements               January 2011


1.  Introduction

   The motivation for Application-Layer Traffic Optimization (ALTO) is
   described in the ALTO problem statement [RFC5693].

   The goal of ALTO is to provide information which can help peer-to-
   peer (P2P) applications to make better decisions with respect to peer
   selection.  However, ALTO may be useful for non-P2P applications as
   well.  For example, clients of client-server applications may use
   information provided by ALTO to select one of several servers or
   information replicas.  As another example, ALTO information could be
   used to select a media relay needed for NAT traversal.  The goal of
   these informed decisions is to improve performance (or Quality of
   Experience) in the application while reducing resource consumption in
   the underlying network infrastructure.

   Usually, it would be difficult or even impossible for application
   entities to acquire this information by other mechanisms (e.g., using
   measurements between the peers of a P2P overlay), because of
   complexity or because it is based on network topology information,
   network operational costs, or network policies, which the respective
   network provider does not want to disclose in detail.

   The logical entities that provide the ALTO service do not take part
   in the actual user data transport, i.e., they do not implement
   functions for relaying user data.  They may be placed on various
   kinds of physical nodes, e.g., on dedicated servers, as auxiliary
   processes in routers, on "trackers" or "super peers" of a P2P
   application, etc.






















Kiesel, et al.            Expires July 28, 2011                 [Page 4]

Internet-Draft              ALTO Requirements               January 2011


2.  Terminology and Architectural Framework

2.1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  ALTO Terminology

   This document uses the following ALTO-related terms, which are
   defined in [RFC5693]:

   Application, Peer, P2P, Resource, Resource Identifier, Resource
   Provider, Resource Consumer, Transport Address, Overlay Network,
   Resource Directory, ALTO Service, ALTO Server, ALTO Client, ALTO
   Query, ALTO Response, ALTO Transaction, Local Traffic, Peering
   Traffic, Transit Traffic, Application protocol, ALTO Client Protocol,
   Provisioning protocol.

   Furthermore, the following additional terms will be used:

   o  Host Group Descriptor: Information used to describe the resource
      consumer which seeks ALTO guidance, or one or several candidate
      resource providers.  This can be, for example, a single IP
      address, an address prefix or address range that contains the
      host(s), or an autonomous system (AS) number.  Different options
      may provide different levels of detail.  Depending on the system
      architecture, this may have implications on the quality of the
      guidance ALTO is able to provide, on whether recommendations can
      be aggregated, and on how much privacy-sensitive information about
      users might be disclosed to additional parties.

   o  Host Characteristics Attribute: Properties of a host (other than
      the host group descriptor), in particular related to its
      attachment to the network.  This information may be stored in the
      ALTO server and transmitted in the ALTO protocol.  It may be
      evaluated according to the rating criteria.

   o  Rating Criterion: The condition or relation that defines the
      "better" in "better-than-random peer selection", which is the
      ultimate goal of ALTO.  Examples may include "host's Internet
      access is not subject to volume based charging (flat rate)" or
      "low topological distance".  Some rating criteria, such as "low
      topological distance", need to include a reference point, i. e.,
      "low topological distance from a given resource consumer", which
      can be described by means of a host group descriptor.




Kiesel, et al.            Expires July 28, 2011                 [Page 5]

Internet-Draft              ALTO Requirements               January 2011


2.3.  Architectural Framework for ALTO

   There are various architectural options for how ALTO could be
   implemented, and specifying or mandating one specific architecture is
   out of the scope of this document.

   The ALTO Working Group Charter [ALTO-charter] itemizes several key
   components, which shall be elaborated and specified by the ALTO
   Working Group.  The ALTO problem statement [RFC5693] defines a
   terminology (see Section 2.2) and presents a figure that gives a
   high-level overview of protocol interaction between ALTO elements.

   This document itemizes requirements for the following components and
   information elements that are part of the above-mentioned
   architecture:

   o  The ALTO client protocol, which is used for sending ALTO queries
      and ALTO responses between ALTO client and ALTO server.

   o  The discovery mechanism, which will be used by ALTO clients in
      order to find out where to send ALTO requests.

   o  The overall architecture, especially with respect to security and
      privacy issues.

   o  Host group descriptors, which are used to describe the location of
      a host in the network topology.

   o  Rating criteria, i. e., conditions or relations that shall be
      evaluated in order to generate the ALTO guidance.





















Kiesel, et al.            Expires July 28, 2011                 [Page 6]

Internet-Draft              ALTO Requirements               January 2011


3.  ALTO Requirements

3.1.  ALTO Client Protocol

3.1.1.  General Requirements

   REQ.  ARv07-1: The ALTO service is provided by one or more ALTO
   servers.  ALTO servers MUST implement the ALTO client protocol, for
   receiving ALTO queries from ALTO clients and for sending the
   corresponding ALTO responses.

   REQ.  ARv07-2: ALTO clients MUST implement the ALTO client protocol,
   for sending ALTO queries to ALTO servers and for receiving the
   corresponding ALTO responses.

   REQ.  ARv07-3: The format of the ALTO query message MUST allow the
   ALTO client to solicit guidance for selecting appropriate resource
   providers.

   REQ.  ARv07-4: The format of the ALTO response message MUST allow the
   ALTO server to express its guidance for selecting appropriate
   resource providers.

   REQ.  ARv07-5: The detailed specification of a protocol is out of the
   scope of this document.  However, any protocol specification that
   claims to implement the ALTO client protocol MUST be compliant to the
   requirements itemized in this document.

3.1.2.  Host Group Descriptor Support

   The ALTO guidance is based on the evaluation of several resource
   providers or groups of resource providers, which are characterized by
   means of host group descriptors, considering one or more rating
   criteria.

   REQ.  ARv07-6: The ALTO client protocol MUST support the usage of
   several different host group descriptor types.

   REQ.  ARv07-7: The ALTO client protocol specification MUST define a
   basic set of host group descriptor types, which MUST be supported by
   all implementations of the ALTO client protocol.

   REQ.  ARv07-8: The ALTO client protocol MUST support the host group
   descriptor types "IPv4 address prefix" and "IPv6 address prefix."
   They can be used to specify the IP address of one host, or an IP
   address range (in CIDR notation), which contains all hosts in
   question.  It is also possible to specify a broader address range
   (i.e., a shorter prefix length) than the intended group of hosts



Kiesel, et al.            Expires July 28, 2011                 [Page 7]

Internet-Draft              ALTO Requirements               January 2011


   actually uses, in order to conceal their exact identity.

   REQ.  ARv07-9: The ALTO client protocol specification MUST define an
   appropriate procedure for adding new host group descriptor types,
   e.g., by establishing an IANA registry.

   REQ.  ARv07-10: ALTO clients and ALTO servers MUST clearly identify
   the type of each host group descriptor sent in ALTO queries or
   responses.

   REQ.  ARv07-11: For host group descriptor types other than "IPv4
   address prefix" and "IPv6 address prefix", the host group descriptor
   type identification MUST be supplemented by a reference to a
   facility, which can be used to translate host group descriptors of
   that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping
   table or an algorithm.

   REQ.  ARv07-12: Protocol functions for mapping other host group
   descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and
   specified as part of the ALTO client protocol, and the corresponding
   address mapping information SHOULD be made available by the same
   entity that wants to use these host group descriptors within the ALTO
   client protocol.  However, an ALTO server or an ALTO client MAY also
   send a reference to an external mapping facility, e.g., a translation
   table to be downloaded as file via HTTP.

   REQ.  ARv07-13: The ALTO client protocol specification MUST define
   mechanisms, which can be used by the ALTO client and the ALTO server
   to indicate that a host group descriptor used by the other party is
   of an unsupported type, or that the indicated mapping mechanism could
   not be used.

3.1.3.  Rating Criteria Support

   REQ.  ARv07-14: The ALTO client protocol MUST support the usage of
   several different rating criteria types.

   REQ.  ARv07-15: The ALTO client protocol specification MUST define a
   basic set of rating criteria types, which MUST be supported by all
   implementations of the ALTO client protocol.

   REQ.  ARv07-16: The ALTO client protocol specification MUST support
   the rating criteria type "relative operator's preference."  This is a
   relative measure, i.e., it is not associated with any unit of
   measurement.  A higher rating according to this criterion indicates
   that the application should prefer the respective candidate resource
   provider over others with lower ratings (unless information from non-
   ALTO sources suggests a different choice, such as transmission



Kiesel, et al.            Expires July 28, 2011                 [Page 8]

Internet-Draft              ALTO Requirements               January 2011


   attempts suggesting that the path is currently congested).  The
   operator of the ALTO server does not have to disclose how and based
   on which data the ratings are actually computed.  Examples could be:
   cost for peering or transit traffic, traffic engineering inside the
   network, and other policies.

   REQ.  ARv07-17: The ALTO client protocol specification MUST define an
   appropriate procedure for adding new rating criteria types, e.g., by
   establishing an IANA registry.

   One design assumption for ALTO is that it is acceptable that the host
   characteristics attributes, which are stored and processed in the
   ALTO servers for giving the guidance, are updated rather
   infrequently.  Typical update intervals may be several orders of
   magnitude longer than the typical network-layer packet round-trip
   time (RTT).  Therefore, ALTO cannot be a replacement for TCP-like
   congestion control mechanisms.  The definition of alternate
   approaches for congestion control is explicitly a non-goal for the
   ALTO working group [ALTO-charter].

   REQ.  ARv07-18: ALTO client protocol specifications MUST NOT define
   rating criteria closely related to the instantaneous network
   congestion state, whose primary aim is to serve an alternative to
   established congestion control strategies, such as using TCP-based
   transport.

   REQ.  ARv07-19: Applications using ALTO guidance MUST NOT rely on the
   ALTO guidance to avoid network congestion.  Instead, applications
   MUST use other appropriate means, such as TCP based transport, to
   avoid causing excessive congestion.

   REQ.  ARv07-20: The ALTO query message SHOULD allow the ALTO client
   to express which rating criteria should be considered, as well as
   their relative relevance for the specific application that will
   eventually make use of the guidance.

   REQ.  ARv07-21: The ALTO response message SHOULD allow the ALTO
   server to express which rating criteria have been considered when
   generating the response.

   REQ.  ARv07-22: The ALTO client protocol specification MUST define
   mechanisms, which can be used by the ALTO client and the ALTO server
   to indicate that a rating criteria used by the other party is of an
   unsupported type.







Kiesel, et al.            Expires July 28, 2011                 [Page 9]

Internet-Draft              ALTO Requirements               January 2011


3.1.4.  Placement of Entities and Timing of Transactions

   With respect to the placement of ALTO clients, several modes of
   operation exist:

   o  One mode of ALTO operation is that an ALTO client may be embedded
      directly in the resource consumer, i.e., the application protocol
      entity that will eventually initiate data transmission to/from the
      selected resource provider(s) in order to access the desired
      resource.  For example, an ALTO client could be integrated into
      the peer of a P2P application that uses a distributed algorithm
      such as "query flooding" for resource discovery.

   o  Another mode of operation is to integrate the ALTO client into a
      third party such as a resource directory, which may issue ALTO
      queries to solicit preference on potential resource providers,
      considering the respective resource consumer.  For example, an
      ALTO client could be integrated into the tracker of a tracker-
      based P2P application, in order to request ALTO guidance on behalf
      of the peers contacting the tracker.

   REQ.  ARv07-23: The ALTO client protocol MUST support the mode of
   operation, in which the ALTO client is directly embedded in the
   resource consumer.

   REQ.  ARv07-24: The ALTO client protocol MUST support the mode of
   operation, in which the ALTO client is embedded in a third party,
   which performs queries on behalf of resource consumers.

   REQ.  ARv07-25: The ALTO client protocol MUST be designed in a way
   that the ALTO service can be provided by an entity which is not the
   operator of the IP access network.

   REQ.  ARv07-26: The ALTO client protocol MUST be designed in a way
   that different instances of the ALTO service operated by different
   providers can coexist.

   With respect to the timing of ALTO queries, several modes of
   operation exist:

   o  In target-aware query mode, an ALTO client performs the ALTO query
      when the desired resource and a set of candidate resource
      providers are already known, i. e., after DHT lookups, queries to
      the resource directory, etc.

   o  In target-independent query mode, ALTO queries are performed in
      advance or periodically, in order to receive comprehensive,
      "target-independent" guidance, which will be cached locally and



Kiesel, et al.            Expires July 28, 2011                [Page 10]

Internet-Draft              ALTO Requirements               January 2011


      evaluated later, when a resource is to be accessed.

   REQ.  ARv07-27: The ALTO client protocol MUST support at least one of
   these two modes, either the target-aware or the target-independent
   query mode.

   REQ.  ARv07-28: The ALTO client protocol SHOULD support both the
   target-aware and the target-independent query mode.

   REQ.  ARv07-29: The ALTO client protocol SHOULD support lifetime
   attributes, to enable caching of recommendations at ALTO clients.

   REQ.  ARv07-30: The ALTO client protocol SHOULD specify an aging
   mechanism, which allows to give newer recommendations precedence over
   older ones.

   REQ.  ARv07-31: The ALTO client protocol SHOULD allow the ALTO server
   to add information about appropriate modes of re-use to its ALTO
   responses.  Re-use may include redistributing an ALTO response to
   other parties, as well as using the same ALTO information in a
   resource directory to improve the responses to different resource
   consumers, within the specified lifetime of the ALTO response.  The
   ALTO server SHOULD be able to express that

   o  no re-use should occur

   o  re-use is appropriate for a specific "target audience", i.e., a
      set of resource consumers explicitly defined by a list of host
      group descriptors.  The ALTO server MAY specify a "target
      audience" in the ALTO response, which is only a subset of the
      known actual "target audience", e.g., if required by operator
      policies

   o  re-use is appropriate for any resource consumer that would send
      (or cause a third party sending on behalf of it) the same ALTO
      query (i.e., with the same query parameters, except for the
      resource consumer ID, if applicable) to this ALTO server

   o  re-use is appropriate for any resource consumer that would send
      (or cause a third party sending on behalf of it) the same ALTO
      query (i.e., with the same query parameters, except for the
      resource consumer ID, if applicable) to any ALTO server

   REQ.  ARv07-32: The ALTO client protocol MUST support scenarios with
   the ALTO client located in the private address realm behind a network
   address translator (NAT).  There are different types of NAT, see
   [RFC4787] and [RFC5382].




Kiesel, et al.            Expires July 28, 2011                [Page 11]

Internet-Draft              ALTO Requirements               January 2011


3.1.5.  Protocol Extensibility

   REQ.  ARv07-33: The ALTO client protocol MUST include support for
   adding protocol extensions in a non-disruptive, backward-compatible
   way.

   REQ.  ARv07-34: The ALTO client protocol MUST include protocol
   versioning support, in order to clearly distinguish between
   incompatible versions of the protocol.

3.1.6.  Error Handling and Overload Protection

   REQ.  ARv07-35: Any application designed to use ALTO MUST also work
   if no ALTO servers can be found or if no responses to ALTO queries
   are received, e.g., due to connectivity problems or overload
   situation.

   REQ.  ARv07-36: The ALTO client protocol MUST use TCP based
   transport.

   REQ.  ARv07-37: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and require them to throttle their query rate.

   REQ.  ARv07-38: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and redirect them to another ALTO server.

   REQ.  ARv07-39: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and terminate the conversation with the ALTO
   client.

   REQ.  ARv07-40: An ALTO server, which is operating close to its
   capacity limit, MUST be able to inform clients about its impending
   overload situation, and reject new conversation attempts.

3.2.  ALTO Server Discovery

   The ALTO client protocol is supported by one or several ALTO server
   discovery mechanisms, which will be used by ALTO clients in order to
   find out where to send ALTO requests.

   REQ.  ARv07-41: ALTO clients which are embedded in the resource
   consumer MUST be able to use the ALTO server discovery mechanism, in
   order to find one or several ALTO servers that can provide ALTO
   guidance suitable for the resource consumer.  This mode of operation
   is called "resource consumer initiated ALTO server discovery".



Kiesel, et al.            Expires July 28, 2011                [Page 12]

Internet-Draft              ALTO Requirements               January 2011


   REQ.  ARv07-42: ALTO clients which are embedded in a resource
   directory and perform third-party ALTO queries on behalf of a remote
   resource consumer MUST be able to use the ALTO server discovery
   mechanism, in order to find one or several ALTO servers that can
   provide ALTO guidance suitable for the respective resource consumer.
   This mode of operation is called "third-party ALTO server discovery".

   REQ.  ARv07-43: ALTO clients MUST be able to perform resource
   consumer initiated ALTO server discovery, even if they are located
   behind a network address translator (NAT).

   REQ.  ARv07-44: ALTO clients MUST be able to perform third-party ALTO
   server discovery, even if they are located behind a network address
   translator (NAT).

   REQ.  ARv07-45: ALTO clients MUST be able to perform third-party ALTO
   server discovery, even if the resource consumer, on behalf of which
   the ALTO query will be sent, is located behind a network address
   translator (NAT).

   REQ.  ARv07-46: The ALTO server discovery mechanism SHOULD leverage
   an existing protocol or mechanism, such as DNS, DHCP, or PPP based
   automatic configuration, etc.  A single mechanism with a broad
   spectrum of applicability SHOULD be preferred over several different
   mechanisms with narrower scopes.

   REQ.  ARv07-47: The ALTO server discovery mechanism SHOULD be able to
   return the respective contact information for multiple ALTO servers.

   REQ.  ARv07-48: The ALTO server discovery mechanism SHOULD be able to
   indicate preferences for each returned ALTO server contact
   information.

3.3.  Security and Privacy

   REQ.  ARv07-49: The ALTO client protocol MUST support mechanisms for
   the authentication of ALTO servers.

   REQ.  ARv07-50: The ALTO client protocol MUST support mechanisms for
   the authentication of ALTO clients.

   REQ.  ARv07-51: The ALTO client protocol MUST support mechanisms for
   the encryption of messages.

   REQ.  ARv07-52: The ALTO client protocol MUST support different
   levels of detail in queries and responses, in order for the operator
   of an ALTO service to be able to control how much information (e.g.,
   about the network topology) is disclosed.



Kiesel, et al.            Expires July 28, 2011                [Page 13]

Internet-Draft              ALTO Requirements               January 2011


   REQ.  ARv07-53: The operator of an ALTO server MUST NOT assume that
   an ALTO client will implement mechanisms or comply with rules that
   limit the ALTO client's ability to redistribute information retrieved
   from the ALTO server to third parties.

   REQ.  ARv07-54: The ALTO client protocol MUST support different
   levels of detail in queries and responses, in order to protect the
   privacy of users, to ensure that the operators of ALTO servers and
   other users of the same application cannot derive sensitive
   information.

   REQ.  ARv07-55: The ALTO client protocol SHOULD be defined in a way,
   that the operator of one ALTO server cannot easily deduce the
   resource identifier (e.g., file name in P2P file sharing) which the
   resource consumer seeking ALTO guidance wants to access.

   REQ.  ARv07-56: The ALTO client protocol MUST support appropriate
   mechanisms to protect the ALTO service against DoS attacks.

































Kiesel, et al.            Expires July 28, 2011                [Page 14]

Internet-Draft              ALTO Requirements               January 2011


4.  IANA Considerations

   This requirements document does not mandate any immediate IANA
   actions.  However, such IANA considerations may arise from future
   ALTO specification documents which try to meet the requirements given
   here.













































Kiesel, et al.            Expires July 28, 2011                [Page 15]

Internet-Draft              ALTO Requirements               January 2011


5.  Security Considerations

5.1.  High-level security considerations

   High-level security considerations for the ALTO service can be found
   in the "Security Considerations" section of the ALTO problem
   statement document [RFC5693].

5.2.  Information Disclosure Scenarios

   The unwanted disclosure of information is one key concern related to
   ALTO.  This section presents a classification and discussion of
   information disclosure scenarios and potential countermeasures.

5.2.1.  Classification of Information Disclosure Scenarios

   o  (1) Excess disclosure of ALTO server operator's data to an
      authorized ALTO client.  The operator of an ALTO server has to
      feed information, such as tables mapping host group descriptors to
      host characteristics attributes, into the server, thereby enabling
      it to give guidance to ALTO clients.  Some operators might
      consider the full set of this information confidential (e.g., a
      detailed map of the operator's network topology), and might want
      to disclose only a subset of it or somehow obfuscated information
      to an ALTO client.

   o  (2) Disclosure of the application behavior to the ALTO server.
      The operator of an ALTO server could infer the application
      behavior (e.g., content identifiers in P2P file sharing
      applications, or lists of resource providers that are considered
      for establishing a connection) from the ALTO queries sent by an
      ALTO client.

   o  (3) Disclosure of ALTO server operator's data (e.g., network
      topology information) to an unauthorized third party.  There are a
      couple of sub-cases here:

      *  (3a) An ALTO server sends the information directly to an
         unauthorized ALTO client.

      *  (3b) An unauthorized party snoops on the data transmission from
         the ALTO server to an authorized ALTO client.

      *  (3c) An authorized ALTO client knowingly forwards the
         information it had received from the ALTO server to an
         unauthorized party.





Kiesel, et al.            Expires July 28, 2011                [Page 16]

Internet-Draft              ALTO Requirements               January 2011


   o  (4) Disclosure of the application behavior to an unauthorized
      third party.

   o  (5) Excess retrieval of ALTO server operator's data by
      collaborating ALTO clients.  Several authorized ALTO clients could
      ask an ALTO server for guidance, and redistribute the responses
      among each other (see also case 3c).  By correlating the ALTO
      responses they could find out more information than intended to be
      disclosed by the ALTO server operator.

5.2.2.  Discussion of Information Disclosure Scenarios

   Scenario (1) may be addressed by the ALTO server operator choosing
   the level of detail of the information to be populated into the ALTO
   server.  Furthermore, access control mechanisms for filtering ALTO
   responses according to the authenticated ALTO client identity might
   be installed in the ALTO server, although this might not be effective
   given the lack of efficient mechanisms for addressing (3c) and (5),
   see below.

   (2) is addressed by allowing ALTO clients to use the target-
   independent query mode.  In this mode of operation, guiding
   information (e.g., "maps") is retrieved from the ALTO server and used
   entirely locally by the ALTO client, i.e., without sending host
   location attributes of candidate resource providers to the ALTO
   server.  In the target-aware query mode, (2) can be addressed by ALTO
   clients by obfuscating the identity of candidate resource consumers,
   e.g., by zeroing-out or randomizing the last few bits of the IP
   addresses.  However, there is the potential side effect of yielding
   inaccurate results.

   (3a), (3b), and (4) may be addressed by authentication, access
   control, and encryption schemes for the ALTO client protocol.
   However, deployment of encryption schemes might not be effective
   given the lack of efficient mechanisms for addressing (3c) and (5),
   see below.

   Straightforward authentication and encryption schemes will not help
   solving (3c) and (5), and there is no other simple and efficient
   mechanism known.  The cost of complex approaches, e.g., based on
   digital rights management (DRM), might easily outweigh the benefits
   of the whole ALTO solution, and therefore they are not considered as
   a viable solution.  That is, ALTO server operators must be aware that
   (3c) and (5) cannot be prevented from happening, and therefore they
   should feed only such data into an ALTO server, which they do not
   consider sensitive with respect to (3c) and (5).

   These insights are reflected in the requirements in this document.



Kiesel, et al.            Expires July 28, 2011                [Page 17]

Internet-Draft              ALTO Requirements               January 2011


5.3.  Security Requirements

   For a set of specific security requirements please refer to
   Section 3.3 of this document.















































Kiesel, et al.            Expires July 28, 2011                [Page 18]

Internet-Draft              ALTO Requirements               January 2011


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [ALTO-charter]
              Marocco, E. and V. Gurbani, "Application-Layer Traffic
              Optimization (ALTO) Working Group Charter", February 2009.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.



























Kiesel, et al.            Expires July 28, 2011                [Page 19]

Internet-Draft              ALTO Requirements               January 2011


Appendix A.  Contributors List and Acknowledgments

   The initial version of this document was co-authored by Laird Popkin.

   The authors would like to thank

   o  Vijay K. Gurbani <vkg@alcatel-lucent.com>

   o  Enrico Marocco <enrico.marocco@telecomitalia.it>

   for fostering discussions that lead to the creation of this document,
   and for giving valuable comments on it.

   The authors were supported by the following people, who have
   contributed to this document:

   o  Richard Alimi <richard.alimi@yale.edu>

   o  Zoran Despotovic <despotovic@docomolab-euro.com>

   o  Jason Livingood <Jason_Livingood@cable.comcast.com>

   o  Saverio Niccolini <saverio.niccolini@nw.neclab.eu>

   o  Jan Seedorf <jan.seedorf@nw.neclab.eu>

   The authors would like to thank the members of the P2PI and ALTO
   mailing lists for their feedback.

   Laird Popkin and Y. Richard Yang are grateful to the many
   contributions made by the members of the P4P working group and Yale
   Laboratory of Networked Systems.  The P4P working group is hosted by
   DCIA.

   Martin Stiemerling, Saverio Niccolini, and Jan Seedorf are 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.









Kiesel, et al.            Expires July 28, 2011                [Page 20]

Internet-Draft              ALTO Requirements               January 2011


Authors' Addresses

   Sebastian Kiesel (editor)
   University of Stuttgart Computing Center
   Networks and Communication Systems Department
   Allmandring 30
   70550 Stuttgart
   Germany

   Email: ietf-alto@skiesel.de
   URI:   http://www.rus.uni-stuttgart.de/nks/


   Stefano Previdi
   Cisco Systems, Inc.

   Email: sprevidi@cisco.com


   Martin Stiemerling
   NEC Laboratories Europe/University of Goettingen

   Email: martin.stiemerling@neclab.eu
   URI:   http://ietf.stiemerling.org


   Richard Woundy
   Comcast Corporation

   Email: Richard_Woundy@cable.comcast.com


   Yang Richard Yang
   Yale University

   Email: yry@cs.yale.edu















Kiesel, et al.            Expires July 28, 2011                [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/