ALTO Fabio Picconi Internet-Draft Technicolor Intended Status: Informational Expires: April 23, 2012 October 21, 2011 ALTO home proxy draft-picconi-alto-home-proxy-00 Abstract This documents discusses the use of ALTO proxies running on home devices such as gateways or home NAS servers. An ALTO home proxy caches ALTO information obtained from an origin ALTO server, and uses that information to serve queries originating from the home network. ALTO home proxies reduce ALTO traffic and query latency, improve scalability, and enhance user privacy. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Fabio Picconi Expires April 23, 2012 [Page 1] Internet-Draft Gateway-based distribution October 21, 2011 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Devices to run home proxies . . . . . . . . . . . . . . . . . . 4 3. Proxy configuration and discovery . . . . . . . . . . . . . . . 4 3.1. Configuration . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Proxy discovery . . . . . . . . . . . . . . . . . . . . . . 5 4. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Transparent vs. non-transparent . . . . . . . . . . . . . . 5 4.2. Caching proxies vs. local ALTO servers . . . . . . . . . . 6 5. Obtaining ALTO information . . . . . . . . . . . . . . . . . . 6 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1 Introduction The ALTO service allows applications to obtain information about the network cost between two peers. Applications use this information to optimize their traffic (e.g., through proximity-based neighbor selection), leading to better performance for end users, and potentially lower operational costs for network operators. See [RFC5693] for the ALTO problem statement. The ALTO protocol [I-D.ietf-alto-protocol] defines communications between an ALTO client (requesting cost information) and an ALTO server (providing such information). Clients are typically peer-to- peer applications run by users, while servers are typically run by network operators. Peer-to-peer trackers may also behave as ALTO clients, using the retrieved ALTO information to return localized peer sets. This document considers only the first scenario, in which peers contact an ALTO server directly to obtain ALTO information. Fabio Picconi Expires April 23, 2012 [Page 2] Internet-Draft Gateway-based distribution October 21, 2011 To improve scalability, peers may exchange the cost information retrieved from an ALTO server, thus reducing server load. This is known as ALTO information redistribution, and is discussed in [I- D.ietf-alto-protocol] and [I-D.gu-alto-redistribution]. The ALTO protocol does not make redistribution mandatory, and does not define how it should be performed. It is up to each application to decide whether to implement redistribution, and how (e.g., by using DHT or a gossip-based protocol). In this document we argue that distribution of ALTO information can be enhanced by employing home proxies. An ALTO home proxy caches ALTO information obtained from an origin ALTO server, and uses it to respond to ALTO queries originating from the local home network. This presents several advantages compared to using a remotely located ALTO server: 1) Reduced ALTO traffic. Application-dependent redistribution might result in unnecessary ALTO traffic. Consider, for instance, a home network with two different active applications (e.g., a file sharing application and a streaming application) which both implement redistribution but using different mechanisms. The network and cost maps downloaded by one application cannot be shared with the other. If both applications use the ALTO home proxy, the ALTO information will be fetched only once. 2) Increased redistribution. ALTO home proxies may redistribute information to the home proxies of other peers. Therefore, applications which do not implement redistribution may still generate little or no load on the ALTO server if they use an ALTO home proxy that implements redistribution. 3) Reduced latency. In case of a cache hit, the ALTO home proxy can serve queries quickly given the low RTT and high bandwidth of home networks. This may improve the performance of delay-sensitive applications. 4) Background updates. If the home proxy is executed in a device that is always on and connected to the network (such as a home gateway or a home NAS), ALTO information updates can be pushed to the proxy during off-peak hours, when there is plenty of available bandwidth and ALTO servers are lightly loaded. 5) Discovery. If the home proxy has been configured to use a default origin ALTO server, then applications using the proxy do not need to use ALTO discovery to select an ALTO server. Moreover, applications may easily discover the home proxy using protocols such as SLP [RFC2608], uPnP, or Bonjour. Fabio Picconi Expires April 23, 2012 [Page 3] Internet-Draft Gateway-based distribution October 21, 2011 6) User privacy. Serving ALTO queries within the home makes it more difficult for a third party (e.g., a remote ALTO server) to infer the user's communications patterns by analyzing ALTO traffic. The following sections discuss in more detail several aspects of using ALTO home proxies. 2. Devices to run home proxies ALTO home proxies may run on any home device which is connected to the home network and has Internet access. This includes PCs, home NAS servers, home gateways, etc. However, it may be preferable to run home proxies on devices which are always on, such as a home gateway or a NAS. This allows the proxy to optimize traffic (e.g., download ALTO information updates during off-peak hours), and to maximize the number of queries that can be served locally. Many users employ home gateways which are owned and managed by their Internet Service Provider (ISP). Typically, the ISP ships the gateway to the user when he or she signs up for the Internet access plan. The gateway is remotely configured by the ISP, which retains control on the firmware, and in particular all the services, that run on the gateway. This is typically the case for triple-play subscriptions, where the gateway runs VoIP and IPTV services in addition to Internet access. ISPs that deploy ALTO servers in their network will probably consider implementing ALTO home proxies as well. The computing power of current gateways should easily support the small increase in CPU load caused by the ALTO proxy service, especially given that the service only replies to queries originating from the local network. Moreover, the home proxy can be added to already deployed gateways by means of a remote firmware upgrade. Some users employ gateways which are not managed by their ISP. In this case, gateway vendors may provide firmware upgrades which can be installed by the user. Similarly, vendors or home NAS servers or other networked home devices may provide firmware upgrades which include an ALTO home proxy. 3. Proxy configuration and discovery Two steps must be executed before applications can use an ALTO home proxy: configuration and discovery. Fabio Picconi Expires April 23, 2012 [Page 4] Internet-Draft Gateway-based distribution October 21, 2011 3.1. Configuration This step involves configuring the ALTO home proxy parameters. One important parameter is the default origin ALTO server, i.e., the server from which ALTO information will be fetched and cached, and which will be used by default to answer queries. This can be obtained using the mechanisms described in [I-D.ietf-alto-server-discovery]. If the ALTO home proxy runs on an ISP-managed gateway, the ISP may also provide a default origin ALTO proxy (the ISP's own). Another important parameter is whether the proxy will behave as a caching proxy or a local server (see Section 3.1 for more details). Other parameters may specify the maximum amount of data that can be cached, the expiration time, etc. The user may be able to configure these parameters through a local management interface (e.g., a web page). 3.2. Proxy discovery Applications running on the home can discover a local ALTO home proxy by employing protocols such as SLP [RFC2608], uPnP, or Bonjour. An important point is that application need not apply the discovery mechanisms that are needed to use a remote ALTO server [I-D.ietf- alto-server-discovery], as the home proxy has already been configured with a default origin ALTO server. 4. Proxy behavior Similarly to HTTP proxies, ALTO home proxies may be transparent or non-transparent. Also, ALTO home proxies may behave as caching proxies or local ALTO servers. 4.1. Transparent vs. non-transparent A non-transparent proxy requires ALTO clients to be aware of their presence, and direct ALTO queries to them instead of remote ALTO servers. ALTO clients must be configured, either manually or automatically, to use the home proxy. Manual configuration is typically achieved by prompting the user for an IP address belonging to the home network (e.g., 192.168.0.x). Automatic configuration can be achieved by using a discovery protocol such as SLP, uPnP, or Bonjour. A transparent proxy intercepts ALTO requests directed to a remote ALTO server. Therefore, they do not require ALTO clients to be aware of their presence, or to discover them using protocols such as SLP, Fabio Picconi Expires April 23, 2012 [Page 5] Internet-Draft Gateway-based distribution October 21, 2011 uPnP, or Bonjour. Transparent proxies would typically run in home gateways so that they can intercept requests originating from multiple devices of the home network. 4.2. Caching proxies vs. local ALTO servers ALTO home proxies may behave as simple HTTP caching proxies. The main advantage of this is caching large responses from ALTO servers, such as full network and cost maps. A caching proxy may also use redistribution to fetch cacheable responses from other caching proxies, thus reducing the load on the ALTO server. Caching proxies may also prefetch ALTO information (e.g., an updated version of the cost map) to reduce latency. The disadvantage of caching proxies is that client-specific requests, such as filtered maps, will probably result in a cache miss. To counter this limitation, a home proxy may behave as a local ALTO server. In this case, it uses the entire cost and network maps previously downloaded from the remote ALTO server to produce, whenever possible, a valid response to the client. A proxy acting as a local server may return filtered maps even though such response has not been previously cached. The main limitation of proxies acting as local ALTO server is that not all the functionalities of the origin ALTO server may be available, e.g., generating signed data, or obtaining information based on non-standard cost models which are not publicly known. 5. Obtaining ALTO information Besides from caching responses from ALTO servers, home proxies may obtain ALTO information from wide variety of sources. Update dissemination may be pull-based or push-based [I-D.gu-alto- redistribution], and peer-to-peer protocols such as BitTorrent may be used for redistribution between home proxies. An important issue is deciding which information to obtain, i.e., which resources and from which ALTO servers. Some users may manually configure their applications to use an ALTO server different from that obtained through the standard ALTO discovery mechanism. Home proxies should be aware of such scenarios, and obtain the appropriate ALTO information to maximize their hit ratio. 6 Security Considerations ALTO home proxying loses its benefits when clients employ SSL/TLS to Fabio Picconi Expires April 23, 2012 [Page 6] Internet-Draft Gateway-based distribution October 21, 2011 verify the identity of the remote ALTO server. Clients may switch back to HTTP to use the home proxy, but should be aware of the possibility of integrity attacks on non-signed data. In the case of ALTO home proxies running on ISP-managed gateways, the ISP may provide SSL/TLS certificates for each gateway, thus supporting SSL/TLS communications between clients and proxies. In this scenario, clients may reasonably assume that home proxies acting as local ALTO servers provides authoritative responses equivalent to those of the ISP's remote ALTO server. As mentioned before, serving ALTO queries within the home reduces the amount of user-sensitive information that leaks to external parties (e.g., a remote ALTO server). Therefore, ALTO home proxies should enhance user privacy. 7 IANA Considerations This document does not mandate any IANA actions. 8 References 8.1 Informative References [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [I-D.gu-alto-redistribution] Yingjie, G., Alimi, R., and R. Even, "ALTO Information Redistribution", draft-gu-alto-redistribution-03 (work in progress), July 2010. [I-D.ietf-alto-server-discovery] Kiesel, S., Siemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", draft-ietf-alto-server- discovery-02 (work in progress), September 2011. [I-D.ietf-alto-protocol] Alimi, R., Penno, R. and Y. Yang, "ALTO Protocol", draft- ietf-alto-protocol-09 (work in progress), June 2011. Fabio Picconi Expires April 23, 2012 [Page 7] Internet-Draft Gateway-based distribution October 21, 2011 Authors' Addresses Fabio Picconi Technicolor 1 rue Jeanne d'Arc 92443 Issy les Moulineaux cedex France EMail: fabio.picconi@technicolor.com Fabio Picconi Expires April 23, 2012 [Page 8]