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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.

   [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, <https://www.rfc-editor.org/info/rfc7301>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

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]