idnits 2.17.1 draft-pauly-masque-quic-proxy-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 : ---------------------------------------------------------------------------- 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 (18 October 2020) is 1285 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-00 == 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-31 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-11 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-31 == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Experimental D. Schinazi 5 Expires: 21 April 2021 Google LLC 6 18 October 2020 8 QUIC-Aware Proxying Using CONNECT-UDP 9 draft-pauly-masque-quic-proxy-00 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 21 April 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 . . . . . . . . . . . . . . . 9 74 4.4. Receiving With Forwarded Mode . . . . . . . . . . . . . . 10 75 4.5. Opting Out of Forwarded Mode . . . . . . . . . . . . . . 10 76 5. Proxy Response Behavior . . . . . . . . . . . . . . . . . . . 10 77 5.1. Removing Mapping State . . . . . . . . . . . . . . . . . 12 78 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. Interactions with Load Balancers . . . . . . . . . . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 9.1. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . 15 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 10.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The CONNECT-UDP HTTP method [CONNECT-UDP] defines a way to send 92 datagrams through an HTTP proxy, where UDP is used to communicate 93 between the proxy and a target server. This can be used to proxy 94 QUIC connections [QUIC], since QUIC runs over UDP datagrams. 96 This document uses the term "target" to refer to the server that a 97 client is accessing via a proxy. This target may be an origin 98 hosting content, or another proxy. 100 This document extends the CONNECT-UDP HTTP method to add signalling 101 about QUIC Connection IDs. QUIC Connection IDs are used to identify 102 QUIC connections in scenarios where there is not a strict 103 bidirectional mapping between one QUIC connection and one UDP 4-tuple 104 (pairs of IP addresses and ports). A proxy that is aware of 105 Connection IDs can reuse UDP 4-tuples between itself and a target for 106 multiple proxied QUIC connections. 108 This extension is only defined for HTTP/3 [HTTP3] and not any earlier 109 versions. 111 Awareness of Connection IDs also allows a proxy to avoid re- 112 encapsulation and re-encryption of proxied QUIC packets once a 113 connection has been established. When this functionality is present, 114 the proxy can support two modes for handling QUIC packets: 116 1. Tunnelled, in which client <-> target QUIC packets are 117 encapsulated inside client <-> proxy QUIC packets. These packets 118 use multiple layers of encryption and congestion control. QUIC 119 long header packets MUST use this mode. QUIC short header 120 packets MAY use this mode. This is the default mode for CONNECT- 121 UDP. 123 2. Forwarded, in which client <-> target QUIC packets are sent 124 directly over the client <-> proxy UDP socket. These packets are 125 only encrypted using the client-target keys, and use the client- 126 target congestion control. This mode MUST only be used for QUIC 127 short header packets. 129 Forwarding is defined as an optimization to reduce CPU processing on 130 clients and proxies, as well as avoiding MTU overhead for packets on 131 the wire. This makes it suitable for deployment situations that 132 otherwise relied on cleartext TCP proxies, which cannot support QUIC 133 and have inferior security and privacy properties. 135 The properties provided by the forwarding mode are as follows: 137 * All packets sent between the client and the target traverse 138 through the proxy device. 140 * The target server cannot know the IP address of the client solely 141 based on the proxied packets the target receives. 143 * Observers of either or both of the client <-> proxy link and the 144 proxy <-> target are not able to learn more about the client <-> 145 target communication than if no proxy was used. 147 It is not a goal of forwarding mode to prevent correlation between 148 client <-> proxy and the proxy <-> target packets from an entity that 149 can observe both links. See Section 8 for further discussion. 151 Both clients and proxies can unilaterally choose to disable forwarded 152 mode for any client <-> target connection. 154 QUIC proxies only need to understand the Header Form bit, and the 155 connection ID fields from packets in client <-> target QUIC 156 connections. Since these fields are all in the QUIC invariants 157 header [INVARIANTS], QUIC proxies can proxy all versions of QUIC. 159 1.1. Conventions and Definitions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 1.2. Terminology 169 This document uses the following terms: 171 * Client: the client of all QUIC connections discussed in this 172 document. 174 * Proxy: the endpoint that responds to the CONNECT-UDP request. 176 * Target: the server that a client is accessing via a proxy. 178 * Client <-> Proxy QUIC connection: a single QUIC connection 179 established from the client to the proxy. 181 * Datagram flow ID: represents a flow of HTTP/3 DATAGRAMs [H3DGRAM] 182 specific to a single client <-> proxy QUIC connection. 184 * Socket: a UDP 4-tuple (local IP address, local UDP port, remote IP 185 address, remote UDP port). In some implementations, this is 186 referred to as a "connected" socket. 188 * Client-facing socket: the socket used to communicate between the 189 client and the proxy. 191 * Server-facing socket: the socket used to communicate between the 192 proxy and the target. 194 * Client Connection ID: a QUIC Connection ID that is chosen by the 195 client, and is used in the Destination Connection ID field of 196 packets from the target to the client. 198 * Server Connection ID: a QUIC Connection ID that is chosen by the 199 target, and is used in the Destination Connection ID field of 200 packets from the client to the target. 202 2. Required Proxy State 204 In the methods defined in this document, the proxy is aware of the 205 QUIC Connection IDs being used by proxied connections, along with the 206 sockets used to communicate with the client and the target. Tracking 207 Connection IDs in this way allows the proxy to reuse server-facing 208 sockets for multiple connections and support the forwarding mode of 209 proxying. 211 QUIC packets can be either tunnelled within an HTTP/3 proxy 212 connection using QUIC DATAGRAM frames [DGRAM], or be forwarded 213 directly alongside an HTTP/3 proxy connection on the same set of IP 214 addresses and UDP ports. The use of forwarded mode requires the 215 consent of both the client and the proxy. 217 In order to correctly route QUIC packets in both tunnelled and 218 forwarded modes, the proxy needs to maintain mappings between several 219 items. There are three required unidirectional mappings, described 220 below. 222 2.1. Datagram Flow ID Mapping 224 Each pair of client <-> proxy QUIC connection and datagram flow ID 225 MUST be mapped to a single server-facing socket. 227 (Client <-> Proxy QUIC connection + Datagram flow ID) 228 => Server-facing socket 230 Multiple datagram flow IDs can map to the same server-facing socket, 231 but a single datagram flow ID cannot be mapped to multiple server- 232 facing sockets. 234 This mapping guarantees that any QUIC packet using the datagram flow 235 ID sent from the client to the proxy in tunnelled mode can be sent to 236 the correct target. 238 2.2. Server Connection ID Mapping 240 Each pair of Server Connection ID and client-facing socket MUST map 241 to a single server-facing socket. 243 (Client-facing socket + Server Connection ID) 244 => Server-facing socket 246 Multiple pairs of Connection IDs and sockets can map to the same 247 server-facing socket. 249 This mapping guarantees that any QUIC packet containing the Server 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 server-facing socket MUST map 257 to a single datagram flow ID on a single client <-> proxy QUIC 258 connection. Additionally, the pair of Client Connection ID and 259 server-facing socket MUST map to a single client-facing socket. 261 (Server-facing socket + Client Connection ID) 262 => (Client <-> Proxy QUIC connection + Datagram flow ID) 263 (Server-facing socket + Client Connection ID) 264 => Client-facing socket 266 Multiple pairs of Connection IDs and sockets can map to the same 267 datagram flow ID 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 server-facing socket for every client request with 273 a unique datagram flow ID. The mapping is critical for any case 274 where server-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. 305 3. Connection ID Headers for CONNECT-UDP 307 This document defines two headers that can be used in CONNECT-UDP 308 requests and responses. All other requirements defined for CONNECT- 309 UDP [CONNECT-UDP] still apply. 311 Both "Client-Connection-Id" and "Server-Connection-Id" are Item 312 Structured Headers [STRUCT]. Their value MUST be a Byte Sequence. 313 The byte sequence MAY be zero-length. The byte sequence length MUST 314 NOT exceed 255 bytes. The ABNF is: 316 Client-Connection-Id = sf-binary 317 Server-Connection-Id = sf-binary 319 "Client-Connection-Id" contains the client connection ID, whereas 320 "Server-Connection-Id" contains the server connection ID. 322 Like the Datagram-Flow-Id header [CONNECT-UDP], the Client- 323 Connection-Id and Server-Connection-Id headers can only be supported 324 by an HTTP/3 proxy. If a proxy does not support HTTP/3 datagrams 325 [H3DGRAM], or it does not support the extension defined in this 326 document, it MUST NOT send the Client-Connection-Id and Server- 327 Connection-Id headers on any responses. If a proxy does support this 328 extension, it MUST echo the Client-Connection-Id and Server- 329 Connection-Id headers on any 2xx (Successful) responses. Clients 330 that do not receive an echoed Client-Connection-Id or Server- 331 Connection-Id header MUST fall back to using CONNECT-UDP without the 332 extended behavior defined in this document. 334 4. Client Request Behavior 336 A client sends new CONNECT-UDP requests when it wants to start a new 337 QUIC connection to a target, when it has received a new Server 338 Connection ID for the target, and before it advertises a new Client 339 Connection ID to the target. 341 Each request MUST contain a Datagram-Flow-Id header and an authority 342 pseudo-header identifying the target. All requests for the same QUIC 343 Connection between a client and a target MUST contain the same 344 authority, and SHOULD contain the same Datagram-Flow-Id. If there is 345 Datagram-Flow-Id mismatch, the proxy will treat the requests as 346 different proxied connections, which could appear as a migration or 347 NAT rebinding event to the target. 349 Each request MUST also contain exactly one connection ID header, 350 either Client-Connection-Id or Server-Connection-Id. Client- 351 Connection-Id requests define paths for receiving packets from the 352 target server to the client, and Server-Connection-Id requests define 353 paths for sending packets from the client to target server. 355 4.1. New Proxied Connection Setup 357 The first time that a client uses a proxy for a given QUIC 358 connection, it selects a new datagram flow ID with an even-numbered 359 value [H3DGRAM]. 361 The first request the clients makes MUST contain the authority 362 pseudo-header, the Datagram-Flow-Id header, and the Client- 363 Connection-Id header. These respectively contain the authority of 364 the target, the selected datagram flow ID and the Client Connection 365 ID that will be used in the initial QUIC packets sent through the 366 proxy. 368 The client can start sending packets tunnelled within DATAGRAM frames 369 as soon as this first CONNECT-UDP request for the datagram flow ID 370 has been sent, even in the same QUIC packet to the proxy. That is, 371 the QUIC packet sent from the client to the proxy MAY contain a 372 STREAM frame containing the CONNECT-UDP request, as well as a 373 DATAGRAM frame that contains a tunnelled QUIC packet to send to the 374 target. This is particularly useful for reducing round trips on 375 connection setup. 377 Since clients are always aware whether or not they are using a QUIC 378 proxy, clients are expected to cooperate with proxies in selecting 379 Client Connection IDs. A proxy detects a conflict when it is not 380 able to create a unique mapping using the Client Connection ID 381 (Section 2.4). It can reject requests that would cause a conflict 382 and indicate this to the client by replying with a 409 (Conflict) 383 status. In order to avoid conflicts, clients SHOULD select Client 384 Connection IDs of at least 8 bytes in length with unpredictable 385 values. A client also SHOULD NOT select a Client Connection ID that 386 matches the ID used for the QUIC connection to the proxy, as this 387 inherently creates a conflict. 389 Note that packets sent in DATAGRAM frames before the proxy has sent 390 its CONNECT-UDP response might be dropped if the proxy rejects the 391 request. Specifically, this can occur if the Client Connection ID 392 causes a conflict and the proxy returns a 409 (Conflict) error. Any 393 DATAGRAM frames that are sent in a separate QUIC packet from the 394 STREAM frame that contains the CONNECT-UDP request might also be 395 dropped in the case that the packet arrives at the proxy before the 396 packet containing the STREAM frame. 398 If the server rejects the first request that uses a specific datagram 399 flow ID, the client MUST retire that datagram flow ID. If the 400 rejection indicated a conflict due to the Client Connection ID, the 401 client MUST select a new Connection ID before sending a new request, 402 and generate a new packet. For example, if a client is sending a 403 QUIC Initial packet and chooses a Connection ID that conflicts with 404 an existing mapping to the same target server, it will need to 405 generate a new QUIC Initial. 407 4.2. Adding New Client Connection IDs 409 Since QUIC connection IDs are chosen by the receiver, an endpoint 410 needs to communicate its chosen connection IDs to its peer before the 411 peer can start using them. In QUICv1, this is performed using the 412 NEW_CONNECTION_ID frame. 414 Prior to informing the target of a new chosen client connection ID, 415 the client MUST send a CONNECT-UDP request with the Client- 416 Connection-Id header to the proxy, and only inform the target of the 417 new client connection ID once a 2xx (Successful) response is 418 received. 420 4.3. Sending With Forwarded Mode 422 Once the client has learned the target server's Connection ID, such 423 as in the response to a QUIC Initial packet, it can send a request 424 containing the Server-Connection-Id header to request the ability to 425 forward packets. The client MUST wait for a successful (2xx) 426 response before using forwarded mode. Prior to receiving the server 427 response, the client MUST send short header packets tunnelled in 428 DATAGRAM frames. The client MAY also choose to tunnel some short 429 header packets even after receiving the successful response. 431 If the client's request that included the Server-Connection-Id is 432 rejected, for example with a 409 (Conflict) response, it MUST NOT 433 forward packets to the requested Server Connection ID, but only use 434 tunnelled mode. The request might also be rejected if the proxy does 435 not support forwarded mode or has it disabled by policy. For any 436 response code other than a 2xx success, the client MUST NOT retry a 437 request for the same Server Connection ID. For errors other than 409 438 (Conflict), clients SHOULD stop sending requests for other Server 439 Connection IDs in the future. 441 QUIC long header packets MUST NOT be forwarded. These packets can 442 only be tunnelled within DATAGRAM frames to avoid exposing 443 unnecessary connection metadata. 445 When forwarding, the client sends a QUIC packet with the target 446 server's Connection ID in the QUIC short header, using the same 447 socket between client and proxy that was used for the main QUIC 448 connection between client and proxy. 450 4.4. Receiving With Forwarded Mode 452 A proxy MUST NOT forward packets from the target to the client until 453 after the client has sent at least one packet in forwarded mode. 454 Once this occurs, the proxy MAY use forwarded mode for any Client 455 Connection ID for which it has a valid mapping. 457 If a client has started using forwarding mode, it MUST be prepared to 458 receive forwarded short header packets on the socket between itself 459 and the proxy for any Client Connection ID that has been accepted by 460 the proxy. The client uses the received Connection ID to determine 461 if a packet was originated by the proxy, or merely forwarded from the 462 target. 464 4.5. Opting Out of Forwarded Mode 466 The use of forwarded mode is initiated by the client sending a 467 request with the Server-Connection-Id header and sending at least one 468 forwarded packet to the proxy. A client that does not wish to accept 469 forwarded packets from the proxy when communicating with a specific 470 target can simply not start forwarding packets to the proxy. 472 5. Proxy Response Behavior 474 Upon receipt of a CONNECT-UDP request that contains a Client- 475 Connection-Id or Server-Connection-Id header, the proxy validates the 476 request, tries to establish the appropriate mappings as described in 477 Section 2, and establishes a new server-facing socket if necessary. 479 The proxy MUST validate that the request only contains one of either 480 the Client-Connection-Id or the Server-Connection-Id header, along 481 with a Datagram-Flow-Id header and an authority pseudo-header. If 482 any of these conditions is not met, the proxy MUST reject the request 483 with a 400 (Bad Request) response. The proxy also MUST reject the 484 request if the requested datagram flow ID has already been used on 485 that client <-> proxy QUIC connection with a different requested 486 authority. 488 The proxy then determines the server-facing socket to associate with 489 the client's datagram flow. This will generally involve performing a 490 DNS lookup for the hostname in the request authority, or finding an 491 existing server-facing socket to the authority. The server-facing 492 socket might already be open due to a previous request from this 493 client, or another. If the socket is not already created, the proxy 494 creates a new one. Proxies can choose to reuse server-facing sockets 495 across multiple datagram flows, or have a unique server-facing socket 496 for every datagram flow. 498 If a proxy reuses server-facing sockets, it SHOULD store which 499 authorities (which could be a domain name or IP address literal) are 500 being accessed over a particular server-facing socket so it can avoid 501 performing a new DNS query and potentially choosing a different 502 server IP address which could map to a different server. 504 If the request includes a Client-Connection-Id header, the proxy is 505 receiving a request to be able to route traffic back to the client 506 using that Connection ID. If the pair of this Client Connection ID 507 and the selected server-facing socket does not create a conflict, the 508 proxy creates the mapping and responds with a 200 (OK) response. 509 After this point, any packets received by the proxy from the server- 510 facing socket that match the Client Connection ID can to be sent to 511 the client. The proxy MUST use tunnelled mode (DATAGRAM frames) on 512 the correct datagram flow for any long header packets. The proxy 513 SHOULD forward directly to the client for any matching short header 514 packets, but MAY tunnel them in DATAGRAM frames. If the pair is not 515 unique, or the proxy chooses not to support zero-length Client 516 Connection IDs, the proxy responds with a 409 (Conflict) response. 517 If this occurs on the first request for a given datagram flow, the 518 proxy removes any mapping for that datagram flow. 520 If the request includes a Server-Connection-Id header, the proxy is 521 receiving a request to allow the client to forward packets to the 522 target. If the pair of this Server Connection ID and the client- 523 facing socket on which the request was received does not create a 524 conflict, the proxy creates the mapping and responds with a 200 (OK) 525 response. Once the successful response is sent, the proxy will 526 forward any short header packets received on the client-facing socket 527 that use the Server Connection ID using the correct server-facing 528 socket. If the pair is not unique, the server responds with a 409 529 (Conflict) response. If this occurs, traffic for that Server 530 Connection ID can only use tunnelled mode, not forwarded. 532 If the proxy does not support forwarded mode, or does not allow 533 forwarded mode for a particular client or authority by policy, it can 534 reject requests that include the Server-Connection-Id header with a 535 response to indicate the error, such as 403 (Forbidden). 537 Any successful (2xx) response MUST also echo any Client-Connection- 538 Id, Server-Connection-Id, and Datagram-Flow-Id headers included in 539 the request. 541 The proxy MUST only forward non-tunnelled packets from the client 542 that are QUIC short header packets (based on the Header Form bit) and 543 have mapped Server Connection IDs. Packets sent by the client that 544 are forwarded SHOULD be considered as activity for restarting QUIC's 545 Idle Timeout [QUIC]. 547 5.1. Removing Mapping State 549 Each CONNECT-UDP request consumes one bidirectional HTTP/3 stream 550 [HTTP3]. For any stream on which the proxy has sent a response 551 indicating success, any mappings for the request last as long as the 552 stream is open. 554 A client that no longer wants a given Connection ID to be forwarded 555 by the proxy, for either direction, MUST cancel its CONNECT-UDP 556 HTTP/3 request by closing the corresponding stream. 558 If the proxy rejects a CONNECT-UDP request by sending a status code 559 of 300 or higher, it MUST close the corresponding stream and remove 560 any associated mappings. 562 If a client's connection to the proxy is terminated for any reason, 563 all mappings associated with all requests are removed. 565 A proxy can close its server-facing socket once all datagram flows 566 mapped to that socket have been removed. 568 6. Example 570 Consider a client that is establishing a new QUIC connection through 571 the proxy. It has selected a Client Connection ID of 0x31323334. It 572 selects the next open datagram flow ID (2). In order to inform a 573 proxy of the new QUIC Client Connection ID, and binds that connection 574 ID to datagram flow ID 2, the client sends the following CONNECT-UDP 575 request: 577 HEADERS 578 :method = CONNECT-UDP 579 :authority = target.example.com:443 580 client-connection-id = :MTIzNA==: 581 datagram-flow-id = 2 583 The client will also send the initial QUIC packet with the Long 584 Header form in a DATAGRAM frame with flow ID 2. 586 Once the proxy sends a 200 response indicating success, packets 587 received by the proxy that match the Connection ID 0x31323334 will be 588 directly forwarded to the client. The proxy will also forward the 589 initial QUIC packet received on DATAGRAM flow ID 2 to 590 target.example.com:443. 592 When the proxy receives a response from target.example.com:443 that 593 has 0x31323334 as the Destination Connection ID, the proxy will 594 forward that packet to the client on DATAGRAM flow ID 2. 596 Once the client learns which Connection ID has been selected by the 597 target server, it can send a new request to the proxy to establish a 598 mapping. In this case, that ID is 0x61626364. The client sends the 599 following request: 601 HEADERS 602 :method = CONNECT-UDP 603 :authority = target.example.com:443 604 server-connection-id = :YWJjZA==: 605 datagram-flow-id = 2 607 The client also sends its reply to the target server in a DATAGRAM 608 frame on flow ID 2 after sending the new request. 610 Once the proxy sends a 200 response indicating success, packets sent 611 by the client that match the Connection ID 0x61626364 will be 612 forwarded to the target server, i.e., without proxy decryption. 614 Upon receiving the response, the client starts sending Short Header 615 packets with a Destination Connection ID of 0x61626364 directly to 616 the proxy (not tunnelled), and these are forwarded directly to the 617 target by the proxy. Similarly, Short Header packets from the target 618 with a Destination Connection ID of 0x31323334 are forwarded directly 619 to the client. 621 7. Interactions with Load Balancers 623 Some QUIC servers are accessed using load balancers, as described in 624 [QUIC-LB]. These load balancers route packets to servers based on 625 the server's Connection ID. These Connection IDs are generated in a 626 way that can be coordinated between servers and their load balancers. 628 If a proxy that supports this extension is itself running behind a 629 load balancer, extra complexity arises once clients start using 630 forwarding mode and sending packets to the proxy that have 631 Destination Connection IDs that belong to the end servers, not the 632 proxy. If the load balancer is not aware of these Connection IDs, or 633 the Connection IDs conflict with other Connection IDs used by the 634 load balancer, packets can be routed incorrectly. 636 QUIC-aware CONNECT-UDP proxies that use forwarding mode generally 637 SHOULD NOT be run behind load balancers; and if they are, they MUST 638 coordinate between the proxy and the load balancer to create mappings 639 for proxied Connection IDs prior to the proxy sending 2xx 640 (Successful) responses to clients. 642 QUIC-aware CONNECT-UDP proxies that do not allow forwarding mode can 643 function unmodified behind QUIC load balancers. 645 8. Security Considerations 647 Proxies that support this extension SHOULD provide protections to 648 rate-limit or restrict clients from opening an excessive number of 649 proxied connections, so as to limit abuse or use of proxies to launch 650 Denial-of-Service attacks. 652 Sending QUIC packets by forwarding through a proxy without tunnelling 653 exposes some QUIC header metadata to onlookers, and can be used to 654 correlate packets flows if an attacker is able to see traffic on both 655 sides of the proxy. Tunnelled packets have similar inference 656 problems. An attacker on both sides of the proxy can use the size of 657 ingress and egress packets to correlate packets belonging to the same 658 connection. (Absent client-side padding, tunneled packets will 659 typically have a fixed amount of overhead that is removed before 660 their DATAGRAM contents are written to the target.) 661 Since proxies that forward QUIC packets do not perform any 662 cryptographic integrity check, it is possible that these packets are 663 either malformed, replays, or otherwise malicious. This may result 664 in proxy targets rate limiting or decreasing the reputation of a 665 given proxy. 667 9. IANA Considerations 669 9.1. HTTP Headers 671 This document registers the "Client-Connection-Id" and "Server- 672 Connection-Id" headers in the "Permanent Message Header Field Names" 673 . 675 +----------------------+----------+--------+---------------+ 676 | Header Field Name | Protocol | Status | Reference | 677 +----------------------+----------+--------+---------------+ 678 | Client-Connection-Id | http | exp | This document | 679 +----------------------+----------+--------+---------------+ 680 | Server-Connection-Id | http | exp | This document | 681 +----------------------+----------+--------+---------------+ 683 10. References 685 10.1. Normative References 687 [CONNECT-UDP] 688 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 689 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 690 00, 28 August 2020, . 693 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 694 Datagram Extension to QUIC", Work in Progress, Internet- 695 Draft, draft-ietf-quic-datagram-01, 24 August 2020, 696 . 699 [H3DGRAM] Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in 700 Progress, Internet-Draft, draft-schinazi-quic-h3-datagram- 701 05, 12 October 2020, . 704 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 705 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 706 quic-http-31, 24 September 2020, . 709 [INVARIANTS] 710 Thomson, M., "Version-Independent Properties of QUIC", 711 Work in Progress, Internet-Draft, draft-ietf-quic- 712 invariants-11, 24 September 2020, . 715 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 716 and Secure Transport", Work in Progress, Internet-Draft, 717 draft-ietf-quic-transport-31, 24 September 2020, 718 . 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, 724 . 726 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 727 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 728 May 2017, . 730 [STRUCT] Nottingham, M. and P. Kamp, "Structured Field Values for 731 HTTP", Work in Progress, Internet-Draft, draft-ietf- 732 httpbis-header-structure-19, 3 June 2020, 733 . 736 10.2. Informative References 738 [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 739 Connection IDs", Work in Progress, Internet-Draft, draft- 740 ietf-quic-load-balancers-04, 14 August 2020, 741 . 744 Acknowledgments 746 Thanks to Lucas Pardue, Ryan Hamilton, and Mirja Kuehlewind for their 747 inputs on this document. 749 Authors' Addresses 751 Tommy Pauly 752 Apple Inc. 753 One Apple Park Way 754 Cupertino, California 95014, 755 United States of America 756 Email: tpauly@apple.com 758 David Schinazi 759 Google LLC 760 1600 Amphitheatre Parkway 761 Mountain View, California 94043, 762 United States of America 764 Email: dschinazi.ietf@gmail.com