Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7971

 
 
 

Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Part 4 of 4, p. 58 to 77
Prev Section

 


prevText      Top      ToC       Page 58 
5.  Using ALTO for CDNs

5.1.  Overview

5.1.1.  Usage Scenario

   This section briefly introduces the usage of ALTO for CDNs, as
   explained in [CDN-USE].  CDNs are used in the delivery of some
   Internet services (e.g., delivery of websites, software updates, and
   video delivery) from a location closer to the location of the user.
   A CDN typically consists of a network of servers often attached to

Top      Up      ToC       Page 59 
   ISP networks.  The point of attachment is often as close to content
   consumers and peering points as economically or operationally
   feasible in order to decrease traffic load on the ISP backbone and to
   provide better user experience measured by reduced latency and higher
   throughput.

   CDNs use several techniques to redirect a client to a server
   (surrogate).  A request-routing function within a CDN is responsible
   for receiving content requests from user agents, obtaining and
   maintaining necessary information about a set of candidate
   surrogates, and selecting and redirecting the user agent to the
   appropriate surrogate.  One common way is relying on the DNS system,
   but there are many other ways, see [RFC3568].

   +--------------------+
   | CDN Request Router |
   |  with ALTO Client  |
   +--------------------+
             /\
             || ALTO protocol
             ||
             \/
         +---------+
         |  ALTO   |
         | Server  |
         +---------+
              :
              : Provisioning protocol
              :
        ,-----------.
     ,-'  Source of  `-.
    (    topological    )
     `-. information ,-'
        `-----------'

        Figure 26: Use of ALTO Information for CDN Request Routing

   In order to derive the optimal benefit from a CDN, it is preferable
   to deliver content from the servers (caches) that are "closest" to
   the end user requesting the content.  The definition of "closest" may
   be as simple as geographical or IP topology distance, but it may also
   consider other combinations of metrics and CDN or ISP policies.  As
   illustrated in Figure 26, ALTO could provide this information.

Top      Up      ToC       Page 60 
   User Agent                  Request Router                 Surrogate
        |                             |                           |
        |     F1 Initial Request      |                           |
        +---------------------------->|                           |
        |                             +--+                        |
        |                             |  | F2 Surrogate Selection |
        |                             |<-+       (using ALTO)     |
        |   F3 Redirection Response   |                           |
        |<----------------------------+                           |
        |                             |                           |
        |     F4 Content Request      |                           |
        +-------------------------------------------------------->|
        |                             |                           |
        |                             |          F5 Content       |
        |<--------------------------------------------------------+
        |                             |                           |

               Figure 27: Example of CDN Surrogate Selection

   Figure 27 illustrates the interaction between a user agent, a request
   router, and a surrogate for the delivery of content in a single CDN.
   As explained in [CDN-USE], the user agent makes an initial request to
   the CDN (F1).  This may be an application-level request (e.g., HTTP)
   or a DNS request.  In the second step (F2), the request router
   selects an appropriate surrogate (or set of surrogates) based on the
   user agent's (or its proxy's) IP address, the request router's
   knowledge of the network topology (which can be obtained by ALTO) and
   reachability cost between CDN caches and end users, and any
   additional CDN policies.  Then, the request router responds to the
   initial request with an appropriate response containing a redirection
   to the selected cache (F3), for example, by returning an appropriate
   DNS A/AAAA record or an HTTP 302 redirect, etc.  The user agent uses
   this information to connect directly to the surrogate and request the
   desired content (F4), which is then delivered (F5).

5.1.2.  Applicability of ALTO

   The most simple use case for ALTO in a CDN context is to improve the
   selection of a CDN surrogate or origin.  In this case, the CDN makes
   use of an ALTO server to choose a better CDN surrogate or origin than
   would otherwise be the case.  Although it is possible to obtain raw
   network map and cost information in other ways, for example,
   passively listening to the ISP's routing protocols or use of active
   probing, the use of an ALTO service to expose that information may
   provide additional control to the ISP over how their network map/cost
   is exposed.  Additionally, it may enable the ISP to maintain a

Top      Up      ToC       Page 61 
   functional separation between their routing plane and network map
   computation functions.  This may be attractive for a number of
   reasons, for example:

   o  The ALTO service could provide a filtered view of the network and/
      or cost map that relates to CDN locations and their proximity to
      end users, for example, to allow the ISP to control the level of
      topology detail they are willing to share with the CDN.

   o  The ALTO service could apply additional policies to the network
      map and cost information to provide a CDN-specific view of the
      network map/cost, for example, to allow the ISP to encourage the
      CDN to use network links that would not ordinarily be preferred by
      a Shortest Path First routing calculation.

   o  The routing plane may be operated and controlled by a different
      operational entity (even within a single ISP) than the CDN.
      Therefore, the CDN may not be able to passively listen to routing
      protocols, nor may it have access to other network topology data
      (e.g., inventory databases).

   When CDN servers are deployed outside of an ISP's network or in a
   small number of central locations within an ISP's network, a
   simplified view of the ISP's topology or an approximation of
   proximity is typically sufficient to enable the CDN to serve end
   users from the optimal server/location.  As CDN servers are deployed
   deeper within ISP networks, it becomes necessary for the CDN to have
   more detailed knowledge of the underlying network topology and costs
   between network locations in order to enable the CDN to serve end
   users from the optimal servers for the ISP.

   The request router in a CDN will typically also take into account
   criteria and constraints that are not related to network topology,
   such as the current load of CDN surrogates, content owner policies,
   end user subscriptions, etc.  This document only discusses use of
   ALTO for network information.

   A general issue for CDNs is that the CDN logic has to match the
   client's IP address with the closest CDN surrogate, for approaches
   that are both DNS or HTTP redirect based (see, for instance,
   [ALTO-CDN]).  This matching is not trivial, for example, in DNS-based
   approaches, where the IP address of the DNS original requester is
   unknown (see [RFC7871] for a discussion of this and a solution
   approach).

   In addition to use by a single CDN, ALTO can also be used in
   scenarios that interconnect several CDNs.  This use case is detailed
   in [CDNI-FCI].

Top      Up      ToC       Page 62 
5.2.  Deployment Recommendations

5.2.1.  ALTO Services

   In its simplest form, an ALTO server would provide an ISP with the
   capability to offer a service to a CDN that provides network map and
   cost information.  The CDN can use that data to enhance its surrogate
   and/or origin selection.  If an ISP offers an ALTO Network and Cost
   Map Service to expose a cost mapping/ranking between end user IP
   subnets (within that ISP's network) and CDN surrogate IP subnets/
   locations, periodic updates of the maps may be needed.  As introduced
   in Section 3.3), it is common for broadband subscribers to obtain
   their IP addresses dynamically, and in many deployments, the IP
   subnets allocated to a particular network region can change
   relatively frequently, even if the network topology itself is
   reasonably static.

   An alternative would be to use the ALTO ECS: when an end user
   requests a given content, the CDN request router issues an ECS
   request with the endpoint address (IPv4/IPv6) of the end user
   (content requester) and the set of endpoint addresses of the
   surrogate (content targets).  The ALTO server receives the request
   and ranks the addresses based on their distance from the content
   requester.  Once the request router obtained from the ALTO server the
   ranked list of locations (for the specific user), it can incorporate
   this information into its selection mechanisms in order to point the
   user to the most appropriate surrogate.

   Since CDNs operate in a controlled environment, the ALTO Network and
   Cost Map Service and ECS have a similar level of security and
   confidentiality of network-internal information.  However, the
   Network and Cost Map Service and ECS differ in the way the ALTO
   service is delivered and address a different set of requirements in
   terms of topology information and network operations.

   If a CDN already has means to model connectivity policies, the map-
   based approaches could possibly be integrated into that.  If the ECS
   service is preferred, a request router that uses ECS could cache the
   results of ECS queries for later usage in order to address the
   scalability limitations of ECS and to reduce the number of
   transactions between the CDN and ALTO server.  The ALTO server may
   indicate in the reply message how long the content of the message is
   to be considered reliable and insert a lifetime value that will be
   used by the CDN in order to cache (and then flush or refresh) the
   entry.

Top      Up      ToC       Page 63 
5.2.2.  Guidance Considerations

   The following discusses how a CDN could make use of ALTO services.

   In one deployment scenario, ALTO could expose ISP end-user
   reachability to a CDN.  The request router needs to have information
   about which end-user IP subnets are reachable via which networks or
   network locations.  The network map services offered by ALTO could be
   used to expose this topology information while avoiding routing-plane
   peering between the ISP and the CDN.  For example, if CDN surrogates
   are deployed within the access or aggregation network, the ISP is
   likely to want to utilize the surrogates deployed in the same access/
   aggregation region in preference to surrogates deployed elsewhere, in
   order to alleviate the cost and/or improve the user experience.

   In addition, CDN surrogates could also use ALTO guidance, e.g., if
   there is more than one upstream source of content or several origins.
   In this case, ALTO could help a surrogate with the decision about
   which upstream source to use.  This specific variant of using ALTO is
   not further detailed in this document.

   If content can be provided by several CDNs, there may be a need to
   interconnect these CDNs.  In this case, ALTO can be used as an
   interface [CDNI-FCI], in particular, for footprint and capabilities
   advertisement.

   Other, and more advanced, scenarios of deploying ALTO are also listed
   in [CDN-USE] and [ALTO-CDN].

   The granularity of ALTO information required depends on the specific
   deployment of the CDN.  For example, an "over-the-top" CDN whose
   surrogates are deployed only within the Internet backbone may only
   require knowledge of which end-user IP subnets are reachable via
   which ISP's networks, whereas a CDN deployed within a particular
   ISP's network requires a finer granularity of knowledge.

   An ALTO server ranks addresses based on topology information it
   acquires from the network.  By default, according to [RFC7285],
   distance in ALTO represents an abstract "routingcost" that can be
   computed, for instance, from routing protocol information.  But an
   ALTO server may also take into consideration other criteria or other
   information sources for policy, state, and performance information
   (e.g., geolocation), as explained in Section 3.2.2.

   The different methods and algorithms through which the ALTO server
   computes topology information and rankings is out of the scope of
   this document.  If rankings are based on routing protocol
   information, it is obvious that network events may impact the ranking

Top      Up      ToC       Page 64 
   computation.  Due to internal redundancy and resilience mechanisms
   inside current networks, most of the network events happening in the
   infrastructure will be handled internally in the network, and they
   should have limited impact on a CDN.  However, catastrophic events
   such as main trunks failures or backbone partitioning will have to be
   taken into account by the ALTO server to redirect traffic away from
   the impacted area.

   An ALTO server implementation may want to keep state about ALTO
   clients in order to inform and signal to these clients when a major
   network event happened, e.g., by a notification mechanism.  In a CDN/
   ALTO interworking architecture with few CDN components interacting
   with the ALTO server, there are less scalability issues in
   maintaining state about clients in the ALTO server, compared to ALTO
   guidance to any Internet user.

6.  Other Use Cases

   This section briefly surveys and references other use cases that have
   been tested or suggested for ALTO deployments.

6.1.  Application Guidance in Virtual Private Networks (VPNs)

   Virtual Private Network (VPN) technology is widely used in public and
   private networks to create groups of users that are separated from
   other users of the network and allows these users to communicate
   among themselves as if they are on a private network.  Network
   Service Providers (NSPs) offer different types of VPNs.  [RFC4026]
   distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN)
   using different sub-types.  In the following, the term "VPN" is used
   to refer to provider supplied virtual private networking.

   From the perspective of an application at an endpoint, a VPN may not
   be very different from any other IP connectivity solution, but there
   are a number of specific applications that could benefit from ALTO
   topology exposure and guidance in VPNs.  As, in the general Internet,
   one advantage is that applications do not have to perform excessive
   measurements on their own.  For instance, potential use cases for
   ALTO application guidance in VPN environments are:

   o  Enterprise application optimization: Enterprise customers often
      run distributed applications that exchange large amounts of data,
      e.g., for synchronization of replicated data bases.  Network
      topology information could be useful for placement of replicas as
      well as for the scheduling of transfers.

   o  Private cloud computing solution: An enterprise customer could run
      its own data centers at several sites.  The cloud management

Top      Up      ToC       Page 65 
      system could want to understand the network costs between
      different sites for intelligent routing and placement decisions of
      Virtual Machines (VMs) among the VPN sites.

   o  Cloud-bursting: One or more VPN endpoints could be located in a
      public cloud.  If an enterprise customer needs additional
      resources, they could be provided by a public cloud, which is
      accessed through the VPN.  Network topology awareness would help
      to decide in which data center of the public cloud those resources
      should be allocated.

   These examples focus on enterprises, which are typical users of VPNs.
   VPN customers typically have no insight into the network topology
   that transports the VPN.  Similar to other ALTO use cases, better-
   than-random application-level decisions would be enabled by an ALTO
   server offered by the NSP, as illustrated in Figure 28.

                       +---------------+
                       |  Customer's   |
                       |   management  |
                       |  application  |.
                       | (ALTO client) |  .
                       +---------------+    .  VPN provisioning
                              /\              . (out-of-scope)
                              || ALTO           .
                              \/                  .
                    +---------------------+       +----------------+
                    |     ALTO server     |       | VPN portal/OSS |
                    |   provided by NSP   |       | (out-of-scope) |
                    +---------------------+       +----------------+
                               : VPN network
                               : and cost maps
                               :
                     /---------:---------\ Network service provider
                     |         :         |
        +-------+   _______________________   +-------+
        | App a | ()_____. .________. .____() | App d |
        +-------+    |   | |        | |  |    +-------+
                     \---| |--------| |--/
                         | |        | |
                         |^|        |^| Customer VPN
                          V          V
                      +-------+  +-------+
                      | App b |  | App c |
                      +-------+  +-------+

                       Figure 28: Using ALTO in VPNs

Top      Up      ToC       Page 66 
   A common characteristic of these use cases is that applications will
   not necessarily run in the public Internet, and that the relationship
   between the provider and customer of the VPN is rather well defined.
   Since VPNs often run in a managed environment, an ALTO server may
   have access to topology information (e.g., traffic engineering data)
   that would not be available for the public Internet, and it may
   expose it to the customer of the VPN only.

   Also, a VPN will not necessarily be static.  The customer could
   possibly modify the VPN and add new VPN sites by a Web portal,
   network management systems, or other OSS solutions.  Prior to adding
   a new VPN site, an application will not have connectivity to that
   site, i.e., an ALTO server could offer access to information that an
   application cannot measure on its own (e.g., expected delay to a new
   VPN site).

   The VPN use cases, requirements, and solutions are further detailed
   in [VPN-SERVICE].

6.2.  In-Network Caching

   Deployment of intra-domain P2P caches has been proposed for
   cooperation between the network operator and the P2P service
   providers, e.g., to reduce the bandwidth consumption in access
   networks [ALTO-P2PCACHE].

Top      Up      ToC       Page 67 
            +--------------+                +------+
            | ISP 1 network+----------------+Peer 1|
            +-----+--------+                +------+
            |
   +--------+------------------------------------------------------+
   |        |                                      ISP 2 network   |
   |  +---------+                                                  |
   |  |L1 Cache |                                                  |
   |  +-----+---+                                                  |
   |        +--------------------+----------------------+          |
   |        |                    |                      |          |
   | +------+------+      +------+-------+       +------+-------+  |
   | | AN1         |      | AN2          |       | AN3          |  |
   | | +---------+ |      | +----------+ |       |              |  |
   | | |L2 Cache | |      | |L2 Cache  | |       |              |  |
   | | +---------+ |      | +----------+ |       |              |  |
   | +------+------+      +------+-------+       +------+-------+  |
   |        |                                           |          |
   |        +--------------------+                      |          |
   |        |                    |                      |          |
   | +------+------+      +------+-------+       +------+-------+  |
   | | SUB-AN11    |      | SUB-AN12     |       | SUB-AN31     |  |
   | | +---------+ |      |              |       |              |  |
   | | |L3 Cache | |      |              |       |              |  |
   | | +---------+ |      |              |       |              |  |
   | +------+------+      +------+-------+       +------+-------+  |
   |        |                    |                      |          |
   +--------+--------------------+----------------------+----------+
            |                    |                      |
        +---+---+            +---+---+                  |
        |       |            |       |                  |
     +--+--+ +--+--+      +--+--+ +--+--+            +--+--+
     |Peer2| |Peer3|      |Peer4| |Peer5|            |Peer6|
     +-----+ +-----+      +-----+ +-----+            +-----+

            Figure 29: General Architecture of Intra-ISP Caches

   Figure 29 depicts the overall architecture of potential P2P cache
   deployments inside an ISP 2 with various access network types.  As
   shown in the figure, P2P caches may be deployed at various levels,
   including the interworking gateway linking with other ISPs, internal
   access network gateways linking with different types of accessing
   networks (e.g., WLAN, cellular, and wired), and even within an
   accessing network at the entries of individual WLAN subnetworks.
   Moreover, depending on the network context and the operator's policy,
   each cache can be a Forwarding Cache or a Bidirectional Cache
   [ALTO-P2PCACHE].

Top      Up      ToC       Page 68 
   In such a cache architecture, the locations of caches could be used
   as dividers of different PIDs to guide intra-ISP network abstraction
   and mark costs among them according to the location and type of
   relevant caches.

   Further details and deployment considerations can be found in
   [ALTO-P2PCACHE].

6.3.  Other Application-Based Network Operations

   An ALTO server can be part of an overall framework for Application-
   Based Network Operations (ABNO) [RFC7491] that brings together
   different technologies.  Such an architecture may include additional
   components such as a PCE for on-demand and application-specific
   reservation of network connectivity, reliability, and resources (such
   as bandwidth).  Some use cases how to leverage ALTO for joint network
   and application-layer optimization are explained in [RFC7491].

7.  Security Considerations

   Security concerns were extensively discussed from the very beginning
   of the development of the ALTO protocol, and they have been
   considered in detail in the ALTO requirements document [RFC6708] as
   well as in the ALTO protocol specification document [RFC7285].  The
   two main security concerns are related to the unwanted disclosure of
   information through ALTO and the negative impact of specially
   crafted, wrong ("faked") guidance presented to an ALTO client.  In
   addition to this, the usual concerns related to the operation of any
   networked application apply.

   This section focuses on the peer-to-peer use case, which is -- from a
   security perspective -- probably the most difficult ALTO use case
   that has been considered.  Special attention is given to the two main
   security concerns.

7.1.  ALTO as a Protocol Crossing Trust Boundaries

   The optimization of peer-to-peer applications was the first use case
   and the impetus for the development of the ALTO protocol, in
   particular, file sharing applications such as BitTorrent [RFC5594].

   As explained in Section 4.1.1, for the publisher of the ALTO
   information (i.e., the ALTO server operator), it may not be apparent
   who is in charge of the P2P application overlay.  Some P2P
   applications do not have any central control entity and the whole
   overlay consists only of the peers, which are under control of the
   individual users.  Other P2P applications may have some control
   entities such as super peers or trackers, but these may be located in

Top      Up      ToC       Page 69 
   foreign countries and under the control of unknown organizations.  As
   outlined in Section 4.2.2, in some scenarios, it may be very
   beneficial to forward ALTO information to such trackers, super peers,
   etc., located in remote networks.  This situation is aggravated by
   the vast number of different P2P applications that are evolving
   quickly and often without any coordination with the network
   operators.

   In summary, it can be said that in many instances of the P2P use
   case, the ALTO protocol bridges the border between the "managed" IP
   network infrastructure under strict administrative control and one or
   more "unmanaged" application overlays, i.e., overlays for which it is
   hard to tell who is in charge of them.  This differs from more-
   controlled environments (e.g., in the CDN use case), in which
   bilateral agreements between the producer and consumer of guidance
   are possible.

7.2.  Information Leakage from the ALTO Server

   An ALTO server will be provisioned with information about the ISP's
   network and possibly also with information about neighboring ISPs.
   This information (e.g., network topology, business relations, etc.)
   is often considered to be confidential to the ISP and can include
   very sensitive information.  ALTO does not require any particular
   level of details of information disclosure; hence, the provider
   should evaluate how much information is revealed and the associated
   risks.

   Furthermore, if the ALTO information is very fine grained, it may
   also be considered sensitive with respect to user privacy.  For
   example, consider a hypothetical endpoint property "provisioned
   access link bandwidth" or "access technology (ADSL, VDSL, FTTH,
   etc.)" and an ALTO service that publishes this property for
   individual IP addresses.  This information could not only be used for
   traffic optimization but, for example, also for targeted advertising
   to residential users with exceptionally good (or bad) connectivity,
   such as special banner ads.  For an advertisement system, it would be
   more complex to obtain such information otherwise, e.g., by bandwidth
   probing.

   Different scenarios related to the unwanted disclosure of an ALTO
   server's information have been itemized and categorized in RFC 6708,
   Section 5.2.1., cases (1)-(3) [RFC6708].

   In some use cases, it is not possible to use access control (see
   Section 7.3) to limit the distribution of ALTO knowledge to a small
   set of trusted clients.  In these scenarios, it seems tempting not to
   use network maps and cost maps at all, and instead completely rely on

Top      Up      ToC       Page 70 
   ECS and endpoint ranking in the ALTO server.  While this practice may
   indeed reduce the amount of information that is disclosed to an
   individual ALTO client, some issues should be considered: first, when
   using the map-based approach, it is trivial to analyze the maximum
   amount of information that could be disclosed to a client -- the full
   maps.  In contrast, when providing endpoint-cost service only, the
   ALTO server operator could be prone to a false feeling of security,
   while clients use repeated queries and/or collaboration to gather
   more information than they are expected to get (see Section 5.2.1.,
   case (3) in [RFC6708]).  Second, the ECS reveals more information
   about the user or application behavior to the ALTO server, e.g.,
   which other hosts are considered as peers for the exchange of a
   significant amount of data (see Section 5.2.1., cases (4)-(6) in
   [RFC6708]).

   Consequently, users may be more reluctant to use the ALTO service at
   all if it is based on the ECS instead of providing network and cost
   maps.  Given that some popular P2P applications are sometimes used
   for purposes such as distribution of files without the explicit
   permission from the copyright owner, it may also be in the interest
   of the ALTO server operator that an ALTO server cannot infer the
   behavior of the application to be optimized.  One possible conclusion
   could be to publish network and cost maps through ALTO that are so
   coarse grained that they do not violate the network operator's or the
   user's interests.

   In other use cases, in more-controlled environments (e.g., in the CDN
   use case) bilateral agreements, access control (see Section 7.3), and
   encryption could be used to reduce the risk of information leakage.

7.3.  ALTO Server Access

   Depending on the use case of ALTO, it may be desired to apply access
   restrictions to an ALTO server, i.e., by requiring client
   authentication.  According to [RFC7285], ALTO requires that HTTP
   Digest Authentication be supported, in order to achieve client
   authentication and possibly to limit the number of parties with whom
   ALTO information is directly shared.  TLS Client Authentication may
   also be supported.

   In general, well-known security management techniques and best
   current practices [RFC4778] for operational ISP infrastructure also
   apply to an ALTO service, including functions to protect the system
   from unauthorized access, key management, reporting security-relevant
   events, and authorizing user access and privileges.

Top      Up      ToC       Page 71 
   For peer-to-peer applications, a potential deployment scenario is
   that an ALTO server is solely accessible by peers from the ISP
   network (as shown in Figure 21).  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 compromised computers that
   are part of a botnet).

   If the ALTO server has to be accessible by parties not located in the
   ISP's network (see Figure 22), e.g., by a third-party tracker or by a
   CDN system outside the ISP's network, the access restrictions have to
   be looser.  In the extreme case, i.e., no access restrictions, each
   and every host in the Internet can access the ALTO server.  This
   might not be the intention of the ISP, as the server is not only
   subject to more possible attacks, but also the server load could
   increase, since possibly more ALTO clients have to be served.

   There are also use cases where the access to the ALTO server has to
   be much more strictly controlled, i.e., where an authentication and
   authorization of the ALTO client to the server may be needed.  For
   instance, in case of CDN optimization, the provider of an ALTO
   service as well as potential users are possibly well-known.  Only CDN
   entities may need ALTO access; access to the ALTO servers by
   residential users may neither be necessary nor be desired.

   Access control can also help to prevent Denial-of-Service (DoS)
   attacks by arbitrary hosts from the Internet.  DoS can both affect an
   ALTO server and an ALTO client.  A server can get overloaded if too
   many 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.

7.4.  Faking ALTO Guidance

   The ALTO services enables an ALTO service provider to influence the
   behavior of network applications.  An attacker who is able to
   generate false replies, or e.g. an attacker who can intercept the
   ALTO server discovery procedure, can provide faked ALTO guidance.

   Here is a list of examples of how the ALTO guidance could be faked
   and what possible consequences may arise:

   Sorting:  An attacker could change the 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

Top      Up      ToC       Page 72 
      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.  In
      another example, fake guidance could give unrealistically low
      costs to devices in an ISP's mobile network, thus encouraging
      other devices to contact them, thereby degrading the ISP's mobile
      network and causing customer dissatisfaction.

   Preference of a single peer:  A single IP address (thus a peer) could
      be marked as to be preferred over all 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 DoS attack.

   The ALTO protocol protects the authenticity and integrity of ALTO
   information while in transit by leveraging the authenticity and
   integrity protection mechanisms in TLS (see Section 8.3.5 of
   [RFC7285]).  It has not yet been investigated how wrong ALTO guidance
   given by an authenticated ALTO server can impact the operation of the
   network and the applications.

8.  References

8.1.  Normative References

   [ALTO-REG]
              IANA, "Application-Layer Traffic Optimization (ALTO)
              Protocol",
              <http://www.iana.org/assignments/alto-protocol>.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              DOI 10.17487/RFC5693, October 2009,
              <http://www.rfc-editor.org/info/rfc5693>.

   [RFC6708]  Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R.,
              and Y. Yang, "Application-Layer Traffic Optimization
              (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708,
              September 2012, <http://www.rfc-editor.org/info/rfc6708>.

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <http://www.rfc-editor.org/info/rfc7285>.

Top      Up      ToC       Page 73 
   [RFC7286]  Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              H. Song, "Application-Layer Traffic Optimization (ALTO)
              Server Discovery", RFC 7286, DOI 10.17487/RFC7286,
              November 2014, <http://www.rfc-editor.org/info/rfc7286>.

8.2.  Informative References

   [ALTO-CDN]
              Penno, R., Medved, J., Alimi, R., Yang, R., and S.
              Previdi, "ALTO and Content Delivery Networks", Work in
              Progress, draft-penno-alto-cdn-03, March 2011.

   [ALTO-H12]
              Kiesel, S. and M. Stiemerling, "ALTO H12", Work in
              Progress, draft-kiesel-alto-h12-02, March 2010.

   [ALTO-P2PCACHE]
              Lingli, D., Chen, W., Yi, Q., and Y. Zhang,
              "Considerations for ALTO with network-deployed P2P
              caches", Work in Progress, draft-deng-alto-p2pcache-03,
              February 2014.

   [CDN-USE]  Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
              S. Previdi, "Use Cases for ALTO within CDNs", Work in
              Progress, draft-jenkins-alto-cdn-use-cases-03, June 2012.

   [CDNI-FCI]
              Seedorf, J., Yang, Y., and J. Peterson, "CDNI Footprint
              and Capabilities Advertisement using ALTO", Work in
              Progress, draft-seedorf-cdni-request-routing-alto-08,
              March 2015.

   [CHINA-TRIAL]
              Li, K. and G. Jian, "ALTO and DECADE service trial within
              China Telecom", Work in Progress,
              draft-lee-alto-chinatelecom-trial-04, March 2012.

   [MAP-CALC]
              Seidel, H., "ALTO map calculation from live network data",
              Work in Progress, draft-seidel-alto-map-calculation-00,
              October 2015.

   [NETWORK-TOPO]
              Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A Data Model for Network
              Topologies", Work in Progress,
              draft-ietf-i2rs-yang-network-topo-06, September 2016.

Top      Up      ToC       Page 74 
   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              DOI 10.17487/RFC3411, December 2002,
              <http://www.rfc-editor.org/info/rfc3411>.

   [RFC3568]  Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
              Content Network (CN) Request-Routing Mechanisms",
              RFC 3568, DOI 10.17487/RFC3568, July 2003,
              <http://www.rfc-editor.org/info/rfc3568>.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <http://www.rfc-editor.org/info/rfc4026>.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <http://www.rfc-editor.org/info/rfc4655>.

   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
              Internet Service Provider Environments", RFC 4778,
              DOI 10.17487/RFC4778, January 2007,
              <http://www.rfc-editor.org/info/rfc4778>.

   [RFC5594]  Peterson, J. and A. Cooper, "Report from the IETF Workshop
              on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
              RFC 5594, DOI 10.17487/RFC5594, July 2009,
              <http://www.rfc-editor.org/info/rfc5594>.

   [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, DOI 10.17487/RFC5632, September 2009,
              <http://www.rfc-editor.org/info/rfc5632>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

Top      Up      ToC       Page 75 
   [RFC6875]  Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "The
              P2P Network Experiment Council's Activities and
              Experiments with Application-Layer Traffic Optimization
              (ALTO) in Japan", RFC 6875, DOI 10.17487/RFC6875, February
              2013, <http://www.rfc-editor.org/info/rfc6875>.

   [RFC7491]  King, D. and A. Farrel, "A PCE-Based Architecture for
              Application-Based Network Operations", RFC 7491,
              DOI 10.17487/RFC7491, March 2015,
              <http://www.rfc-editor.org/info/rfc7491>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <http://www.rfc-editor.org/info/rfc7752>.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016,
              <http://www.rfc-editor.org/info/rfc7871>.

   [RFC7921]  Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
              <http://www.rfc-editor.org/info/rfc7921>.

   [RFC7922]  Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
              the Routing System (I2RS) Traceability: Framework and
              Information Model", RFC 7922, DOI 10.17487/RFC7922, June
              2016, <http://www.rfc-editor.org/info/rfc7922>.

   [UPDATE-SSE]
              Roome, W. and Y. Yang, "ALTO Incremental Updates Using
              Server-Sent Events (SSE)", Work in Progress,
              draft-ietf-alto-incr-update-sse-03, September 2016.

   [VPN-SERVICE]
              Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The
              Virtual Private Network (VPN) Service in ALTO: Use Cases,
              Requirements and Extensions", Work in Progress,
              draft-scharf-alto-vpn-service-02, February 2014.

   [XDOM-DISC]
              Kiesel, S. and M. Stiemerling, "Application Layer Traffic
              Optimization (ALTO) Cross-Domain Server Discovery", Work
              in Progress, draft-kiesel-alto-xdom-disc-02, July 2016.

Top      Up      ToC       Page 76 
Acknowledgments

   This memo is the result of contributions made by several people:

   o  Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP
      deployment requirements and monitoring.

   o  Rich Woundy contributed text to Section 3.3.

   o  Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed
      Section 6.2.

   Thomas-Rolf Banniza, Vinayak Hegde, Qin Wu, Wendy Roome, and Sabine
   Randriamasy provided very useful comments and reviewed the document.

Top      Up      ToC       Page 77 
Authors' Addresses

   Martin Stiemerling
   Hochschule Darmstadt

   Email: mls.ietf@gmail.com
   URI:   http://ietf.stiemerling.org


   Sebastian Kiesel
   University of Stuttgart Information Center
   Networks and Communication Systems Department
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: ietf-alto@skiesel.de


   Michael Scharf
   Nokia
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: michael.scharf@nokia.com


   Hans Seidel
   BENOCS GmbH
   Winterfeldtstrasse 21
   Berlin  10781
   Germany

   Email: hseidel@benocs.com


   Stefano Previdi
   Cisco Systems, Inc.
   Via Del Serafico 200
   Rome  00191
   Italy

   Email: sprevidi@cisco.com