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:// | | |
|<WPDAUTH>/<WPDURI> | | |
|------------------->| | |
| | | |
|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://*/<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.
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://<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.
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]