Network Working Group S. Randriamasy, Ed. Internet-Draft Alcatel-Lucent Bell Labs Intended status: Experimental April 15, 2011 Expires: October 17, 2011 Provider Confidential ALTO with Relays draft-randriamasy-alto-relay-01 Abstract IETF is designing a new service called ALTO (Application Layer traffic Optimization) that includes a "Network Map Service" and an "Endpoint Ranking Service" and thus incentives for application clients to connect to ISP preferred Endpoints. These services provide a view of the Network Provider (NP) topology to overlay clients. However, NPs remain reluctant to implement the ALTO protocol for security reasons. In particular, they do not want their topology to be easily unveiled to third parties and thus more vulnerable to misuse. This document proposes a scheme to preserve Network Provider confidentiality while allowing the use of ALTO information for applications. It introduces an "ALTO Relay" that gets the provider confidential ALTO response and hands it to a functional entity called a Connection Relay. Meanwhile the ALTO Client gets a status and directions to connect to Connection Relay, that then will hand the desired application data. The benefit for Application Clients accepting ALTO transactions involving ALTO Relays is a better quality of experience. Requirements Language 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 RFC 2119 [RFC2119]. 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 Randriamasy Expires October 17, 2011 [Page 1] Internet-Draft Provider Confidential ALTO with Relays April 2011 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 17, 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. Randriamasy Expires October 17, 2011 [Page 2] Internet-Draft Provider Confidential ALTO with Relays April 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Provider Confidential ALTO . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Provider Confidential ALTO architecture . . . . . . . . . 7 4.2.1. Architecture Framework . . . . . . . . . . . . . . . . 7 4.2.2. Current Transaction framework . . . . . . . . . . . . 8 4.3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. ALTO requirements . . . . . . . . . . . . . . . . . . . . 10 4.4.1. ALTO Relays and Connection Relays . . . . . . . . . . 10 4.4.2. PC ALTO discovery processes . . . . . . . . . . . . . 11 4.5. ALTO protocol description updates . . . . . . . . . . . . 11 4.5.1. Need for a PC Service Property . . . . . . . . . . . . 11 4.5.2. ALTO messages . . . . . . . . . . . . . . . . . . . . 11 5. Other optional Connection Relay Services . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Randriamasy Expires October 17, 2011 [Page 3] Internet-Draft Provider Confidential ALTO with Relays April 2011 1. Introduction IETF is designing a new service called ALTO that provides guidance to P2P 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 Quality of Experience (QoE) in the application while reducing resource consumption in the underlying network infrastructure. The ALTO protocol conveys the Internet View from the perspective of a Network Provider network region that spans from a region of an Autonomous System (AS) to several ASes. Together with this Network Map, the Network Provider determines a Cost Map between locations of the Network Map. Last, it provides the NP oriented Ranking of Endpoints w.r.t. their routing cost. Thus an application client can easily get the whole Provider Network topology. Network Providers (NP) in this document include both ISPs, who provide means to transport the data and Content Delivery Network (CDN) who care for the dissemination, storage and possibly identification of the "best" content copy. For security reasons however, Network Providers for either transport or delivery of content, are reluctant to provide their network topology to third parties that may misuse it. Indeed, the current ALTO protocol draft, see [ID-alto-protocol] , includes a section on "Security Considerations" where section "Privacy Considerations for ISPs" mentions the layer confidentiality issue that needs to be solved before ISPs adopt the ALTO protocol. This draft proposes to address this issue by introducing a transaction mode qualified as "Provider Confidential" (PC). A PC ALTO transaction involves one or several additional entities that are called an ALTO Relay. An ALTO Relay gets the ALTO Responses issued by an ALTO Server in place of the Application Client. The ALTO Client itself just gets a status indicating success or failure of the transaction. In case of success, the Application Client connects to an entity called a Connection Relay (CR), that is linked to an ALTO Relay and mapped to the network region hosting the requesting Application Client. The Application Client, meanwhile specifies how to select and connect to the candidate Endpoints given their ranking or cost. It sends this "connection policy" to its associated Connection Relay, that must enforce it with the ranking or cost received from the ALTO Server. The CR then communicates with the Application Client who thus knows nothing about the ALTO selected Endpoints. The best applicable ALTO Services are in particular the Endpoint Cost Service and the Endpoint Property Service. This way, users of an ISP that supports Provider Confidential ALTO Randriamasy Expires October 17, 2011 [Page 4] Internet-Draft Provider Confidential ALTO with Relays April 2011 Services get a better QoE while the ISP saves its resources. An Application Client MAY refuse to use Provider Confidential ALTO Services. In that case, one option is that the client gets no ALTO service at all, especially if the ISP supports only PC ALTO services, and thus a worse QoE. 2. Scope It is assumed that Applications likely to use the ALTO service have a choice among several connection endpoints as it is the case for most of them. This draft generalizes the term P2P Client to Application Client. Application Clients include CDN Clients and any Application Client having the choice in several connection points for data or resource exchange, such as GRID Application Clients, Gaming Application Clients and a limited number of P2P Clients. The term P2P Clients is used only in the figures, to better illustrate the difference of the present proposal with the current ALTO protocol draft. This draft focuses on the use case where: the ALTO Client is embedded in the Application Client , only one ALTO Relay and one Connection Relay is involved in a PC ALTO Transaction, and the ALTO Relay is embedded in the Connection Relay. 3. Terminology Endpoint (EP): stands for Connection Endpoint as in can be a content location in [ID-alto-protocol]. Network Provider: can be an ISP who provides means to transport the data or a Content Delivery Network (CDN) provider who cares for the dissemination, persistent storage and possibly identification of the "best"content copy. Application Client (AC): a Client having the choice in several connection points for data or resource exchange: typically a client of a CDN or a GRID application or a small P2P network. ALTO Relay: a functional entity that is mapped to the Application Client (AC) w.r.t. the region hosting this Application Client, by an ALTO discovery process driven by the Network Provider. It receives the ALTO responses in place of the requesting AC. The ALTO Relay discovery process still needs to be specified. Randriamasy Expires October 17, 2011 [Page 5] Internet-Draft Provider Confidential ALTO with Relays April 2011 Connection Relay: this networking entity is linked to or hosts an ALTO Relay and is connected with both the Selected Endpoints and the Application Client. It is a transit point between an AC and the Selected Endpoints so that the AC ignores the ID and location of the Selected EPs. Provider Confidential (PC) ALTO Service: this service uses ALTO Relays and Connection Relays to keep the Provider Network information ignored by the ACs while providing ALTO Services. 4. Provider Confidential ALTO 4.1. Overview To prevent Provider Confidential (PC) information from being unveiled to Application Clients, this draft proposes an indirection of the information provided by an ALTO Server to an intermediate ALTO Functional Entity that is linked to a Networking Entity taking care of the transport of the data between the Application Client and the selected Endpoint(s). In this draft, the intermediate Functional Entity is called ALTO Relay and the connecting Networking entity a Connection Relay. These two entities are managed by the Network Provider. PC ALTO is particularly well suited to the ALTO protocol services reporting on Endpoint Cost and Endpoint Properties. Figure 1 shows an example scenario provided in the ALTO protocol draft, see [ID-alto-protocol], where the ALTO client is embedded in the P2P Client and requires an ALTO server servicing its own ISP to provide the Endpoint Cost for a list of gathered peers. The use case proceeds as follows: 1. The P2P Client discovers peers from sources such as Peer Exchange (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and P2P Trackers. 2. The P2P Client queries the ALTO Server's Ranking Service, including discovered peers as the set of Destination Endpoints, and indicates the 'ordinal' Cost Mode. The response indicates the ranking of the candidate peers. 3. The P2P Client connects to the peers in the order specified in the ranking. Randriamasy Expires October 17, 2011 [Page 6] Internet-Draft Provider Confidential ALTO with Relays April 2011 .---------. .---------------. | | (2) Get Endpoint Ranking | | | ALTO | <----------------------> | [ALTO Client] | | Server | | | | | | P2P Client | .---------. `---------' `---------------' <- | P2P | .---------. / | ^ ^ | Tracker | | Peer 1 | <-------------- | | \ `---------' `---------' | (1) Gather Peers . (3) Connect to | | \ . Selected Peers / .--------. .--------. .---------. / | P2P | | DHT | | Peer 50 | <---------------- | Client | `--------' `---------' | (PEX) | `--------' Figure 1: Current ALTO protocol scenario for an ALTO Client collocated with the P2P Client and querying the ALTO server Ranking Service. 4.2. Provider Confidential ALTO architecture 4.2.1. Architecture Framework The Provider Confidential Services mentionned in this draft apply whether the ALTO Client is co-located with the Application Client or with the Application Endpoint tracker. However they are more suitable to the first of these two cases. Several kinds of mapping and discovery processes are needed to support PC ALTO. They still need to be specified w.r.t. the ALTO Server Discovery under definition. An AC can be serviced by one or several ALTO Servers. Likewise, an ALTO Relay can be embedded in a Connection Relay, or connected to several Connection Relays. An AC itself can be connected to several Connection Relays associated to one ALTO Relay. Future work on PC ALTO needs to define: o The association between an ALTO Server and the ALTO Relay receiving its responses. o The association between an Application Client and one or more ALTO Connection Relays. o The mapping between ALTO Relays and ALTO Connection Relays. The mappings between the ALTO Server and ALTO Relay should be managed by the NP. Randriamasy Expires October 17, 2011 [Page 7] Internet-Draft Provider Confidential ALTO with Relays April 2011 4.2.2. Current Transaction framework For the moment the described PC ALTO transaction relies on the following hypotheses: 1. An ALTO Client named AOC1 is embedded in or connected to an Application Client. 2. AOC1 has discovered a reference ALTO server AOS(1), that is possibly communicating with other ALTO servers. 3. AOC1 has discovered the capabilities of AOS(1) and discovers and accepts that all or several types of requested Provider Network information are classified as PC. 4. AOS(1) is mapped to an ALTO Relay AOR(AOS(1)), by a relevant ALTO discovery process, managed by the Network Provider. 5. The information requested by AOC1 will be sent to the ALTO Relay AOR(AOS(1)). 6. AOC(1) will receive from AOS(1) specific ALTO responses (i) containing an ALTO status code of success or failure for its request, (ii) indicating Provider Confidentiality. A. If the association between an ALTO Client and an ALTO Connection Relay is managed by the Network Provider, then AOS(1) MUST send to AOC(1) the ID or the Address of the Connection Relay(s) it can associate with. 7. AOR(AOS(1)) is embedded in or connected to a Connection Relay that MUST connect to both the Application Client and to the Selected Endpoints. 4.3. Use cases Figure 2 depicts the features and mechanisms added to the current ALTO scenario for Provider Confidential ALTO services, for the use case depicted in Figure 1. The EPs have already been discovered. In this figure, the term Peer is replaced by the term Endpoint, the term P2P Client by Application Client and a specific Tracker for resource sharing Application Endpoints should be added to the tools involved in step (1) of Figure 1. Last the ALTO Service requested by the ALTO Client in this example is the "Endpoint Cost" in 'ordinal' mode, that provides a ranking of the candidate Endpoints. We focus on the ALTO use case where the ALTO Client is co-located with an Application Client in a terminal node. As in section Randriamasy Expires October 17, 2011 [Page 8] Internet-Draft Provider Confidential ALTO with Relays April 2011 Figure1, the Application Client queries the ALTO Server servicing its own ISP. An ALTO Relay is mapped to the queried ALTO server. This ALTO Relay is associated to one single ALTO Connection Relay and embedded in it. The ALTO Client requests the ALTO Endpoint Ranking Service. .---------. .---------------. | |(2) Get Endpoint Cost | | | | (ordinal) | [ALTO Client] | | ALTO | <---------------------- | | | Server | ----------------------> | Application | | | (4) Send ALTO Status | Client | .---------. `---------' (PC) and address of `---------------' <--- | EP | | Connection Relay | ^ ^ | Tracker | | | | \ `---------' '-----------------------. | | \ | | | \ (3) Send Endpoint Costs | | (1) Gather Endpoints to ALTO Relay | (5) Connect to | \ | Connection Relay | \ | Send EP specs | \ | | | \ .-----------. v v | \ | Endpoint1 | .------------. .--------. .--------. `-----------' <------------- |[ALTO Relay]| | DNS | | DHT | . (6) Connect to | | | | `--------' . Selected EPs | Connection | | ... | .-----------. <------------- | Relay | `--------' | Endpoint9 | `------------' `-----------' Figure 2: Provider Confidential ALTO transaction for an ALTO Client collocated with the Application Client and querying the ALTO Server Endpoint Cost Service in ordinal mode. The ALTO Relay is embedded in the Connection Relay. The EPs have already been discovered. The use case proceeds as follows: 1. The Application Client discovers EPs from Endpoints tracking processes applicable to CDN, Trackerless P2P, or other applications connecting several EPs such as gaming and GRID. 2. The Application Client via its ALTO Client queries the ALTO Server's Endpoint Cost Service, including discovered Endpoints as the set of Destination Endpoints, and indicates the 'ordinal' Randriamasy Expires October 17, 2011 [Page 9] Internet-Draft Provider Confidential ALTO with Relays April 2011 Cost Mode. 3. The ALTO Server sends the requested Path Ranking information to its associated ALTO Relay, 4. The ALTO Server responds to the Application Client with: A. an ALTO status indicating: (i) failure or success and (ii) that the Provider Confidential ServiceType is activated, B. the IP address of the Connection Relay to connect to, * An option is that: if the Network Provider gives the Application Client the possibility to refuse the Provider Confidential ServiceType and if the AC does so, then it may get a lower priority service. * The ALTO Server response to the ALTO Client: + Does not contain any EP address (or other Network Information) but MAY content other synthetic information such as the number of processed EP locations. + MUST indicate that the sending of the requested information to the ALTO Relay has been is completed. 5. The Application Client connects to the Connection Relay and sends its requirements on how to select and connect to the Endpoints. E.g. to how many. 6. The Connection Relay connects to the selected Endpoints. * The Connection Relay is now a transit point between the ALTO Client and the selected application Endpoints. 4.4. ALTO requirements This section lists the features and updates to the ALTO protocol draft that are needed to support PC ALTO transactions. 4.4.1. ALTO Relays and Connection Relays These are the basic additional ALTO architecture elements. In this framework, the ALTO Relay is associated to the Control plane and the Connection Relay to the Data plane. The current protocol draft [ID-alto-protocol], , in Section on "Service ID", stresses that "for scalability and fault tolerance, multiple ALTO Servers may deployed to serve equivalent ALTO information". Likewise, the deployment and Randriamasy Expires October 17, 2011 [Page 10] Internet-Draft Provider Confidential ALTO with Relays April 2011 association of ALTO Relays and Connection Relays should allow scalability and fault tolerance, especially for large numbers of connected Endpoints. 4.4.2. PC ALTO discovery processes An ALTO Relay discovery process is necessary to associate ALTO Servers and ALTO Relays. Preferably, it just looks up the mapping between Servers and Relays, which is previously set by the Provider Network management and updated when necessary, typically when the Network Map changes, which is not frequent. Likewise, whether the ALTO Connection Relay discovery is driven by the ALTO Server needs to be decided. 4.5. ALTO protocol description updates This section proposes a list of updates to the current ALTO protocol draft that would support PC ALTO. 4.5.1. Need for a PC Service Property ALTO services and related requests are currently classified w.r.t. their type, that is, the information they provide. They should also be classified w.r.t. the way the Network Provider management processes the ALTO requests and the responses sent to the Application Client. Typically, if a requested information is considered as Provider Confidential by a NP, the corresponding request should be classified so and this information sent to the ALTO Client. In Section "Protocol Structure", Service Properties could be introduced to characterize Provider Confidential ALTO Services. Another section may detail how a PC attribute is defined. For example, the section on "Server Capability" may introduce something like: enum { ServiceDistribution, ..., } ServiceProperty; enum { Provider Confidential, Public, Unauthorized, ... } ServiceDistribution; 4.5.2. ALTO messages This section on PC specific ALTO messages is very schematic and will be further detailed as the work on PC ALTO Services progresses. Randriamasy Expires October 17, 2011 [Page 11] Internet-Draft Provider Confidential ALTO with Relays April 2011 4.5.2.1. ALTO Status Codes for PC Services When the "Provider Confidential" Service Distribution property is available and activated, the ALTO Status codes for the responses sent to an ALTO Client MUST include the case where a request has been successfully processed but the requested information redirected to the ALTO Relay because the invoked ALTO Service is PC. In [ID-alto-protocol] , the section on "ALTO Status Codes" provides definitions in Table 1 "ALTO Status Codes". A PC specific status code should be added. It could be for instance: "ALTO Status code = 7 (or whatever), HTTP Status code=204, Description = (Success) No Content". 4.5.2.2. ALTO Requests The ALTO Client does not know in advance whether an ALTO Service is PC or not. So the Request syntax remains the same as the one described in [ID-alto-protocol], Section 7.7.5.1.1 "Request Syntax". request = POST, HTTP method and URI path 4.5.2.3. Response Syntax for PC Services If the PC service distribution mode is activated, then the ServiceProperty attribute ServiceDistribution MUST be set to "Provider Confidential". 4.5.2.3.1. ALTO Server response to ALTO Relay The ALTO Server response to an ALTO Relay contains the ALTO information requested by the ALTO Client. 4.5.2.3.2. ALTO response to ALTO Client The response to the ALTO Client sent by ALTO Server contains: the ALTO Status, plus possible PC specific Response Meta Information plus the address or ID of the Connection Relay to connect to. 5. Other optional Connection Relay Services A Connection Relay may host other services. At the first place, it can act as a cache for the data traded by all the interconnected Application Clients. This can significantly help saving time and resources both in transport and retrieval of information and resources. Randriamasy Expires October 17, 2011 [Page 12] Internet-Draft Provider Confidential ALTO with Relays April 2011 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations The Application Client MUST have the guarantee to be connected to a Connection Relay that is safe, as the latter is managed by the NP and therefore must be protected from any spoofing. However the client may want additional guarantees about the way the NP will process its requests for ALTO information. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [ID-alto-protocol] ""ALTO Protocol" draft-ietf-alto-protocol-07.txt", March 2011. Author's Address Sabine Randriamasy (editor) Alcatel-Lucent Bell Labs Route de Villejust NOZAY 91620 FRANCE Email: Sabine.Randriamasy@alcatel-lucent.com Randriamasy Expires October 17, 2011 [Page 13]