Network Working Group V. Vasiliev Internet-Draft Google Intended status: Standards Track November 2, 2019 Expires: May 5, 2020 WebTransport over QUIC draft-vvv-webtransport-quic-01 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 5, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Vasiliev Expires May 5, 2020 [Page 1] Internet-Draft QuicTransport November 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Connection Establishment . . . . . . . . . . . . . . . . . . 4 3.1. Identifying as QuicTransport . . . . . . . . . . . . . . 4 3.2. Client Indication . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Origin Field . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Path Field . . . . . . . . . . . . . . . . . . . . . 5 3.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. QuicTransport URI Scheme . . . . . . . . . . . . . . . . . . 6 7. Transport Properties . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9.1. ALPN Value Registration . . . . . . . . . . . . . . . . . 9 9.2. Client Indication Fields Registry . . . . . . . . . . . . 9 9.3. URI Scheme Registration . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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. QUIC [QUIC] is a UDP-based multiplexed secure transport. It is the underlying protocol for HTTP/3 [I-D.ietf-quic-http], 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 Vasiliev Expires May 5, 2020 [Page 2] Internet-Draft QuicTransport November 2019 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. 1.1. Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document follows terminology defined in Section 1.2 of [OVERVIEW]. The diagrams describe encoding following the conventions described in Section 1.3 of [QUIC]. 2. Protocol Overview 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. WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream. WebTransport datagrams are provided through the QUIC datagram extension [QUIC-DATAGRAM]. Vasiliev Expires May 5, 2020 [Page 3] Internet-Draft QuicTransport November 2019 3. Connection Establishment 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. 3.1. Identifying as QuicTransport In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation [RFC7301]. 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. 3.2. Client Indication 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: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (16) | Length (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Client indication format The pair includes the following fields: Key: Indicates the field that is being expressed. Length: Indicates the length of the value (the length of the key and the length itself are not included). Value: The value of the field, the semantics of which are determined by the key. Vasiliev Expires May 5, 2020 [Page 4] Internet-Draft QuicTransport November 2019 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. 3.2.1. Origin Field 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: Name: Origin Key: 0x0000 Description: The origin [RFC6454] 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 [FETCH]. 3.2.2. Path Field 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: Name: Path Key: 0x0001 Description: The path component of the QuicTransport URI. Vasiliev Expires May 5, 2020 [Page 5] Internet-Draft QuicTransport November 2019 The user agent MUST send a non-empty "Path" field. When the connection is initiated through a URI Section 6, 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]. The server MAY use the value of the "Path" field in any way defined by the target application. 3.3. 0-RTT 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. 0-RTT support in QuicTransport is OPTIONAL, as it is in QUIC and TLS 1.3. 4. Streams 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 [QUIC]. The QUIC stream IDs are the stream IDs that are exposed to the application. 5. Datagrams 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. 6. QuicTransport URI Scheme NOTE: the URI scheme definition in this section is provisional and subject to change, especially the name of the scheme. Vasiliev Expires May 5, 2020 [Page 6] Internet-Draft QuicTransport November 2019 QuicTransport uses the "quic-transport" URI scheme for identifying QuicTransport servers. The syntax definition below uses Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query" and "fragment" are adopted from [RFC3986]. The syntax of a QuicTransport URI SHALL be: quic-transport-URI = "quic-transport:" "//" host [ ":" port ] path-abempty [ "?" query ] [ "#" fragment ] The "path-abempty" and the "query" portions of the URI are communicated to the server in the client indication as described in Section 3.2.2. The "quic-transport" URI scheme supports the "/.well- known/" path prefix defined in [RFC8615]. 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 Section 3. 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. 7. Transport Properties QuicTransport supports most WebTransport features as described in Table 1. Vasiliev Expires May 5, 2020 [Page 7] Internet-Draft QuicTransport November 2019 +---------------------+--------------------------+ | Property | Support | +---------------------+--------------------------+ | Stream independence | Always supported | | | | | Partial reliability | Always supported | | | | | Pooling support | Not supported | | | | | Connection mobility | Implementation-dependent | +---------------------+--------------------------+ Table 1: Transport properties of QuicTransport 8. Security Considerations QuicTransport satisfies all of the security requirements imposed by [OVERVIEW] 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 [I-D.ietf-quic-recovery] 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 Vasiliev Expires May 5, 2020 [Page 8] Internet-Draft QuicTransport November 2019 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. 9. IANA Considerations 9.1. ALPN Value Registration The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]: The "wq-vvv-01" label identifies QUIC used as a protocol for WebTransport: Protocol: QuicTransport Identification Sequence: 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") Specification: This document 9.2. Client Indication Fields Registry IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry. Every entry in the registry SHALL include the following fields: Name: The name of the field. Key: The 16-bit unique identifier that is used on the wire. Description: A brief description of what the parameter does. Vasiliev Expires May 5, 2020 [Page 9] Internet-Draft QuicTransport November 2019 Reference: The document that describes the parameter. 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. 9.3. URI Scheme Registration This document contains the request for the registration of the URI scheme "quic-transport". The registration request is in accordance with [RFC7595]. Scheme name: quic-transport Status: Permanent Applications/protocols that use this scheme name: QuicTransport Contact: IETF Chair chair@ietf.org [1] Change controller: IESG iesg@ietf.org [2] Reference: Section 6 of this document. Well-Known URI Support: Section 6 of this document. 10. References 10.1. Normative References [FETCH] WHATWG, "Fetch Standard", November 2019, . [OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", draft-vvv-webtransport-overview-01 (work in progress). [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic- transport-latest (work in progress). [QUIC-DATAGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", draft-pauly-quic-datagram- latest (work in progress). Vasiliev Expires May 5, 2020 [Page 10] Internet-Draft QuicTransport November 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . Vasiliev Expires May 5, 2020 [Page 11] Internet-Draft QuicTransport November 2019 10.2. Informative References [I-D.ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", draft-ietf-quic-http-23 (work in progress), September 2019. [I-D.ietf-quic-recovery] Iyengar, J. and I. Swett, "QUIC Loss Detection and Congestion Control", draft-ietf-quic-recovery-23 (work in progress), September 2019. [I-D.vvv-webtransport-http3] Vasiliev, V., "WebTransport over HTTP/3", draft-vvv- webtransport-http3-00 (work in progress), May 2019. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . 10.3. URIs [1] mailto:chair@ietf.org [2] mailto:iesg@ietf.org Author's Address Victor Vasiliev Google Email: vasilvv@google.com Vasiliev Expires May 5, 2020 [Page 12]