idnits 2.17.1 draft-pauly-masque-quic-proxy-03.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 date (5 March 2022) is 781 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-07 == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-06 == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Experimental D. Schinazi 5 Expires: 6 September 2022 Google LLC 6 5 March 2022 8 QUIC-Aware Proxying Using HTTP 9 draft-pauly-masque-quic-proxy-03 11 Abstract 13 This document defines an extension to UDP Proxying over HTTP that 14 adds specific optimizations for proxied QUIC connections. This 15 extension allows a proxy to reuse UDP 4-tuples for multiple 16 connections. It also defines a mode of proxying in which QUIC short 17 header packets can be forwarded using an HTTP/3 proxy rather than 18 being re-encapsulated and re-encrypted. 20 Discussion Venues 22 This note is to be removed before publishing as an RFC. 24 Source for this draft and an issue tracker can be found at 25 https://github.com/tfpauly/quic-proxy (https://github.com/tfpauly/ 26 quic-proxy). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 6 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Required Proxy State . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Stream Mapping . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Target Connection ID Mapping . . . . . . . . . . . . . . 5 67 2.3. Client Connection ID Mappings . . . . . . . . . . . . . . 6 68 2.4. Detecting Connection ID Conflicts . . . . . . . . . . . . 6 69 3. Connection ID Capsule Types . . . . . . . . . . . . . . . . . 7 70 4. Client Request Behavior . . . . . . . . . . . . . . . . . . . 8 71 4.1. New Proxied Connection Setup . . . . . . . . . . . . . . 9 72 4.2. Adding New Client Connection IDs . . . . . . . . . . . . 9 73 4.3. Sending With Forwarded Mode . . . . . . . . . . . . . . . 9 74 4.4. Receiving With Forwarded Mode . . . . . . . . . . . . . . 10 75 5. Proxy Response Behavior . . . . . . . . . . . . . . . . . . . 11 76 5.1. Removing Mapping State . . . . . . . . . . . . . . . . . 12 77 5.2. Handling Connection Migration . . . . . . . . . . . . . . 13 78 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. Interactions with Load Balancers . . . . . . . . . . . . . . 15 80 8. Packet Size Considerations . . . . . . . . . . . . . . . . . 15 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . 16 84 10.2. Capsule Types . . . . . . . . . . . . . . . . . . . . . 17 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 11.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 UDP Proxying over HTTP [CONNECT-UDP] defines a way to send datagrams 94 through an HTTP proxy, where UDP is used to communicate between the 95 proxy and a target server. This can be used to proxy QUIC 96 connections [QUIC], since QUIC runs over UDP datagrams. 98 This document uses the term "target" to refer to the server that a 99 client is accessing via a proxy. This target may be an origin 100 hosting content, or another proxy. 102 This document extends the UDP proxying protocol to add signalling 103 about QUIC Connection IDs. QUIC Connection IDs are used to identify 104 QUIC connections in scenarios where there is not a strict 105 bidirectional mapping between one QUIC connection and one UDP 4-tuple 106 (pairs of IP addresses and ports). A proxy that is aware of 107 Connection IDs can reuse UDP 4-tuples between itself and a target for 108 multiple proxied QUIC connections. 110 Awareness of Connection IDs also allows a proxy to avoid re- 111 encapsulation and re-encryption of proxied QUIC packets once a 112 connection has been established. When this functionality is present, 113 the proxy can support two modes for handling QUIC packets: 115 1. Tunnelled, in which client <-> target QUIC packets are 116 encapsulated inside client <-> proxy QUIC packets. These packets 117 use multiple layers of encryption and congestion control. QUIC 118 long header packets MUST use this mode. QUIC short header 119 packets MAY use this mode. This is the default mode for UDP 120 proxying. 122 2. Forwarded, in which client <-> target QUIC packets are sent 123 directly over the client <-> proxy UDP socket. These packets are 124 only encrypted using the client-target keys, and use the client- 125 target congestion control. This mode MUST only be used for QUIC 126 short header packets. 128 Forwarding is defined as an optimization to reduce CPU processing on 129 clients and proxies, as well as avoiding MTU overhead for packets on 130 the wire. This makes it suitable for deployment situations that 131 otherwise relied on cleartext TCP proxies, which cannot support QUIC 132 and have inferior security and privacy properties. 134 The properties provided by the forwarding mode are as follows: 136 * All packets sent between the client and the target traverse 137 through the proxy device. 139 * The target server cannot know the IP address of the client solely 140 based on the proxied packets the target receives. 142 * Observers of either or both of the client <-> proxy link and the 143 proxy <-> target are not able to learn more about the client <-> 144 target communication than if no proxy was used. 146 It is not a goal of forwarding mode to prevent correlation between 147 client <-> proxy and the proxy <-> target packets from an entity that 148 can observe both links. See Section 9 for further discussion. 150 Both clients and proxies can unilaterally choose to disable forwarded 151 mode for any client <-> target connection. 153 The forwarding mode of this extension is only defined for HTTP/3 154 [HTTP3] and not any earlier versions of HTTP. The forwarding mode 155 also requires special handling in order to be compatible with 156 intermediaries or load balancers (see Section 7). 158 QUIC proxies only need to understand the Header Form bit, and the 159 connection ID fields from packets in client <-> target QUIC 160 connections. Since these fields are all in the QUIC invariants 161 header [INVARIANTS], QUIC proxies can proxy all versions of QUIC. 163 1.1. Conventions and Definitions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 1.2. Terminology 173 This document uses the following terms: 175 * Client: the client of all QUIC connections discussed in this 176 document. 178 * Proxy: the endpoint that responds to the UDP proxying request. 180 * Target: the server that a client is accessing via a proxy. 182 * Client <-> Proxy QUIC connection: a single QUIC connection 183 established from the client to the proxy. 185 * Socket: a UDP 4-tuple (local IP address, local UDP port, remote IP 186 address, remote UDP port). In some implementations, this is 187 referred to as a "connected" socket. 189 * Client-facing socket: the socket used to communicate between the 190 client and the proxy. 192 * Target-facing socket: the socket used to communicate between the 193 proxy and the target. 195 * Client Connection ID: a QUIC Connection ID that is chosen by the 196 client, and is used in the Destination Connection ID field of 197 packets from the target to the client. 199 * Target Connection ID: a QUIC Connection ID that is chosen by the 200 target, and is used in the Destination Connection ID field of 201 packets from the client to the target. 203 2. Required Proxy State 205 In the methods defined in this document, the proxy is aware of the 206 QUIC Connection IDs being used by proxied connections, along with the 207 sockets used to communicate with the client and the target. Tracking 208 Connection IDs in this way allows the proxy to reuse target-facing 209 sockets for multiple connections and support the forwarding mode of 210 proxying. 212 QUIC packets can be either tunnelled within an HTTP proxy connection 213 using HTTP Datagram frames [HTTP-DGRAM], or be forwarded directly 214 alongside an HTTP/3 proxy connection on the same set of IP addresses 215 and UDP ports. The use of forwarded mode requires the consent of 216 both the client and the proxy. 218 In order to correctly route QUIC packets in both tunnelled and 219 forwarded modes, the proxy needs to maintain mappings between several 220 items. There are three required unidirectional mappings, described 221 below. 223 2.1. Stream Mapping 225 Each pair of client <-> proxy QUIC connection and an HTTP stream MUST 226 be mapped to a single target-facing socket. 228 (Client <-> Proxy QUIC connection + Stream) 229 => Target-facing socket 231 Multiple streams can map to the same target-facing socket, but a 232 single stream cannot be mapped to multiple target-facing sockets. 234 This mapping guarantees that any HTTP Datagram using a stream sent 235 from the client to the proxy in tunnelled mode can be sent to the 236 correct target. 238 2.2. Target Connection ID Mapping 240 Each pair of Target Connection ID and client-facing socket MUST map 241 to a single target-facing socket. 243 (Client-facing socket + Target Connection ID) 244 => Target-facing socket 246 Multiple pairs of Connection IDs and sockets can map to the same 247 target-facing socket. 249 This mapping guarantees that any QUIC packet containing the Target 250 Connection ID sent from the client to the proxy in forwarded mode can 251 be sent to the correct target. Thus, a proxy that does not allow 252 forwarded mode does not need to maintain this mapping. 254 2.3. Client Connection ID Mappings 256 Each pair of Client Connection ID and target-facing socket MUST map 257 to a single stream on a single client <-> proxy QUIC connection. 258 Additionally, the pair of Client Connection ID and target-facing 259 socket MUST map to a single client-facing socket. 261 (Target-facing socket + Client Connection ID) 262 => (Client <-> Proxy QUIC connection + Stream) 263 (Target-facing socket + Client Connection ID) 264 => Client-facing socket 266 Multiple pairs of Connection IDs and sockets can map to the same 267 stream or client-facing socket. 269 These mappings guarantee that any QUIC packet sent from a target to 270 the proxy can be sent to the correct client, in either tunnelled or 271 forwarded mode. Note that this mapping becomes trivial if the proxy 272 always opens a new target-facing socket for every client request with 273 a unique stream. The mapping is critical for any case where target- 274 facing sockets are shared or reused. 276 2.4. Detecting Connection ID Conflicts 278 In order to be able to route packets correctly in both tunnelled and 279 forwarded mode, proxies check for conflicts before creating a new 280 mapping. If a conflict is detected, the proxy will reject the 281 client's request, as described in Section 5. 283 Two sockets conflict if and only if all members of the 4-tuple (local 284 IP address, local UDP port, remote IP address, and remote UDP port) 285 are identical. 287 Two Connection IDs conflict if and only if one Connection ID is equal 288 to or a prefix of another. For example, a zero-length Connection ID 289 conflicts with all connection IDs. This definition of a conflict 290 originates from the fact that QUIC short headers do not carry the 291 length of the Destination Connection ID field, and therefore if two 292 short headers with different Destination Connection IDs are received 293 on a shared socket, one being a prefix of the other prevents the 294 receiver from identifying which mapping this corresponds to. 296 The proxy treats two mappings as being in conflict when a conflict is 297 detected for all elements on the left side of the mapping diagrams 298 above. 300 Since very short Connection IDs are more likely to lead to conflicts, 301 particularly zero-length Connection IDs, a proxy MAY choose to reject 302 all requests for very short Connection IDs as conflicts, in 303 anticipation of future conflicts. Note that a request that doesn't 304 contain any Connection ID is equivalent to a request for a zero- 305 length Connection ID, and similarly would cause conflicts when 306 forwarding. 308 3. Connection ID Capsule Types 310 Proxy awareness of QUIC Connection IDs relies on using capsules 311 ([HTTP-DGRAM]) to signal the addition and removal of client and 312 Target Connection IDs. 314 Note that these capsules do not register contexts. QUIC packets are 315 encoded using HTTP Datagrams with the context ID set to zero as 316 defined in [CONNECT-UDP]. 318 The capsules used for QUIC-aware proxying allow a client to register 319 connection IDs with the proxy, and for the proxy to acknowledge or 320 reject the connection ID mappings. 322 The REGISTER_CLIENT_CID and REGISTER_TARGET_CID capsule types (see 323 Section 10.2 for the capsule type values) allow a client to inform 324 the proxy about a new Client Connection ID or a new Target Connection 325 ID, respectively. These capsule types MUST only be sent by a client. 327 The ACK_CLIENT_CID and ACK_TARGET_CID capsule types (see Section 10.2 328 for the capsule type values) are sent by the proxy to the client to 329 indicate that a mapping was successfully created for a registered 330 connection ID. These capsule types MUST only be sent by a proxy. 332 The CLOSE_CLIENT_CID and CLOSE_TARGET_CID capsule types (see 333 Section 10.2 for the capsule type values) allow either a client or a 334 proxy to remove a mapping for a connection ID. These capsule types 335 MAY be sent by either a client or the proxy. If a proxy sends a 336 CLOSE_CLIENT_CID without having sent an ACK_CLIENT_CID, or if a proxy 337 sends a CLOSE_TARGET_CID without having sent an ACK_TARGET_CID, it is 338 rejecting a Connection ID registration. 340 All Connection ID capsule types share the same format: 342 Connection ID Capsule { 343 Type (i) = 0xffe100..0xffe103, 344 Length (i), 345 Connection ID (0..2040), 346 } 348 Figure 1: Connection ID Capsule Format 350 Connection ID: A connection ID being registered or acknowledged, 351 which is between 0 and 255 bytes in length. The length of the 352 connection ID is implied by the length of the capsule. Note that 353 in QUICv1, the length of the Connection ID is limited to 20 bytes, 354 but QUIC invariants allow up to 255 bytes. 356 4. Client Request Behavior 358 A client initiates UDP proxying via a CONNECT request as defined in 359 [CONNECT-UDP]. Within its request, it includes the "Proxy-QUIC- 360 Forwarding" header to indicate whether or not the request should 361 support forwarding. If this header is not included, the client MUST 362 NOT send any connection ID capsules. 364 The "Proxy-QUIC-Forwarding" is an Item Structured Header [RFC8941]. 365 Its value MUST be a Boolean. Its ABNF is: 367 Proxy-QUIC-Forwarding = sf-boolean 369 If the client wants to enable QUIC packet forwarding for this 370 request, it sets the value to "?1". If it doesn't want to enable 371 forwarding, but instead only provide information about QUIC 372 Connection IDs for the purpose of allowing the proxy to share a 373 target-facing socket, it sets the value to "?0". 375 If the proxy supports QUIC-aware proxying, it will include the 376 "Proxy-QUIC-Forwarding" header in successful HTTP responses. The 377 value indicates whether or not the proxy supports forwarding. If the 378 client does not receive this header in responses, the client SHALL 379 assume that the proxy does not understand how to parse Connection ID 380 capsules, and MUST NOT send any Connection ID capsules. 382 The client sends a REGISTER_CLIENT_CID capsule whenever it advertises 383 a new Client Connection ID to the target, and a REGISTER_TARGET_CID 384 capsule when it has received a new Target Connection ID for the 385 target. Note that the initial REGISTER_CLIENT_CID capsule MAY be 386 sent prior to receiving an HTTP response from the proxy. 388 4.1. New Proxied Connection Setup 390 To initiate QUIC-aware proxying, the client sends a 391 REGISTER_CLIENT_CID capsule containing the initial Client Connection 392 ID that the client has advertised to the target. 394 If the mapping is created successfully, the client will receive a 395 ACK_CLIENT_CID capsule that contains the same connection ID that was 396 requested. 398 Since clients are always aware whether or not they are using a QUIC 399 proxy, clients are expected to cooperate with proxies in selecting 400 Client Connection IDs. A proxy detects a conflict when it is not 401 able to create a unique mapping using the Client Connection ID 402 (Section 2.4). It can reject requests that would cause a conflict 403 and indicate this to the client by replying with a CLOSE_CLIENT_CID 404 capsule. In order to avoid conflicts, clients SHOULD select Client 405 Connection IDs of at least 8 bytes in length with unpredictable 406 values. A client also SHOULD NOT select a Client Connection ID that 407 matches the ID used for the QUIC connection to the proxy, as this 408 inherently creates a conflict. 410 If the rejection indicated a conflict due to the Client Connection 411 ID, the client MUST select a new Connection ID before sending a new 412 request, and generate a new packet. For example, if a client is 413 sending a QUIC Initial packet and chooses a Connection ID that 414 conflicts with an existing mapping to the same target server, it will 415 need to generate a new QUIC Initial. 417 4.2. Adding New Client Connection IDs 419 Since QUIC connection IDs are chosen by the receiver, an endpoint 420 needs to communicate its chosen connection IDs to its peer before the 421 peer can start using them. In QUICv1, this is performed using the 422 NEW_CONNECTION_ID frame. 424 Prior to informing the target of a new chosen client connection ID, 425 the client MUST send a REGISTER_CLIENT_CID capsule request containing 426 the new Client Connection ID. 428 The client should only inform the target of the new Client Connection 429 ID once an ACK_CLIENT_CID capsule is received that contains the 430 echoed connection ID. 432 4.3. Sending With Forwarded Mode 434 Support for forwarding mode is determined by the "Proxy-QUIC- 435 Forwarding" header, see Section 5. 437 Once the client has learned the target server's Connection ID, such 438 as in the response to a QUIC Initial packet, it can send a 439 REGISTER_TARGET_CID capsule containing the Target Connection ID to 440 request the ability to forward packets. 442 The client MUST wait for an ACK_TARGET_CID capsule that contains the 443 echoed connection ID before using forwarded mode. 445 Prior to receiving the proxy server response, the client MUST send 446 short header packets tunnelled in HTTP Datagram frames. The client 447 MAY also choose to tunnel some short header packets even after 448 receiving the successful response. 450 If the Target Connection ID registration is rejected, for example 451 with a CLOSE_TARGET_CID capsule, it MUST NOT forward packets to the 452 requested Target Connection ID, but only use tunnelled mode. The 453 request might also be rejected if the proxy does not support 454 forwarded mode or has it disabled by policy. 456 QUIC long header packets MUST NOT be forwarded. These packets can 457 only be tunnelled within HTTP Datagram frames to avoid exposing 458 unnecessary connection metadata. 460 When forwarding, the client sends a QUIC packet with the target 461 server's Connection ID in the QUIC short header, using the same 462 socket between client and proxy that was used for the main QUIC 463 connection between client and proxy. 465 4.4. Receiving With Forwarded Mode 467 If the client has indicated support for forwarding with the "Proxy- 468 QUIC-Forwarding" header, the proxy MAY use forwarded mode for any 469 Client Connection ID for which it has a valid mapping. 471 Once a client has sent "Proxy-QUIC-Forwarding" with a value of "?1", 472 it MUST be prepared to receive forwarded short header packets on the 473 socket between itself and the proxy for any Client Connection ID that 474 it has registered with a REGISTER_CLIENT_CID capsule. The client 475 uses the Destination Connection ID field of the received packet to 476 determine if the packet was originated by the proxy, or merely 477 forwarded from the target. 479 5. Proxy Response Behavior 481 Upon receipt of a CONNECT request that includes the "Proxy-QUIC- 482 Forwarding" header, the proxy indicates to the client that it 483 supports QUIC-aware proxying by including a "Proxy-QUIC-Forwarding" 484 header in a successful response. If it supports QUIC packet 485 forwarding, it sets the value to "?1"; otherwise, it sets it to "?0". 487 Upon receipt of a REGISTER_CLIENT_CID or REGISTER_TARGET_CID capsule, 488 the proxy validates the registration, tries to establish the 489 appropriate mappings as described in Section 2. 491 The proxy MUST reply to each REGISTER_CLIENT_CID capsule with either 492 an ACK_CLIENT_CID or CLOSE_CLIENT_CID capsule containing the 493 Connection ID that was in the registration capsule. 495 Similarly, the proxy MUST reply to each REGISTER_TARGET_CID capsule 496 with either an ACK_TARGET_CID or CLOSE_TARGET_CID capsule containing 497 the Connection ID that was in the registration capsule. 499 The proxy then determines the target-facing socket to associate with 500 the client's request. This will generally involve performing a DNS 501 lookup for the target hostname in the CONNECT request, or finding an 502 existing target-facing socket to the authority. The target-facing 503 socket might already be open due to a previous request from this 504 client, or another. If the socket is not already created, the proxy 505 creates a new one. Proxies can choose to reuse target-facing sockets 506 across multiple UDP proxying requests, or have a unique target-facing 507 socket for every UDP proxying request. 509 If a proxy reuses target-facing sockets, it SHOULD store which 510 authorities (which could be a domain name or IP address literal) are 511 being accessed over a particular target-facing socket so it can avoid 512 performing a new DNS query and potentially choosing a different 513 target server IP address which could map to a different target 514 server. 516 Target-facing sockets MUST NOT be reused across QUIC and non-QUIC UDP 517 proxy requests, since it might not be possible to correctly 518 demultiplex or direct the traffic. Any packets received on a target- 519 facing socket used for proxying QUIC that does not correspond to a 520 known Connection ID MUST be dropped. 522 When the proxy recieves a REGISTER_CLIENT_CID capsule, it is 523 receiving a request to be able to route traffic back to the client 524 using that Connection ID. If the pair of this Client Connection ID 525 and the selected target-facing socket does not create a conflict, the 526 proxy creates the mapping and responds with a ACK_CLIENT_CID capsule. 528 After this point, any packets received by the proxy from the target- 529 facing socket that match the Client Connection ID can to be sent to 530 the client. The proxy MUST use tunnelled mode (HTTP Datagram frames) 531 for any long header packets. The proxy SHOULD forward directly to 532 the client for any matching short header packets if forwarding is 533 supported by the client, but the proxy MAY tunnel these packets in 534 HTTP Datagram frames instead. If the mapping would create a 535 conflict, the proxy responds with a CLOSE_CLIENT_CID capsule. 537 When the proxy recieves a REGISTER_TARGET_CID capsule, it is 538 receiving a request to allow the client to forward packets to the 539 target. If the pair of this Target Connection ID and the client- 540 facing socket on which the request was received does not create a 541 conflict, the proxy creates the mapping and responds with a 542 ACK_TARGET_CID capsule. Once the successful response is sent, the 543 proxy will forward any short header packets received on the client- 544 facing socket that use the Target Connection ID using the correct 545 target-facing socket. If the pair is not unique, the proxy responds 546 with a CLOSE_TARGET_CID capsule. If this occurs, traffic for that 547 Target Connection ID can only use tunnelled mode, not forwarded. 549 If the proxy does not support forwarded mode, or does not allow 550 forwarded mode for a particular client or authority by policy, it can 551 reject all REGISTER_TARGET_CID requests with CLOSE_TARGET_CID 552 capsule. 554 The proxy MUST only forward non-tunnelled packets from the client 555 that are QUIC short header packets (based on the Header Form bit) and 556 have mapped Target Connection IDs. Packets sent by the client that 557 are forwarded SHOULD be considered as activity for restarting QUIC's 558 Idle Timeout [QUIC]. 560 5.1. Removing Mapping State 562 For any connection ID for which the proxy has sent an 563 acknowledgement, any mappings for the connection ID last until either 564 endpoint sends a close capsule or the either side of the HTTP stream 565 closes. 567 A client that no longer wants a given Connection ID to be forwarded 568 by the proxy sends a CLOSE_CLIENT_CID or CLOSE_TARGET_CID capsule. 570 If a client's connection to the proxy is terminated for any reason, 571 all mappings associated with all requests are removed. 573 A proxy can close its target-facing socket once all UDP proxying 574 requests mapped to that socket have been removed. 576 5.2. Handling Connection Migration 578 If a proxy supports QUIC connection migration, it needs to ensure 579 that a migration event does not end up sending too many tunnelled or 580 proxied packets on a new path prior to path validation. 582 Specifically, the proxy MUST limit the number of packets that it will 583 proxy to an unvalidated client address to the size of an initial 584 congestion window. Proxies additionally SHOULD pace the rate at 585 which packets are sent over a new path to avoid creating 586 unintentional congestion on the new path. 588 6. Example 590 Consider a client that is establishing a new QUIC connection through 591 the proxy. It has selected a Client Connection ID of 0x31323334. In 592 order to inform a proxy of the new QUIC Client Connection ID, the 593 client also sends a REGISTER_CLIENT_CID capsule. 595 The client will also send the initial QUIC packet with the Long 596 Header form in an HTTP datagram. 598 Client Server 600 STREAM(44): HEADERS --------> 601 :method = CONNECT 602 :protocol = connect-udp 603 :scheme = https 604 :path = /target.example.com/443/ 605 :authority = proxy.example.org 606 proxy-quic-forwarding = ?1 607 capsule-protocol = ?1 609 STREAM(44): DATA --------> 610 Capsule Type = REGISTER_CLIENT_CID 611 Connection ID = 0x31323334 613 DATAGRAM --------> 614 Quarter Stream ID = 11 615 Context ID = 0 616 Payload = Encapsulated QUIC initial 618 <-------- STREAM(44): HEADERS 619 :status = 200 620 proxy-quic-forwarding = ?1 621 capsule-protocol = ?1 623 <-------- STREAM(44): DATA 624 Capsule Type = ACK_CLIENT_CID 625 Connection ID = 0x31323334 627 /* Wait for target server to respond to UDP packet. */ 629 <-------- DATAGRAM 630 Quarter Stream ID = 11 631 Context ID = 0 632 Payload = Encapsulated QUIC initial 634 Once the client learns which Connection ID has been selected by the 635 target server, it can send a new request to the proxy to establish a 636 mapping for forwarding. In this case, that ID is 0x61626364. The 637 client sends the following capsule: 639 STREAM(44): DATA --------> 640 Capsule Type = REGISTER_TARGET_CID 641 Connection ID = 0x61626364 643 <-------- STREAM(44): DATA 644 Capsule Type = ACK_TARGET_CID 645 Connection ID = 0x61626364 647 Upon receiving an ACK_TARGET_CID capsule, the client starts sending 648 Short Header packets with a Destination Connection ID of 0x61626364 649 directly to the proxy (not tunnelled), and these are forwarded 650 directly to the target by the proxy. Similarly, Short Header packets 651 from the target with a Destination Connection ID of 0x31323334 are 652 forwarded directly to the client. 654 7. Interactions with Load Balancers 656 Some QUIC servers are accessed using load balancers, as described in 657 [QUIC-LB]. These load balancers route packets to servers based on 658 the server's Connection ID. These Connection IDs are generated in a 659 way that can be coordinated between servers and their load balancers. 661 If a proxy that supports this extension is itself running behind a 662 load balancer, extra complexity arises once clients start using 663 forwarding mode and sending packets to the proxy that have 664 Destination Connection IDs that belong to the target servers, not the 665 proxy. If the load balancer is not aware of these Connection IDs, or 666 the Connection IDs conflict with other Connection IDs used by the 667 load balancer, packets can be routed incorrectly. 669 QUIC-aware proxies that use forwarding mode generally SHOULD NOT be 670 run behind load balancers; and if they are, they MUST coordinate 671 between the proxy and the load balancer to create mappings for 672 proxied Connection IDs prior to the proxy ACK_CLIENT_CID or 673 ACK_TARGET_CID capsules to clients. 675 QUIC-aware proxies that do not allow forwarding mode can function 676 unmodified behind QUIC load balancers. 678 8. Packet Size Considerations 680 Since Initial QUIC packets must be at least 1200 bytes in length, the 681 HTTP Datagram frames that are used for a QUIC-aware proxy MUST be 682 able to carry at least 1200 bytes. 684 Additionally, clients that connect to a proxy for purpose of proxying 685 QUIC SHOULD start their connection with a larger packet size than 686 1200 bytes, to account for the overhead of tunnelling an Initial QUIC 687 packet within an HTTP Datagram frame. If the client does not begin 688 with a larger packet size than 1200 bytes, it will need to perform 689 Path MTU (Maximum Transmission Unit) discovery to discover a larger 690 path size prior to sending any tunnelled Initial QUIC packets. 692 Once a proxied QUIC connections moves into forwarded mode, the client 693 SHOULD initiate Path MTU discovery to increase its end-to-end MTU. 695 9. Security Considerations 697 Proxies that support this extension SHOULD provide protections to 698 rate-limit or restrict clients from opening an excessive number of 699 proxied connections, so as to limit abuse or use of proxies to launch 700 Denial-of-Service attacks. 702 Sending QUIC packets by forwarding through a proxy without tunnelling 703 exposes some QUIC header metadata to onlookers, and can be used to 704 correlate packet flows if an attacker is able to see traffic on both 705 sides of the proxy. Tunnelled packets have similar inference 706 problems. An attacker on both sides of the proxy can use the size of 707 ingress and egress packets to correlate packets belonging to the same 708 connection. (Absent client-side padding, tunneled packets will 709 typically have a fixed amount of overhead that is removed before 710 their HTTP Datagram contents are written to the target.) 712 Since proxies that forward QUIC packets do not perform any 713 cryptographic integrity check, it is possible that these packets are 714 either malformed, replays, or otherwise malicious. This may result 715 in proxy targets rate limiting or decreasing the reputation of a 716 given proxy. 718 10. IANA Considerations 720 10.1. HTTP Header 722 This document registers the "Proxy-QUIC-Forwarding" header in the 723 "Permanent Message Header Field Names" 724 . 726 +-----------------------+----------+--------+---------------+ 727 | Header Field Name | Protocol | Status | Reference | 728 +-----------------------+----------+--------+---------------+ 729 | Proxy-QUIC-Forwarding | http | exp | This document | 730 +-----------------------+----------+--------+---------------+ 732 Figure 2: Registered HTTP Header 734 10.2. Capsule Types 736 This document registers six new values in the "HTTP Capsule Types" 737 registry established by [HTTP-DGRAM]. 739 +=====================+==========+===============+ 740 | Capule Type | Value | Specification | 741 +=====================+==========+===============+ 742 | REGISTER_CLIENT_CID | 0xffe100 | This Document | 743 +---------------------+----------+---------------+ 744 | REGISTER_TARGET_CID | 0xffe101 | This Document | 745 +---------------------+----------+---------------+ 746 | ACK_CLIENT_CID | 0xffe102 | This Document | 747 +---------------------+----------+---------------+ 748 | ACK_TARGET_CID | 0xffe103 | This Document | 749 +---------------------+----------+---------------+ 750 | CLOSE_CLIENT_CID | 0xffe104 | This Document | 751 +---------------------+----------+---------------+ 752 | CLOSE_TARGET_CID | 0xffe105 | This Document | 753 +---------------------+----------+---------------+ 755 Table 1: Registered Capsule Types 757 11. References 759 11.1. Normative References 761 [CONNECT-UDP] 762 Schinazi, D., "UDP Proxying Support for HTTP", Work in 763 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 764 07, 4 March 2022, . 767 [HTTP-DGRAM] 768 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 769 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 770 datagram-06, 4 March 2022, 771 . 774 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 775 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 776 quic-http-34, 2 February 2021, 777 . 780 [INVARIANTS] 781 Thomson, M., "Version-Independent Properties of QUIC", 782 RFC 8999, DOI 10.17487/RFC8999, May 2021, 783 . 785 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 786 Multiplexed and Secure Transport", RFC 9000, 787 DOI 10.17487/RFC9000, May 2021, 788 . 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 797 May 2017, . 799 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 800 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 801 . 803 11.2. Informative References 805 [QUIC-LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating 806 Routable QUIC Connection IDs", Work in Progress, Internet- 807 Draft, draft-ietf-quic-load-balancers-12, 11 February 808 2022, . 811 Acknowledgments 813 Thanks to Lucas Pardue, Ryan Hamilton, and Mirja Kuehlewind for their 814 inputs on this document. 816 Authors' Addresses 818 Tommy Pauly 819 Apple Inc. 820 One Apple Park Way 821 Cupertino, California 95014, 822 United States of America 823 Email: tpauly@apple.com 824 David Schinazi 825 Google LLC 826 1600 Amphitheatre Parkway 827 Mountain View, California 94043, 828 United States of America 829 Email: dschinazi.ietf@gmail.com