UDP Rendezvous over HTTP

Introduction CONNECT-UDP () allows an HTTP client to proxy UDP payloads to a fixed remote host and port. This document defines a sibling protocol to CONNECT-UDP for deployments where both endpoints can connect to the same proxy. A Listener opens a long-lived rendezvous request and receives a Rendezvous ID. A Client opens a separate rendezvous request carrying that ID. The proxy associates both requests and forwards HTTP Datagrams () between them. One Listener request can serve multiple Clients. Authentication and distribution of Rendezvous IDs are out of scope.

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 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

Listener:: The endpoint that creates a listener request. A Listener can communicate with multiple Clients on one request.
Client:: The endpoint that creates a join request. A join request connects to exactly one Listener.
Rendezvous ID:: An opaque identifier issued by the proxy for a Listener request.

The Listener and Client are both HTTP clients.

Protocol

Requests This protocol uses HTTP Extended CONNECT (, ) with the :protocol pseudo-header field set to connect-udp-rendezvous. It is defined for HTTP/2 and HTTP/3, but not HTTP/1.1. An endpoint MUST NOT send a rendezvous request until it has received SETTINGS_ENABLE_CONNECT_PROTOCOL with value 1. Endpoints are configured with an HTTPS URI identifying the rendezvous proxy. A rendezvous request uses this URI as its target. Requests and successful responses use the Capsule Protocol as described in . The request and successful response MUST contain a Capsule-Protocol field with value ?1. A successful response has a status code in the 2xx range. An endpoint MUST abort the request if these requirements are not met. The proxy MUST NOT interpret the service URI as a UDP target or open a UDP socket.

The Connect-UDP-Rendezvous HTTP Field Connect-UDP-Rendezvous is an Item Structured Header Field (). Its bare item is the Token listen or join. The id parameter, when present, is a Byte Sequence. Connect-UDP-Rendezvous Field Values

Message	Field Value
Listener request	`listen`
Successful Listener response	`listen; id=:...:`
Join request	`join; id=:...:`
Successful join response	`join`

The field MUST NOT appear in trailers. Unknown parameters are ignored. A request with a missing field or a field that cannot be parsed or does not match the table is malformed. The proxy MUST respond with a 400 (Bad Request) status code. A Rendezvous ID is opaque to both endpoints. The proxy MUST NOT issue the same ID for two live Listener requests. An endpoint that receives a successful response without the expected field value MUST abort the request and MUST NOT send HTTP Datagrams on it. The proxy SHOULD use the same error response for an unknown Rendezvous ID and an unauthorized association.

Datagram Forwarding HTTP Datagrams use the format defined in and the Context ID allocation rules from . A join request uses Context ID 0. When forwarding the first datagram on that request, the proxy allocates a new non-zero odd Context ID on the Listener request and replaces Context ID 0 with it. It uses that Context ID for all datagrams on the join request; the reverse mapping applies to datagrams from the Listener. The proxy MUST NOT reuse a Context ID on the same Listener request, modify a UDP payload, or forward it to more than one association. When the Listener receives a datagram from the proxy with a previously unseen odd Context ID that has not been closed, it registers that Context ID as a new Client association before processing the datagram. The Listener MUST NOT send an HTTP Datagram using the Context ID before receiving it from the proxy. A Listener request MUST NOT carry Context ID 0. A recipient MUST abort the request stream if it receives one. Other unregistered Context IDs are handled as specified in . The proxy MUST drop a datagram that does not fit on the outgoing connection. UDP payloads MUST NOT exceed 65527 octets. An oversized payload on a join request is handled as specified in ; the proxy MUST close the association if it receives an oversized payload from the Listener. A Client MAY send HTTP Datagrams before receiving the response to its join request. The proxy MUST NOT forward a datagram before sending a successful response. It MAY discard or buffer early datagrams. Buffering MUST be bounded; buffered datagrams MUST be discarded if the request is rejected. A Client MUST discard an HTTP/3 Datagram received before the response.

Closing Associations The RENDEZVOUS_CLOSE capsule closes one association. It contains exactly one Context ID encoded as a QUIC variable-length integer:

RENDEZVOUS_CLOSE Capsule Format RENDEZVOUS_CLOSE capsules are only sent on Listener requests and MUST carry a non-zero odd Context ID. Receipt on another request, or with a zero or even Context ID, is an error processing the Capsule Protocol. A proxy MUST treat receipt for a Context ID it never allocated as the same error. A RENDEZVOUS_CLOSE capsule sent by the proxy can arrive before the first datagram for that Context ID. The Listener MUST record the Context ID as closed until the Listener request ends and discard later datagrams carrying it. Once the Listener or proxy sends or receives this capsule, it MUST NOT send HTTP Datagrams using that Context ID. Closing or resetting either direction of a rendezvous request causes the proxy to close the other direction. Closing the Listener request also invalidates the Rendezvous ID and closes every join request. Closing a join request causes the proxy to send RENDEZVOUS_CLOSE if the Listener request remains open and a Context ID was allocated, unless it received that capsule from the Listener. A RENDEZVOUS_CLOSE from the Listener causes the proxy to close the corresponding join request.

Security Considerations Proxy authentication does not provide end-to-end peer authentication, confidentiality, or integrity. Applications that require these properties use an end-to-end protocol such as QUIC or DTLS.

IANA Considerations This document requests registration of the following value in the "HTTP Upgrade Tokens" registry:

Value	Description	Expected Version Tokens	Reference
connect-udp-rendezvous	Rendezvous Proxying of UDP Payloads	None	This document

This document requests registration of the following field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Field Name	Status	Structured Type	Reference
Connect-UDP-Rendezvous	provisional	Item	This document

This document requests registration of the following value in the "HTTP Capsule Types" registry:

Value	Capsule Type	Status	Reference
TBD1	RENDEZVOUS_CLOSE	provisional	This document

The change controller is the IETF and the contact is the MASQUE Working Group (masque@ietf.org).