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