--- 1/draft-ietf-webtrans-overview-02.txt 2022-03-07 15:16:31.992217766 -0800 +++ 2/draft-ietf-webtrans-overview-03.txt 2022-03-07 15:16:32.008217970 -0800 @@ -1,18 +1,18 @@ WEBTRANS V. Vasiliev Internet-Draft Google -Intended status: Standards Track 28 July 2021 -Expires: 29 January 2022 +Intended status: Standards Track 7 March 2022 +Expires: 8 September 2022 The WebTransport Protocol Framework - draft-ietf-webtrans-overview-02 + draft-ietf-webtrans-overview-03 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,56 +38,53 @@ 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 29 January 2022. + This Internet-Draft will expire on 8 September 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 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. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. Common Transport Requirements . . . . . . . . . . . . . . . . 5 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 6 4. Transport Features . . . . . . . . . . . . . . . . . . . . . 6 - 4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.3. Protocol-Specific Features . . . . . . . . . . . . . . . 8 - 4.4. Bandwidth Prediction . . . . . . . . . . . . . . . . . . 8 - 5. Buffering and Prioritization . . . . . . . . . . . . . . . . 8 - 6. Transport Properties . . . . . . . . . . . . . . . . . . . . 9 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 9.2. Informative References . . . . . . . . . . . . . . . . . 10 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5. Transport Properties . . . . . . . . . . . . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 8.2. Informative References . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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 @@ -108,27 +105,28 @@ One existing option available to Web developers are WebRTC data 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: + An alternative design would be to open multiple WebSocket connections + over HTTP/3 [I-D.ietf-httpbis-h3-websockets] 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.ietf-quic-datagram]) are not available. @@ -185,121 +183,102 @@ 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 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 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 protocol used. - Any WebTransport protocol MUST use TLS [RFC8446] or a semantically + All WebTransport protocols 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 WebTransport protocol MUST require the user agent to obtain and + All WebTransport protocols 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. + Freshness [RFC7675] is another example of a mechanism satisfying this + requirement. - Any WebTransport protocol MUST limit the rate at which the client + All WebTransport protocols 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 [RFC9002]). - Any WebTransport protocol MUST support simultaneously establishing + All WebTransport protocols MUST support simultaneously establishing multiple sessions between the same client and server. - Any WebTransport protocol MUST prevent the clients from establishing + All WebTransport protocols MUST prevent clients from establishing transport sessions to network endpoints that are not WebTransport servers. - Any WebTransport protocol MUST provide a way for servers to filter - clients that can access it by checking the initiating origin - [RFC6454]. + All WebTransport protocols MUST provide a way for the user agent to + indicate the origin [RFC6454] of the client to the server. - Any WebTransport protocol MUST provide a way for a server endpoint + All WebTransport protocols 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, 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. + WebTransport session establishment is an asynchronous process. A + session is considered _ready_ from the client's perspective when the + server has confirmed that it is willing to accept the session with + the provided origin and URI. WebTransport protocols MAY allow + clients to send data before the session is ready; however, they MUST + NOT use mechanisms that are unsafe against replay attacks without an + explicit indication from the client. 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. - All transport protocols MUST provide datagrams, unidirectional and - bidirectional streams in order to make the transport protocols easily + bidirectional streams in order to make the transport protocols interchangeable. 4.1. Datagrams A datagram is a sequence of bytes that is limited in size (generally to the path MTU) and is not expected to be transmitted reliably. The general goal for WebTransport datagrams is to be similar in behavior to UDP while being subject to common requirements expressed in Section 2. - The WebTransport sender is not expected to retransmit datagrams, - though it may if it is using a TCP-based protocol or some other - underlying protocol that requires reliable delivery. WebTransport - datagrams are not expected to be flow controlled, meaning that the - receiver might drop datagrams if the application is not consuming - them fast enough. + A WebTransport sender is not expected to retransmit datagrams, though + it may end up doing so if it is using a TCP-based protocol or some + other underlying protocol that only provides reliable delivery. + WebTransport datagrams are not expected to be flow controlled, + meaning that the receiver might drop datagrams if the application is + not consuming them fast enough. - The application MUST be provided with the maxiumum datagram size that + The application MUST be provided with the maximum datagram size that it can send. The size SHOULD be derived from the result of 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. @@ -314,97 +293,41 @@ Streams SHOULD be sufficiently lightweight that they can be used as messages. Data sent on a stream is flow controlled by the transport protocol. In addition to flow controlling stream data, the creation of new streams is flow controlled as well: an endpoint may only open a limited number of streams until the peer explicitly allows creating more streams. - Every stream within a transport has a unique 64-bit number - identifying it. Both unidirectional and bidirectional streams share - the number space. The client and the server have to agree on the - numbering, so it can be referenced in the application payload. - - WebTransport does not impose any other specific restrictions on the - structure of stream IDs, and they should be treated as opaque 64-bit - blobs. - -4.3. Protocol-Specific Features - - In addition to features described above, there are some capabilities - that may be provided by an individual protocol but are not - universally applicable to all protocols. Those are allowed, but any - protocol is expected to be useful without those features, and - portable clients should not rely on them. - - A notable class of protocol-specific features are features available - only in non-pooled transports. Since those transports have a - dedicated connection, a user agent can provide clients with an - extensive amount of transport-level data that would be too noisy and - difficult to interpret when the connection is shared with unrelated - traffic. For instance, a user agent can provide the number of - packets lost, or the number of times stream data was delayed due to - flow control. It can also expose variables related to congestion - control, such as the size of the congestion window or the current - pacing rate. - -4.4. Bandwidth Prediction - - Using congestion control state and transport metrics, the client can - predict the rate at which it can send data. That is essential for - many WebTransport use cases; for instance, real time media - applications adapt the video bitrate to be a fraction of the - throughput they expect to be available. While not all transport - protocols can provide low-level transport details, all protocols - SHOULD provide the client with an estimate of the available - bandwidth. - -5. Buffering and Prioritization - - TODO: expand this outline into a full summary. - - * Datagrams are intended for low-latency communications, so the - buffers for them should be small, and prioritized over stream - data. - - * In general, the transport should not apply aggregation algorithms - (e.g., Nagle's algorithm [RFC0896]) to datagrams. - -6. Transport Properties +5. Transport Properties - In addition to common requirements, each transport can have multiple - optional properties associated with it. Querying them allows the - client to ascertain the presence of features it can use without - requiring knowledge of all protocols. This allows introducing new - transports as drop-in replacements for existing ones. + WebTransport defines common semantics for multiple protocols to allow + them to be used interchangeably. Nevertheless, those protocols still + have substantially different performance properties that an + application may want to query. - The following properties are defined in this specification: + The most notable property is support for unreliable data delivery. + The protocol is defined to support unreliable delivery if: - * Stream independence. This indicates that there is no head of line - blocking between different streams. + * Resetting a stream results in the lost stream data no longer being + retransmitted, and - * Partial reliability. This indicates that if a stream is reset, - none of the data sent on it will be retransmitted. This also - indicates that datagrams will not be retransmitted. + * The datagrams are never retransmitted. - * Pooling support. Indicates that multiple transports using this - transport protocol may end up sharing the same transport layer - connection, and thus share a congestion controller and other + Another important property is pooling support. Pooling means that + multiple transport sessions may end up sharing the same transport + layer connection, and thus share a congestion controller and other contexts. - * Connection mobility. Indicates that the transport may continue - existing even if the network path between the client and the - server changes. - -7. Security Considerations +6. Security Considerations Providing untrusted clients with a reasonably low-level access to the network comes with risks. This document mitigates those risks by imposing a set of common requirements described in Section 2. WebTransport mandates the use of TLS for all protocols implementing it. This has a dual purpose. On one hand, it protects the transport from the network, including both potential attackers and ossification by middleboxes. On the other hand, it protects the network elements from potential confusion attacks such as the one discussed in @@ -419,107 +342,102 @@ example, the client must not be able to distinguish between a network address that is unreachable and one that is reachable but is not a WebTransport server. WebTransport does not support any traditional means of HTTP-based authentication. It is not necessarily based on HTTP, and hence does not support HTTP cookies or HTTP authentication. Since it requires TLS, individual transport protocols MAY expose TLS-based authentication capabilities such as client certificates. -8. IANA Considerations +7. IANA Considerations There are no requests to IANA in this document. -9. References +8. References -9.1. Normative References +8.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 +8.2. Informative References - [CSP] W3C, "Content Security Policy Level 3", July 2021, + [CSP] W3C, "Content Security Policy Level 3", March 2022, . + [I-D.ietf-httpbis-h3-websockets] + Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work + in Progress, Internet-Draft, draft-ietf-httpbis-h3- + websockets-04, 8 February 2022, + . + [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-34, 2 February 2021, + Draft, draft-ietf-quic-datagram-10, 4 February 2022, . + datagram-10>. [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-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, . + May 2021, . Author's Address Victor Vasiliev Google - Email: vasilvv@google.com