WebTransport over QUIC
Google
vasilvv@google.com
Transport
WebTransport is a protocol framework that enables clients constrained
by the Web security model to communicate with a remote server using a secure
multiplexed transport. This document describes QuicTransport, a transport
protocol that uses a dedicated QUIC connection and provides
support for unidirectional streams, bidirectional streams and datagrams.
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
QUIC: A UDP-Based Multiplexed and Secure Transport
Fastly
Mozilla
An Unreliable Datagram Extension to QUIC
Apple
Apple
Google
The WebTransport Protocol Framework
Google
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.
The Web Origin Concept
This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
Hypertext Transfer Protocol Version 3 (HTTP/3)
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3.
QUIC Loss Detection and Congestion Control
This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery [3].