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.

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, a protocol conforming to the WebTransport protocol framework. QuicTransport is an application protocol running directly over QUIC. The protocol is designed to have low implementation overhead on the server side, meaning that server software that already has a working QUIC implementation available would not require large amounts 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 . The diagrams describe encoding following the conventions described in Section 1.3 of .

Each instance of 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 a congestion controller with other connections. QuicTransport is designed to be a minimal extension of QUIC, and as such does not provide much higher-level functionality, such as pooling, exchanging metadata at session establishment, redirects, and other similar capabilties not provided by QUIC itself. Http3Transport can be used in situations where these features are desired. When a client requests a QuicTransport session 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 additionally sends a client indication containing the requested path and the origin of the initiating website to the server. At that point, the connection is ready from the client’s perspective. The server MUST wait until the client indication is received before processing any application data. 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 both have received a TLS Finished message from the server and has sent a client indication. From the server perspective, the session is established after the client indication has been successfully processed.

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-vvv-01” and it MUST close the connection unless the server confirms that ALPN value.

In order to verify that the client’s origin is allowed to connect to the server in question, the user agent has to communicate the origin to the server. This is accomplished by sending a special message, called client indication, on stream 2, which is the first client-initiated unidirectional stream. The client indication is a sequence of key-value pairs that are formatted in the following way:

The pair includes the following fields: Indicates the field that is being expressed. Indicates the length of the value (the length of the key and the length itself are not included). The value of the field, the semantics of which are determined by the key. A FIN on the stream 2 SHALL indicate that the message is complete. The client MUST send the entirety of the client indication and a FIN immediately after opening the connection. The server MUST NOT process any application data before receiving the entirety of the client indication. The total length of the client indication MUST NOT exceed 65,535 bytes. In order to ensure that the user agent can send the client indication immediately, the server MUST set initial_max_streams_uni transport parameter to at least 1. The user agent MUST close the connection if the server sets initial_max_streams_uni to 0. The server MUST ignore any field it does not recognize. All of the fields MUST be unique; the server MAY close the connection if any of the keys is used more than once.

In order to allow the server to enforce its origin policy, the user agent has to communicate the origin in the client indication. This can be accomplished using the “Origin” field: Origin 0x0000 The origin of the client initiating the connection. The user agent MUST send the “Origin” field. The “Origin” field MUST be set to the origin of the client initiating the connection, serialized as described in the “serializing a request origin” section of .

In order to allow multiplexing multiple application on the same host-port tuple, QuicTransport allows specifying extra routing information in the path component of the URI. That component is communicated using the “Path” field in the client indication: Path 0x0001 The path component of the QuicTransport URI. The user agent MUST send a non-empty “Path” field. When the connection is initiated through a URI , that value SHALL be the path-abempty part, followed by a concatenation of the ? literal and the query componenet if such is present. In case when path-abempty is empty, the value sent SHALL be /. Unlike HTTP, the authority portion of the URL is not communicated in the client indication. As QuicTransport has its own connection dedicated to it, the host name portion can be retrieved from the server_name TLS extension . The server MAY use the value of the “Path” field in any way defined by the target application.

QuicTransport provides applications with the 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 lower latency, but has the drawback of being vulnerable to replay attacks. Since only the application can make an informed decision as to 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 by the client. 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 the corresponding type. All other operations (read, write, close) are also mapped directly to the operations 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.

NOTE: the URI scheme definition in this section is provisional and subject to change, especially the name of the scheme. QuicTransport uses the quic-transport URI scheme for identifying QuicTransport servers. The syntax definition below uses Augmented Backus-Naur Form (ABNF) . The definitions of host, port, path-abempty, query and fragment are adopted from . The syntax of a QuicTransport URI SHALL be:

The path-abempty and the query portions of the URI are communicated to the server in the client indication as described in . The quic-transport URI scheme supports the /.well-known/ path prefix defined in . This document does not assign any semantics to the fragment portion of the URI. Any QuicTransport implementation MUST ignore those until a subsequent specification assigns semantics to those. The host component MUST NOT be empty. If the port component is missing, the port SHALL be assumed to be 0. In order to connect to a QuicTransport server identified by a given URI, the user agent SHALL establish a QUIC connection to the specified host and port as described in . It MUST immediately signal an error to the client if the port value is 0. NOTE: this effectively requires the port number to be specified. This specification may include an actually usable default port number in the future.

QuicTransport supports most 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 clients cannot send data to a network endpoint that has not accepted an incoming connection. 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. WebTransport requires user agents to continually verify that the server is still interested in talking to them. QuicTransport accomplishes that by virtue of QUIC being an acknowledgement-based protocol; if the client is attempting to send data, and the server does not send any ACK frames in response, the client side of the QUIC connection will time out. QuicTransport prevents WebTransport clients from connecting to arbitrary non-Web servers through the use of ALPN. Unlike TLS over TCP, successful ALPN negotiation is mandatory in QUIC. Thus, unless the server explicitly picks the QuicTransport ALPN value, the TLS handshake will fail. QuicTransport uses a unidirectional QUIC stream to provide the server with the origin of the client. In order to avoid the use of QuicTransport to scan internal networks, 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, user agents SHOULD limit the amount of simultaneous connections opened. The server MAY limit the amount of open connections from a given client.

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

IANA SHALL add a registry for “QuicTransport Client Indication Fields” registry. Every entry in the registry SHALL include the following fields: The name of the field. The 16-bit unique identifier that is used on the wire. A brief description of what the parameter does. The document that describes the parameter. The IANA policy, as described in , SHALL be Standards Action for values between 0x0000 and 0x03ff; Specification Required for values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff.

This document contains the request for the registration of the URI scheme quic-transport. The registration request is in accordance with . quic-transport Permanent QuicTransport IETF Chair chair@ietf.org IESG iesg@ietf.org of this document. of this document.

Fastly Mozilla Apple Apple Google Google WHATWG 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. 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. 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. 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] 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. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. 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. WebTransport [OVERVIEW] 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 Http3Transport, a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] 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].