HTTPBIS W. Chow Internet-Draft Mobolize Intended status: Standards Track S. Mishra Expires: April 30, 2015 Verizon Communications J. McEachern, Ed. ATIS October 27, 2014 Web Proxy Description (WPD) Proxy Discovery draft-chow-httpbis-proxy-discovery-00 Abstract This document proposes mechanisms for applications to discover web proxy description files across different network configurations that are complementary to but not reliant upon an external network service or function, such as DHCP or DNS. 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 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 April 30, 2015. Copyright Notice Copyright (c) 2014 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 Chow, et al. Expires April 30, 2015 [Page 1] Internet-Draft WPD proxy discovery October 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Scope of the document . . . . . . . . . . . . . . . . . . 2 2.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proxy locations . . . . . . . . . . . . . . . . . . . . . . . 3 4. WPD Authorities . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Pre-defined authority . . . . . . . . . . . . . . . . . . 4 4.2. Network authority . . . . . . . . . . . . . . . . . . . . 6 4.3. Origin authority . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Terminology 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. Introduction 2.1. Scope of the document [I-D.nottingham-web-proxy-desc] proposes a web proxy description ("WPD") format and use of well-known URI to download it, but it does not specify a mechanism to identify the authority for the URL of the WPD. This document proposes a process to bootstrap the WPD process, and outlines mechanisms to locate the authority for the WPD file, and how to validate that authority. The mechanisms specified in this document leverage HTTP to enable a wide variety of user agents to discover a WPD without reliance on extensions being implemented in another protocol or external network service, such as DNS or DHCP. This approach also allows the WPD to be automatically discovered for a zero configuration setup. Chow, et al. Expires April 30, 2015 [Page 2] Internet-Draft WPD proxy discovery October 2014 2.2. Use cases The mechanisms in this document were designed to enable the following use cases: 1. Support secure and private access to a proxy on a public WiFi hotspot. 2. Support a mobile device accessing multiple networks with different proxies. The mobile device must be able to access the correct network proxy, and to change proxies as it switches between WiFi and cellular, or between operator networks. 3. Support proxies operating in different locations, possibly in a cooperative manner. The proxies could be in a private network, in a service provider network, or in the cloud, and could be limited to a specific service domain or a specific access technology. 4. Support proxies deployed on a corporate or home network. 5. Allow an app or content provider to have its own proxy. The mechanisms proposed in this document are designed to meet the following goals: 1. Enable wide scale support across many network types, including, but not limited to, wireless, satellite, enterprise and private networks. 2. Enable applications to discover a proxy without relying on support from lower software layers or external network services, such as DNS or DHCP. 3. Simplify the process for a user (or user agent) to use a proxy, while still providing robust security. 4. Enable both automatic and manual configuration, depending on the user and network requirements. 5. Enable dynamic WPDs (i.e., different WPDs for different networks). 3. Proxy locations The location of a proxy will influence the characteristics of a proxy and how it is used. This document considers the following proxy locations: Chow, et al. Expires April 30, 2015 [Page 3] Internet-Draft WPD proxy discovery October 2014 Internet/Cloud: Proxies that are based in the cloud can be owned and managed by 3rd parties, independent of the service provider or end user. Although these proxies are owned by 3rd parties, they can be invoked by the user, the network operator, or by application providers. Over time, the party accessing the proxy can change, depending on the configuration. This makes cloud based proxies useful for 3rd party optimization services that can be used for a range of applications, or for application specific optimization. Examples include browser-specific compression services, and Content Distribution Networks (CDN). Service provider: Proxies can also be owned and operated by the network service provider, and can be used to manage and/or optimize traffic carried over the specific network. The proxy can be physically located in the service provider core network, the access network, or even on the customer premise. These proxies can be used to provide services such as privacy, content filtering or security services such as malware detection. Service provider proxies are also used to enhance capacity through network optimization or to increase effective network speed and improve page load times. These proxies can also be used to apply network policy and track billing, including zero rating for selected applications. Examples of service provider proxies include those deployed in the MNO packet core, ISP central office, public hotspots, or inflight WiFi. Private: Proxies can be owned or controlled by the device owner, and deployed in a controlled network environment. These proxies can be used to provide content filtering and security services. They can also provide various services to enhance the effective speed or decrease bandwidth usage. Examples of private proxies include corporate proxies and firewalls, MiFi devices, home routers and localhost. 4. WPD Authorities A proxy's location determines the authority that is used to discover the WPD that describes it. The WPD authority may be distinct from the proxies described in the WPD, so the WPD Server is considered a logically distinct entity from the proxy. This document describes several possible WPD authorities, and provides a mechanism to identify and authenticate each one in the following sections. 4.1. Pre-defined authority In this case, the authority is pre-configured into the device or application, and is used by the UA to probe for the appropriate proxy. This mechanism would be limited to instances where the proxy Chow, et al. Expires April 30, 2015 [Page 4] Internet-Draft WPD proxy discovery October 2014 provider is explicitly authorized to control the configuration of the device or application. Examples would include "locked" mobile phones, PCs owned by the enterprise/school, or a browser associated with a cloud-based compression service. Mechanism: The pre-configured authority is seeded into the device or an app beforehand through an out-of-band (OOB) mechanism, so that it is available at the time that the WPD is requested. The OOB mechanism can often be static, such as being hard-coded into the UA, but this approach is complementary to dynamic mechanisms, such as those leveraging an external network service, such as a PDP context for mobile devices or LDAP for PCs. Proxy scope: The scope of the UA determines the scope of traffic affected by the WPD. If the UA has device wide administrative privileges, it can apply the WPD configuration to all traffic on the device. If the UA is an application without administrative privileges, it can only apply the WPD configuration to the traffic for that application. Sequence diagram: +-------+ +------+ +----------+ +---------+ |Origin | |Client| |WPD Server| | Proxy | |Server | +--+---+ +----+-----+ +---------+ +---+---+ | | | | 1 -->| | | | | | | | |UA: GET https:// | | | |/ | | | |------------------->| | | | | | | |UA: set up TLS connection | | |------------------------------------>| | | | | | |UA: send HTTP/s requests |Proxy: forwards | |------------------------------------>|----------------->| | | | | | | | | | | | | 1: OOB-defined WPD authority Chow, et al. Expires April 30, 2015 [Page 5] Internet-Draft WPD proxy discovery October 2014 4.2. Network authority In this case, the UA probes the network for the WPD, allowing the current network to advertise its web proxies, such as a privacy proxy on a public WiFi hotspot, optimization proxy on a MiFi device, or a content filtering proxy on a corporate network. This approach allows the proxy configuration to be customized for the current network, and is dynamically updated when the user device attaches to a different network. Mechanism: The network authority for the WPD request is identified by the UA sending a request to the WPD URI with the "http" scheme to any authority, so that the network can respond with a redirect to the authority where its WPD can be found. The redirect MUST specify a URL with the "https" scheme, to ensure that the network authority can be securely authenticated by the UA. Proxy scope: The scope of the WPD is limited to the current network. Proxy information can be cached, but a change in the network MUST clear the proxies it configured. The scope of the UA determines the scope of traffic affected by the WPD. If the UA has device wide administrative privileges, it can apply the WPD configuration to all traffic on the device. If the UA is an application without administrative privileges, it can only apply the WPD configuration to the traffic for that application. Sequence diagram: Chow, et al. Expires April 30, 2015 [Page 6] Internet-Draft WPD proxy discovery October 2014 +-------+ +------+ +----------+ +-----+ +----------+ |Origin | |Client| | WiFi AP | |Proxy| |WPD Server| |Server | +--+---+ +----+-----+ +-----+ +----------+ +---+---+ |Device connects to | | | | |WiFi access point | | | | |------------------->| | | | | | | | | |UA: captive portal | | | | |detect/login | | | | |------------------->| | | | | | | | | | | | | | |UA: GET http://*/ | Redirect | | |-------------------------------------. | | | | | | | | .--<------------------------------------' | | | |UA: GET https:/// | | | '-|---------------------------------------------->| | | | | | | | | | | | |UA: set up TLS connection | | | |---------------------------------->| | | | | | | | | | | | | |UA: send HTTP/s requests |Proxy: forwards | |---------------------------------->|------------------------->| | | | | | 4.3. Origin authority In this case, the UA probes for the WPD using the origin server as the authority for the WPD URI. This allows the content provider to specify a proxy for its content. The scope of the WPD from the origin server is inherently limited to the traffic to/from that origin and the UA MUST enforce this. Mechanism: The WPD from the origin server MUST be requested using the "https" scheme, to ensure that it is coming from that origin authority. This ensures it bypasses all intermediaries and avoids overlapping with the other network authority mechanism. Proxy scope: The scope of the WPD from the origin server MUST be limited to the traffic to that origin server. Sequence diagram: Chow, et al. Expires April 30, 2015 [Page 7] Internet-Draft WPD proxy discovery October 2014 +-------+ +------+ +---------+ |Origin | |Client| | Proxy | |Server | +--+---+ +---------+ +---+---+ | | | | | | |UA: GET https:/// | |------------------------------------------->| | | | |UA: send HTTP/s requests |Proxy: forwards | |------------------------>|----------------->| | | | | | | | | | 5. IANA Considerations This document does not contain any considerations for IANA. 6. Security Considerations This document specifies mechanisms to locate the authority for the WPD across different applications and network types, so it is important that these mechanisms allow the user agent to securely authenticate the WPD. Therefore, this document proposes that WPD requests SHOULD use the "https" scheme whenever possible to ensure strong authentication for the WPD server for each of the mechanisms. However, certain network scenarios may provide strong authentication of the WPD authority through other means, such as through operational security on a private network, so this document does not preclude those alternatives. The proxy can observe unencryped traffic that traverses it, but it MUST NOT alter the end-to-end encryption for "https" requests. Also, the scope of the WPD and the traffic it affects is enforced by the user agent. In the case where the WPD is advertised by the content provider, the user agent MUST ensure that the scope of the network traffic is limited to the authority specified when requesting that WPD. This ensures that an origin server can only direct requests to proxies for its own traffic and it cannot reroute traffic for other origins. 7. Acknowledgments The editor and authors thank Dan Druta, Vijay K. Gurbani, David Lerner, Peter Lepska, John Border and Chi-Jiun Su for feedback and suggestions. Chow, et al. Expires April 30, 2015 [Page 8] Internet-Draft WPD proxy discovery October 2014 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.nottingham-web-proxy-desc] Nottingham, M., "The Web Proxy Description Format", draft- nottingham-web-proxy-desc-01 (work in progress), October 2014. [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", draft-ietf-httpbis-http2-14 (work in progress), July 2014. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, July 2014. Authors' Addresses William Chow Mobolize Email: wchow@mobolize.com Sanjay Mishra Verizon Communications Email: sanjay.mishra@verizon.com Chow, et al. Expires April 30, 2015 [Page 9] Internet-Draft WPD proxy discovery October 2014 James McEachern (editor) ATIS Email: jmceachern@atis.org Chow, et al. Expires April 30, 2015 [Page 10]