idnits 2.17.1 draft-kuehlewind-masque-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 (9 March 2020) is 1508 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-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-27 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 == Outdated reference: A later version (-11) exists of draft-olteanu-intarea-socks-6-08 == Outdated reference: A later version (-03) exists of draft-piraux-quic-tunnel-00 == Outdated reference: A later version (-08) exists of draft-schinazi-httpbis-transport-auth-01 -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). 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: 10 September 2020 T. Fossati 6 Arm 7 L. Pardue 8 Cloudflare 9 9 March 2020 11 Use Cases and Requirements for QUIC as a Substrate 12 draft-kuehlewind-masque-quic-substrate-00 14 Abstract 16 In situations where direct connectivity is not available or desired, 17 proxies in the network are used to forward and potentially translate 18 traffic. TCP is often used as a proxying or tunneling protocol. 19 QUIC is a new, emerging transport protocol and there is a similar 20 expectation that it too will be used as a substrate once it is widely 21 deployed. Using QUIC instead of TCP in existing scenarios will allow 22 proxying and tunneling services to maintain the benefits of QUIC 23 natively, without degrading the performance and security 24 characteristics. QUIC also opens up new opportunities for these 25 services to have lower latency and better multistreaming support. 26 This document summarizes current and future usage scenarios to derive 27 requirements for QUIC as a substrate and to provide additional 28 considerations for proxy signaling and control protocol as proposed 29 by MASQUE. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 10 September 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Obfuscation via Tunneling . . . . . . . . . . . . . . . . 3 67 2.2. Advanced Support of User Agents . . . . . . . . . . . . . 5 68 2.2.1. Security and Access Policy Enforcement . . . . . . . 6 69 2.3. Frontend Support for Load Balancing and Migration/ 70 Mobility . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.4. IoT Gateways . . . . . . . . . . . . . . . . . . . . . . 7 72 2.5. Multi-hop Chaining Usage . . . . . . . . . . . . . . . . 8 73 2.5.1. Considerations for Multiple Encryption . . . . . . . 9 74 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Review of Existing Approaches . . . . . . . . . . . . . . . . 10 76 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 6.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 QUIC is a new transport protocol that was developed with a focus on 85 optimizing HTTP traffic by supporting multiplexing without head-of- 86 line-blocking and integrating security directly into the transport. 87 This tight integration of security allows the transport and security 88 handshakes to be combined into a single round-trip exchange, after 89 which both the transport connection and authenticated encryption keys 90 are ready. 92 Based on the expectation that QUIC will be widely used for HTTP, it 93 follows that there will also be a need to enable the use of QUIC for 94 HTTP proxy services. 96 Beyond HTTP, however, QUIC provides a general-purpose transport 97 protocol that can be used for many other kinds of traffic, whenever 98 the features provided by QUIC (compared to existing options, like 99 TCP) are beneficial to the high-layer service. Specifically, QUIC's 100 ability to multiplex, encrypt data, and migrate between network paths 101 makes it ideal for solutions that needs to tunnel or proxy traffic. 103 Existing proxies that are not based on QUIC are often transparent. 104 That is, they do not require the cooperation of the ultimate 105 connection endpoints, and are often not visible to one or both of the 106 endpoints. If QUIC provides the basis for future tunneling and 107 proxying solutions, it is expected that this relationship will 108 change. At least one of the endpoints will be aware of the proxy and 109 explicitly coordinate with it. This allows client hosts to make 110 explicit decisions about the services they request from proxies (for 111 example, simple forwarding or more advance, e.g. performance- 112 optimizing, services), and to do so using a secure communication 113 channel between themselves and the proxy. 115 MASQUE [I-D.schinazi-masque] is a proposed framework that allows 116 running multiple network or application services inside one QUIC 117 connection to be forwarded to one or more target servers. The end- 118 to-end traffic between the client and the target server will be 119 tunnelled in a (outer) QUIC connection between the client and the 120 MASQUE server. This outer connection can also be used to securely 121 exchange additional signal or control information between the MASQUE 122 server and the client. 124 This document describes some of the use cases for using QUIC for 125 proxying and tunneling, as proposed by MASQUE, and explains the 126 protocol impacts and tradeoffs of such deployments. 128 2. Usage Scenarios 130 2.1. Obfuscation via Tunneling 132 Tunnels are used in many scenarios within the core of the network 133 from a client endpoint to a proxy middlepoint on the way towards the 134 server. In many cases, when the client explicitly decides to use the 135 support of a proxy in order to connect to a server, it does so 136 because a direct connection may be blocked or impaired. This can 137 either be the case in e.g. enterprise network where traffic is 138 firewalled and web traffic needs to be routed over an explicitly 139 provided HTTP proxy, or other reasons for blocking of certain 140 services e.g. due to censorship, data exfiltration protection, etc. 142 Tunneling through a proxy server can provide various benefits, 143 particularly when using a proxy that has a secure multiplexed channel 144 like QUIC: 146 * Obfuscating the traffic patterns of the traffic from the 147 perspective of observers between the client and the proxy. If the 148 content of connections to many end servers can be coalesced as one 149 flow, it becomes increasingly difficult for observers to detect 150 how many inner connections are being used, or what the content of 151 those connections are. 153 * Obfuscating the client's IP address from the perspective of 154 observers after the proxy, to the end server itself. This allows 155 the client to reduce information leaked about its actual location, 156 improving privacy. 158 * Obfuscating the end server's IP address from the observers between 159 the client and the proxy, which protects the identity of a private 160 server's address or circumvents local firewall rules. 162 In any of these tunneling scenarios, including those deployed today, 163 the client explicitly decides to make use of a proxy service while it 164 is usually fully transparent for the server, or even with the 165 intention to hide the client's identity from the server. This is 166 explicitly part of the design as these services are targeting an 167 impaired or otherwise constrained network setup. 169 Therefore, in this usage scenario the client knows the proxy's 170 address and explicitly selects to connect to the proxy in order to 171 instruct the proxy to forward its traffic to a specific target 172 server. Often the proxy is also preconfigured to "know" the client 173 and therefore the client needs to authenticate itself (e.g. using 174 HTTP Transport Authentication [I-D.schinazi-httpbis-transport-auth]). 175 But even without authentication, at a minimum, the client needs to 176 communicate directly with the proxy to provide the address of the 177 target server it wants to connect to, e.g. using HTTP CONNECT, and 178 potentially other information needed to inform the behaviour of the 179 proxy. 181 Usually the server is not aware of the proxy in the middle, so the 182 proxy needs to re-write the IP address of any traffic inside the 183 tunnel to ensure that the return traffic is also routed back to the 184 proxy. This is also often used to conceal the address/location of 185 the client to the server, e.g. to access local content that would not 186 be accessible by the client at its current location otherwise. 188 2.2. Advanced Support of User Agents 190 Depending on the traffic that is sent "over" the proxy, it is also 191 possible that the proxy can perform additional support services if 192 requested by the client. Today, Performance Enhancing Proxies (PEPs) 193 usually work transparently by either fully or partially terminating 194 the transport connection. For many of these support services the 195 termination is actually not needed and may even be problematic. 196 However, it is often the only, or at least easiest, solution if no 197 direct communication with the client is available. Enabling these 198 services based on an explicit tunnel setup between the client and the 199 proxy provides such a communication channel and makes it possible to 200 exchange information in a private and authenticated way. 202 It is expected that in-network functions are usually provided close 203 to the client e.g. hosted by the access network provider. Having 204 this direct relation between the endpoint and the network service is 205 also necessary in order to discover the service, as the assumption is 206 that a client knows how to address the proxy service and which 207 service is offered (besides forwarding). Such a setup is especially 208 valuable in access networks with challenging link environments such 209 as satellite or cellular networks. While end-to-end functions need 210 to be designed to handle all kind of network conditions, direct 211 support from the network can help to optimize for the specific 212 characteristics of the access network such as use of link-specific 213 congestion control or local repair mechanisms. 215 Further, if not provided by the server directly, a network support 216 function can also assist the client to adapt or prioritize the 217 traffic based on user preferences or device characteristics and 218 capabilities. Again, especially if the access network is 219 constrained, this can benefit both the network provider to save 220 resources and the client to receive the desired service quicker or 221 less impaired. Such a service could even be extended to include 222 caching or pre-fetching if the necessary trust relationship between 223 the client and the proxy exists. 225 Depending on the function requested, the proxy would need to access 226 or alter the traffic or context which is limiting due to the 227 necessary trust. Therefore alternative models should be pursued in 228 most cases. One such model is explicit exchange of information about 229 the current network state from the proxy to the client. This enables 230 some services to function by having the end-to-end peers act on or 231 inject the learned information from the proxy into the end-to-end 232 connection(s). Thus achieving the benefits without the need to 233 access the content or some of the traffic metadata directly. 234 Especially transport layer optimizations do not need access to the 235 actual user content. Network functions should generally minimize 236 dependencies to higher layer characteristics as those may change 237 frequently. 239 Similar to previous usage scenario, in this setup the client 240 explicitly selects the proxy and specifies the requested support 241 function. Often the server may not need to be aware of it but 242 depending on the optimization function, server cooperation could be 243 beneficial as well. Usually though, it is expected that even if the 244 server is aware, no direct information exchange is needed between the 245 proxy and the server. Instead, any needed information will be 246 provided "over" the client and thus, the client and the proxy need a 247 direct and secured communication channel in order to request and 248 configure a service and exchange or expose the needed information and 249 metadata. 251 2.2.1. Security and Access Policy Enforcement 253 Some deployment models may wish to enforce security or access 254 policies on traffic flowing between domains (physical, logical, 255 administrative, security etc.). To support this, endpoints 256 coordinate through a gateway that can require information about the 257 transport layer, application layer and application content. Policy 258 is generally configured out-of-band, either statically or through 259 some independent control plane. 261 In one use case, the enforcement function controls egress traffic; a 262 client connects to a proxy, typically inside the same domain, in 263 order to cross the domain boundary. In another use case, the 264 enforcement function controls ingress traffic; a client connects to a 265 proxy that controls access to the ultimate destination. This may be 266 deployed inside the target domain, near it, or further away as a part 267 of a third-party security service. Clients are usually remote and 268 diverse, and use connections that have crossed several other domains 269 (with or without tunnels). 271 Enforcement functions typically require some form of client 272 authentication such as username, password, or certificate. 273 Authentication is enforced at the earliest stage of communication. 275 Enforcement rules might require access to transport characteristics 276 of the ultimate endpoints (such as client source IP address). This 277 might change as traffic moves between domains, whether tunneling is 278 used or not. Therefore, it can be desirable to encapsulate original 279 information in form accessible to the enforcement function. 281 2.3. Frontend Support for Load Balancing and Migration/Mobility 283 Application service providers aiming to improve access flexibility 284 might use proxies in front of their services. 286 In one usage scenario the client communicates with a reverse proxy 287 that assists with access to and selection of the content requested. 288 This proxy that may or may not be under the authority of the service 289 provider. Today such reverse proxies terminate the connection, 290 including the security association, and as such appear as the 291 communication endpoint to the client. Terminating both transport and 292 security may be problematic if the proxy provider is not under the 293 direct authority of the actual service provider (e.g. a contracted 294 third party). 296 In another usage scenario the client communicates with a frontend 297 proxy that manages traffic steering to assist with load balancing or 298 migration for mobility support of server or client. This proxy is 299 more likely to be located close to the server and under the same 300 administrative domain, or at least has some trust relationship with 301 the application service provider. The server may have its own 302 communication channel with the proxy or tunnel endpoint in order to 303 provide data that is used for decision making. Meanwhile, the client 304 is usually not aware of any specifics of the setup behind the 305 substrate endpoint. However, improving visibility may benefit future 306 explicit tunneling or proxying approaches. 308 2.4. IoT Gateways 310 A number of IoT devices are connected via a low-power wireless 311 network (e.g., a Bluetooth LE piconet) and need to talk to their 312 parent cloud service to provide sensor readings or receive firmware 313 updates. 315 When end-to-end IP connectivity is not possible or desirable for at 316 least some of the devices, one or more IP capable nodes in the 317 piconet can be designated as ad-hoc gateways to forward sensor 318 traffic to the cloud and vice-versa. In other scenarios, a less 319 constrained node - sometimes called a "smart gateway" - can provide 320 the forwarding role permanently. In both cases, the gateway node 321 routes messages based on client's session identifiers, which need to 322 be unique among all the active participants so that the gateway can 323 route unambiguously. The access network attachment is expected to 324 change over time but the end-to-end communication (especially the 325 security association) needs to persist for as long as possible. 327 A strong requirement for these deployments is privacy: data on the 328 public Internet (i.e., from the gateway to the cloud service) needs 329 to be made as opaque as possible to passive observers, possibly 330 hiding the natural traffic patterns associated with the sensor 331 network. A mechanism to provide discovery of the proxy node to the 332 rest of the piconet is also typically necessary. 334 Today, the above requirements can be met by composing an end-to-end 335 secure channel (e.g., based on DTLS sessions with client-chosen 336 connection IDs [I-D.ietf-tls-dtls-connection-id] or application layer 337 TLS [I-D.friel-tls-atls] from the sensors to the cloud together with 338 a multiplexed secure tunnel (e.g., using HTTP/2 WebSockets [RFC8441], 339 or a proprietary shim) from the gateway to the cloud. In the future, 340 a more homogeneous solution could be provided by QUIC for both the 341 end-to-end and tunneling services, thus simplifying code dependencies 342 on the gateway nodes. 344 2.5. Multi-hop Chaining Usage 346 Providing a generic approach to use QUIC as a substrate also enables 347 the combination of multiple of the above use cases. For example, 348 employing multiple obfuscating proxies in sequence, where the 349 communication with each proxy is individually secured, can enable 350 onion-like layered security. Each proxy will only know the address 351 of the prior hop and after itself, similar as provided by onion 352 routing in Tor project [TOR]. 354 Further, it would also be possible to chain proxies for different 355 reasons. A client may select proxying support from its access 356 network, while a web service provider may utilize a front-end load 357 balancing proxy to provide end-to-end secure communication with the 358 applications components servers. Here the proxy and the load 359 balancer have different tasks. The access network proxy optimizes 360 the aggregated data transport. The load balancer needs to route 361 different set of end-to-end protected data that it aggregates. A 362 third example would be multiple proxies to cooperate and maybe 363 exchange measurement information in order to optimize the QUIC 364 connection over a specific segment. 366 The above examples indicates that a solution likely have to consider 367 how to establish a security model so that endpoints can selectively 368 choose what connection related information to share with the 369 different proxy entities. The possible efficiency should also be 370 consider and multiple layers of encapsulation should be avoided when 371 the security model allows for it. 373 2.5.1. Considerations for Multiple Encryption 375 Using QUIC in a multi-hop fashion will generally cause all user data 376 to be encrypted multiple times, once for each hop. There are two 377 main reasons to encrypt data multiple times in a multi-hop network: 379 1. To ensure that no hop can see both the connection metadata of the 380 client and the server (thus obfuscating IP addresses and other 381 related data that is visible in cleartext in the transport 382 protocol headers). 384 2. To prevent an attacker from being able to correlate data between 385 different hops to identify a particular flow of data as it passes 386 through multiple hops. 388 However, multiple layers of encryption can have a noticeable impact 389 on the end-to-end latency of data. When a Tor-like approach is used, 390 each piece of user data will be encrypted N times, where N is the 391 number of hops. Devices such as IoT devices that may not have 392 support for cryptographic optimizations, or are constrained in terms 393 of processing or power usage, could be significantly slowed down due 394 to the extra overhead or not be able to process such traffic at all. 396 Since QUIC is an encrypted transport, the content of all packets 397 after the handshake is opaque to any attacker. Short-header packets, 398 particularly those that have zero-length Connection IDs, only send 399 encrypted fields. Thus, for all packets beyond the QUIC handshake, 400 encrypting packets multiple times through a multi-hop proxy primarily 401 achieves benefit 2) described above, since benefit 1) is already 402 achieved by QUIC being forwarded without re-encryption. If a 403 deployment is more concerned with benefit 1) than benefit 2), it 404 might be preferable to use a solution that forwards QUIC packets 405 without re-encrypting once QUIC handshakes are complete. 407 3. Requirements 409 To use QUIC as a substrate, it could be beneficial if unreliable 410 transmission is supported as well as having a way to potentially 411 influence or disable congestion control if the inner tunnel traffic 412 is known to be congestion controlled. 414 Communication between the client and proxy is more likely to be 415 realized as a separate protocol on top of QUIC or HTTP as e.g. 416 proposed by MASQUE. However, a QUIC extensibility mechanism could be 417 used to indicate to the receiver that QUIC is used as a substrate and 418 potentially additional information about which protocol is used for 419 communication between these entities. A similar mechanism could be 420 realized in HTTP instead. In both cases it is important that the 421 QUIC connection cannot be identified as a substrate by an observer on 422 the path. 424 With QUIC, the use of proxying functions cannot be done 425 transparently. Instead, proxies needs to be explicitly discoverable. 426 The simplest form of such discovery could include pre-configuration 427 or via out-of-band signaling. The proxy could also be discovered 428 through advertisement when a client is connected to a network (for 429 example, the Dynamic Host Configuration Protocol). Alternatively, 430 the client could obtain a white-listed proxy address when making 431 first contact with the server (CNAME/IPaddress). In both cases the 432 proxy needs to have a routable address and name. 434 4. Review of Existing Approaches 436 As already mentioned, HTTP proxies are usually realized by use of the 437 HTTP CONNECT method (see Section 4.3.6 of [RFC7231]). This is 438 commonly used to establish a tunnelled TLS session over a TCP 439 connection to an origin server identified by a request-target. In 440 HTTP/1.1, the entire client-to-proxy HTTP connection is converted 441 into a tunnel. In HTTP/2 (see Section 8.3 of [RFC7540]) and HTTP/3 442 (see Section 4.2 of [I-D.ietf-quic-http]), a single stream gets 443 dedicated to a tunnel. Conventional HTTP CONNECT is only specified 444 to open a TCP connection between proxy and server, even in HTTP/3, so 445 it enables forwarding based on a split TCP-TCP or QUIC-TCP connection 446 but unaltered payload traffic. There is no currently-specified HTTP 447 mechanism to instruct a proxy to create a UDP or IP association to 448 the server. [HINT] contains a deeper analysis of the problem space 449 and potential solutions. Of those explored, a good candidate for 450 MASQUE is the Extended CONNECT method [RFC8441], accepts a 451 ":protocol" pseudo-header that could be used to express an 452 alternative protocol between proxy and server. 454 An explicit proxy control protocol is the SOCKS protocol [RFC1928]. 455 Version 6 is currently under standardization 456 [I-D.olteanu-intarea-socks-6] which provides fast connection 457 establishment. Use of QUIC could even further improve that. 458 However, SOCKS provides support to establish forwarding sockets using 459 a new connection (with a different port). This behavior is visible 460 to the path and not necessary if the underlying transport is 461 multiplexing capable, as QUIC is. A SOCKS-like protocol could still 462 be used for negotiation and authentication between the client and the 463 proxy. An example proposal for this approach is 464 [I-D.piraux-quic-tunnel]. 466 In that sense the TCP PROXY protocol could also be seen as a light- 467 weight version of SOCKS (see 468 https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). This 469 protocol was never standardized and only provides a limited set of 470 functionality. 472 5. Contributors 474 Magnus Westerlund has contributed two paragraphs on combining 475 proxies. 477 Tommy Pauly has contributed text on multiple layers of encryption, 478 and other edits to the use cases. 480 6. References 482 6.1. Normative References 484 [I-D.schinazi-masque] 485 Schinazi, D., "The MASQUE Protocol", Work in Progress, 486 Internet-Draft, draft-schinazi-masque-02, 8 January 2020, 487 . 490 6.2. Informative References 492 [HINT] Pardue, L., "HTTP-initiated Network Tunnelling (HiNT)", 493 Work in Progress, Internet-Draft, draft-pardue-httpbis- 494 http-network-tunnelling-01, 18 October 2018, 495 . 498 [I-D.friel-tls-atls] 499 Friel, O., Barnes, R., Pritikin, M., Tschofenig, H., and 500 M. Baugher, "Application-Layer TLS", Work in Progress, 501 Internet-Draft, draft-friel-tls-atls-04, 4 November 2019, 502 . 505 [I-D.ietf-quic-http] 506 Bishop, M., "Hypertext Transfer Protocol Version 3 507 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 508 quic-http-27, 21 February 2020, . 511 [I-D.ietf-tls-dtls-connection-id] 512 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 513 Identifiers for DTLS 1.2", Work in Progress, Internet- 514 Draft, draft-ietf-tls-dtls-connection-id-07, 21 October 515 2019, . 518 [I-D.olteanu-intarea-socks-6] 519 Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", 520 Work in Progress, Internet-Draft, draft-olteanu-intarea- 521 socks-6-08, 4 November 2019, . 524 [I-D.piraux-quic-tunnel] 525 Piraux, M. and O. Bonaventure, "Tunneling Internet 526 protocols inside QUIC", Work in Progress, Internet-Draft, 527 draft-piraux-quic-tunnel-00, 4 November 2019, 528 . 531 [I-D.schinazi-httpbis-transport-auth] 532 Schinazi, D., "HTTP Transport Authentication", Work in 533 Progress, Internet-Draft, draft-schinazi-httpbis- 534 transport-auth-01, 8 January 2020, . 538 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 539 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 540 DOI 10.17487/RFC1928, March 1996, 541 . 543 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 544 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 545 DOI 10.17487/RFC7231, June 2014, 546 . 548 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 549 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 550 DOI 10.17487/RFC7540, May 2015, 551 . 553 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 554 RFC 8441, DOI 10.17487/RFC8441, September 2018, 555 . 557 [TOR] "TOR Project", 5 June 2019, . 559 Authors' Addresses 561 Mirja Kuehlewind 562 Ericsson 564 Email: mirja.kuehlewind@ericsson.com 565 Zaheduzzaman Sarker 566 Ericsson 568 Email: zaheduzzaman.sarker@ericsson.com 570 Thomas Fossati 571 Arm 573 Email: thomas.fossati@arm.com 575 Lucas Pardue 576 Cloudflare 578 Email: lucaspardue.24.7@gmail.com