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