idnits 2.17.1 draft-pauly-masque-quic-proxy-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 : ---------------------------------------------------------------------------- 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 (13 April 2021) is 1108 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-03 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-33 == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: 15 October 2021 Google LLC 6 13 April 2021 8 QUIC-Aware Proxying Using CONNECT-UDP 9 draft-pauly-masque-quic-proxy-01 11 Abstract 13 This document defines an extension to the CONNECT-UDP HTTP method 14 that adds specific optimizations for QUIC connections that are 15 proxied. This extension allows a proxy to reuse UDP 4-tuples for 16 multiple connections. It also defines a mode of proxying in which 17 QUIC short header packets can be forwarded through the proxy rather 18 than 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 15 October 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified 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. Datagram Flow ID Mapping . . . . . . . . . . . . . . . . 5 66 2.2. Server Connection ID Mapping . . . . . . . . . . . . . . 6 67 2.3. Client Connection ID Mappings . . . . . . . . . . . . . . 6 68 2.4. Detecting Connection ID Conflicts . . . . . . . . . . . . 6 69 3. Connection ID Headers for CONNECT-UDP . . . . . . . . . . . . 7 70 4. Client Request Behavior . . . . . . . . . . . . . . . . . . . 8 71 4.1. New Proxied Connection Setup . . . . . . . . . . . . . . 8 72 4.2. Adding New Client Connection IDs . . . . . . . . . . . . 9 73 4.3. Sending With Forwarded Mode . . . . . . . . . . . . . . . 10 74 4.4. Receiving With Forwarded Mode . . . . . . . . . . . . . . 10 75 4.5. Opting Out of Forwarded Mode . . . . . . . . . . . . . . 11 76 5. Proxy Response Behavior . . . . . . . . . . . . . . . . . . . 11 77 5.1. Removing Mapping State . . . . . . . . . . . . . . . . . 13 78 5.2. Handling Connection Migration . . . . . . . . . . . . . . 13 79 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. Interactions with Load Balancers . . . . . . . . . . . . . . 14 81 8. Packet Size Considerations . . . . . . . . . . . . . . . . . 15 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 10.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 16 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 11.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The CONNECT-UDP HTTP method [CONNECT-UDP] defines a way to send 94 datagrams through an HTTP proxy, where UDP is used to communicate 95 between the proxy and a target server. This can be used to proxy 96 QUIC 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 CONNECT-UDP HTTP method 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 This extension is only defined for HTTP/3 [HTTP3] and not any earlier 111 versions. 113 Awareness of Connection IDs also allows a proxy to avoid re- 114 encapsulation and re-encryption of proxied QUIC packets once a 115 connection has been established. When this functionality is present, 116 the proxy can support two modes for handling QUIC packets: 118 1. Tunnelled, in which client <-> target QUIC packets are 119 encapsulated inside client <-> proxy QUIC packets. These packets 120 use multiple layers of encryption and congestion control. QUIC 121 long header packets MUST use this mode. QUIC short header 122 packets MAY use this mode. This is the default mode for CONNECT- 123 UDP. 125 2. Forwarded, in which client <-> target QUIC packets are sent 126 directly over the client <-> proxy UDP socket. These packets are 127 only encrypted using the client-target keys, and use the client- 128 target congestion control. This mode MUST only be used for QUIC 129 short header packets. 131 Forwarding is defined as an optimization to reduce CPU processing on 132 clients and proxies, as well as avoiding MTU overhead for packets on 133 the wire. This makes it suitable for deployment situations that 134 otherwise relied on cleartext TCP proxies, which cannot support QUIC 135 and have inferior security and privacy properties. 137 The properties provided by the forwarding mode are as follows: 139 * All packets sent between the client and the target traverse 140 through the proxy device. 142 * The target server cannot know the IP address of the client solely 143 based on the proxied packets the target receives. 145 * Observers of either or both of the client <-> proxy link and the 146 proxy <-> target are not able to learn more about the client <-> 147 target communication than if no proxy was used. 149 It is not a goal of forwarding mode to prevent correlation between 150 client <-> proxy and the proxy <-> target packets from an entity that 151 can observe both links. See Section 9 for further discussion. 153 Both clients and proxies can unilaterally choose to disable forwarded 154 mode for any client <-> target connection. 156 QUIC proxies only need to understand the Header Form bit, and the 157 connection ID fields from packets in client <-> target QUIC 158 connections. Since these fields are all in the QUIC invariants 159 header [INVARIANTS], QUIC proxies can proxy all versions of QUIC. 161 1.1. Conventions and Definitions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 1.2. Terminology 171 This document uses the following terms: 173 * Client: the client of all QUIC connections discussed in this 174 document. 176 * Proxy: the endpoint that responds to the CONNECT-UDP request. 178 * Target: the server that a client is accessing via a proxy. 180 * Client <-> Proxy QUIC connection: a single QUIC connection 181 established from the client to the proxy. 183 * Datagram flow ID: represents a flow of HTTP/3 DATAGRAMs [H3DGRAM] 184 specific to a single client <-> proxy QUIC connection. 186 * Socket: a UDP 4-tuple (local IP address, local UDP port, remote IP 187 address, remote UDP port). In some implementations, this is 188 referred to as a "connected" socket. 190 * Client-facing socket: the socket used to communicate between the 191 client and the proxy. 193 * Server-facing socket: the socket used to communicate between the 194 proxy and the target. 196 * Client Connection ID: a QUIC Connection ID that is chosen by the 197 client, and is used in the Destination Connection ID field of 198 packets from the target to the client. 200 * Server Connection ID: a QUIC Connection ID that is chosen by the 201 target, and is used in the Destination Connection ID field of 202 packets from the client to the target. 204 2. Required Proxy State 206 In the methods defined in this document, the proxy is aware of the 207 QUIC Connection IDs being used by proxied connections, along with the 208 sockets used to communicate with the client and the target. Tracking 209 Connection IDs in this way allows the proxy to reuse server-facing 210 sockets for multiple connections and support the forwarding mode of 211 proxying. 213 QUIC packets can be either tunnelled within an HTTP/3 proxy 214 connection using QUIC DATAGRAM frames [DGRAM], or be forwarded 215 directly alongside an HTTP/3 proxy connection on the same set of IP 216 addresses and UDP ports. The use of forwarded mode requires the 217 consent of both the client and the proxy. 219 In order to correctly route QUIC packets in both tunnelled and 220 forwarded modes, the proxy needs to maintain mappings between several 221 items. There are three required unidirectional mappings, described 222 below. 224 2.1. Datagram Flow ID Mapping 226 Each pair of client <-> proxy QUIC connection and datagram flow ID 227 MUST be mapped to a single server-facing socket. 229 (Client <-> Proxy QUIC connection + Datagram flow ID) 230 => Server-facing socket 232 Multiple datagram flow IDs can map to the same server-facing socket, 233 but a single datagram flow ID cannot be mapped to multiple server- 234 facing sockets. 236 This mapping guarantees that any QUIC packet using the datagram flow 237 ID sent from the client to the proxy in tunnelled mode can be sent to 238 the correct target. 240 2.2. Server Connection ID Mapping 242 Each pair of Server Connection ID and client-facing socket MUST map 243 to a single server-facing socket. 245 (Client-facing socket + Server Connection ID) 246 => Server-facing socket 248 Multiple pairs of Connection IDs and sockets can map to the same 249 server-facing socket. 251 This mapping guarantees that any QUIC packet containing the Server 252 Connection ID sent from the client to the proxy in forwarded mode can 253 be sent to the correct target. Thus, a proxy that does not allow 254 forwarded mode does not need to maintain this mapping. 256 2.3. Client Connection ID Mappings 258 Each pair of Client Connection ID and server-facing socket MUST map 259 to a single datagram flow ID on a single client <-> proxy QUIC 260 connection. Additionally, the pair of Client Connection ID and 261 server-facing socket MUST map to a single client-facing socket. 263 (Server-facing socket + Client Connection ID) 264 => (Client <-> Proxy QUIC connection + Datagram flow ID) 265 (Server-facing socket + Client Connection ID) 266 => Client-facing socket 268 Multiple pairs of Connection IDs and sockets can map to the same 269 datagram flow ID or client-facing socket. 271 These mappings guarantee that any QUIC packet sent from a target to 272 the proxy can be sent to the correct client, in either tunnelled or 273 forwarded mode. Note that this mapping becomes trivial if the proxy 274 always opens a new server-facing socket for every client request with 275 a unique datagram flow ID. The mapping is critical for any case 276 where server-facing sockets are shared or reused. 278 2.4. Detecting Connection ID Conflicts 280 In order to be able to route packets correctly in both tunnelled and 281 forwarded mode, proxies check for conflicts before creating a new 282 mapping. If a conflict is detected, the proxy will reject the 283 client's request, as described in Section 5. 285 Two sockets conflict if and only if all members of the 4-tuple (local 286 IP address, local UDP port, remote IP address, and remote UDP port) 287 are identical. 289 Two Connection IDs conflict if and only if one Connection ID is equal 290 to or a prefix of another. For example, a zero-length Connection ID 291 conflicts with all connection IDs. This definition of a conflict 292 originates from the fact that QUIC short headers do not carry the 293 length of the Destination Connection ID field, and therefore if two 294 short headers with different Destination Connection IDs are received 295 on a shared socket, one being a prefix of the other prevents the 296 receiver from identifying which mapping this corresponds to. 298 The proxy treats two mappings as being in conflict when a conflict is 299 detected for all elements on the left side of the mapping diagrams 300 above. 302 Since very short Connection IDs are more likely to lead to conflicts, 303 particularly zero-length Connection IDs, a proxy MAY choose to reject 304 all requests for very short Connection IDs as conflicts, in 305 anticipation of future conflicts. Note that a request that doesn't 306 contain any Connection ID is equivalent to a request for a zero- 307 length Connection ID, and similarly would cause conflicts when 308 forwarding. 310 3. Connection ID Headers for CONNECT-UDP 312 This document defines two headers that can be used in CONNECT-UDP 313 requests and responses. All other requirements defined for CONNECT- 314 UDP [CONNECT-UDP] still apply. 316 Both "Client-Connection-Id" and "Server-Connection-Id" are Item 317 Structured Headers [STRUCT]. Their value MUST be a Byte Sequence. 318 The byte sequence MAY be zero-length. The byte sequence length MUST 319 NOT exceed 255 bytes. The ABNF is: 321 Client-Connection-Id = sf-binary 322 Server-Connection-Id = sf-binary 324 "Client-Connection-Id" contains the client connection ID, whereas 325 "Server-Connection-Id" contains the server connection ID. 327 Like the Datagram-Flow-Id header [CONNECT-UDP], the Client- 328 Connection-Id and Server-Connection-Id headers can only be supported 329 by an HTTP/3 proxy. If a proxy does not support HTTP/3 datagrams 330 [H3DGRAM], or it does not support the extension defined in this 331 document, it MUST NOT send the Client-Connection-Id and Server- 332 Connection-Id headers on any responses. If a proxy does support this 333 extension, it MUST echo the Client-Connection-Id and Server- 334 Connection-Id headers on any 2xx (Successful) responses. Clients 335 that do not receive an echoed Client-Connection-Id or Server- 336 Connection-Id header MUST fall back to using CONNECT-UDP without the 337 extended behavior defined in this document. 339 4. Client Request Behavior 341 A client sends new CONNECT-UDP requests when it wants to start a new 342 QUIC connection to a target, when it has received a new Server 343 Connection ID for the target, and before it advertises a new Client 344 Connection ID to the target. 346 Each request MUST contain a Datagram-Flow-Id header and an authority 347 pseudo-header identifying the target. All requests for the same QUIC 348 Connection between a client and a target MUST contain the same 349 authority, and SHOULD contain the same Datagram-Flow-Id. If there is 350 Datagram-Flow-Id mismatch, the proxy will treat the requests as 351 different proxied connections, which could appear as a migration or 352 NAT rebinding event to the target. 354 Each request MUST also contain exactly one connection ID header, 355 either Client-Connection-Id or Server-Connection-Id. Client- 356 Connection-Id requests define paths for receiving packets from the 357 target server to the client, and Server-Connection-Id requests define 358 paths for sending packets from the client to target server. 360 4.1. New Proxied Connection Setup 362 The first time that a client uses a proxy for a given QUIC 363 connection, it selects a new datagram flow ID with an even-numbered 364 value [H3DGRAM]. 366 The first request the clients makes MUST contain the authority 367 pseudo-header, the Datagram-Flow-Id header, and the Client- 368 Connection-Id header. These respectively contain the authority of 369 the target, the selected datagram flow ID and the Client Connection 370 ID that will be used in the initial QUIC packets sent through the 371 proxy. 373 The client can start sending packets tunnelled within DATAGRAM frames 374 as soon as this first CONNECT-UDP request for the datagram flow ID 375 has been sent, even in the same QUIC packet to the proxy. That is, 376 the QUIC packet sent from the client to the proxy MAY contain a 377 STREAM frame containing the CONNECT-UDP request, as well as a 378 DATAGRAM frame that contains a tunnelled QUIC packet to send to the 379 target. This is particularly useful for reducing round trips on 380 connection setup. 382 Since clients are always aware whether or not they are using a QUIC 383 proxy, clients are expected to cooperate with proxies in selecting 384 Client Connection IDs. A proxy detects a conflict when it is not 385 able to create a unique mapping using the Client Connection ID 386 (Section 2.4). It can reject requests that would cause a conflict 387 and indicate this to the client by replying with a 409 (Conflict) 388 status. In order to avoid conflicts, clients SHOULD select Client 389 Connection IDs of at least 8 bytes in length with unpredictable 390 values. A client also SHOULD NOT select a Client Connection ID that 391 matches the ID used for the QUIC connection to the proxy, as this 392 inherently creates a conflict. 394 Note that packets sent in DATAGRAM frames before the proxy has sent 395 its CONNECT-UDP response might be dropped if the proxy rejects the 396 request. Specifically, this can occur if the Client Connection ID 397 causes a conflict and the proxy returns a 409 (Conflict) error. Any 398 DATAGRAM frames that are sent in a separate QUIC packet from the 399 STREAM frame that contains the CONNECT-UDP request might also be 400 dropped in the case that the packet arrives at the proxy before the 401 packet containing the STREAM frame. 403 If the server rejects the first request that uses a specific datagram 404 flow ID, the client MUST retire that datagram flow ID. If the 405 rejection indicated a conflict due to the Client Connection ID, the 406 client MUST select a new Connection ID before sending a new request, 407 and generate a new packet. For example, if a client is sending a 408 QUIC Initial packet and chooses a Connection ID that conflicts with 409 an existing mapping to the same target server, it will need to 410 generate a new QUIC Initial. 412 4.2. Adding New Client Connection IDs 414 Since QUIC connection IDs are chosen by the receiver, an endpoint 415 needs to communicate its chosen connection IDs to its peer before the 416 peer can start using them. In QUICv1, this is performed using the 417 NEW_CONNECTION_ID frame. 419 Prior to informing the target of a new chosen client connection ID, 420 the client MUST send a CONNECT-UDP request with the Client- 421 Connection-Id header to the proxy, and only inform the target of the 422 new client connection ID once a 2xx (Successful) response is 423 received. 425 4.3. Sending With Forwarded Mode 427 Once the client has learned the target server's Connection ID, such 428 as in the response to a QUIC Initial packet, it can send a request 429 containing the Server-Connection-Id header to request the ability to 430 forward packets. The client MUST wait for a successful (2xx) 431 response before using forwarded mode. Prior to receiving the server 432 response, the client MUST send short header packets tunnelled in 433 DATAGRAM frames. The client MAY also choose to tunnel some short 434 header packets even after receiving the successful response. 436 If the client's request that included the Server-Connection-Id is 437 rejected, for example with a 409 (Conflict) response, it MUST NOT 438 forward packets to the requested Server Connection ID, but only use 439 tunnelled mode. The request might also be rejected if the proxy does 440 not support forwarded mode or has it disabled by policy. For any 441 response code other than a 2xx success, the client MUST NOT retry a 442 request for the same Server Connection ID. For errors other than 409 443 (Conflict), clients SHOULD stop sending requests for other Server 444 Connection IDs in the future. 446 QUIC long header packets MUST NOT be forwarded. These packets can 447 only be tunnelled within DATAGRAM frames to avoid exposing 448 unnecessary connection metadata. 450 When forwarding, the client sends a QUIC packet with the target 451 server's Connection ID in the QUIC short header, using the same 452 socket between client and proxy that was used for the main QUIC 453 connection between client and proxy. 455 4.4. Receiving With Forwarded Mode 457 A proxy MUST NOT forward packets from the target to the client until 458 after the client has sent at least one packet in forwarded mode. 459 Once this occurs, the proxy MAY use forwarded mode for any Client 460 Connection ID for which it has a valid mapping. 462 If a client has started using forwarding mode, it MUST be prepared to 463 receive forwarded short header packets on the socket between itself 464 and the proxy for any Client Connection ID that has been accepted by 465 the proxy. The client uses the received Connection ID to determine 466 if a packet was originated by the proxy, or merely forwarded from the 467 target. 469 4.5. Opting Out of Forwarded Mode 471 The use of forwarded mode is initiated by the client sending a 472 request with the Server-Connection-Id header and sending at least one 473 forwarded packet to the proxy. A client that does not wish to accept 474 forwarded packets from the proxy when communicating with a specific 475 target can simply not start forwarding packets to the proxy. 477 5. Proxy Response Behavior 479 Upon receipt of a CONNECT-UDP request that contains a Client- 480 Connection-Id or Server-Connection-Id header, the proxy validates the 481 request, tries to establish the appropriate mappings as described in 482 Section 2, and establishes a new server-facing socket if necessary. 484 The proxy MUST validate that the request only contains one of either 485 the Client-Connection-Id or the Server-Connection-Id header, along 486 with a Datagram-Flow-Id header and an authority pseudo-header. If 487 any of these conditions is not met, the proxy MUST reject the request 488 with a 400 (Bad Request) response. The proxy also MUST reject the 489 request if the requested datagram flow ID has already been used on 490 that client <-> proxy QUIC connection with a different requested 491 authority. 493 The proxy then determines the server-facing socket to associate with 494 the client's datagram flow. This will generally involve performing a 495 DNS lookup for the hostname in the request authority, or finding an 496 existing server-facing socket to the authority. The server-facing 497 socket might already be open due to a previous request from this 498 client, or another. If the socket is not already created, the proxy 499 creates a new one. Proxies can choose to reuse server-facing sockets 500 across multiple datagram flows, or have a unique server-facing socket 501 for every datagram flow. 503 If a proxy reuses server-facing sockets, it SHOULD store which 504 authorities (which could be a domain name or IP address literal) are 505 being accessed over a particular server-facing socket so it can avoid 506 performing a new DNS query and potentially choosing a different 507 server IP address which could map to a different server. 509 Server-facing sockets MUST NOT be reused across QUIC and non-QUIC 510 CONNECT-UDP requests, since it might not be possible to correctly 511 demultiplex or direct the traffic. Any packets received on a server- 512 facing socket used for proxying QUIC that does not correspond to a 513 known Connection ID MUST be dropped. 515 If the request includes a Client-Connection-Id header, the proxy is 516 receiving a request to be able to route traffic back to the client 517 using that Connection ID. If the pair of this Client Connection ID 518 and the selected server-facing socket does not create a conflict, the 519 proxy creates the mapping and responds with a 200 (OK) response. 520 After this point, any packets received by the proxy from the server- 521 facing socket that match the Client Connection ID can to be sent to 522 the client. The proxy MUST use tunnelled mode (DATAGRAM frames) on 523 the correct datagram flow for any long header packets. The proxy 524 SHOULD forward directly to the client for any matching short header 525 packets, but MAY tunnel them in DATAGRAM frames. If the pair is not 526 unique, or the proxy chooses not to support zero-length Client 527 Connection IDs, the proxy responds with a 409 (Conflict) response. 528 If this occurs on the first request for a given datagram flow, the 529 proxy removes any mapping for that datagram flow. 531 If the request includes a Server-Connection-Id header, the proxy is 532 receiving a request to allow the client to forward packets to the 533 target. If the pair of this Server Connection ID and the client- 534 facing socket on which the request was received does not create a 535 conflict, the proxy creates the mapping and responds with a 200 (OK) 536 response. Once the successful response is sent, the proxy will 537 forward any short header packets received on the client-facing socket 538 that use the Server Connection ID using the correct server-facing 539 socket. If the pair is not unique, the server responds with a 409 540 (Conflict) response. If this occurs, traffic for that Server 541 Connection ID can only use tunnelled mode, not forwarded. 543 If the proxy does not support forwarded mode, or does not allow 544 forwarded mode for a particular client or authority by policy, it can 545 reject requests that include the Server-Connection-Id header with a 546 response to indicate the error, such as 403 (Forbidden). 548 Any successful (2xx) response MUST also echo any Client-Connection- 549 Id, Server-Connection-Id, and Datagram-Flow-Id headers included in 550 the request. 552 The proxy MUST only forward non-tunnelled packets from the client 553 that are QUIC short header packets (based on the Header Form bit) and 554 have mapped Server Connection IDs. Packets sent by the client that 555 are forwarded SHOULD be considered as activity for restarting QUIC's 556 Idle Timeout [QUIC]. 558 5.1. Removing Mapping State 560 Each CONNECT-UDP request consumes one bidirectional HTTP/3 stream 561 [HTTP3]. For any stream on which the proxy has sent a response 562 indicating success, any mappings for the request last as long as the 563 stream is open. 565 A client that no longer wants a given Connection ID to be forwarded 566 by the proxy, for either direction, MUST cancel its CONNECT-UDP 567 HTTP/3 request by closing the corresponding stream. 569 If the proxy rejects a CONNECT-UDP request by sending a status code 570 of 300 or higher, it MUST close the corresponding stream and remove 571 any associated mappings. 573 If a client's connection to the proxy is terminated for any reason, 574 all mappings associated with all requests are removed. 576 A proxy can close its server-facing socket once all datagram flows 577 mapped to that socket have been removed. 579 5.2. Handling Connection Migration 581 If a proxy supports QUIC connection migration, it needs to ensure 582 that a migration event does not end up sending too many tunnelled or 583 proxied packets on a new path prior to path validation. 585 Specifically, the proxy MUST limit the number of packets that it will 586 proxy to an unvalidated client address to the size of an initial 587 congestion window. Proxies additionally SHOULD pace the rate at 588 which packets are sent over a new path to avoid creating 589 unintentional congestion on the new path. 591 6. Example 593 Consider a client that is establishing a new QUIC connection through 594 the proxy. It has selected a Client Connection ID of 0x31323334. It 595 selects the next open datagram flow ID (2). In order to inform a 596 proxy of the new QUIC Client Connection ID, and binds that connection 597 ID to datagram flow ID 2, the client sends the following CONNECT-UDP 598 request: 600 HEADERS 601 :method = CONNECT-UDP 602 :authority = target.example.com:443 603 client-connection-id = :MTIzNA==: 604 datagram-flow-id = 2 605 The client will also send the initial QUIC packet with the Long 606 Header form in a DATAGRAM frame with flow ID 2. 608 Once the proxy sends a 200 response indicating success, packets 609 received by the proxy that match the Connection ID 0x31323334 will be 610 directly forwarded to the client. The proxy will also forward the 611 initial QUIC packet received on DATAGRAM flow ID 2 to 612 target.example.com:443. 614 When the proxy receives a response from target.example.com:443 that 615 has 0x31323334 as the Destination Connection ID, the proxy will 616 forward that packet to the client on DATAGRAM flow ID 2. 618 Once the client learns which Connection ID has been selected by the 619 target server, it can send a new request to the proxy to establish a 620 mapping. In this case, that ID is 0x61626364. The client sends the 621 following request: 623 HEADERS 624 :method = CONNECT-UDP 625 :authority = target.example.com:443 626 server-connection-id = :YWJjZA==: 627 datagram-flow-id = 2 629 The client also sends its reply to the target server in a DATAGRAM 630 frame on flow ID 2 after sending the new request. 632 Once the proxy sends a 200 response indicating success, packets sent 633 by the client that match the Connection ID 0x61626364 will be 634 forwarded to the target server, i.e., without proxy decryption. 636 Upon receiving the response, the client starts sending Short Header 637 packets with a Destination Connection ID of 0x61626364 directly to 638 the proxy (not tunnelled), and these are forwarded directly to the 639 target by the proxy. Similarly, Short Header packets from the target 640 with a Destination Connection ID of 0x31323334 are forwarded directly 641 to the client. 643 7. Interactions with Load Balancers 645 Some QUIC servers are accessed using load balancers, as described in 646 [QUIC-LB]. These load balancers route packets to servers based on 647 the server's Connection ID. These Connection IDs are generated in a 648 way that can be coordinated between servers and their load balancers. 650 If a proxy that supports this extension is itself running behind a 651 load balancer, extra complexity arises once clients start using 652 forwarding mode and sending packets to the proxy that have 653 Destination Connection IDs that belong to the end servers, not the 654 proxy. If the load balancer is not aware of these Connection IDs, or 655 the Connection IDs conflict with other Connection IDs used by the 656 load balancer, packets can be routed incorrectly. 658 QUIC-aware CONNECT-UDP proxies that use forwarding mode generally 659 SHOULD NOT be run behind load balancers; and if they are, they MUST 660 coordinate between the proxy and the load balancer to create mappings 661 for proxied Connection IDs prior to the proxy sending 2xx 662 (Successful) responses to clients. 664 QUIC-aware CONNECT-UDP proxies that do not allow forwarding mode can 665 function unmodified behind QUIC load balancers. 667 8. Packet Size Considerations 669 Since Initial QUIC packets must be at least 1200 bytes in length, the 670 DATAGRAM frames that are used for a QUIC-aware CONNECT-UDP proxy MUST 671 be able to carry at least 1200 bytes. 673 Additionally, clients that connect to a proxy for purpose of proxying 674 QUIC SHOULD start their connection with a larger packet size than 675 1200 bytes, to account for the overhead of tunnelling an Initial QUIC 676 packet within a DATAGRAM frame. If the client does not begin with a 677 larger packet size than 1200 bytes, it will need to perform Path MTU 678 (Maximum Transmission Unit) discovery to discover a larger path size 679 prior to sending any tunnelled Initial QUIC packets. 681 Once a proxied QUIC connections moves into forwarded mode, the client 682 SHOULD initiate Path MTU discovery to increase its end-to-end MTU. 684 9. Security Considerations 686 Proxies that support this extension SHOULD provide protections to 687 rate-limit or restrict clients from opening an excessive number of 688 proxied connections, so as to limit abuse or use of proxies to launch 689 Denial-of-Service attacks. 691 Sending QUIC packets by forwarding through a proxy without tunnelling 692 exposes some QUIC header metadata to onlookers, and can be used to 693 correlate packets flows if an attacker is able to see traffic on both 694 sides of the proxy. Tunnelled packets have similar inference 695 problems. An attacker on both sides of the proxy can use the size of 696 ingress and egress packets to correlate packets belonging to the same 697 connection. (Absent client-side padding, tunneled packets will 698 typically have a fixed amount of overhead that is removed before 699 their DATAGRAM contents are written to the target.) 700 Since proxies that forward QUIC packets do not perform any 701 cryptographic integrity check, it is possible that these packets are 702 either malformed, replays, or otherwise malicious. This may result 703 in proxy targets rate limiting or decreasing the reputation of a 704 given proxy. 706 10. IANA Considerations 708 10.1. HTTP Headers 710 This document registers the "Client-Connection-Id" and "Server- 711 Connection-Id" headers in the "Permanent Message Header Field Names" 712 . 714 +----------------------+----------+--------+---------------+ 715 | Header Field Name | Protocol | Status | Reference | 716 +----------------------+----------+--------+---------------+ 717 | Client-Connection-Id | http | exp | This document | 718 +----------------------+----------+--------+---------------+ 719 | Server-Connection-Id | http | exp | This document | 720 +----------------------+----------+--------+---------------+ 722 11. References 724 11.1. Normative References 726 [CONNECT-UDP] 727 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 728 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 729 03, 5 January 2021, . 732 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 733 Datagram Extension to QUIC", Work in Progress, Internet- 734 Draft, draft-ietf-quic-datagram-01, 24 August 2020, 735 . 738 [H3DGRAM] Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in 739 Progress, Internet-Draft, draft-schinazi-quic-h3-datagram- 740 05, 12 October 2020, . 743 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 744 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 745 quic-http-33, 15 December 2020, . 748 [INVARIANTS] 749 Thomson, M., "Version-Independent Properties of QUIC", 750 Work in Progress, Internet-Draft, draft-ietf-quic- 751 invariants-13, 14 January 2021, . 754 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 755 and Secure Transport", Work in Progress, Internet-Draft, 756 draft-ietf-quic-transport-34, 14 January 2021, 757 . 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, 762 DOI 10.17487/RFC2119, March 1997, 763 . 765 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 766 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 767 May 2017, . 769 [STRUCT] Nottingham, M. and P. Kamp, "Structured Field Values for 770 HTTP", Work in Progress, Internet-Draft, draft-ietf- 771 httpbis-header-structure-19, 3 June 2020, 772 . 775 11.2. Informative References 777 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 778 Connection IDs", Work in Progress, Internet-Draft, draft- 779 ietf-quic-load-balancers-05, 30 October 2020, 780 . 783 Acknowledgments 785 Thanks to Lucas Pardue, Ryan Hamilton, and Mirja Kuehlewind for their 786 inputs on this document. 788 Authors' Addresses 790 Tommy Pauly 791 Apple Inc. 792 One Apple Park Way 793 Cupertino, California 95014, 794 United States of America 795 Email: tpauly@apple.com 797 David Schinazi 798 Google LLC 799 1600 Amphitheatre Parkway 800 Mountain View, California 94043, 801 United States of America 803 Email: dschinazi.ietf@gmail.com