QUIC-Aware Proxying Using HTTP

1.1. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

This document uses the following terms:¶

• Client: the client of all QUIC connections discussed in this document.¶

• Proxy: the endpoint that responds to the UDP proxying request.¶

• Target: the server that a client is accessing via a proxy.¶

• Client-to-proxy 4-tuple: the UDP 4-tuple (client IP address, client UDP port, proxy IP address, proxy UDP port) used to communicate between the client and the proxy.¶

• Proxy-to-target 4-tuple: the UDP 4-tuple (proxy IP address, proxy UDP port, target IP address, target UDP port) used to communicate between the proxy and the target.¶

• Client Connection ID (CID): a QUIC Connection ID that is chosen by the client, and is used in the Destination Connection ID field of packets from the target to the client.¶

• Target Connection ID (CID): a QUIC Connection ID that is chosen by the target, and is used in the Destination Connection ID field of packets from the client to the target.¶

• Virtual Connection ID (VCID): a fake QUIC Connection ID chosen by the proxy that is used on the client-to-proxy 4-tuple in forwarded mode.¶

• Client VCID: a VCID used by the proxy to send forwarded packets from the target to the client.¶

• Target VCID: a VCID used by the client to send forwarded packets to the target via the proxy.¶

• Packet Transform: the procedure used to modify packets before they enter the client-proxy link.¶

2.1. Connection ID Awareness

For a proxy to be aware of proxied QUIC connection IDs, it needs to know and correlate three values:¶

1. The HTTP stream used to proxy a client-to-target QUIC connection¶

2. The client-chosen connection ID on the client-to-target QUIC connection, or the "client CID"¶

3. The target-chosen connection ID on the client-to-target QUIC connection, or the "target CID"¶

For example, consider a proxy using HTTP/3 that has two clients (A and B) connected simultaneously, each client coming from a different IP address and port. Each client makes a request to proxy a UDP flow to "target.example.net" on port 443. If the proxy knows that client A's connection to the target has negotiated a client CID AAAAAAAA and a target CID 11111111, and client B's connection to the target has negotiated a client CID BBBBBBBB and a target CID 22222222, then the proxy would be able to use the same proxy-to-target 4-tuple for both connections, because it can route packets from the target to the correct client based on CID AAAAAAAA or BBBBBBBB.¶

In order to share a proxy-to-target 4-tuple between multiple proxied connections, the proxy MUST guarantee that the client CIDs do not conflict. See Section 4.3.1 for more discussion of handling CID conflicts.¶

2.2. Virtual Connection IDs

Virtual Connection IDs (VCIDs) are QUIC Connection IDs used on the link between a client and proxy that do not belong to the QUIC connection between the client and proxy, but instead are aliases for particular client-to-target connections. VCIDs are only used in forwarded mode. They are established using HTTP capsules [HTTP-CAPSULES] as described in Section 5.2.¶

For example, consider a proxy using HTTP/3 that has a single client connected to it. The client-to-proxy QUIC connection has AAAAAAAA as the client CID and BBBBBBBB as the proxy CID. The client has connected to a single target through the proxy, and the client-to-target QUIC connection has CCCCCCCC as the client CID and DDDDDDDD as the target CID. In order to use forwarded mode, the proxy assigns VCIDs to use on the client-to-proxy link to represent the client-to-target connection. In this case, the VCIDs could be EEEEEEEE for the client VCID and FFFFFFFF for the target VCID.¶

In order for a proxy to correctly route packets using VCIDs from client-to-target and target-to-client, the proxy MUST guarantee that the mappings between VCIDs, CIDs, and 4-tuples are unique. Specifically, in order to route packets sent by the client, the proxy needs to be able to observe the VCID and the client-to-proxy 4-tuple, and map them to a specific target CID and proxy-to-target 4-tuple. In order to route packets sent by a target, the proxy needs to be able to observe the client CID and the proxy-to-target 4-tuple, and map them to a specific VCID and client-to-proxy 4-tuple. Since proxies choose the VCID values, they can ensure that the VCIDs are distinguishable.¶

Servers receiving QUIC packets can employ load balancing strategies such as those described in [QUIC-LB] that encode routing information in the connection ID. When operating in forwarded mode, clients send QUIC packets destined for the target directly to the proxy. Since these packets are generated using the target CID, load balancers may not have the necessary information to route packets to the correct proxy. The target VCID is a VCID chosen by the proxy that the client uses when sending forwarded mode packets. The proxy replaces the target VCID with the target CID prior to forwarding the packet to the target.¶

Similarly, QUIC requires that connection IDs aren't reused over multiple network paths to avoid linkability. The client VCID is a connection ID chosen by the proxy that the proxy uses when sending forwarded mode packets. The proxy replaces the client CID with the client VCID prior to forwarding the packet to the client. Clients take advantage of this to avoid linkability when migrating a client to proxy network path. The client VCID allows the connection ID bytes to change on the wire without requiring the connection IDs on the client-to-target connection to change. To reduce the likelihood of connection ID conflicts, the proxy MUST choose a client VCID that is at least as long as the original client CID. Similarly, clients multiplexing connections on the same UDP 4-tuple SHOULD choose a client CID that's sufficiently long to reduce the likelihood of a conflict with the proxy-chosen client VCID. For proxies that share a client-facing IP and port with other proxies, support target-facing port sharing, and cannot guarantee there are no proxies being proxied to, the client VCID MUST be constructed such that it is unpredictable to the client or to guarantee no conflicts among all proxies sharing an IP address and port. For such proxies, a client VCID MUST NOT be equal to the original client CID. See Section 9 for more discussion on client VCID construction.¶

Clients and Proxies not implementing forwarded mode do not need to consider VCIDs since all client-to-target datagrams will be encapsulated within the client-to-proxy connection.¶

3.1. Proxy-QUIC-Forwarding Header

A client initiates UDP proxying via a CONNECT request as defined in [CONNECT-UDP]. Within its request, it includes the "Proxy-QUIC-Forwarding" header to indicate whether or not the request should support forwarding.¶

"Proxy-QUIC-Forwarding" is an Item Structured Header [RFC8941]. Its value MUST be a Boolean.¶

If the client wants to enable QUIC packet forwarding for this request, it sets the value to "?1". Otherwise, it sets the value to "?0" or omits the header.¶

If advertising support for forwarding, the client MUST add an "accept-transform" parameter whose value is a String containing the supported packet transforms (Section 5.7) in order of descending preference, separated by commas. If the proxy receives a "Proxy-QUIC-Forwarding" header with a value of "?1" and without the "accept-transform" parameter, it MUST ignore the header and respond as if the client had not sent the "Proxy-QUIC-Forwarding" header.¶

If advertising support for forwarding, the client MAY add an "active-vcid-limit" parameter whose value is an Integer indicating the maximum number of active Virtual Connection IDs that the proxy can issue for each registered connection ID (Section 5.4). The value MUST be at least 2. If the parameter is absent, a limit of 2 is assumed. If the proxy receives an "active-vcid-limit" parameter whose value is not an Integer or is less than 2, it MUST ignore the header and respond as if the client had not sent the "Proxy-QUIC-Forwarding" header.¶

If the proxy supports forwarded mode for the request, it will include the "Proxy-QUIC-Forwarding" header with a value of "?1" in successful HTTP responses. If the client does not receive this header with a value of "?1", the client SHALL assume that the proxy does not support forwarded mode. If the client receives a transform that it did not advertise support for, it MUST abort the request.¶

The proxy MUST include a "transform" parameter whose value is a String indicating the selected transform. If the proxy does not recognize or accept any of the transforms offered by the client, it MUST omit this parameter and set the header field value to "?0", or omit the header entirely.¶

Clients MUST NOT send the "transform" parameter and proxies MUST NOT send the "accept-transform" or "active-vcid-limit" parameters. Clients MUST ignore receipt of an "accept-transform" or "active-vcid-limit" parameter and proxies MUST ignore receipt of a "transform" parameter.¶

3.2. Proxy-QUIC-Port-Sharing Header

A client may include the "Proxy-QUIC-Port-Sharing" header to indicate whether or not the proxy is permitted to share ports between this QUIC connection and other proxied QUIC connections.¶

"Proxy-QUIC-Port-Sharing" is an Item Structured Header [RFC8941]. Its value MUST be a Boolean.¶

Clients SHOULD send this with a value of "?1" unless the client wishes to prohibit this behavior. Permitting the proxy to share ports may allow the proxy to conserve resources and support more clients. Clients should not advertise support for port sharing unless they are willing to share the same 4-tuple when communicating with the target. Sharing ports with other QUIC connections may result in fate-sharing with clients that might be considered to be untrusted or malicious by the target. Such fate-sharing may impact performance or may lead to being misclassified as malicious.¶

A proxy that supports port sharing for the request includes "Proxy-QUIC-Port-Sharing" with a value of "?1" in its response. A proxy that does not support port sharing, SHOULD send "Proxy-QUIC-Port-Sharing" with a value of "?0". Doing so allows clients to stop sending capsules for this extension if forwarding mode is also not supported.¶

When port sharing is supported and forwarded mode is not, registration of target Connection IDs is permitted, but is not required since port sharing only requires demultiplexing QUIC packets in the target-to-client direction.¶

4.1. Capsule Types and Formats

Register Client CID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Connection ID (0..2040),
}

Register Target CID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Connection ID Length (i),
  Connection ID (0..2040),
  Stateless Reset Token (..),
}

Acknowledge CID Capsule {
  Type (i) = see {{iana}} for the values of the capsule types
  Length (i),
  Connection ID Sequence Number (i),
}

Reject CID Capsule {
  Type (i) = see {{iana}} for the values of the capsule types
  Length (i),
  Reason (i),
  Connection ID Sequence Number (i),
}

Retire CID Capsule {
  Type (i) = see {{iana}} for the values of the capsule types
  Length (i),
  Connection ID Sequence Number (i),
}

Maximum Connection IDs Capsule {
  Type (i) = see {{iana}} for the values of the capsule types
  Length (i),
  Maximum Connection IDs (i),
}

4.2. Client Considerations

The client sends a REGISTER_CLIENT_CID capsule before it advertises a new client CID to the target, and a REGISTER_TARGET_CID capsule when it has received a new target CID for the target. When a connection ID is retired on the client-to-target connection, the client sends the corresponding RETIRE_CLIENT_CID or RETIRE_TARGET_CID capsule. Note that initial REGISTER_CLIENT_CID capsules MAY be sent prior to receiving an HTTP response from the proxy.¶

A client MUST NOT register a connection ID that is already registered on the same request.¶

Connection ID registrations are subject to proxy-advertised limits. Each registration has a corresponding sequence number (Section 4). The client MUST NOT send a registration capsule with a sequence number greater than or equal to the value the proxy advertises for that type of registration via the MAX_CLIENT_CIDS or MAX_TARGET_CIDS capsule. The initial limit for each type is 2, allowing sequence numbers 0 and 1 for a total of two registrations of each type without receiving a MAX_CLIENT_CIDS or MAX_TARGET_CIDS capsule from the proxy.¶

A client that cannot register a new target CID due to the MAX_TARGET_CIDS limit uses tunnelled mode for packets that use that target CID. A client that cannot register a new client CID within a reasonable time due to the MAX_CLIENT_CIDS limit, and cannot continue without it, SHOULD abort the proxied connection by resetting the HTTP stream with the H3_NO_ERROR error code.¶

4.3. Proxy Considerations

The proxy MUST reply to each REGISTER_CLIENT_CID capsule with either an ACK_CLIENT_CID or REJECT_CLIENT_CID capsule containing the sequence number of the registration.¶

Similarly, the proxy MUST reply to each REGISTER_TARGET_CID capsule with either an ACK_TARGET_CID or REJECT_TARGET_CID capsule containing the sequence number of the registration.¶

A proxy that receives a REGISTER_CLIENT_CID or REGISTER_TARGET_CID capsule for a connection ID that is already registered on the same request MUST reset the stream with H3_DATAGRAM_ERROR error code.¶

A proxy that receives a RETIRE_CLIENT_CID or RETIRE_TARGET_CID capsule with a sequence number that the client has not yet used for that type of registration MUST reset the stream with H3_DATAGRAM_ERROR error code. A proxy ignores these capsules for registrations that the client has already retired, or that the proxy has rejected, which can happen when the rejection and retirement capsules are sent simultaneously.¶

The proxy then determines the proxy-to-target 4-tuple to associate with the client's request. This will generally involve performing a DNS lookup for the target hostname in the CONNECT request, or finding an existing proxy-to-target 4-tuple to the authority. The proxy-to-target 4-tuple might already be open due to a previous request from this client, or another. If the 4-tuple is not already created, the proxy creates a new one. Proxies can choose to reuse proxy-to-target 4-tuples across multiple UDP proxying requests, or have a unique proxy-to-target 4-tuple for every UDP proxying request. If the client did not send a value of "?1" for the "Proxy-QUIC-Port-Sharing" header, port reuse is not permitted and the proxy MUST allocate a new UDP 4-tuple.¶

If a proxy reuses proxy-to-target 4-tuples, it SHOULD store which authorities (which could be a domain name or IP address literal) are being accessed over a particular proxy-to-target 4-tuple so it can avoid performing a new DNS query and potentially choosing a different target server IP address which could map to a different target server.¶

Proxy-to-target 4-tuples MUST NOT be reused across QUIC and non-QUIC UDP proxy requests, since it might not be possible to correctly demultiplex or direct the traffic. Any packets received on a proxy-to-target 4-tuple used for proxying QUIC that does not correspond to a known CID MUST be dropped.¶

When the proxy receives a REGISTER_CLIENT_CID capsule, it is receiving a request to be able to route traffic matching the client CID back to the client. If the pair of this client CID and the selected proxy-to-target 4-tuple does not create a conflict, the proxy creates the mapping and responds with an ACK_CLIENT_CID capsule. If the mapping would create a conflict, the proxy responds with a REJECT_CLIENT_CID capsule with the CONFLICT reason code.¶

When the proxy receives a REGISTER_TARGET_CID capsule, it creates the mapping and responds with an ACK_TARGET_CID capsule, or responds with a REJECT_TARGET_CID capsule if it cannot create the mapping, such as due to a conflict (Section 4.3.1).¶

In order to permit the client to change client-to-target connection IDs, the proxy SHOULD send MAX_CLIENT_CIDS and MAX_TARGET_CIDS capsules allowing the client additional connection ID registrations.¶

5.1. Virtual Connection ID Capsule Types and Formats

New Target VCID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Virtual Connection ID Sequence Number (i),
  Retire Prior To (i),
  Virtual Connection ID Length (i),
  Virtual Connection ID (8..2040),
  Stateless Reset Token (..),
}

New Client VCID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Virtual Connection ID Sequence Number (i),
  Virtual Connection ID (8..2040),
}

Acknowledge Client VCID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Virtual Connection ID Sequence Number (i),
  Stateless Reset Token (..),
}

Reject Client VCID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Reason (i),
  Connection ID Sequence Number (i),
  Virtual Connection ID Sequence Number (i),
}

Retire Target VCID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Virtual Connection ID Sequence Number (i),
}

Retire Client VCID Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i),
  Connection ID Sequence Number (i),
  Virtual Connection ID Sequence Number (i),
}

5.2. Issuing Virtual Connection IDs

After acknowledging a target CID registration, a proxy that is willing to forward packets for that target CID issues one or more target VCIDs for it using NEW_TARGET_VCID capsules. The client can use any target VCID that it has received for sending forwarded mode packets, as long as the target VCID has not been retired and the proxy has not requested its retirement. Since the proxy is the endpoint that receives packets using target VCIDs, it MUST be prepared to receive forwarded mode packets using a target VCID before sending the NEW_TARGET_VCID capsule that issues it, and the client does not acknowledge target VCIDs.¶

After acknowledging a client CID registration, a proxy proposes one or more client VCIDs for it using NEW_CLIENT_VCID capsules. Unless it has retired the registration (see below), the client MUST respond to each with an ACK_CLIENT_VCID capsule if it is prepared to receive forwarded mode packets using that client VCID, or with a REJECT_CLIENT_VCID capsule otherwise. A client rejects a client VCID that conflicts with another Connection ID on the client-to-proxy 4-tuple using the CONFLICT reason code, and a client VCID that is too short using the TOO_SHORT reason code. The proxy MUST NOT send forwarded mode packets using a client VCID until it has received an ACK_CLIENT_VCID capsule for it. After receiving a REJECT_CLIENT_VCID capsule, the proxy can propose another client VCID, and SHOULD take the reason code into account when choosing it. If the reason was TOO_SHORT, any client VCID that the proxy proposes next for the same client CID MUST be longer.¶

Each NEW_TARGET_VCID and NEW_CLIENT_VCID capsule carries the sequence number of the Virtual Connection ID that it issues. The first Virtual Connection ID that the proxy issues for a registration has sequence number 0, and each subsequent Virtual Connection ID that it issues for the same registration has a sequence number one greater than the previous one. Capsules refer to a Virtual Connection ID by the sequence number of its registration and its own sequence number. A client that receives one of these capsules for a registration that it has not retired, with a sequence number that is not the next one for that registration, MUST reset the stream with H3_DATAGRAM_ERROR error code.¶

Proxies MUST choose unpredictable target VCIDs to avoid forwarding loop attacks, and MUST use target VCIDs that do not introduce a conflict with any other Connection ID on the client-to-proxy 4-tuple. Requirements for choosing client VCIDs are described in Section 2.2.¶

A proxy SHOULD keep at least one unused Virtual Connection ID available for each registered connection ID that it forwards packets for, issuing new ones as others are retired, within the limit set by the client (Section 5.4). This allows the endpoint that sends packets to switch to an unused Virtual Connection ID without first exchanging capsules, for example when the network path changes (Section 5.9).¶

A client ignores NEW_TARGET_VCID and NEW_CLIENT_VCID capsules for a registration that it has already retired, which can happen when the retirement and issuance capsules are sent simultaneously. These Virtual Connection IDs are retired along with the others for that registration when the proxy processes the corresponding RETIRE_CLIENT_CID or RETIRE_TARGET_CID capsule (Section 5.3). A client that receives one of these capsules for a registration that the proxy has not acknowledged MUST reset the stream with H3_DATAGRAM_ERROR error code.¶

5.3. Retiring Virtual Connection IDs

The client retires target VCIDs using RETIRE_TARGET_VCID capsules, and the proxy retires client VCIDs using RETIRE_CLIENT_VCID capsules. An endpoint retires a Virtual Connection ID when it will no longer send packets using it, for example after the network path changes (Section 5.9). An endpoint checks for the Stateless Reset Token associated with a Virtual Connection ID only after it has sent packets using that Virtual Connection ID (Section 10.3.1 of [QUIC]). Before sending the capsule that retires a Virtual Connection ID, the endpoint MUST stop sending forwarded mode packets using it and MUST stop checking for the associated Stateless Reset Token.¶

Until a Virtual Connection ID is retired, the endpoint that receives packets using it MUST keep its state for that Virtual Connection ID, and MUST NOT send a Stateless Reset in response to packets that use it, since its peer might still act on the corresponding Stateless Reset Token. Once it has received the capsule that retires the Virtual Connection ID, it can remove all state for it. Packets that use a retired Virtual Connection ID and arrive later, for example due to reordering, can be dropped or answered with a Stateless Reset, which the peer will ignore.¶

When a registration is retired, the Virtual Connection IDs associated with it are retired as well:¶

• Before sending a RETIRE_TARGET_CID capsule, the client MUST stop using all target VCIDs for that target CID and stop checking for their Stateless Reset Tokens. These target VCIDs are retired once the proxy receives the capsule.¶

• After sending a RETIRE_CLIENT_CID capsule, the client continues to accept packets using the client VCIDs for that client CID, and MUST NOT send Stateless Resets in response to them, until they are retired. Upon receiving the RETIRE_CLIENT_CID capsule, the proxy MUST stop using and stop checking for the Stateless Reset Tokens of all client VCIDs for that client CID, and retire each of them with a RETIRE_CLIENT_VCID capsule.¶

A proxy can also withdraw a client VCID that it has proposed, before the client accepts it, by retiring it. A proxy ignores ACK_CLIENT_VCID and REJECT_CLIENT_VCID capsules for client VCIDs that it has already retired, such as those that it has withdrawn, and a client ignores RETIRE_CLIENT_VCID capsules for client VCIDs that are not active, such as those that it has rejected or ignored. A proxy that receives an ACK_CLIENT_VCID or REJECT_CLIENT_VCID capsule with a Virtual Connection ID sequence number that it has not yet used for that registration MUST reset the stream with H3_DATAGRAM_ERROR error code. Likewise, a client that receives a RETIRE_CLIENT_VCID capsule for a registration that it has not retired, with a Virtual Connection ID sequence number that the proxy has not yet used for that registration, MUST reset the stream with H3_DATAGRAM_ERROR error code.¶

A proxy that receives a RETIRE_TARGET_VCID capsule for a target VCID that it did not issue, or that is already retired, MUST reset the stream with H3_DATAGRAM_ERROR error code.¶

5.4. Limiting Active Virtual Connection IDs

The client limits the number of active Virtual Connection IDs that the proxy issues for each registered connection ID using the "active-vcid-limit" parameter of the "Proxy-QUIC-Forwarding" header (Section 3.1), much like the active_connection_id_limit transport parameter of QUIC (Section 18.2 of [QUIC]). Unlike that transport parameter, the limit applies to each registered connection ID separately, and only the client sets one, since the proxy chooses all Virtual Connection IDs.¶

A Virtual Connection ID counts toward the limit while it is active, whether or not any packets have been sent using it. A target VCID is active from when the client receives it until the client retires it. A client VCID is active from when the client receives it until the client rejects it or receives a RETIRE_CLIENT_VCID capsule for it. The proxy MUST NOT send a NEW_TARGET_VCID or NEW_CLIENT_VCID capsule that would cause the number of active Virtual Connection IDs for a connection ID to exceed the limit.¶

Since capsules are processed in order, a proxy that has reached the limit can replace a Virtual Connection ID without waiting for a round trip. For client VCIDs, it retires one before proposing its replacement. For target VCIDs, it issues the replacement in a NEW_TARGET_VCID capsule whose Retire Prior To field asks the client to retire at least one target VCID, which the client does before adding the new one (Section 5.3.1). As in QUIC (Section 5.1.1 of [QUIC]), the proxy can therefore issue a target VCID that temporarily exceeds the limit from its own point of view, until it receives the corresponding RETIRE_TARGET_VCID capsules.¶

After processing a NEW_TARGET_VCID or NEW_CLIENT_VCID capsule, including retiring any target VCIDs that it asks the client to retire, a client that has more active Virtual Connection IDs for the connection ID than the limit allows MUST reset the stream with H3_DATAGRAM_ERROR error code.¶

5.5. Sending With Forwarded Mode

Support for forwarded mode is determined by the "Proxy-QUIC-Forwarding" header, see Section 3.1.¶

Once the client has learned the target server's Connection ID, such as in the response to a QUIC Initial packet, it can send a REGISTER_TARGET_CID capsule containing the target CID to request the ability to forward packets.¶

Forwarded mode requires connection IDs to be registered and Virtual Connection IDs to be issued, and, as a consequence, cannot be leveraged without a round trip. This is particularly pronounced when chaining proxies because registration happens sequentially. While waiting for forwarded mode to become enabled, clients SHOULD communicate over tunnelled mode to avoid end-to-end delays.¶

Prior to receiving the proxy's response, the client MUST send short header packets tunnelled in HTTP Datagram frames. The client MAY also choose to tunnel some short header packets even after receiving the successful response.¶

If the proxy rejects the target CID registration or does not issue any target VCIDs for it, the client continues to use tunnelled mode for that target CID.¶

QUIC long header packets MUST NOT be forwarded. These packets can only be tunnelled within HTTP Datagram frames to avoid exposing unnecessary connection metadata.¶

When forwarding, the client sends a QUIC packet with the target VCID in the QUIC short header, using the same 4-tuple between client and proxy that was used for the main QUIC connection between client and proxy.¶

The proxy will forward to the target any short header packets received from the client that use one of its target VCIDs, after first rewriting the target VCID to be the correct target CID and executing the negotiated transform.¶

The proxy MUST only forward non-tunnelled packets from the client that are QUIC short header packets (based on the Header Form bit), that use target VCIDs that the proxy has issued and that have not been retired, and that arrive from a client address from which the proxy accepts forwarded mode packets (Section 5.9). Packets sent by the client that are forwarded SHOULD be considered as activity for restarting QUIC's Idle Timeout [QUIC].¶

When forwarding, the proxy sends a QUIC packet with the client VCID in the QUIC short header, using the same 4-tuple between client and proxy that was used for the main QUIC connection between client and proxy.¶

Prior to sending a forwarded mode packet, the sender MUST replace the Connection ID with the Virtual Connection ID. If the Virtual Connection ID is larger than the Connection ID, the sender MUST extend the length of the packet by the difference between the two lengths, to include the entire Virtual Connection ID. If the Virtual Connection ID is smaller than the Connection ID, the sender MUST shrink the length of the packet by the difference between the two lengths.¶

Clients and proxies supporting forwarded mode MUST be able to handle Virtual Connection IDs of different lengths than the corresponding Connection IDs.¶

5.6. Receiving With Forwarded Mode

Once the client has acknowledged a client VCID, the proxy SHOULD forward to the client any short header packets from the target that use the corresponding client CID, after replacing that client CID with the client VCID and executing the negotiated transform (Section 5.7).¶

Once a client has sent an ACK_CLIENT_VCID capsule to the proxy, it MUST be prepared to receive forwarded short header packets on the 4-tuple between itself and the proxy for the specified client VCID, until that client VCID is retired (Section 5.3).¶

The client uses the Destination Connection ID field of the received packet to determine if the packet was originated by the proxy, or merely forwarded from the target. The client replaces the client VCID with the real client CID before processing the packet further.¶

Clients can cease receiving with forwarded mode over an existing tunnel while retaining the same client-to-target connection by creating a new tunnel with "Proxy-QUIC-Forwarding" set to "?0" and migrating the client-to-target connection.¶

5.7. Packet Transforms

A packet transform is the procedure applied to encode packets as they are sent on the link between the client and proxy, along with the inverse decode step applied on receipt. When sending packets, the packet transform is applied after replacing a CID with a VCID. When receiving packets, the packet transform is applied before replacing a VCID with a CID.¶

Simple transforms can be modeled as a function as follows:¶

Inputs:¶

1. A QUIC short header packet with a VCID.¶

2. The mode (encode or decode).¶

3. The direction (client-to-proxy or proxy-to-client).¶

4. Any configuration information negotiated at startup.¶

Output:¶

• A UDP payload that conforms to the QUIC invariants [INVARIANTS] and does not modify the Connection ID.¶

More complex transform behaviors could have internal state, but no such transforms are presented here.¶

Packet transforms are identified by an IANA-registered name, and negotiated in the HTTP headers (see Section 3.1). This document defines two initial transforms: the identity transform and the scramble transform.¶

5.8. Connection Maintenance in Forwarded Mode

When a client and proxy are using forwarded mode, it is possible that there can be long periods of time in which no ack-eliciting packets (see Section 2 of [QUIC-RETRANSMISSION]) are exchanged between the client and proxy. If these periods extend beyond the effective idle timeout for the client-to-proxy QUIC connection (see Section 10.1 of [QUIC]), the QUIC connection might be closed by the proxy if the proxy does not use forwarded packets as an explicit liveness signal. To avoid this, clients SHOULD send keepalive packets to the proxy before the idle timeouts would be reached, which can be done using a PING frame or another ack-eliciting frame as described in Section 10.1.1 of [QUIC].¶

5.9. Handling Connection Migration

If a proxy supports QUIC connection migration, it needs to ensure that a migration event does not end up sending too many tunnelled or forwarded packets on a new path prior to path validation.¶

Specifically, the proxy MUST NOT forward packets to an unvalidated client address. Proxies additionally SHOULD pace the rate at which packets are sent over a new path to avoid creating unintentional congestion on the new path.¶

When operating in forwarded mode, the proxy reconfigures forwarding rules (i.e., the mappings for VCIDs) as the network path between the client and proxy changes. As with connection IDs in QUIC (Section 9.5 of [QUIC]), a Virtual Connection ID MUST NOT be used for sending packets on more than one network path, other than when the peer's address changes without its knowledge, such as due to NAT rebinding. Since the proxy issues more than one Virtual Connection ID for each connection ID (Section 5.2), the client and proxy can switch to a Virtual Connection ID that they have not used before when the network path changes, without first exchanging capsules.¶

Since forwarded mode packets are not authenticated, a proxy only accepts them from a client address once it has successfully processed a client-to-proxy QUIC packet from that address, that is, a packet that it decrypted and did not discard as a duplicate (Section 12.3 of [QUIC]), including a probing packet (Section 9.1 of [QUIC]). Otherwise, an attacker that has observed a target VCID could use it to inject packets toward the target from any address (Section 9.2).¶

The proxy continues to accept forwarded mode packets from an address for as long as it maintains state for the network path to that address, such as a network path that the client is probing or the previous network path after a migration (Section 9.3.2 of [QUIC]), unless path validation to that address fails. The proxy drops forwarded mode packets that arrive from any other address. Regardless of the address that they arrive from, the proxy does not send a Stateless Reset in response to forwarded mode packets that use a target VCID that has not been retired (Section 5.3).¶

The proxy sends forwarded mode packets to the client only at the address that the client-to-proxy QUIC connection uses, and only once that address is validated. That address only changes when the client-to-proxy QUIC connection migrates (Section 9.3 of [QUIC]), and never in response to forwarded mode packets. While the client-to-proxy QUIC connection uses an address that it has not yet validated, the proxy tunnels packets for the client in HTTP Datagram frames instead, subject to the anti-amplification limit for that address (Section 8 of [QUIC]).¶

5.10. Handling Server Preferred Addresses

QUIC allows servers to tell clients about a preferred address the server would like to use (Section 9.6 of [QUIC]). When this happens, the client can migrate to the preferred address.¶

When a client using a proxy wants to migrate to the preferred address of the target server, it needs to create a new UDP proxying request to the proxy (using the method defined in [CONNECT-UDP]) and using the preferred IP address of the target as the host to which to connect. This is the behavior clients using a proxy will have regardless of using the QUIC-aware mechanisms defined in this document. From the proxy's perspective, the migrating request is separate from the original request.¶

Note that clients can be aware of the target address being used for the original proxy request by looking at next-hop parameter on a Proxy-Status header sent by the proxy in its response (Section 2.1.2 of [RFC9209]). This allows a client to know if it ought to migrate to the preferred address, or is already connected to the preferred address. To support the ability of clients to do this, proxies implementing this specification SHOULD send the Proxy-Status header in responses and include the next-hop parameter.¶

5.11. Handling ECN Marking

Explicit Congestion Notification marking [ECN] uses two bits in the IP header to signal congestion from a network to endpoints. When using forwarded mode, the proxy replaces IP headers for packets exchanged between the client and target; these headers can include ECN markings. Proxies SHOULD preserve ECN markings on forwarded packets in both directions, to allow ECN to function end-to-end. If the proxy does not preserve ECN markings, it MUST set ECN marks to zero on the IP headers it generates.¶

Forwarded mode does not create an IP-in-IP tunnel, so the guidance in [ECN-TUNNEL] about transferring ECN markings between inner and outer IP headers does not apply.¶

A proxy MAY additionally add ECN markings to signal congestion being experienced on the proxy itself.¶

Forwarding ECN markings introduces certain active attacks. See Section 9.2 for more detail.¶

5.12. Stateless Resets for Forwarded Mode QUIC Packets

While the lifecycle of forwarding rules is bound to the lifecycle of the client-to-proxy HTTP stream, a peer may not be aware that the stream has terminated. If the forwarding rules are lost or removed without the peer's knowledge, the peer may send forwarded mode packets even though the client or proxy no longer has state for that connection. To allow the client or proxy to signal this, a Stateless Reset Token can be provided for each Virtual Connection ID. A Stateless Reset for a target VCID resets the client-to-target connection, and a Stateless Reset for a client VCID causes the proxy to reset the request stream (Section 5.1.3).¶

When a Virtual Connection ID is retired intentionally, the procedures in Section 5.3 ensure that the peer has stopped checking for the corresponding Stateless Reset Token before a Stateless Reset can be sent for it, so that retiring a Virtual Connection ID never has either effect.¶

Consider a proxy that initiates closure of a client-to-proxy QUIC connection. If the client is temporarily unresponsive or unreachable, the proxy might have considered the connection closed and removed all connection state (including the stream mappings used for forwarding). If the client never learned about the closure, it might send forwarded mode packets to the proxy, assuming the stream mappings and client-to-proxy connection are still intact. The proxy will receive these forwarded mode packets, but won't have any state corresponding to the destination connection ID in the packet. If the proxy has provided a stateless reset token for the target VCID, it can send a stateless reset packet to quickly notify the client that the client-to-target connection is broken.¶

Stateless Resets sent by the target do not contain a negotiated connection ID, so the proxy sends them to the client as tunnelled datagrams (Section 4.3.2), even when forwarded mode is enabled.¶

9.1. Passive Attacks

A passive attacker aims to deanonymize a client by correlating traffic across both sides of the proxy. When using forwarded mode with the identity packet transform (see Section 5.7.1), such correlation is trivial by matching a subset of QUIC packet bytes as packets enter the proxy on one side and exit on the other. Packet transforms such as scramble mitigate this by cryptographically preventing such byte comparisons (see Section 5.7.2).¶

Regardless of which packet transform is used, both tunnelled and forwarded mode are still vulnerable to size and timing attacks, without the addition of techniques that go beyond the analysis in this document, such as padding and adding chaff packets. Such techniques could be supported in future packet transforms, subject to additional security analysis.¶

Unlike tunnelled mode where packets are fully encapsulated in the client-to-proxy connection, clients using forwarded mode to access multiple target servers over the same client-to-proxy connection expose the number of target servers they are communicating with on each connection to passive attackers that can observe the client-to-proxy traffic. This additional metadata revealed on each packet simplifies size and timing attacks.¶

9.2. Active Attacks

An active attacker is an adversary that can inject, modify, drop, and view packets in the network. Some active attacks have different effects between forwarded mode and tunnelled mode, but active attacks can be used to correlate flows in either mode.¶

Both tunnelled mode and forwarded mode (regardless of packet transform) are vulnerable to packet injection in the target-to-client direction. An attacker can inject a burst of packets with a known QUIC Connection ID and see which Connection ID is used for the corresponding burst on the proxy-to-client network path.¶

Forwarded mode is vulnerable to some active attacks that tunnelled mode is not. For example, packet injection with a known QUIC Connection ID can also happen in the client-to-proxy direction, which only affects forwarded mode since tunnelled mode sends packets within an authenticated and integrity protected QUIC connection to the proxy (see [RFC9001]). None of the packet transforms defined in this document provide integrity protection. Even if a packet transform did provide integrity protection, attackers can inject replayed packets. Protection against replayed packets is similarly provided by QUIC in tunnelled mode, but not provided by any of the forwarded mode packet transforms defined in this document. Similarly, Forwarded mode packets are vulnerable to active attacks when [ECN] markings are forwarded. Specifically, an attacker could embed a signal over a series of packets by clearing or setting ECN bits. This attack is possible without injecting, dropping, or modifying the QUIC packet, but instead modifying the packet's IP header.¶

An active attacker can modify packets in the client-to-proxy direction, which would cause a tunnelling proxy to silently drop packets, while a forwarding proxy would forward the packets. In this way, forwarded mode is less vulnerable to flow recognition based on corrupting a portion of packets in a burst.¶

9.3. Connection ID Registration Attacks

Chaining of proxies using forwarded mode introduces the risk of forwarding loop attacks. Proxies are known to be vulnerable to one such forwarding loop attack when sharing an IP address and port with other proxies, supporting target-facing port sharing, and proxying to other proxies. Preventing client VCID conflicts across proxies sharing an IP address and port mitigates one such forwarding loop attack. Conflicts can be avoided by partitioning the client VCID space across proxies, using sufficiently long and random values, or by other means.¶

10.1. HTTP Header Fields

This document registers the "Proxy-QUIC-Forwarding" and "Proxy-QUIC-Port-Sharing" header fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" <https://www.iana.org/assignments/http-fields>.¶

    +-------------------------+-----------+-----------------+---------------+----------+
    |      Field Name         |  Status   | Structured Type |   Reference   | Comments |
    +-------------------------+-----------+-----------------+---------------+----------+
    | Proxy-QUIC-Forwarding   | permanent |      Item       | This document |   None   |
    | Proxy-QUIC-Port-Sharing | permanent |      Item       | This document |   None   |
    +-------------------------+-----------+-----------------+---------------+----------+

10.2. Proxy QUIC Forwarding Parameter Names

This document establishes a new registry, "Proxy QUIC Forwarding Parameter Names", for parameter names to use with the "Proxy-QUIC-Forwarding" header field, in <https://www.iana.org/assignments/masque/masque.xhtml>. Registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [IANA-POLICY]).¶

10.3. Packet Transform Names

This document establishes a new registry for packet transform names in <https://www.iana.org/assignments/masque/masque.xhtml> and defines two initial transforms: "identity" and "scramble". Until the scramble transform is finalized, deployments use the value "scramble-dt" instead of the reserved value "scramble" (see Section 5.7.2). Registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [IANA-POLICY]).¶

10.4. CID Capsule Reason Codes

This document establishes a new registry, "CID Capsule Reason Codes", for reason codes used in REJECT_CLIENT_CID, REJECT_TARGET_CID, and REJECT_CLIENT_VCID capsules, in <https://www.iana.org/assignments/masque/masque.xhtml>. This registry governs a 62-bit space and operates under the QUIC registration policy documented in Section 22.1 of [QUIC]. This new registry includes the common set of fields listed in Section 22.1.1 of [QUIC]. In addition to those common fields, all registrations in this registry MUST include a "Name" field that contains a short name or label for the Reason.¶

Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [IANA-POLICY]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [IANA-POLICY].¶

10.5. Capsule Types

This document registers sixteen new values in the "HTTP Capsule Types" registry established by [HTTP-CAPSULES]. Note that the codepoints below will be replaced with lower values before publication.¶

All of these new entries use the following values for these fields:¶

Status:

provisional (permanent when this document is published)¶

Reference:

This document¶

Change Controller:

IETF¶

Contact:

masque@ietf.org¶

Notes:

None¶

11.1. Normative References

[CONNECT-UDP]

Schinazi, D., "Proxying UDP in HTTP", RFC 9298, DOI 10.17487/RFC9298, August 2022, <https://www.rfc-editor.org/rfc/rfc9298>.

[ECN]

Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/rfc/rfc3168>.

[HTTP3]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

[HTTP-CAPSULES]

Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, <https://www.rfc-editor.org/rfc/rfc9297>.

[IANA-POLICY]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[INVARIANTS]

Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, <https://www.rfc-editor.org/rfc/rfc8999>.

[QUIC]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[QUIC-RETRANSMISSION]

Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8941]

Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, <https://www.rfc-editor.org/rfc/rfc8941>.

[SP800-38A]

Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", 1 December 2001, <https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf>.

11.2. Informative References

[ECN-TUNNEL]

Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/rfc/rfc6040>.

[QUIC-GREASE]

Thomson, M., "Greasing the QUIC Bit", RFC 9287, DOI 10.17487/RFC9287, August 2022, <https://www.rfc-editor.org/rfc/rfc9287>.

[QUIC-LB]

Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet-Draft, draft-ietf-quic-load-balancers-22, 23 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-22>.

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.

[RFC9209]

Nottingham, M. and P. Sikora, "The Proxy-Status HTTP Response Header Field", RFC 9209, DOI 10.17487/RFC9209, June 2022, <https://www.rfc-editor.org/rfc/rfc9209>.

[RFC9308]

Kühlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", RFC 9308, DOI 10.17487/RFC9308, September 2022, <https://www.rfc-editor.org/rfc/rfc9308>.