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