Network Working Group V. Vasiliev Internet-Draft Google Intended status: Standards Track May 3, 2019 Expires: November 4, 2019 WebTransport over QUIC draft-vvv-webtransport-quic-00 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-TRANSPORT] 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 November 4, 2019. 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 November 4, 2019 [Page 1] Internet-Draft QuicTransport May 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 . . . . . . . . . . . . . . . . . . . . . . . 2 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Connection Establishment . . . . . . . . . . . . . . . . . . 3 3.1. Identifying as QuicTransport . . . . . . . . . . . . . . 3 3.2. Verifying the Origin . . . . . . . . . . . . . . . . . . 3 3.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Transport Properties . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.1. ALPN Value Registration . . . . . . . . . . . . . . . . . 6 8.2. QUIC Transport Parameter Registration . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction QUIC [QUIC-TRANSPORT] 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, an adaptation of QUIC to WebTransport model. The protocol is designed to be low-overhead on the server side, meaning that server software that already has a working QUIC implementation available would not require a large amount of code to implement QuicTransport. Where possible, WebTransport concepts are mapped directly to the corresponding QUIC concepts. 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. Vasiliev Expires November 4, 2019 [Page 2] Internet-Draft QuicTransport May 2019 This document follows terminology defined in Section 1.2 of [OVERVIEW]. 2. Protocol Overview Each QuicTransport uses a single dedicated QUIC connection. This allows the peers to exercise a greater level of control over the way their data is being transmitted. However, this also means that multiple instances of QuicTransport cannot be pooled, and thus do not benefit from sharing congestion control context with other potentially already existing connections. Http3Transport [I-D.vvv- webtransport-http3] can be used in situations where such pooling is beneficial. When a client requests a QuicTransport 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 that the client is allowed to connect to the specified endpoint using "web_accepted_origins" transport parameter. Once the verification succeeds and the QUIC connection is ready, the client can send and receive streams and datagrams. WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream. WebTransport datagrams are provided through the QUIC datagram extension [QUIC-DATAGRAM]. 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 receives a TLS Finished message from the server. 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" and it MUST NOT establish the session unless that value is accepted. 3.2. Verifying the Origin In order to verify that the client is authorized to access a specific WebTransport server, QuicTransport has a mechanism to verify the origin [RFC6454] associated with the client. The server MUST send a "web_accepted_origins" transport parameter which SHALL be one of the following: Vasiliev Expires November 4, 2019 [Page 3] Internet-Draft QuicTransport May 2019 o A value "*", indicating that any origin is accepted. o A comma-separated list of accepted origins, serialized as described in Section 6 of [RFC6454]. In the latter case, the user agent MUST verify that one of the origins is identical (as defined in Section 5 of [RFC6454]) to the origin of the client; otherwise, it MUST abort the session establishment. 3.3. 0-RTT QuicTransport provides applications with ability to use the 0-RTT feature described in [RFC8446] and [QUIC-TRANSPORT]. 0-RTT allows a client to send data before the TLS session is fully established. It provides a lower latency, but has the drawback of being vulnerable to replay attacks as a result. Since only the application can make the decision of whether some data is safe to send in that context, 0-RTT requires the client API to only send data over 0-RTT when specifically requested. 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 corresponding type. All other operations (read, write, close) are also mapped directly to the operations as defined in [QUIC-TRANSPORT]. 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. The datagram ID SHALL be absent. The datagrams sent using QuicTransport MUST be subject to congestion control. 6. Transport Properties QuicTransport supports most of WebTransport features as described in Table 1. Vasiliev Expires November 4, 2019 [Page 4] Internet-Draft QuicTransport May 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 7. 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 the user agent will prevent the client from sending data to network endpoints that are not QuicTransport endpoints. 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. QuicTransport prevents the WebTransport clients connecting to arbitrary non-Web servers through the use of ALPN. Unlike TLS over TCP, successfully ALPN negotiation is mandatory in QUIC. Thus, unless the server explicitly picks "wq" as the ALPN value, the TLS handshake will fail. It will also fail unless the "web_accepted_origins" is present. QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist. The origin is not sent explicitly, Vasiliev Expires November 4, 2019 [Page 5] Internet-Draft QuicTransport May 2019 as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it. In order to avoid the use of QuicTransport, 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, the user agegts SHOULD limit the amount of simultaneous connections opened. The server MAY limit the amount of connections open by the same client. 8. IANA Considerations 8.1. ALPN Value Registration The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]: The "wq" label identifies QUIC used as a protocol for WebTransport: Protocol: QuicTransport Identification Sequence: 0x77 0x71 ("wq") Specification: This document 8.2. QUIC Transport Parameter Registration The following entry is added to the "QUIC Transport Parameter Registry" registry established by [QUIC-TRANSPORT]: The "web_accepted_origins" parameter allows the server to indicate origins that are permitted to connect to it: Value: 0x???? Parameter Name: web_accepted_origins Specification: This document Vasiliev Expires November 4, 2019 [Page 6] Internet-Draft QuicTransport May 2019 9. References 9.1. Normative References [OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", draft-vvv-webtransport-overview-00 (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). [QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic- transport-latest (work in progress). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . 9.2. Informative References [I-D.ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", draft-ietf-quic-http-20 (work in progress), April 2019. Vasiliev Expires November 4, 2019 [Page 7] Internet-Draft QuicTransport May 2019 [I-D.ietf-quic-recovery] Iyengar, J. and I. Swett, "QUIC Loss Detection and Congestion Control", draft-ietf-quic-recovery-20 (work in progress), April 2019. Author's Address Victor Vasiliev Google Email: vasilvv@google.com Vasiliev Expires November 4, 2019 [Page 8]