--- 1/draft-ietf-webtrans-overview-01.txt 2021-07-28 18:13:09.956065230 -0700 +++ 2/draft-ietf-webtrans-overview-02.txt 2021-07-28 18:13:09.984065935 -0700 @@ -1,18 +1,18 @@ WEBTRANS V. Vasiliev Internet-Draft Google -Intended status: Standards Track 18 October 2020 -Expires: 21 April 2021 +Intended status: Standards Track 28 July 2021 +Expires: 29 January 2022 The WebTransport Protocol Framework - draft-ietf-webtrans-overview-01 + draft-ietf-webtrans-overview-02 Abstract The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used @@ -38,25 +38,25 @@ 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 21 April 2021. + This Internet-Draft will expire on 29 January 2022. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. @@ -100,44 +100,44 @@ stream between a client and a server could rely on WebSockets [RFC6455], a message-based protocol compatible with the Web security model. However, since the abstraction it provides is a single ordered stream of messages, it suffers from head-of-line blocking (HOLB), meaning that all messages must be sent and received in order even if they are independent and some of them are no longer needed. This makes it a poor fit for latency-sensitive applications which rely on partial reliability and stream independence for performance. One existing option available to Web developers are WebRTC data - channels [I-D.ietf-rtcweb-data-channel], which provide a WebSocket- - like API for a peer-to-peer SCTP channel protected by DTLS. In - theory, it is possible to use it for the use cases addressed by this - specification. However, in practice, its use in non-browser-to- - browser settings has been quite low due to its dependency on ICE - (which fits poorly with the Web model) and userspace SCTP (which has - very few implementations available). + channels [RFC8831], which provide a WebSocket-like API for a peer-to- + peer SCTP channel protected by DTLS. In theory, it is possible to + use it for the use cases addressed by this specification. However, + in practice, its use in non-browser-to-browser settings has been + quite low due to its dependency on ICE (which fits poorly with the + Web model) and userspace SCTP (which has very few implementations + available). An alternative design would be to layer WebSockets over HTTP/3 [I-D.ietf-quic-http] in a manner similar to how they are currently layered over HTTP/2 [RFC8441]. That would avoid head-of-line blocking and provide an ability to cancel a stream by closing the corresponding WebSocket object. However, this approach has a number of drawbacks, which all stem primarily from the fact that semantically each WebSocket is a completely independent entity: * Each new stream would require a WebSocket handshake to agree on application protocol used, meaning that it would take at least one RTT to establish each new stream before the client can write to it. * Only clients can initiate streams. Server-initiated streams and other alternative modes of communication (such as the QUIC - DATAGRAM frame [I-D.pauly-quic-datagram]) are not available. + DATAGRAM frame [I-D.ietf-quic-datagram]) are not available. * While the streams would normally be pooled by the user agent, this is not guaranteed, and the general process of mapping a WebSocket to a server is opaque to the client. This introduces unpredictable performance properties into the system, and prevents optimizations which rely on the streams being on the same connection (for instance, it might be possible for the client to request different retransmission priorities for different streams, but that would be much more complex unless they are all on the same connection). @@ -154,123 +154,121 @@ "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. WebTransport is a framework that aims to abstract away the underlying transport protocol while still exposing a few key transport-layer aspects to application developers. It is structured around the following concepts: - Transport session: A transport session is a single communication - context established between a client and a server. It may - correspond to a specific transport-layer connection, or it may be - a logical entity within an existing multiplexed transport-layer - connection. Transport sessions are logically independent from one - another even if some sessions can share an underlying transport- - layer connection. + WebTransport session: A WebTransport session is a single + communication context established between a client and a server. + It may correspond to a specific transport-layer connection, or it + may be a logical entity within an existing multiplexed transport- + layer connection. Transport sessions are logically independent + from one another even if some sessions can share an underlying + transport-layer connection. - Transport protocol: A transport protocol (WebTransport protocol in - contexts where this might be ambiguous) is an instantiation of - WebTransport over a given transport-layer protocol. + WebTransport protocol: A WebTransport protocol is a specific + protocol that can be used to establish a WebTransport session. Datagram: A datagram is a unit of transmission that is treated atomically. Stream: A stream is a sequence of bytes that is reliably delivered to the receiving application in the same order as it was transmitted by the sender. Streams can be of arbitrary length, - and therefore cannot always be buffered entirely in memory. It is - expected for transport protocols and APIs to provide partial + and therefore cannot always be buffered entirely in memory. + WebTransport protocols and APIs are expected to provide partial stream data to the application before the stream has been entirely received. Message: A message is a stream that is sufficiently small that it can be fully buffered before being passed to the application. WebTransport does not define messages as a primitive, since from the transport perspective they can be simulated by fully buffering a stream before passing it to the application. However, this distinction is important to highlight since some of the similar protocols and APIs (notably WebSocket [RFC6455]) use messages as a core abstraction. Transport property: A transport property is a specific behavior that - may or may not be exhibited by a transport. Some of those are - inherent for all instances of a given transport protocol (TCP- - based transport cannot support unreliable delivery), while others - can vary even within the same protocol (QUIC connections may or - may not support connection migration). + may or may not be exhibited by a WebTransport protocol. Some of + those are inherent for all instances of a given transport protocol + (TCP-based transport cannot support unreliable delivery), while + others can vary even within the same protocol (QUIC connections + may or may not support connection migration). Server: A WebTransport server is an application that accepts - incoming transport sessions. + incoming WebTransport sessions. Client: A WebTransport client is an application that initiates the transport session and may be running in a constrained security context, for instance, a JavaScript application running inside a browser. User agent: A WebTransport user agent is a software system that has an unrestricted access to the host network stack and can create transports on behalf of the client. 2. Common Transport Requirements Since clients are not necessarily trusted and have to be constrained by the Web security model, WebTransport imposes certain requirements - on any specific transport protocol used. + on any specific protocol used. - Any transport protocol used MUST use TLS [RFC8446] or a semantically + Any WebTransport protocol MUST use TLS [RFC8446] or a semantically equivalent security protocol (for instance, DTLS [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or later, unless they aim for backwards compatibility with legacy systems. - Any transport protocol used MUST require the user agent to obtain and + Any WebTransport protocol MUST require the user agent to obtain and maintain explicit consent from the server to send data. For connection-oriented protocols (such as TCP or QUIC), the connection establishment and keep-alive mechanisms suffice. STUN Consent Freshness [RFC7675] is another example of the mechanism satisfying this requirement. - Any transport protocol used MUST limit the rate at which the client + Any WebTransport protocol MUST limit the rate at which the client sends data. This SHOULD be accomplished via a feedback-based - congestion control mechanism (such as [RFC5681] or - [I-D.ietf-quic-recovery]). + congestion control mechanism (such as [RFC5681] or [RFC9002]). - Any transport protocol used MUST support simultaneously establishing + Any WebTransport protocol MUST support simultaneously establishing multiple sessions between the same client and server. - Any transport protocol used MUST prevent the clients from - establishing transport sessions to network endpoints that are not - WebTransport servers. + Any WebTransport protocol MUST prevent the clients from establishing + transport sessions to network endpoints that are not WebTransport + servers. - Any transport protocol used MUST provide a way for servers to filter + Any WebTransport protocol MUST provide a way for servers to filter clients that can access it by checking the initiating origin [RFC6454]. - Any transport protocol used MUST provide a way for a server endpoint + Any WebTransport protocol MUST provide a way for a server endpoint location to be described using a URI [RFC3986]. This enables integration with various Web platform features that represent resources as URIs, such as Content Security Policy [CSP]. 3. Session Establishment WebTransport session establishment is most often asynchronous, although in some transports it can succeed instantaneously (for instance, if a transport is immediately pooled with an existing connection). A session MUST NOT be considered established until it is secure against replay attacks. For instance, in protocols creating a new TLS 1.3 session [RFC8446], this would mean that the user agent MUST NOT treat the session as established until it received a Finished message from the server. - In some cases, the transport protocol might allow transmitting data + In some cases, a WebTransport protocol might allow transmitting data before the session is established; an example is TLS 0-RTT data. Since this data can be replayed by attackers, it MUST NOT be used unless the client has explicitly requested 0-RTT for specific streams or datagrams it knows to be safely replayable. 4. Transport Features The following transport features are defined in this document. This list is not meant to be comprehensive; future documents may define new features for both new and already existing transports. @@ -299,22 +297,22 @@ performing path MTU discovery. 4.2. Streams A unidirectional stream is a one-way reliable in-order stream of bytes where the initiator is the only endpoint that can send data. A bidirectional stream allows both endpoints to send data and can be conceptually represented as a pair of unidirectional streams. The streams are in general expected to follow the semantics and the - state machine of QUIC streams ([I-D.ietf-quic-transport], Sections 2 - and 3). TODO: describe the stream state machine explicitly. + state machine of QUIC streams ([RFC9000], Sections 2 and 3). TODO: + describe the stream state machine explicitly. A WebTransport stream can be reset, indicating that the endpoint is not interested in either sending or receiving any data related to the stream. In that case, the sender is expected to not retransmit any data that was already sent on that stream. Streams SHOULD be sufficiently lightweight that they can be used as messages. Data sent on a stream is flow controlled by the transport protocol. @@ -432,102 +430,96 @@ There are no requests to IANA in this document. 9. References 9.1. Normative References [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, - . + . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, - . + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . + 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 - [CSP] W3C, "Content Security Policy Level 3", October 2020, + [CSP] W3C, "Content Security Policy Level 3", July 2021, . + [I-D.ietf-quic-datagram] + Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable + Datagram Extension to QUIC", Work in Progress, Internet- + Draft, draft-ietf-quic-datagram-03, 12 July 2021, + . + [I-D.ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- - quic-http-31, 24 September 2020, . - - [I-D.ietf-quic-recovery] - Iyengar, J. and I. Swett, "QUIC Loss Detection and - Congestion Control", Work in Progress, Internet-Draft, - draft-ietf-quic-recovery-31, 24 September 2020, - . - - [I-D.ietf-quic-transport] - Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed - and Secure Transport", Work in Progress, Internet-Draft, - draft-ietf-quic-transport-31, 24 September 2020, - . - - [I-D.ietf-rtcweb-data-channel] - Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data - Channels", Work in Progress, Internet-Draft, draft-ietf- - rtcweb-data-channel-13, 4 January 2015, - . + quic-http-34, 2 February 2021, + . [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- - dtls13-38, 29 May 2020, . - - [I-D.pauly-quic-datagram] - Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable - Datagram Extension to QUIC", Work in Progress, Internet- - Draft, draft-pauly-quic-datagram-05, 4 November 2019, - . + dtls13-43, 30 April 2021, + . [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, - . + . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, - . + . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, - . + . [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, - October 2015, . + October 2015, . [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", RFC 8441, DOI 10.17487/RFC8441, September 2018, - . + . + + [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data + Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, + . + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + . + + [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection + and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, + May 2021, . Author's Address Victor Vasiliev Google Email: vasilvv@google.com