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 AAAA0000 and a target CID 0000AAAA, and client B's connection to the target has negotiated a client CID BBBB0000 and a target CID 0000BBBB, 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 AAAA0000 or BBBB0000.¶

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.8 for more discussion of handlng 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 4.¶

For example, consider a proxy using HTTP/3 that has a single client connected to it. The client-to-proxy QUIC connection has CCCC0000 as the client CID and 0000CCCC as the proxy CID. The client has connected to a single target through the proxy, and the client-to-target QUIC connection has CCCC1111 as the client CID and 1111CCCC 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 CCCC2222 for the client's VCID and 2222CCCC for the proxy's VCID that it uses to forward to the target.¶

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 Virtual client CID allows the connection ID bytes to change on the wire without requiring the connection IDs on the client to target connection 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. The client VCID MUST either be constructed such that it is unpredictable to the client or to guarantee no conflicts among all proxies sharing an IP address and port. See Section 8 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.¶

2.3. Negotiating Modes and Connection IDs

In order to support QUIC-aware proxying, both clients and proxies need to support capsules [HTTP-CAPSULES], which is indicated by including the "Capsule-Protocol" header field in requests and responses. If this header field is not included, none of the functionality in this document can be used.¶

  capsule-protocol = ?1

To support forwarded mode, both clients and proxies need to include the "Proxy-QUIC-Forwarding" header field, as defined in Section 3. This indicates support for forwarded mode, and allows negotiation of packet transforms to apply when forwarding (Section 5.3), along with any parameters for specific transforms. Clients or proxies that don't support forwarded mode will not include this header field.¶

  proxy-quic-forwarding = ?1; accept-transform=scramble,identity; \
      scramble-key=:abc...789=:

After negotiating support with header fields, clients and proxies use the capsules defined in Section 4 to communicate information about CIDs and VCIDs.¶

For QUIC-aware proxying without forwarded mode, the steps are as follows:¶

1. The client sends the REGISTER_CLIENT_CID capsule once it selects a CID that it will use for receiving packets from a target.¶

2. The proxy sends the ACK_CLIENT_CID capsule to acknowledge that CID, with no associated client VCID; alternatively, the proxy can send the CLOSE_CLIENT_CID if it detects a conflict with another CID.¶

3. The client sends the REGISTER_TARGET_CID capsule as soon as it learns the target CID on the client-to-target connection.¶

4. The proxy sends the ACK_TARGET_CID capsule to acknowledge that CID, with no associated target VCID; alternatively, the proxy can send the CLOSE_TARGET_CID if it detects a conflict with another CID.¶

5. The proxy sends the MAX_CONNECTION_IDS capsule to allow additional registration of new connection IDs via future REGISTER_CLIENT_CID and REGISTER_TARGET_CID capsules.¶

6. Whenever a client or target stops uses a particular CID, the client sends a CLOSE_CLIENT_CID or CLOSE_TARGET_CID capsule. The client can also initiate new REGISTER_CLIENT_CID or REGISTER_TARGET_CID exchanges at any time.¶

For QUIC-aware proxying with forwarded mode, the steps are as follows:¶

1. The client sends the REGISTER_CLIENT_CID capsule once it selects a CID that it will use for receiving packets from a target.¶

2. The proxy sends the ACK_CLIENT_CID capsule to acknowledge that CID, with a client VCID; alternatively, the proxy can send the CLOSE_CLIENT_CID if it detects a conflict with another CID.¶

3. The client sends the ACK_CLIENT_VCID capsule to acknowledge the client VCID, which allows forwarded packets for that VCID to be used.¶

4. The client sends the REGISTER_TARGET_CID capsule as soon as it learns the target CID on the client-to-target connection.¶

5. The proxy sends the ACK_TARGET_CID capsule to acknowledge that CID, with a target VCID; alternatively, the proxy can send the CLOSE_TARGET_CID if it detects a conflict with another CID. Once the client receives the target VCID, it can start sending forwarded packets using the target VCID.¶

6. The proxy sends the MAX_CONNECTION_IDS capsule to allow additional registration of new connection IDs via future REGISTER_CLIENT_CID and REGISTER_TARGET_CID capsules.¶

7. Whenever a client or target stops uses a particular CID, the client sends a CLOSE_CLIENT_CID or CLOSE_TARGET_CID capsule. The client can also initiate new REGISTER_CLIENT_CID or REGISTER_TARGET_CID exchanges at any time.¶

4.1. REGISTER_CLIENT_CID

The REGISTER_CLIENT_CID capsule is sent by the client and contains a single connection ID that is the client-provided connection ID on the client-to-target QUIC connection.¶

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

Connection ID:

A connection ID being registered, which is between 0 and 255 bytes in length. The length of the connection ID is implied by the length of the capsule. Note that in QUICv1, the length of the Connection ID is limited to 20 bytes, but QUIC invariants allow up to 255 bytes.¶

4.2. REGISTER_TARGET_CID

The REGISTER_TARGET_CID capsule is sent by the client and includes the target-provided connection ID on the client-to-target QUIC connection, and the corresponding Stateless Reset Token.¶

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

Connection ID Length

The length of the connection ID being registered, which is between 0 and 255. Note that in QUICv1, the length of the Connection ID is limited to 20 bytes, but QUIC invariants allow up to 255 bytes.¶

Connection ID

A connection ID being registered whose length is equal to Connection ID Length. This is the real target CID.¶

Stateless Reset Token Length

The length of the target-provided Stateless Reset Token.¶

Stateless Reset Token

The target-provided Stateless Reset token allowing the proxy to correctly recognize Stateless Reset packets to be tunnelled to the client.¶

4.3. ACK_CLIENT_CID

The ACK_CLIENT_CID capsule is sent by the proxy in response to a REGISTER_CLIENT_CID capsule. It optionally assigns a Virtual Connection ID when forwarded mode is supported.¶

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

Connection ID Length

The length of the connection ID being acknowledged, which is between 0 and 255. Note that in QUICv1, the length of the Connection ID is limited to 20 bytes, but QUIC invariants allow up to 255 bytes.¶

Connection ID

A connection ID being acknowledged whose length is equal to Connection ID Length. This is the real Cilent Connection ID.¶

Virtual Connection ID Length

The length of the client VCID being provided. This MUST be a valid connection ID length for the QUIC version used in the client-to-proxy QUIC connection. When forwarded mode is not negotiated, the length MUST be zero. The Virtual Connection ID Length and Connection ID Length SHOULD be equal when possible to avoid the need to resize packets during replacement. The client VCID Length MUST be at least as large as the Connection ID to reduce the likelihood of connection ID conflicts.¶

Virtual Connection ID

The proxy-chosen connection ID that the proxy MUST use when sending in forwarded mode. The proxy rewrites forwarded mode packets to contain the correct client VCID prior to sending them to the client.¶

4.4. ACK_TARGET_CID

The ACK_TARGET_CID capsule is sent by the proxy in response to a REGISTER_TARGET_CID capsule. It optionally assigns a Virtual Connection ID and Stateless Reset Token if forwarded mode is enabled.¶

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

Connection ID Length

The length of the connection ID being acknowledged, which is between 0 and 255. Note that in QUICv1, the length of the Connection ID is limited to 20 bytes, but QUIC invariants allow up to 255 bytes.¶

Connection ID

A connection ID being acknowledged whose length is equal to Connection ID Length. This is the real target CID.¶

Virtual Connection ID Length

The length of the target VCID being provided. This MUST be a valid connection ID length for the QUIC version used in the client-to-proxy QUIC connection. When forwarded mode is not negotiated, the length MUST be zero. The Virtual Connection ID Length and Connection ID Length SHOULD be equal when possible to avoid the need to resize packets during replacement.¶

Virtual Connection ID

The proxy-chosen connection ID that the client MUST use when sending in forwarded mode. The proxy rewrites forwarded mode packets to contain the correct target CID prior to sending them.¶

Stateless Reset Token Length

The length of the Stateless Reset Token sent by the proxy in response to forwarded mode packets in order to reset the client-to-target QUIC connection. When forwarded mode is not negotiated, the length MUST be zero. Proxies choosing not to support stateless resets MAY set the length to zero. Clients receiving a zero-length stateless reset token MUST ignore it.¶

Stateless Reset Token

A Stateless Reset Token allowing reset of the client-to-target connection in response to client-to-target forwarded mode packets.¶

4.5. ACK_CLIENT_VCID

The ACK_CLIENT_VCID capsule type is sent by the client in response to an ACK_TARGET_CID capsule that contains a virtual connection ID.¶

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

Connection ID Length

The length of the connection ID being acknowledged, which is between 0 and 255. Note that in QUICv1, the length of the Connection ID is limited to 20 bytes, but QUIC invariants allow up to 255 bytes.¶

Connection ID

A connection ID being acknowledged whose length is equal to Connection ID Length. This is the real Cilent Connection ID.¶

Virtual Connection ID Length

The length of the client VCID being acknowledged.¶

Virtual Connection ID

The proxy-chosen virtual connection ID being acknowledged whose length is equal to Virtual Connection ID Length.¶

Stateless Reset Token Length

The length of the Stateless Reset Token that may be sent by the client in response to forwarded mode packets to reset the client-to-target connection. Clients choosing not to support stateless resets MAY set the length to zero. Proxies receiving a zero-length stateless reset token MUST ignore it.¶

Stateless Reset Token

A Stateless Reset Token allowing reset of the target-to-client forwarding rule in response to target-to-client forwarded mode packets.¶

4.6. CLOSE_CLIENT_CID and CLOSE_TARGET_CID

CLOSE_CLIENT_CID and CLOSE_TARGET_CID capsule types include a single connection ID to close. They can be sent by either clients or proxies.¶

Close CID Capsule {
  Type (i) = see {{iana}} for the values of the capsule types
  Length (i),
  Connection ID (0..2040),
}

Connection ID:

A connection ID being closed, which is between 0 and 255 bytes in length. The length of the connection ID is implied by the length of the capsule. Note that in QUICv1, the length of the Connection ID is limited to 20 bytes, but QUIC invariants allow up to 255 bytes.¶

4.7. MAX_CONNECTION_IDS

The MAX_CONNECTION_IDS capsule is sent by the proxy to permit additional connection ID registrations.¶

Maximum Connection IDs Capsule {
  Type (i) = see {{iana}} for the value of the capsule type
  Length (i)
  Maximum Sequence Number (i)
}

Maximum Sequence Number

The maximum permitted sequence number for connection ID registrations. This MUST NOT be less than 1.¶

4.8. Detecting Conflicts

In order to be able to route packets correctly in both tunnelled and forwarded mode, proxies check for conflicts before creating a new CID mapping. If a conflict is detected, the proxy will reject the client's request using a CLOSE_CLIENT_CID or CLOSE_TARGET_CID capsule.¶

Two 4-tuples conflict if and only if all members of the 4-tuple (local IP address, local UDP port, remote IP address, and remote UDP port) are identical.¶

Two Connection IDs conflict if and only if one Connection ID is equal to or a prefix of another. For example, a zero-length Connection ID conflicts with all connection IDs. This definition of a conflict originates from the fact that QUIC short headers do not carry the length of the Destination Connection ID field, and therefore if two short headers with different Destination Connection IDs are received on a shared 4-tuple, one being a prefix of the other prevents the receiver from identifying which mapping this corresponds to.¶

The proxy treats two mappings as being in conflict when a conflict is detected for all elements on the left side of the mapping diagrams above.¶

Since very short Connection IDs are more likely to lead to conflicts, particularly zero-length Connection IDs, a proxy MAY choose to reject all requests for very short Connection IDs as conflicts, in anticipation of future conflicts.¶

4.9. Client Considerations

The client sends a REGISTER_CLIENT_CID capsule whenever 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. In order to change the connection ID bytes on the wire, a client can solicit new virtual connection IDs by re-registering the same connection IDs. The client may solicit a new target VCID by sending a REGISTER_TARGET_CID capsule with a previously registered target CID. Similarly, the client may solicit a new client VCID by sending a REGISTER_CLIENT_CID with a previously registered client CID. The client MUST acknowledge the new client VCID with an ACK_CLIENT_VCID capsule or close the registration. The proxy MUST NOT send in forwarded mode until ACK_CLIENT_VCID has been received. Clients are responsible for changing Virtual Connection IDs when the HTTP stream's network path changes to avoid linkability across network paths. Note that initial REGISTER_CLIENT_CID capsules MAY be sent prior to receiving an HTTP response from the proxy.¶

Connection ID registrations are subject to a proxy-advertised limit. Each registration has a corresponding sequence number. The client MUST NOT send a registration capsule with a sequence number greater than what the proxy advertises via the MAX_CONNECTION_IDS capsule. The initial MAX_CONNECTION_IDS value is 1, allowing both sequence numbers 0 and 1 for a total of two registrations without receiving a MAX_CONNECTION_IDS capsule from the proxy.¶

Clients that cannot register new connection IDs within a reasonable time due to the MAX_CONNECTION_IDS limit SHOULD abort the proxied connection by resetting the HTTP stream with error code NO_ERROR. This may happen, for example, if the target server sends a NEW_CONNECTION_ID frame with Sequence Number and Retire Prior To equal to the same value.¶

4.10. Proxy Considerations

The proxy MUST reply to each REGISTER_CLIENT_CID capsule with either an ACK_CLIENT_CID or CLOSE_CLIENT_CID capsule containing the Connection ID that was in the registration capsule.¶

Similarly, the proxy MUST reply to each REGISTER_TARGET_CID capsule with either an ACK_TARGET_CID or CLOSE_TARGET_CID capsule containing the Connection ID that was in the registration capsule.¶

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 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 recieves a REGISTER_CLIENT_CID capsule, it is receiving a request to be able to route traffic matching the client CID back to the client using. 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 forwarded mode is enabled, the capsule contains a proxy-chosen client VCID. If forwarded mode is enabled, and after receiving an ACK_CLIENT_VCID capsule from the client, any packets received by the proxy from the proxy-to-target 4-tuple that match the client CID can to be sent to the client after the proxy has replaced the CID with the client VCID. If forwarded mode is not supported, the proxy MUST NOT send a client VCID by setting the length to zero. The proxy MUST use tunnelled mode (HTTP Datagram frames) for any long header packets. The proxy SHOULD forward directly to the client for any matching short header packets if forwarding is supported by the client, but the proxy MAY tunnel these packets in HTTP Datagram frames instead. If the mapping would create a conflict, the proxy responds with a CLOSE_CLIENT_CID capsule.¶

When the proxy recieves a REGISTER_TARGET_CID capsule, it is receiving a request to allow the client to forward packets to the target. The proxy generates a target VCID for the client to use when sending packets in forwarded mode. If forwarded mode is not supported, the proxy MUST NOT send a target VCID by setting the length to zero. If forwarded mode is supported, the proxy MUST use a target VCID that does not introduce a conflict with any other Connection ID on the client-to-proxy 4-tuple. The proxy creates the mapping and responds with an ACK_TARGET_CID capsule. Once the successful response is sent, the proxy will forward any short header packets received on the client-to-proxy 4-tuple that use the target VCID using the correct proxy-to-target 4-tuple after first rewriting the target VCID to be the correct target CID.¶

Proxies MUST choose unpredictable client and target VCIDs to avoid forwarding loop attacks.¶

The proxy MUST only forward non-tunnelled packets from the client that are QUIC short header packets (based on the Header Form bit) and have mapped target VCIDs. Packets sent by the client that are forwarded SHOULD be considered as activity for restarting QUIC's Idle Timeout [QUIC].¶

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

5.1. Sending With Forwarded Mode

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

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.¶

The client MUST wait for an ACK_TARGET_CID capsule that contains the echoed connection ID and target VCID before using forwarded mode.¶

Prior to receiving the proxy server 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 target CID registration is rejected, for example with a CLOSE_TARGET_CID capsule, it MUST NOT forward packets to the requested target CID, but only use tunnelled mode. The request might also be rejected if the proxy does not support forwarded mode or has it disabled by policy.¶

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.¶

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.2. Receiving With Forwarded Mode

If the client has indicated support for forwarded mode with the "Proxy-QUIC-Forwarding" header, the proxy MAY use forwarded mode for any client CID for which it has a valid mapping.¶

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.¶

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.¶

5.3. 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. Simple transforms can be modeled as a function as follows:¶

Inputs:¶

1. A QUIC short header packet (after Connection ID remapping).¶

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 [RFC8999] 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). This document defines two initial transforms: the identity transform and the scramble transform.¶

5.4. 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.5. 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 limit the number of packets that it will proxy to an unvalidated client address to the size of an initial congestion window. 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 or removes forwarding rules as the network path between the client and proxy changes. In the event of passive migration, the proxy automatically reconfigures forwarding rules to use the latest active and validated network path for the HTTP stream. In the event of active migration, the proxy removes forwarding rules in order to not send packets with the same connection ID bytes over multiple network paths. After initiating active migration, clients are no longer able to send forwarded mode packets since the proxy will have removed forwarding rules. Clients can proceed with tunnelled mode or can request new forwarding rules via REGISTER_CLIENT_CID and REGISTER_TARGET_CID capsules. Each of the acknowledging capsules will contain new virtual connection IDs to prevent packets with the same connection ID bytes being used over multiple network paths. Note that the client CID and target CID can stay the same while the target VCID and client VCID change.¶

5.6. 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.¶

5.7. Stateless Resets for Forwarded Mode QUIC Packets

While the lifecycle of forwarding rules are bound to the lifecycle of the client-to-proxy HTTP stream, a peer may not be aware that the stream has terminated. If the above mappings are lost or removed without the peer's knowledge, they 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 reset the client-to-target connection in the absence of the mappings above, a stateless reset token corresponding to the Virtual Connection ID can be provided.¶

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.¶

8.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.3.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.3.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.¶

8.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.¶

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.¶

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.¶

Chaining of proxies using forwarded mode introduces the risk of forwarding loop attacks. 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.¶

9.1. HTTP Header Field

This document registers the "Proxy-QUIC-Forwarding" header field 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   |
    +-----------------------+-----------+-----------------+---------------+----------+

9.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]).¶

    +-----------------------+-------------------------------------+---------------+--------------------------------+
    | Parameter Name        | Description                         | Reference     | Notes                          |
    +-----------------------+-------------------------------------+---------------+--------------------------------+
    | accept-transform      | contains supported transforms       | This document | Section {{forwarding-header}}  |
    +-----------------------+-------------------------------------+---------------+--------------------------------+
    | transform             | indicates selected transforms       | This document | Section {{forwarding-header}}  |
    +-----------------------+-------------------------------------+---------------+--------------------------------+
    | scramble-key          | contains key for scramble transform | This document | Section {{scramble-transform}} |
    +-----------------------+-------------------------------------+---------------+--------------------------------+

9.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". Prior to finalization, deployments that implement the version of the scramble transform defined in this document should use the value "scramble-dt". Once the design team proposal is adopted and a new draft is submitted, the wire identifier will become "scramble-XX" where XX is the draft number. Registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [IANA-POLICY]).¶

9.4. Capsule Types

This document registers six 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¶

10.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>.

[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>.

[HTTP3]

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

[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>.

10.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-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-19, 5 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-19>.

[RFC8999]

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

[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>.