Draft: draft-vvv-webtransport-quic

Commentary: Please bring the backticks back .
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.
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
QuicTransport, a transport protocol that uses a dedicated QUIC QUIC
connection and provides support for unidirectional streams,
bidirectional streams and datagrams.
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.
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 congestion control context with
other potentially already existing connections.
QuicTransport is designed to be a minimal extension of QUIC, and as
such does not provide a lot of commonly desired higher-level
functionality, such as pooling, exchanging metadata at session
establishment, redirects, and other similar capabilties not provided
by QUIC itself.  Http3Transport [I-D.vvv-webtransport-http3] can be
used in situations where a higher-level approach is 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 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 indication is received before processing
any application data.
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 I-D.vvv-webtransport-http3 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.
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.
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 server MUST ignore the fields 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.
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.
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 "serializing a request origin" [1] of
FETCH.
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 FETCH.
The user agent MUST send a non-empty "Path" field.  When the
connection is initiated through a URI (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 "/".
The user agent MUST send a non-empty "Path" field.  When the
connection is initiated through a URI 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 (RFC6066).
QuicTransport provides applications with ability to use the 0-RTT
feature described in RFC8446 and QUIC.  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.
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 RFC6066.
QuicTransport provides applications with the ability to use the 0-RTT
feature described in RFC8446 and QUIC.  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.
QuicTransport uses the QUIC DATAGRAM frame QUIC-DATAGRAM 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.
NOTE: the URI scheme defintion in this section is provisional and
subject to change, especially the name of the scheme.
QuicTransport uses the QUIC DATAGRAM frame QUIC-DATAGRAM 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 supports most of WebTransport features as described in
properties.
QuicTransport supports most WebTransport features as described in
properties.
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 ACK-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 "wq" as the ALPN value, the TLS handshake
will fail.
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.
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.
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 16-bit uniquie identifier that is used on the wire.
The IANA policy, as descrbied in RFC8126, 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.
The 16-bit unique identifier that is used on the wire.
The IANA policy, as described in RFC8126, 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.