WebTransport over QUIC

QUIC is a UDP-based multiplexed secure transport. It is the underlying protocol for HTTP/3 , and as such is reasonably expected to be available in web browsers and server-side web frameworks. This makes it a compelling transport to base a WebTransport protocol on. This document defines QuicTransport, an adaptation of QUIC to WebTransport model. The protocol is designed to be low-overhead on the server side, meaning that server software that already has a working QUIC implementation available would not require a large amount of code to implement QuicTransport. Where possible, WebTransport concepts are mapped directly to the corresponding QUIC concepts.

The keywords “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 follows terminology defined in Section 1.2 of .

Each QuicTransport uses a single dedicated QUIC connection. This allows the peers to exercise a greater level of control over the way their data is being transmitted. However, this also means that multiple instances of QuicTransport cannot be pooled, and thus do not benefit from sharing congestion control context with other potentially already existing connections. Http3Transport [I-D.vvv-webtransport-http3] can be used in situations where such pooling is beneficial. When a client requests a QuicTransport to be created, the user agent establishes a QUIC connection to the specified address. It verifies that the the server is a QuicTransport endpoint using ALPN, and that the client is allowed to connect to the specified endpoint using web_accepted_origins transport parameter. Once the verification succeeds and the QUIC connection is ready, the client can send and receive streams and datagrams. WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream. WebTransport datagrams are provided through the QUIC datagram extension .

In order to establish a QuicTransport session, a QUIC connection must be established. From the client perspective, the session becomes established when the client receives a TLS Finished message from the server.

In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation . The user agent MUST request the ALPN value of “wq” and it MUST NOT establish the session unless that value is accepted.

In order to verify that the client is authorized to access a specific WebTransport server, QuicTransport has a mechanism to verify the origin associated with the client. The server MUST send a web_accepted_origins transport parameter which SHALL be one of the following: A value *, indicating that any origin is accepted. A comma-separated list of accepted origins, serialized as described in Section 6 of . In the latter case, the user agent MUST verify that one of the origins is identical (as defined in Section 5 of ) to the origin of the client; otherwise, it MUST abort the session establishment.

QuicTransport provides applications with ability to use the 0-RTT feature described in and . 0-RTT allows a client to send data before the TLS session is fully established. It provides a lower latency, but has the drawback of being vulnerable to replay attacks as a result. Since only the application can make the decision of whether some data is safe to send in that context, 0-RTT requires the client API to only send data over 0-RTT when specifically requested. 0-RTT support in QuicTransport is OPTIONAL, as it is in QUIC and TLS 1.3.

QuicTransport unidirectional and bidirectional streams are created by creating a QUIC stream of corresponding type. All other operations (read, write, close) are also mapped directly to the operations as defined in . The QUIC stream IDs are the stream IDs that are exposed to the application.

QuicTransport uses the QUIC DATAGRAM frame to provide WebTransport datagrams. A QuicTransport endpoint MUST negotiate and support the DATAGRAM frame. The datagrams provided by the application are sent as-is. The datagram ID SHALL be absent. The datagrams sent using QuicTransport MUST be subject to congestion control.

QuicTransport supports most of WebTransport features as described in . Property Support Stream independence Always supported Partial reliability Always supported Pooling support Not supported Connection mobility Implementation-dependent

QuicTransport satisfies all of the security requirements imposed by on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the the client is potentially untrusted. QuicTransport uses QUIC with TLS, and as such, provides the full range of security properties provided by TLS, including confidentiality, integrity and authentication of the server. QUIC is a client-server protocol where a client cannot send data until either the handshake is complete or a previously established session is resumed. This ensures that the user agent will prevent the client from sending data to network endpoints that are not QuicTransport endpoints. Furthermore, the QuicTransport session can be immediately aborted by the server through a connection close or a stateless reset, causing the user agent to stop the traffic from the client. This provides a defense against potential denial-of-service attacks on the network by untrusted clients. QUIC provides a congestion control mechanism that limits the rate at which the traffic is sent. This prevents potentially malicious clients from overloading the network. QuicTransport prevents the WebTransport clients connecting to arbitrary non-Web servers through the use of ALPN. Unlike TLS over TCP, successfully ALPN negotiation is mandatory in QUIC. Thus, unless the server explicitly picks wq as the ALPN value, the TLS handshake will fail. It will also fail unless the web_accepted_origins is present. QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist. The origin is not sent explicitly, as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it. In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients to distinguish different connection errors before the correct ALPN is received from the server. Since each instance of QuicTransport opens a new connection, a malicious client can cause resource exhaustion, both on the local system (through depleting file descriptor space or other per-connection resources) and on a given remote server. Because of that, the user agegts SHOULD limit the amount of simultaneous connections opened. The server MAY limit the amount of connections open by the same client.

The following entry is added to the “Application Layer Protocol Negotiation (ALPN) Protocol IDs” registry established by : The “wq” label identifies QUIC used as a protocol for WebTransport: QuicTransport 0x77 0x71 (“wq”) This document

The following entry is added to the “QUIC Transport Parameter Registry” registry established by : The “web_accepted_origins” parameter allows the server to indicate origins that are permitted to connect to it: 0x???? web_accepted_origins This document