idnits 2.17.1 draft-loreto-wpd-usage-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 232, but not defined == Unused Reference: 'RFC2119' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 277, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-14 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Druta 3 Internet-Draft G. Bourg 4 Intended status: Informational AT&T 5 Expires: April 30, 2015 S. Loreto 6 Ericsson 7 October 27, 2014 9 Using WPD to configure network proxies 10 draft-loreto-wpd-usage-00 12 Abstract 14 This specification provides feedbacks and improvements suggestions to 15 "The Web Proxy Description Format" draft. It is an initial set of 16 considerations collected while reviewing the WPD draft to understand 17 how it could be used in a Telecom Operator network; specifically 18 Cellular and Operated WiFi Networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 30, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. WPD Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Traffic Flow label . . . . . . . . . . . . . . . . . . . 2 57 2.2. Web Protocol . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The Web Proxy Description (WPD) Format . . . . . . . . . . . 4 59 3.1. proxy objects members . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Label . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.2. WebProtocol . . . . . . . . . . . . . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Draft [I-D.nottingham-web-proxy-desc] presents a simple and reliable 71 way to describe a Web Proxy Configuration (WPD), and proposes the 72 usage of a well-known URI [RFC5785] to designate a well-know location 73 where the WPD can be found. 75 The WPD allows the description of multiple proxies in one WPD file as 76 long as they are under the same authority; clients may choose any 77 proxy they wish, and may use more than one proxy at a time. However 78 the proxy description should be extended to provide better user 79 experience and smoother interaction with the network. 81 2. WPD Proxies 83 [I-D.nottingham-web-proxy-desc] defines the "WPD Proxy" concept and 84 place additional requirements upon this proxy, as well as upon 85 clients using it. The following sections proposes improvements and 86 changes to those requirements. 88 2.1. Traffic Flow label 90 3GPP Mobile Networks support Traffic Flow Templates that allow 91 specific flows to traverse different data bearers; a flow is 92 identified by the 5-tuple {dest addr, source addr, protocol, dest 93 port, source port}. These data bearers can have different 94 characteristics based on how they are configured. Specifically, in 95 scheduled networks there is an inherent balancing act between 96 absolute data rate, latency, and jitter. Today 3GPP mobile networks 97 balance the needs of different types of traffic (e.g. the high bit 98 rate download that is unaffected by jitter vs real time 99 communications that are lower bit rate but require minimal jitter or 100 latency impact) by detecting traffic and assigning flows to bearers 101 that are best configured for the type of traffic. Traffic 102 classification is not used to discriminate between clients or between 103 servers. Instead, it is necessary to optimally utilize the radio 104 resources resulting in improved user experience. 106 WPD proxy mandates the usage of HTTP2 [I-D.ietf-httpbis-http2] over 107 TLS for connections from clients. 109 The usage of a single TCP connection to an addressable and explicit 110 proxy provides several benefits, however at same time it prevents a 111 3GPP mobile network from working as previously described, because it 112 is not possible to de-multiplex the traffic within the single TCP 113 socket into multiple data bearers. For a 3GPP mobile network, this 114 limits the ability to tune the network efficiently based on traffic 115 classification. 117 As draft [I-D.nottingham-web-proxy-desc] already allows a client to 118 choose multiple proxies to be used at a time, it should be possible 119 for a client to use multiple proxies for different purposes as long 120 as it is clear to the client the different type of advantages offered 121 by each proxy listed in the retrieved WPD file. In this way a 122 different proxy instance could be used for flows of each traffic 123 type. 125 This document defines a new WPD's "proxy object" member ("label"), 126 describing the purpose and the specific services offered by a proxy. 127 Labels can be used by the client to identify the right proxy that 128 should be used for a specific traffic type or them can be used to 129 identify proxies offering specific optimisation functions. 131 A client can use the "label" member to identify the right proxy to be 132 used for a specific class of traffic (e.g. "dft" for a traffic 133 balance between latency and jitter, "rtc" for low bandwidth but 134 jitter sensitive real time communications, or "hdr" for High Data 135 Rate traffic that is unaffected by jitter). The client is, in many 136 situations, able to determine from the context of an HTTP transaction 137 what type of "label" to apply to an http resource. The client may 138 then decide to map the label's resource with the proxy with the same 139 label listed in the retrieved WPD or to use the default proxy. 140 Additionally, it should be possible for the content provider to 141 explicitly label resources to suggest they traverse a specific proxy 142 path. 144 2.2. Web Protocol 146 "Clients MUST use HTTP/2 over TLS to connect to a WPD proxy; if 147 one cannot be established, the client MUST consider that proxy 148 "failed"." 150 Using TLS to provide security, confidentiality and integrity is an 151 important requirement to have. However restricting the possibility 152 to establishing connection from client only to "HTTP/2 over TLS" 153 closes the door to innovation. It would much better to define a list 154 of criteria that protocol has to fulfil in order to be used between a 155 Client and a WPD Proxy. In order to maximize interoperability, 156 HTTP/2 MUST be mandatory to implement, however other protocols that 157 meet the minimum requirements may also be used. 159 A possible but not complete list of requirements can be: "The 160 protocol session between the client and server must use a multiplexed 161 and flow controlled protocol. This is necessary to effectively scale 162 the proxy server and provide differentiated service priority between 163 requests while protecting resource constraints on both ends. The 164 reduction in connection count is particularly meaningful to an 165 intermediary, and the protocol support for prioritization is needed 166 to mitigate the change in connection granularity." 168 3. The Web Proxy Description (WPD) Format 170 The proxy information currently defined in the WPD proposal should be 171 extended in order to both provide a better user experience and a 172 smoother interaction with the network. For example: 174 { 175 "name": "ExampleCorp Web Proxy", 176 "desc": "ExampleCorp's Proxy Gateway for Web access. Note that 177 all traffic through this proxy is logged, and may be 178 filtered for content.", 179 "moreInfo": "https://inside.example.com/proxy/", 180 "proxies": [ 181 { 182 "host": "proxy.example.com", 183 "port": 8080, 184 "clientNetworks": ["192.0.2.0/24"] 185 "label": "dft" 186 "WebProtocol": "h2" 188 }, 189 { 190 "host": "proxy1.example.com", 191 "port": 8080, 192 "clientNetworks": ["192.0.2.0/24"] 193 "label": "rtc" 194 "WebProtocol": "h2" 195 } 196 ], 197 "alwaysDirect": ["example.com", "192.0.2.0/24"], 198 "failDirect": False 199 } 201 The reminder of this section defines the proposed extensions of the 202 WPD object members. 204 3.1. proxy objects members 206 A proxy object as defined in [I-D.nottingham-web-proxy-desc] 207 represents a HTTP proxy endpoint within the WPD JSON representation. 208 At moment the only Proxy objects' "label" value defined are the 209 following "host", "port", "clientNetworks". 211 The following sections define new members necessary to completely 212 describe a WPD Proxy. 214 3.1.1. Label 216 A string containing the tag specifying the class of traffic. This 217 specification defines the following three three labels: 219 dft: a traffic class with balance between latency and jitter; 220 rtc: a traffic class for low bandwidth but jitter sensitive real 221 time communications; 223 hdr: a traffic class for High Data Rate traffic that is unaffected 224 by jitter. 226 It should be possible to use implementation defined labels for which 227 the Client MUST use the label on the http resource URL to send the 228 request to the corresponding proxy entry in the WPD. If the label 229 does not have a matching entry, the Client MUST use the default proxy 230 (dft). 232 [TBD] create a new IANA register for the label. 234 3.1.2. WebProtocol 236 A string containing the ALPN tag [RFC7301] describing the protocol 237 supported by the proxy to establish a session between the client and 238 proxy itself. This member MUST be present. 240 4. IANA Considerations 242 This specification creates a new IANA registry, in accordance with 243 the principles set out in [RFC5226], for the "label" Proxy objects' 244 parameter namespace describing the specific class of traffic or 245 optimisation feature provided by a proxy. 247 5. Security Considerations 249 See [I-D.nottingham-web-proxy-desc] for general security 250 considerations on the WPD usage. 252 It should be noted that the usage of multiple proxies, proposed in 253 this document, discloses the type of traffic requested and used by 254 the client (i.e. the end user). 256 6. Acknowledgments 258 The authors wish to thank Diego Lopez, Kevin Smith, Martin Nilsson, 259 Sanjay Mishra and Mathilde Cayla for their comments and useful 260 feedback. 262 7. Normative References 264 [I-D.ietf-httpbis-http2] 265 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 266 Protocol version 2", draft-ietf-httpbis-http2-14 (work in 267 progress), July 2014. 269 [I-D.nottingham-web-proxy-desc] 270 Nottingham, M., "The Web Proxy Description Format", draft- 271 nottingham-web-proxy-desc-01 (work in progress), October 272 2014. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 278 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 279 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 281 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 282 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 283 May 2008. 285 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 286 Uniform Resource Identifiers (URIs)", RFC 5785, April 287 2010. 289 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 290 "Transport Layer Security (TLS) Application-Layer Protocol 291 Negotiation Extension", RFC 7301, July 2014. 293 Authors' Addresses 295 Dan Druta 296 AT&T 298 Email: dd5826@att.com 300 Gus Bourg 301 AT&T 303 Email: gb3635@att.com 305 Salvatore Loreto 306 Ericsson 307 Hirsalantie 11 308 Jorvas 02420 309 Finland 311 Email: salvatore.loreto@ericsson.com