Network Working Group D. Druta Internet-Draft G. Bourg Intended status: Informational AT&T Expires: April 30, 2015 S. Loreto Ericsson October 27, 2014 Using WPD to configure network proxies draft-loreto-wpd-usage-00 Abstract This specification provides feedbacks and improvements suggestions to "The Web Proxy Description Format" draft. It is an initial set of considerations collected while reviewing the WPD draft to understand how it could be used in a Telecom Operator network; specifically Cellular and Operated WiFi Networks. 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 Druta, et al. Expires April 30, 2015 [Page 1] Internet-Draft WPD Usage October 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. WPD Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Traffic Flow label . . . . . . . . . . . . . . . . . . . 2 2.2. Web Protocol . . . . . . . . . . . . . . . . . . . . . . 4 3. The Web Proxy Description (WPD) Format . . . . . . . . . . . 4 3.1. proxy objects members . . . . . . . . . . . . . . . . . . 5 3.1.1. Label . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. WebProtocol . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Draft [I-D.nottingham-web-proxy-desc] presents a simple and reliable way to describe a Web Proxy Configuration (WPD), and proposes the usage of a well-known URI [RFC5785] to designate a well-know location where the WPD can be found. The WPD allows the description of multiple proxies in one WPD file as long as they are under the same authority; clients may choose any proxy they wish, and may use more than one proxy at a time. However the proxy description should be extended to provide better user experience and smoother interaction with the network. 2. WPD Proxies [I-D.nottingham-web-proxy-desc] defines the "WPD Proxy" concept and place additional requirements upon this proxy, as well as upon clients using it. The following sections proposes improvements and changes to those requirements. 2.1. Traffic Flow label 3GPP Mobile Networks support Traffic Flow Templates that allow specific flows to traverse different data bearers; a flow is identified by the 5-tuple {dest addr, source addr, protocol, dest port, source port}. These data bearers can have different characteristics based on how they are configured. Specifically, in scheduled networks there is an inherent balancing act between absolute data rate, latency, and jitter. Today 3GPP mobile networks Druta, et al. Expires April 30, 2015 [Page 2] Internet-Draft WPD Usage October 2014 balance the needs of different types of traffic (e.g. the high bit rate download that is unaffected by jitter vs real time communications that are lower bit rate but require minimal jitter or latency impact) by detecting traffic and assigning flows to bearers that are best configured for the type of traffic. Traffic classification is not used to discriminate between clients or between servers. Instead, it is necessary to optimally utilize the radio resources resulting in improved user experience. WPD proxy mandates the usage of HTTP2 [I-D.ietf-httpbis-http2] over TLS for connections from clients. The usage of a single TCP connection to an addressable and explicit proxy provides several benefits, however at same time it prevents a 3GPP mobile network from working as previously described, because it is not possible to de-multiplex the traffic within the single TCP socket into multiple data bearers. For a 3GPP mobile network, this limits the ability to tune the network efficiently based on traffic classification. As draft [I-D.nottingham-web-proxy-desc] already allows a client to choose multiple proxies to be used at a time, it should be possible for a client to use multiple proxies for different purposes as long as it is clear to the client the different type of advantages offered by each proxy listed in the retrieved WPD file. In this way a different proxy instance could be used for flows of each traffic type. This document defines a new WPD's "proxy object" member ("label"), describing the purpose and the specific services offered by a proxy. Labels can be used by the client to identify the right proxy that should be used for a specific traffic type or them can be used to identify proxies offering specific optimisation functions. A client can use the "label" member to identify the right proxy to be used for a specific class of traffic (e.g. "dft" for a traffic balance between latency and jitter, "rtc" for low bandwidth but jitter sensitive real time communications, or "hdr" for High Data Rate traffic that is unaffected by jitter). The client is, in many situations, able to determine from the context of an HTTP transaction what type of "label" to apply to an http resource. The client may then decide to map the label's resource with the proxy with the same label listed in the retrieved WPD or to use the default proxy. Additionally, it should be possible for the content provider to explicitly label resources to suggest they traverse a specific proxy path. Druta, et al. Expires April 30, 2015 [Page 3] Internet-Draft WPD Usage October 2014 2.2. Web Protocol "Clients MUST use HTTP/2 over TLS to connect to a WPD proxy; if one cannot be established, the client MUST consider that proxy "failed"." Using TLS to provide security, confidentiality and integrity is an important requirement to have. However restricting the possibility to establishing connection from client only to "HTTP/2 over TLS" closes the door to innovation. It would much better to define a list of criteria that protocol has to fulfil in order to be used between a Client and a WPD Proxy. In order to maximize interoperability, HTTP/2 MUST be mandatory to implement, however other protocols that meet the minimum requirements may also be used. A possible but not complete list of requirements can be: "The protocol session between the client and server must use a multiplexed and flow controlled protocol. This is necessary to effectively scale the proxy server and provide differentiated service priority between requests while protecting resource constraints on both ends. The reduction in connection count is particularly meaningful to an intermediary, and the protocol support for prioritization is needed to mitigate the change in connection granularity." 3. The Web Proxy Description (WPD) Format The proxy information currently defined in the WPD proposal should be extended in order to both provide a better user experience and a smoother interaction with the network. For example: Druta, et al. Expires April 30, 2015 [Page 4] Internet-Draft WPD Usage October 2014 { "name": "ExampleCorp Web Proxy", "desc": "ExampleCorp's Proxy Gateway for Web access. Note that all traffic through this proxy is logged, and may be filtered for content.", "moreInfo": "https://inside.example.com/proxy/", "proxies": [ { "host": "proxy.example.com", "port": 8080, "clientNetworks": ["192.0.2.0/24"] "label": "dft" "WebProtocol": "h2" }, { "host": "proxy1.example.com", "port": 8080, "clientNetworks": ["192.0.2.0/24"] "label": "rtc" "WebProtocol": "h2" } ], "alwaysDirect": ["example.com", "192.0.2.0/24"], "failDirect": False } The reminder of this section defines the proposed extensions of the WPD object members. 3.1. proxy objects members A proxy object as defined in [I-D.nottingham-web-proxy-desc] represents a HTTP proxy endpoint within the WPD JSON representation. At moment the only Proxy objects' "label" value defined are the following "host", "port", "clientNetworks". The following sections define new members necessary to completely describe a WPD Proxy. 3.1.1. Label A string containing the tag specifying the class of traffic. This specification defines the following three three labels: dft: a traffic class with balance between latency and jitter; Druta, et al. Expires April 30, 2015 [Page 5] Internet-Draft WPD Usage October 2014 rtc: a traffic class for low bandwidth but jitter sensitive real time communications; hdr: a traffic class for High Data Rate traffic that is unaffected by jitter. It should be possible to use implementation defined labels for which the Client MUST use the label on the http resource URL to send the request to the corresponding proxy entry in the WPD. If the label does not have a matching entry, the Client MUST use the default proxy (dft). [TBD] create a new IANA register for the label. 3.1.2. WebProtocol A string containing the ALPN tag [RFC7301] describing the protocol supported by the proxy to establish a session between the client and proxy itself. This member MUST be present. 4. IANA Considerations This specification creates a new IANA registry, in accordance with the principles set out in [RFC5226], for the "label" Proxy objects' parameter namespace describing the specific class of traffic or optimisation feature provided by a proxy. 5. Security Considerations See [I-D.nottingham-web-proxy-desc] for general security considerations on the WPD usage. It should be noted that the usage of multiple proxies, proposed in this document, discloses the type of traffic requested and used by the client (i.e. the end user). 6. Acknowledgments The authors wish to thank Diego Lopez, Kevin Smith, Martin Nilsson, Sanjay Mishra and Mathilde Cayla for their comments and useful feedback. 7. Normative References [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. Druta, et al. Expires April 30, 2015 [Page 6] Internet-Draft WPD Usage October 2014 [I-D.nottingham-web-proxy-desc] Nottingham, M., "The Web Proxy Description Format", draft- nottingham-web-proxy-desc-01 (work in progress), October 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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 Dan Druta AT&T Email: dd5826@att.com Gus Bourg AT&T Email: gb3635@att.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Druta, et al. Expires April 30, 2015 [Page 7]