idnits 2.17.1
draft-vvv-webtransport-quic-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([QUIC], [OVERVIEW]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (November 2, 2019) is 1630 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '1' on line 538
-- Looks like a reference, but probably isn't: '2' on line 540
-- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH'
-- No information found for draft-ietf-quic-transport-latest - is the name
correct?
-- Possible downref: Normative reference to a draft: ref. 'QUIC'
-- No information found for draft-pauly-quic-datagram-latest - is the name
correct?
-- Possible downref: Normative reference to a draft: ref. 'QUIC-DATAGRAM'
== Outdated reference: A later version (-34) exists of
draft-ietf-quic-http-23
== Outdated reference: A later version (-34) exists of
draft-ietf-quic-recovery-23
== Outdated reference: A later version (-03) exists of
draft-vvv-webtransport-http3-00
Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group V. Vasiliev
3 Internet-Draft Google
4 Intended status: Standards Track November 2, 2019
5 Expires: May 5, 2020
7 WebTransport over QUIC
8 draft-vvv-webtransport-quic-01
10 Abstract
12 WebTransport [OVERVIEW] is a protocol framework that enables clients
13 constrained by the Web security model to communicate with a remote
14 server using a secure multiplexed transport. This document describes
15 QuicTransport, a transport protocol that uses a dedicated QUIC [QUIC]
16 connection and provides support for unidirectional streams,
17 bidirectional streams and datagrams.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on May 5, 2020.
36 Copyright Notice
38 Copyright (c) 2019 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
56 3. Connection Establishment . . . . . . . . . . . . . . . . . . 4
57 3.1. Identifying as QuicTransport . . . . . . . . . . . . . . 4
58 3.2. Client Indication . . . . . . . . . . . . . . . . . . . . 4
59 3.2.1. Origin Field . . . . . . . . . . . . . . . . . . . . 5
60 3.2.2. Path Field . . . . . . . . . . . . . . . . . . . . . 5
61 3.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 6
62 4. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 5. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 6
64 6. QuicTransport URI Scheme . . . . . . . . . . . . . . . . . . 6
65 7. Transport Properties . . . . . . . . . . . . . . . . . . . . 7
66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
68 9.1. ALPN Value Registration . . . . . . . . . . . . . . . . . 9
69 9.2. Client Indication Fields Registry . . . . . . . . . . . . 9
70 9.3. URI Scheme Registration . . . . . . . . . . . . . . . . . 10
71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
72 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
73 10.2. Informative References . . . . . . . . . . . . . . . . . 12
74 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
77 1. Introduction
79 WebTransport [OVERVIEW] is a protocol framework that enables clients
80 constrained by the Web security model to communicate with a remote
81 server using a secure multiplexed transport. This document describes
82 QuicTransport, a transport protocol that uses a dedicated QUIC [QUIC]
83 connection and provides support for unidirectional streams,
84 bidirectional streams and datagrams.
86 QUIC [QUIC] is a UDP-based multiplexed secure transport. It is the
87 underlying protocol for HTTP/3 [I-D.ietf-quic-http], and as such is
88 reasonably expected to be available in web browsers and server-side
89 web frameworks. This makes it a compelling transport to base a
90 WebTransport protocol on.
92 This document defines QuicTransport, a protocol conforming to the
93 WebTransport protocol framework. QuicTransport is an application
94 protocol running directly over QUIC. The protocol is designed to
95 have low implementation overhead on the server side, meaning that
96 server software that already has a working QUIC implementation
97 available would not require large amounts of code to implement
98 QuicTransport. Where possible, WebTransport concepts are mapped
99 directly to the corresponding QUIC concepts.
101 1.1. Terminology
103 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
105 "OPTIONAL" in this document are to be interpreted as described in BCP
106 14 [RFC2119] [RFC8174] when, and only when, they appear in all
107 capitals, as shown here.
109 This document follows terminology defined in Section 1.2 of
110 [OVERVIEW]. The diagrams describe encoding following the conventions
111 described in Section 1.3 of [QUIC].
113 2. Protocol Overview
115 Each instance of QuicTransport uses a single dedicated QUIC
116 connection. This allows the peers to exercise a greater level of
117 control over the way their data is being transmitted. However, this
118 also means that multiple instances of QuicTransport cannot be pooled,
119 and thus do not benefit from sharing a congestion controller with
120 other connections.
122 QuicTransport is designed to be a minimal extension of QUIC, and as
123 such does not provide much higher-level functionality, such as
124 pooling, exchanging metadata at session establishment, redirects, and
125 other similar capabilties not provided by QUIC itself.
126 Http3Transport [I-D.vvv-webtransport-http3] can be used in situations
127 where these features are desired.
129 When a client requests a QuicTransport session to be created, the
130 user agent establishes a QUIC connection to the specified address.
131 It verifies that the the server is a QuicTransport endpoint using
132 ALPN, and additionally sends a client indication containing the
133 requested path and the origin of the initiating website to the
134 server. At that point, the connection is ready from the client's
135 perspective. The server MUST wait until the client indication is
136 received before processing any application data.
138 WebTransport streams are provided by creating an individual
139 unidirectional or bidirectional QUIC stream. WebTransport datagrams
140 are provided through the QUIC datagram extension [QUIC-DATAGRAM].
142 3. Connection Establishment
144 In order to establish a QuicTransport session, a QUIC connection must
145 be established. From the client perspective, the session becomes
146 established when the client both have received a TLS Finished message
147 from the server and has sent a client indication. From the server
148 perspective, the session is established after the client indication
149 has been successfully processed.
151 3.1. Identifying as QuicTransport
153 In order to identify itself as a WebTransport application,
154 QuicTransport relies on TLS Application-Layer Protocol Negotiation
155 [RFC7301]. The user agent MUST request the ALPN value of "wq-vvv-01"
156 and it MUST close the connection unless the server confirms that ALPN
157 value.
159 3.2. Client Indication
161 In order to verify that the client's origin is allowed to connect to
162 the server in question, the user agent has to communicate the origin
163 to the server. This is accomplished by sending a special message,
164 called client indication, on stream 2, which is the first client-
165 initiated unidirectional stream.
167 The client indication is a sequence of key-value pairs that are
168 formatted in the following way:
170 0 1 2 3
171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
173 | Key (16) | Length (16) |
174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
175 | Value (*) ...
176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
178 Figure 1: Client indication format
180 The pair includes the following fields:
182 Key: Indicates the field that is being expressed.
184 Length: Indicates the length of the value (the length of the key and
185 the length itself are not included).
187 Value: The value of the field, the semantics of which are determined
188 by the key.
190 A FIN on the stream 2 SHALL indicate that the message is complete.
191 The client MUST send the entirety of the client indication and a FIN
192 immediately after opening the connection. The server MUST NOT
193 process any application data before receiving the entirety of the
194 client indication. The total length of the client indication MUST
195 NOT exceed 65,535 bytes.
197 In order to ensure that the user agent can send the client indication
198 immediately, the server MUST set "initial_max_streams_uni" transport
199 parameter to at least "1". The user agent MUST close the connection
200 if the server sets "initial_max_streams_uni" to "0".
202 The server MUST ignore any field it does not recognize. All of the
203 fields MUST be unique; the server MAY close the connection if any of
204 the keys is used more than once.
206 3.2.1. Origin Field
208 In order to allow the server to enforce its origin policy, the user
209 agent has to communicate the origin in the client indication. This
210 can be accomplished using the "Origin" field:
212 Name: Origin
214 Key: 0x0000
216 Description: The origin [RFC6454] of the client initiating the
217 connection.
219 The user agent MUST send the "Origin" field. The "Origin" field MUST
220 be set to the origin of the client initiating the connection,
221 serialized as described in the "serializing a request origin" section
222 of [FETCH].
224 3.2.2. Path Field
226 In order to allow multiplexing multiple application on the same host-
227 port tuple, QuicTransport allows specifying extra routing information
228 in the path component of the URI. That component is communicated
229 using the "Path" field in the client indication:
231 Name: Path
233 Key: 0x0001
235 Description: The path component of the QuicTransport URI.
237 The user agent MUST send a non-empty "Path" field. When the
238 connection is initiated through a URI Section 6, that value SHALL be
239 the "path-abempty" part, followed by a concatenation of the "?"
240 literal and the "query" componenet if such is present. In case when
241 "path-abempty" is empty, the value sent SHALL be "/".
243 Unlike HTTP, the "authority" portion of the URL is not communicated
244 in the client indication. As QuicTransport has its own connection
245 dedicated to it, the host name portion can be retrieved from the
246 "server_name" TLS extension [RFC6066].
248 The server MAY use the value of the "Path" field in any way defined
249 by the target application.
251 3.3. 0-RTT
253 QuicTransport provides applications with the ability to use the 0-RTT
254 feature described in [RFC8446] and [QUIC]. 0-RTT allows a client to
255 send data before the TLS session is fully established. It provides
256 lower latency, but has the drawback of being vulnerable to replay
257 attacks. Since only the application can make an informed decision as
258 to whether some data is safe to send in that context, 0-RTT requires
259 the client API to only send data over 0-RTT when specifically
260 requested by the client.
262 0-RTT support in QuicTransport is OPTIONAL, as it is in QUIC and TLS
263 1.3.
265 4. Streams
267 QuicTransport unidirectional and bidirectional streams are created by
268 creating a QUIC stream of the corresponding type. All other
269 operations (read, write, close) are also mapped directly to the
270 operations defined in [QUIC]. The QUIC stream IDs are the stream IDs
271 that are exposed to the application.
273 5. Datagrams
275 QuicTransport uses the QUIC DATAGRAM frame [QUIC-DATAGRAM] to provide
276 WebTransport datagrams. A QuicTransport endpoint MUST negotiate and
277 support the DATAGRAM frame. The datagrams provided by the
278 application are sent as-is.
280 6. QuicTransport URI Scheme
282 NOTE: the URI scheme definition in this section is provisional and
283 subject to change, especially the name of the scheme.
285 QuicTransport uses the "quic-transport" URI scheme for identifying
286 QuicTransport servers.
288 The syntax definition below uses Augmented Backus-Naur Form (ABNF)
289 [RFC5234]. The definitions of "host", "port", "path-abempty",
290 "query" and "fragment" are adopted from [RFC3986]. The syntax of a
291 QuicTransport URI SHALL be:
293 quic-transport-URI = "quic-transport:" "//"
294 host [ ":" port ]
295 path-abempty
296 [ "?" query ]
297 [ "#" fragment ]
299 The "path-abempty" and the "query" portions of the URI are
300 communicated to the server in the client indication as described in
301 Section 3.2.2. The "quic-transport" URI scheme supports the "/.well-
302 known/" path prefix defined in [RFC8615].
304 This document does not assign any semantics to the "fragment" portion
305 of the URI. Any QuicTransport implementation MUST ignore those until
306 a subsequent specification assigns semantics to those.
308 The "host" component MUST NOT be empty. If the "port" component is
309 missing, the port SHALL be assumed to be 0.
311 In order to connect to a QuicTransport server identified by a given
312 URI, the user agent SHALL establish a QUIC connection to the
313 specified "host" and "port" as described in Section 3. It MUST
314 immediately signal an error to the client if the port value is 0.
316 NOTE: this effectively requires the port number to be specified.
317 This specification may include an actually usable default port number
318 in the future.
320 7. Transport Properties
322 QuicTransport supports most WebTransport features as described in
323 Table 1.
325 +---------------------+--------------------------+
326 | Property | Support |
327 +---------------------+--------------------------+
328 | Stream independence | Always supported |
329 | | |
330 | Partial reliability | Always supported |
331 | | |
332 | Pooling support | Not supported |
333 | | |
334 | Connection mobility | Implementation-dependent |
335 +---------------------+--------------------------+
337 Table 1: Transport properties of QuicTransport
339 8. Security Considerations
341 QuicTransport satisfies all of the security requirements imposed by
342 [OVERVIEW] on WebTransport protocols, thus providing a secure
343 framework for client-server communication in cases when the the
344 client is potentially untrusted.
346 QuicTransport uses QUIC with TLS, and as such, provides the full
347 range of security properties provided by TLS, including
348 confidentiality, integrity and authentication of the server.
350 QUIC is a client-server protocol where a client cannot send data
351 until either the handshake is complete or a previously established
352 session is resumed. This ensures that clients cannot send data to a
353 network endpoint that has not accepted an incoming connection.
354 Furthermore, the QuicTransport session can be immediately aborted by
355 the server through a connection close or a stateless reset, causing
356 the user agent to stop the traffic from the client. This provides a
357 defense against potential denial-of-service attacks on the network by
358 untrusted clients.
360 QUIC provides a congestion control mechanism [I-D.ietf-quic-recovery]
361 that limits the rate at which the traffic is sent. This prevents
362 potentially malicious clients from overloading the network.
364 WebTransport requires user agents to continually verify that the
365 server is still interested in talking to them. QuicTransport
366 accomplishes that by virtue of QUIC being an acknowledgement-based
367 protocol; if the client is attempting to send data, and the server
368 does not send any ACK frames in response, the client side of the QUIC
369 connection will time out.
371 QuicTransport prevents WebTransport clients from connecting to
372 arbitrary non-Web servers through the use of ALPN. Unlike TLS over
373 TCP, successful ALPN negotiation is mandatory in QUIC. Thus, unless
374 the server explicitly picks the QuicTransport ALPN value, the TLS
375 handshake will fail.
377 QuicTransport uses a unidirectional QUIC stream to provide the server
378 with the origin of the client.
380 In order to avoid the use of QuicTransport to scan internal networks,
381 the user agents MUST NOT allow the clients to distinguish different
382 connection errors before the correct ALPN is received from the
383 server.
385 Since each instance of QuicTransport opens a new connection, a
386 malicious client can cause resource exhaustion, both on the local
387 system (through depleting file descriptor space or other per-
388 connection resources) and on a given remote server. Because of that,
389 user agents SHOULD limit the amount of simultaneous connections
390 opened. The server MAY limit the amount of open connections from a
391 given client.
393 9. IANA Considerations
395 9.1. ALPN Value Registration
397 The following entry is added to the "Application Layer Protocol
398 Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]:
400 The "wq-vvv-01" label identifies QUIC used as a protocol for
401 WebTransport:
403 Protocol: QuicTransport
405 Identification Sequence: 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30
406 0x31 ("wq-vvv-01")
408 Specification: This document
410 9.2. Client Indication Fields Registry
412 IANA SHALL add a registry for "QuicTransport Client Indication
413 Fields" registry. Every entry in the registry SHALL include the
414 following fields:
416 Name: The name of the field.
418 Key: The 16-bit unique identifier that is used on the wire.
420 Description: A brief description of what the parameter does.
422 Reference: The document that describes the parameter.
424 The IANA policy, as described in [RFC8126], SHALL be Standards Action
425 for values between 0x0000 and 0x03ff; Specification Required for
426 values between 0x0400 and 0xefff; and Private Use for values between
427 0xf000 and 0xffff.
429 9.3. URI Scheme Registration
431 This document contains the request for the registration of the URI
432 scheme "quic-transport". The registration request is in accordance
433 with [RFC7595].
435 Scheme name: quic-transport
437 Status: Permanent
439 Applications/protocols that use this scheme name: QuicTransport
441 Contact: IETF Chair chair@ietf.org [1]
443 Change controller: IESG iesg@ietf.org [2]
445 Reference: Section 6 of this document.
447 Well-Known URI Support: Section 6 of this document.
449 10. References
451 10.1. Normative References
453 [FETCH] WHATWG, "Fetch Standard", November 2019,
454 .
456 [OVERVIEW]
457 Vasiliev, V., "The WebTransport Protocol Framework",
458 draft-vvv-webtransport-overview-01 (work in progress).
460 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
461 Multiplexed and Secure Transport", draft-ietf-quic-
462 transport-latest (work in progress).
464 [QUIC-DATAGRAM]
465 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
466 Datagram Extension to QUIC", draft-pauly-quic-datagram-
467 latest (work in progress).
469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
470 Requirement Levels", BCP 14, RFC 2119,
471 DOI 10.17487/RFC2119, March 1997,
472 .
474 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
475 Resource Identifier (URI): Generic Syntax", STD 66,
476 RFC 3986, DOI 10.17487/RFC3986, January 2005,
477 .
479 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
480 Specifications: ABNF", STD 68, RFC 5234,
481 DOI 10.17487/RFC5234, January 2008,
482 .
484 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
485 DOI 10.17487/RFC6454, December 2011,
486 .
488 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
489 "Transport Layer Security (TLS) Application-Layer Protocol
490 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
491 July 2014, .
493 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
494 and Registration Procedures for URI Schemes", BCP 35,
495 RFC 7595, DOI 10.17487/RFC7595, June 2015,
496 .
498 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
499 Writing an IANA Considerations Section in RFCs", BCP 26,
500 RFC 8126, DOI 10.17487/RFC8126, June 2017,
501 .
503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
505 May 2017, .
507 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
508 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
509 .
511 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
512 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
513 .
515 10.2. Informative References
517 [I-D.ietf-quic-http]
518 Bishop, M., "Hypertext Transfer Protocol Version 3
519 (HTTP/3)", draft-ietf-quic-http-23 (work in progress),
520 September 2019.
522 [I-D.ietf-quic-recovery]
523 Iyengar, J. and I. Swett, "QUIC Loss Detection and
524 Congestion Control", draft-ietf-quic-recovery-23 (work in
525 progress), September 2019.
527 [I-D.vvv-webtransport-http3]
528 Vasiliev, V., "WebTransport over HTTP/3", draft-vvv-
529 webtransport-http3-00 (work in progress), May 2019.
531 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
532 Extensions: Extension Definitions", RFC 6066,
533 DOI 10.17487/RFC6066, January 2011,
534 .
536 10.3. URIs
538 [1] mailto:chair@ietf.org
540 [2] mailto:iesg@ietf.org
542 Author's Address
544 Victor Vasiliev
545 Google
547 Email: vasilvv@google.com