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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

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.

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:

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 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.

                                                           +-------+
   +------+           +----------+     +---------+         |Origin |
   |Client|           |WPD Server|     |  Proxy  |         |Server |
   +--+---+           +----+-----+     +---------+         +---+---+
      |                    |                |                  |
 1 -->|                    |                |                  |
      |                    |                |                  |
      |UA: GET https://    |                |                  |
      |<WPDAUTH>/<WPDURI>  |                |                  |
      |------------------->|                |                  |
      |                    |                |                  |
      |UA: set up TLS connection            |                  |
      |------------------------------------>|                  |
      |                    |                |                  |
      |UA: send HTTP/s requests             |Proxy: forwards   |
      |------------------------------------>|----------------->|
      |                    |                |                  |
      |                    |                |                  |
      |                    |                |                  |

 1: OOB-defined WPD authority

     

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.

                                                               +-------+
 +------+           +----------+     +-----+   +----------+    |Origin |
 |Client|           | WiFi AP  |     |Proxy|   |WPD Server|    |Server |
 +--+---+           +----+-----+     +-----+   +----------+    +---+---+
    |Device connects to  |              |           |              |
    |WiFi access point   |              |           |              |
    |------------------->|              |           |              |
    |                    |              |           |              |
    |UA: captive portal  |              |           |              |
    |detect/login        |              |           |              |
    |------------------->|              |           |              |
    |                    |              |           |              |
    |                    |              |           |              |
    |UA: GET http://*/<WPDURI>          | Redirect  |              |
    |-------------------------------------.         |              |
    |                    |              |  |        |              |
  .--<------------------------------------'         |              |
 |  |UA: GET https://<WPDAUTH>/<WPDURI> |           |              |
  '-|---------------------------------------------->|              |
    |                    |              |           |              |
    |                    |              |           |              |
    |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.

                                               +-------+
   +------+                +---------+         |Origin |
   |Client|                |  Proxy  |         |Server |
   +--+---+                +---------+         +---+---+
      |                         |                  |
      |                         |                  |
      |UA: GET https://<ORIGIN>/<WPDURI>           |
      |------------------------------------------->|
      |                         |                  |
      |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.

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", Internet-Draft draft-nottingham-web-proxy-desc-01, October 2014.
[I-D.ietf-httpbis-http2] Belshe, M., Peon, R., Thomson, M. and A. Melnikov, "Hypertext Transfer Protocol version 2.0", Internet-Draft draft-ietf-httpbis-http2-02, April 2013.
[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
James McEachern (editor) ATIS EMail: jmceachern@atis.org