idnits 2.17.1 draft-kuehlewind-quic-substrate-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 07, 2019) is 1756 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-friel-tls-atls-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft Z. Sarker 4 Intended status: Informational Ericsson 5 Expires: December 9, 2019 T. Fossati 6 Arm 7 June 07, 2019 9 Use Cases and Requirements for QUIC as a Substrate 10 draft-kuehlewind-quic-substrate-00 12 Abstract 14 TCP is often used as a proxying or tunneling protocol. QUIC is a 15 new, emerging transport protocol and there is a similar expectation 16 that it too will be used as a substrate once it is widely deployed. 17 Using QUIC instead of TCP in existing scenarios will allow proxying 18 and tunneling services to maintain the benefits of QUIC natively, 19 without degrading the performance and security characteristics. QUIC 20 also opens up new opportunities for these services to have lower 21 latency and better multistreaming support. This document summarizes 22 current and future usage scenarios to derive requirements for QUIC 23 and to provide additional protocol considerations. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 9, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 QUIC is a new transport protocol that was initially developed as a 60 way to optimize HTTP traffic by supporting multiplexing without head- 61 of-line-blocking and integrating security directly into the 62 transport. This tight integration of security allows the transport 63 and security handshakes to be combined into a single round-trip 64 exchange, after which both the transport connection and authenticated 65 encryption keys are ready. 67 Based on the expectation that QUIC will be widely used for HTTP, it 68 follows that there will also be a need to enable the use of QUIC for 69 HTTP proxy services. 71 Beyond HTTP, however, QUIC provides a general-purpose transport 72 protocol that can be used for many other kinds of traffic, whenever 73 the features provided by QUIC (compared to existing options, like 74 TCP) are beneficial to the high-layer service. Specifically, QUIC's 75 ability to multiplex, encrypt data, and migrate between network paths 76 makes it ideal for solutions that need to tunnel or proxy traffic. 78 Existing proxies that are not based on QUIC are often transparent. 79 That is, they do not require the cooperation of the ultimate 80 connection endpoints, and are often not visible to one or both of the 81 endpoints. If QUIC provides the basis for future tunneling and 82 proxying solutions, it is expected that this relationship will 83 change. At least one of the endpoints will be aware of the proxy and 84 explicitly coordinate with it. This allows client hosts to make 85 explicit decisions about the services they request from proxies (for 86 example, simple forward or more advance performance-optimizing 87 services), and to do so using a secure communication channel between 88 themselves and the proxy. 90 This document describes some of the use cases for using QUIC for 91 proxying and tunneling, and explains the protocol impacts and 92 tradeoffs of such deployments. 94 2. Usage Scenarios 96 2.1. Obfuscation via Tunneling 98 Tunnels are used in many scenarios within the core of the network as 99 well as from a client endpoint to a proxy middlepoint on the way 100 towards the server. In many cases, when the client explicitly 101 decides to use the support of a proxy in order to connect to a 102 server, it does so because a direct connection may be blocked or 103 impaired. This can either be the case in e.g. enterprise network 104 where traffic is firewalled and web traffic needs to be routed over 105 an explicitly provided HTTP proxy, or other reasons for blocking of 106 certain services e.g. due to censorship, data exfiltration 107 protection, etc. 109 In this usage scenario the client knows the proxy's address and 110 explicitly selects to connect to the proxy in order to instruct the 111 proxy to forward its traffic to a specific server. At a minimum, the 112 client needs to communicate directly with the proxy to provide the 113 address of the server it wants to connect to, e.g. using HTTP 114 CONNECT. 116 Tunneling through a proxy server can provide various benefits, 117 particularly when using a proxy that has a secure multiplexed channel 118 like QUIC: 120 o Obfuscating the end server's IP address from the observers between 121 the client and the proxy, which protects the identity of a private 122 server's address or circumvents local firewall rules. 124 o Obfuscating the client's IP address from the perspective of 125 observers after the proxy, to the end server itself. This allows 126 the client to select content as if it has the address or location 127 of the proxy. 129 o Obfuscating the traffic patterns of the traffic from the 130 perspective of observers between the client and the proxy. If the 131 content of connections to many end servers can be coalesced as one 132 flow, it becomes increasingly difficult for observers to detect 133 how many inner connections are being used, or what the content of 134 those connections are. 136 Such a setup can also be realized with the use of an outer tunnel 137 which would additionally obfuscate the content of the tunnel traffic 138 to any observer between the client and the proxy. Usually the server 139 is not aware of the proxy in the middle, so the proxy needs to re- 140 write the IP address of any traffic inside the tunnel to ensure that 141 the return traffic is also routed back to the proxy. This is also 142 often used to conceal the address/location of the client to the 143 server, e.g. to access local content that would not be accessible by 144 the client at its current location otherwise. 146 In any of these tunneling scenarios, including those deployed today, 147 the client explicitly decides to make use of a proxy service while 148 being fully transparent for the server, or even with the intention to 149 hide the client's identity from the server. This is explicitly part 150 of the design as these services are targeting an impaired or 151 otherwise constrained network setup. Therefore, an explicit 152 communication channel between client and proxy is needed to at least 153 communicate the information about the target server's address, and 154 potentially other information needed to inform the behaviour of the 155 proxy. 157 2.2. Advanced Support of User Agents 159 Depending on the traffic that is sent "over" the proxy, it is also 160 possible that the proxy can perform additional support services if 161 requested by the client. Today, Performance Enhancing Proxies (PEPs) 162 usually work transparently by either fully or partially terminating 163 the transport connection or even intercepting the end-to-end 164 encryption. For many of these support services termination is 165 actually not needed and may even be problematic. However, it is 166 often the only, or at least easiest, solution if no direct 167 communication with the client is available. Enabling these services 168 based on an explicit tunnel setup between the client and the proxy 169 provides such a communication channel and makes it possible to 170 exchange information in a private and authenticated way. 172 It is expected that in-network functions are usually provided close 173 to the client e.g. hosted by the access network provider. Having 174 this direct relation between the endpoint and the network service is 175 also necessary in order to discover the service, as the assumption is 176 that a client knows how to address the proxy service and which 177 service is offered (besides forwarding). Such a setup is especially 178 valuable in access networks with challenging link environments such 179 as satellite or cellular networks. While end-to-end functions need 180 to be designed to handle all kind of network conditions, direct 181 support from the network can help to optimize for the specific 182 characteristics of the access network such as use of link-specific 183 congestion control or local repair mechanisms. 185 Further, if not provided by the server directly, a network support 186 function can also assist the client to adapt the traffic based on 187 device characteristics and capabilities or user preferences. Again, 188 especially if the access network is constrained, this can benefit 189 both the network provider to save resources and the client to receive 190 the desired service quicker or less impaired. Such a service could 191 even be extended to include caching or pre-fetching depending on the 192 trust relationship between the client and the proxy. 194 Depending on the function provided, the proxy may need to access or 195 alter the traffic or content. Alternatively, if the information 196 provided by the client or proxy can be trusted, it might in some 197 cases also be possible for each of the entities to act based on this 198 information without the need to access the content or some of the 199 traffic metadata directly. Especially transport layer optimizations 200 do not need access to the actual user content. Network functions 201 should generally minimize dependencies to higher layer 202 characteristics as those may change frequently. 204 Similar as in the previous usage scenario, in this setup the client 205 explicitly selects the proxy and specifies the requested support 206 function. Often the server may not need to be aware of it, however, 207 depending on the optimization function, server cooperation could be 208 beneficial as well. However, the client and the proxy need a direct 209 and secured communication channel in order to request and configure a 210 service and exchange or expose the needed information and metadata. 212 2.3. Frontend Support for Load Balancing and Migration/Mobility 214 In this usage scenario the application service provider aims for 215 flexibility in server selection, therefore the client communicates 216 with a reverse proxy that may or may not be under the authority of 217 the service provider. Such a proxy assists the client to access and 218 select the content requested. Today reverse proxies terminate the 219 connection, including the security association, and as such appear as 220 the communication endpoint to the client. Terminating not only the 221 transport connection but also the security association is especially 222 problematic if the proxy provider is not under the direct authority 223 of the actual service provider but a contracted third party. 225 A similar setup may be used to perform load balancing or migration 226 for mobility support, of both the server or client, where a frontend 227 proxy can redirect the traffic to a different backend server. Today 228 this is realized fully transparent to the client and the client is 229 not aware of the network setup behind the proxy. However, such a 230 setup may as well benefit in future from an explicit tunneling or 231 proxying approach. 233 In this usage scenario the client interact with a proxy that is 234 located close to the server and potentially even under the same 235 administrative domain or at least has some trust relationship with 236 the application service provider. The server is aware of this setup 237 and may have an own communication channel with the proxy or tunnel 238 endpoint as well, in order to advise it about server selection. 239 However, the client is usually not aware of any specifics about the 240 setup behind the substrate endpoint. 242 2.4. IoT Gateways 244 A number of IoT devices are connected via a low-power wireless 245 network (e.g., a Bluetooth LE piconet) and need to talk to their 246 parent cloud service to provide sensor readings or receive firmware 247 updates. When end-to-end IP connectivity is not possible or 248 desirable for at least some of the devices, one or more IP capable 249 nodes in the piconet can be designated as ad-hoc gateways to forward 250 sensor traffic to the cloud and vice-versa. In other scenarios, a 251 less constrained node - sometimes called a "smart gateway" - can 252 assume the forwarding role permanently. In both cases, the gateway 253 node routes messages based on client's session identifiers, which 254 need to be unique among all the active participants so that the 255 gateway can route unambiguously. The access network attachment is 256 expected to change over time but the end-to-end communication 257 (especially the security association) needs to persist for as long as 258 possible. A strong requirement for these deployments is privacy: 259 data on the public Internet (i.e., from the gateway to the cloud 260 service) needs to be made as opaque as possible to passive observers, 261 possibly hiding the natural traffic patterns associated with the 262 sensor network. A mechanism to provide discovery of the proxy node 263 to the rest of the piconet is also typically necessary. 265 Today, the above requirements can be met by composing an end-to-end 266 secure channel (e.g., based on DTLS sessions with client-chosen 267 connection IDs [I-D.ietf-tls-dtls-connection-id] or application layer 268 TLS [I-D.friel-tls-atls] from the sensors to the cloud together with 269 a multiplexed secure tunnel (e.g., using HTTP/2 Websockets [RFC8441], 270 or a proprietary shim) from the gateway to the cloud. In the future, 271 a more homogeneous solution could be provided by QUIC 272 [I-D.ietf-quic-transport] for both the end-to-end and tunneling 273 services, thus simplifying code dependencies on the gateway nodes. 275 2.5. Multi-hop Chaining Usage 277 Providing a generic approach to use QUIC as a substrate also enables 278 the combination of multiples of the above use cases. For example, 279 employing multiple obfuscating proxies in sequence, where the 280 communication with each proxy is individually secured, can enable 281 onion-like layered security. Each proxy will only know the address 282 of the prior hop and after itself, similar as provided by onion 283 routing in Tor project [TOR]. 285 Further it would also be possible to chain proxies for different 286 reasons. A client may select proxying support from its access 287 network, while a web service provider may utilize a front-end load 288 balancing proxy to provide end-to-end secure communication with the 289 applications components servers. Here the proxy and the load 290 balancer have different tasks. The access network proxy optimizes 291 the aggregated data transport. The load balancer needs to route 292 different set of end-to-end protected data that it aggregates. A 293 third example would be multiple proxies to cooperate and maybe 294 exchange measurement information in order to optimize the QUIC 295 connection over a specific segment. 297 The above examples indicates that a solution likely have to consider 298 how to establish a security model so that endpoints can selectively 299 choose what connection related information to share with the 300 different proxy entities. The possible efficiency should also be 301 consider and multiple layers of encapsulation should be avoided when 302 the security model allows for it. 304 3. Requirements 306 To use QUIC as a substrate, it could be beneficial if unreliable 307 transmission is supported as well as having a way to potentially 308 influence or disable congestion control if the inner tunnel traffic 309 is known to be congestion controlled. 311 Communication between the client and proxy is more likely to be 312 realized as a separate protocol on top of QUIC or HTTP. However, a 313 QUIC extensibility mechanism could be used to indicate to the 314 receiver that QUIC is used as a substrate and potentially additional 315 information about which protocol is used for communication between 316 these entities. A similar mechanism could be realized in HTTP 317 instead. In both cases it is important that the QUIC connection 318 cannot be identified as a substrate by an observer on the path. 320 As existing proxying functions cannot be perform transparently the 321 QUIC is used, the discovery of a proxy on path need to be explicit. 322 In the simplest form of such discovery could include pre- 323 configuration or via out-of-band signaling. The proxy can advertise 324 it's existence when a client is connected to a network (DHCP), the 325 client can get a white-listed proxy address when making first contact 326 with the server (CNAME/IPaddress). In both cases the proxy need to 327 have a routable address and name. 329 4. Contributors 331 Magnus Westerlund have contributed two paragraphs on combining 332 proxies. 334 5. Acknowledgments 336 Thanks to Tommy Pauly, and Lucas Pardue for contributing thoughts and 337 comments on these use cases, as well as text edits! 339 6. Informative References 341 [I-D.friel-tls-atls] 342 Friel, O., Barnes, R., Pritikin, M., Tschofenig, H., and 343 M. Baugher, "Application-Layer TLS", draft-friel-tls- 344 atls-02 (work in progress), March 2019. 346 [I-D.ietf-quic-transport] 347 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 348 and Secure Transport", draft-ietf-quic-transport-20 (work 349 in progress), April 2019. 351 [I-D.ietf-tls-dtls-connection-id] 352 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 353 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 354 id-05 (work in progress), May 2019. 356 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 357 RFC 8441, DOI 10.17487/RFC8441, September 2018, 358 . 360 [TOR] "TOR Project", June 2019, . 362 Authors' Addresses 364 Mirja Kuehlewind 365 Ericsson 367 Email: mirja.kuehlewind@ericsson.com 369 Zaheduzzaman Sarker 370 Ericsson 372 Email: zaheduzzaman.sarker@ericsson.com 373 Thomas Fossati 374 Arm 376 Email: thomas.fossati@arm.com