idnits 2.17.1 draft-ietf-webtrans-overview-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBTRANS V. Vasiliev 3 Internet-Draft Google 4 Intended status: Standards Track 7 March 2022 5 Expires: 8 September 2022 7 The WebTransport Protocol Framework 8 draft-ietf-webtrans-overview-03 10 Abstract 12 The WebTransport Protocol Framework enables clients constrained by 13 the Web security model to communicate with a remote server using a 14 secure multiplexed transport. It consists of a set of individual 15 protocols that are safe to expose to untrusted applications, combined 16 with a model that allows them to be used interchangeably. 18 This document defines the overall requirements on the protocols used 19 in WebTransport, as well as the common features of the protocols, 20 support for some of which may be optional. 22 Note to Readers 24 Discussion of this draft takes place on the WebTransport mailing list 25 (webtransport@ietf.org), which is archived at 26 . 28 The repository tracking the issues for this draft can be found at 29 . The web API draft corresponding to this document can be 31 found at . 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 8 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4 69 2. Common Transport Requirements . . . . . . . . . . . . . . . . 5 70 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 6 71 4. Transport Features . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Transport Properties . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 8.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 The WebTransport Protocol Framework enables clients constrained by 85 the Web security model to communicate with a remote server using a 86 secure multiplexed transport. It consists of a set of individual 87 protocols that are safe to expose to untrusted applications, combined 88 with a model that allows them to be used interchangeably. 90 This document defines the overall requirements on the protocols used 91 in WebTransport, as well as the common features of the protocols, 92 support for some of which may be optional. 94 1.1. Background 96 Historically, web applications that needed a bidirectional data 97 stream between a client and a server could rely on WebSockets 98 [RFC6455], a message-based protocol compatible with the Web security 99 model. However, since the abstraction it provides is a single 100 ordered stream of messages, it suffers from head-of-line blocking 101 (HOLB), meaning that all messages must be sent and received in order 102 even if they are independent and some of them are no longer needed. 103 This makes it a poor fit for latency-sensitive applications which 104 rely on partial reliability and stream independence for performance. 106 One existing option available to Web developers are WebRTC data 107 channels [RFC8831], which provide a WebSocket-like API for a peer-to- 108 peer SCTP channel protected by DTLS. In theory, it is possible to 109 use it for the use cases addressed by this specification. However, 110 in practice, its use in non-browser-to-browser settings has been 111 quite low due to its dependency on ICE (which fits poorly with the 112 Web model) and userspace SCTP (which has very few implementations 113 available). 115 An alternative design would be to open multiple WebSocket connections 116 over HTTP/3 [I-D.ietf-httpbis-h3-websockets] in a manner similar to 117 how they are currently layered over HTTP/2 [RFC8441]. That would 118 avoid head-of-line blocking and provide an ability to cancel a stream 119 by closing the corresponding WebSocket object. However, this 120 approach has a number of drawbacks, which all stem primarily from the 121 fact that semantically each WebSocket is a completely independent 122 entity: 124 * Each new stream would require a WebSocket handshake to agree on 125 application protocol used, meaning that it would take at least one 126 RTT to establish each new stream before the client can write to 127 it. 129 * Only clients can initiate streams. Server-initiated streams and 130 other alternative modes of communication (such as the QUIC 131 DATAGRAM frame [I-D.ietf-quic-datagram]) are not available. 133 * While the streams would normally be pooled by the user agent, this 134 is not guaranteed, and the general process of mapping a WebSocket 135 to a server is opaque to the client. This introduces 136 unpredictable performance properties into the system, and prevents 137 optimizations which rely on the streams being on the same 138 connection (for instance, it might be possible for the client to 139 request different retransmission priorities for different streams, 140 but that would be much more complex unless they are all on the 141 same connection). 143 The WebTransport protocol framework avoids all of those issues by 144 letting applications create a single transport object that can 145 contain multiple streams multiplexed together in a single context 146 (similar to SCTP, HTTP/2, QUIC and others), and can be also used to 147 send unreliable datagrams (similar to UDP). 149 1.2. Conventions and Definitions 151 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 WebTransport is a framework that aims to abstract away the underlying 158 transport protocol while still exposing a few key transport-layer 159 aspects to application developers. It is structured around the 160 following concepts: 162 WebTransport session: A WebTransport session is a single 163 communication context established between a client and a server. 164 It may correspond to a specific transport-layer connection, or it 165 may be a logical entity within an existing multiplexed transport- 166 layer connection. Transport sessions are logically independent 167 from one another even if some sessions can share an underlying 168 transport-layer connection. 170 WebTransport protocol: A WebTransport protocol is a specific 171 protocol that can be used to establish a WebTransport session. 173 Datagram: A datagram is a unit of transmission that is treated 174 atomically. 176 Stream: A stream is a sequence of bytes that is reliably delivered 177 to the receiving application in the same order as it was 178 transmitted by the sender. Streams can be of arbitrary length, 179 and therefore cannot always be buffered entirely in memory. 180 WebTransport protocols and APIs are expected to provide partial 181 stream data to the application before the stream has been entirely 182 received. 184 Message: A message is a stream that is sufficiently small that it 185 can be fully buffered before being passed to the application. 186 WebTransport does not define messages as a primitive, since from 187 the transport perspective they can be simulated by fully buffering 188 a stream before passing it to the application. However, this 189 distinction is important to highlight since some of the similar 190 protocols and APIs (notably WebSocket [RFC6455]) use messages as a 191 core abstraction. 193 Server: A WebTransport server is an application that accepts 194 incoming WebTransport sessions. 196 Client: A WebTransport client is an application that initiates the 197 transport session and may be running in a constrained security 198 context, for instance, a JavaScript application running inside a 199 browser. 201 User agent: A WebTransport user agent is a software system that has 202 an unrestricted access to the host network stack and can create 203 transports on behalf of the client. 205 2. Common Transport Requirements 207 Since clients are not necessarily trusted and have to be constrained 208 by the Web security model, WebTransport imposes certain requirements 209 on any specific protocol used. 211 All WebTransport protocols MUST use TLS [RFC8446] or a semantically 212 equivalent security protocol (for instance, DTLS 213 [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or 214 later, unless they aim for backwards compatibility with legacy 215 systems. 217 All WebTransport protocols MUST require the user agent to obtain and 218 maintain explicit consent from the server to send data. For 219 connection-oriented protocols (such as TCP or QUIC), the connection 220 establishment and keep-alive mechanisms suffice. STUN Consent 221 Freshness [RFC7675] is another example of a mechanism satisfying this 222 requirement. 224 All WebTransport protocols MUST limit the rate at which the client 225 sends data. This SHOULD be accomplished via a feedback-based 226 congestion control mechanism (such as [RFC5681] or [RFC9002]). 228 All WebTransport protocols MUST support simultaneously establishing 229 multiple sessions between the same client and server. 231 All WebTransport protocols MUST prevent clients from establishing 232 transport sessions to network endpoints that are not WebTransport 233 servers. 235 All WebTransport protocols MUST provide a way for the user agent to 236 indicate the origin [RFC6454] of the client to the server. 238 All WebTransport protocols MUST provide a way for a server endpoint 239 location to be described using a URI [RFC3986]. This enables 240 integration with various Web platform features that represent 241 resources as URIs, such as Content Security Policy [CSP]. 243 3. Session Establishment 245 WebTransport session establishment is an asynchronous process. A 246 session is considered _ready_ from the client's perspective when the 247 server has confirmed that it is willing to accept the session with 248 the provided origin and URI. WebTransport protocols MAY allow 249 clients to send data before the session is ready; however, they MUST 250 NOT use mechanisms that are unsafe against replay attacks without an 251 explicit indication from the client. 253 4. Transport Features 255 All transport protocols MUST provide datagrams, unidirectional and 256 bidirectional streams in order to make the transport protocols 257 interchangeable. 259 4.1. Datagrams 261 A datagram is a sequence of bytes that is limited in size (generally 262 to the path MTU) and is not expected to be transmitted reliably. The 263 general goal for WebTransport datagrams is to be similar in behavior 264 to UDP while being subject to common requirements expressed in 265 Section 2. 267 A WebTransport sender is not expected to retransmit datagrams, though 268 it may end up doing so if it is using a TCP-based protocol or some 269 other underlying protocol that only provides reliable delivery. 270 WebTransport datagrams are not expected to be flow controlled, 271 meaning that the receiver might drop datagrams if the application is 272 not consuming them fast enough. 274 The application MUST be provided with the maximum datagram size that 275 it can send. The size SHOULD be derived from the result of 276 performing path MTU discovery. 278 4.2. Streams 280 A unidirectional stream is a one-way reliable in-order stream of 281 bytes where the initiator is the only endpoint that can send data. A 282 bidirectional stream allows both endpoints to send data and can be 283 conceptually represented as a pair of unidirectional streams. 285 The streams are in general expected to follow the semantics and the 286 state machine of QUIC streams ([RFC9000], Sections 2 and 3). TODO: 287 describe the stream state machine explicitly. 289 A WebTransport stream can be reset, indicating that the endpoint is 290 not interested in either sending or receiving any data related to the 291 stream. In that case, the sender is expected to not retransmit any 292 data that was already sent on that stream. 294 Streams SHOULD be sufficiently lightweight that they can be used as 295 messages. 297 Data sent on a stream is flow controlled by the transport protocol. 298 In addition to flow controlling stream data, the creation of new 299 streams is flow controlled as well: an endpoint may only open a 300 limited number of streams until the peer explicitly allows creating 301 more streams. 303 5. Transport Properties 305 WebTransport defines common semantics for multiple protocols to allow 306 them to be used interchangeably. Nevertheless, those protocols still 307 have substantially different performance properties that an 308 application may want to query. 310 The most notable property is support for unreliable data delivery. 311 The protocol is defined to support unreliable delivery if: 313 * Resetting a stream results in the lost stream data no longer being 314 retransmitted, and 316 * The datagrams are never retransmitted. 318 Another important property is pooling support. Pooling means that 319 multiple transport sessions may end up sharing the same transport 320 layer connection, and thus share a congestion controller and other 321 contexts. 323 6. Security Considerations 325 Providing untrusted clients with a reasonably low-level access to the 326 network comes with risks. This document mitigates those risks by 327 imposing a set of common requirements described in Section 2. 329 WebTransport mandates the use of TLS for all protocols implementing 330 it. This has a dual purpose. On one hand, it protects the transport 331 from the network, including both potential attackers and ossification 332 by middleboxes. On the other hand, it protects the network elements 333 from potential confusion attacks such as the one discussed in 334 Section 10.3 of [RFC6455]. 336 One potential concern is that even when a transport cannot be 337 created, the connection error would reveal enough information to 338 allow an attacker to scan the network addresses that would normally 339 be inaccessible. Because of that, the user agent that runs untrusted 340 clients MUST NOT provide any detailed error information until the 341 server has confirmed that it is a WebTransport endpoint. For 342 example, the client must not be able to distinguish between a network 343 address that is unreachable and one that is reachable but is not a 344 WebTransport server. 346 WebTransport does not support any traditional means of HTTP-based 347 authentication. It is not necessarily based on HTTP, and hence does 348 not support HTTP cookies or HTTP authentication. Since it requires 349 TLS, individual transport protocols MAY expose TLS-based 350 authentication capabilities such as client certificates. 352 7. IANA Considerations 354 There are no requests to IANA in this document. 356 8. References 358 8.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 366 Resource Identifier (URI): Generic Syntax", STD 66, 367 RFC 3986, DOI 10.17487/RFC3986, January 2005, 368 . 370 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 371 DOI 10.17487/RFC6454, December 2011, 372 . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 379 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 380 . 382 8.2. Informative References 384 [CSP] W3C, "Content Security Policy Level 3", March 2022, 385 . 387 [I-D.ietf-httpbis-h3-websockets] 388 Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work 389 in Progress, Internet-Draft, draft-ietf-httpbis-h3- 390 websockets-04, 8 February 2022, 391 . 394 [I-D.ietf-quic-datagram] 395 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 396 Datagram Extension to QUIC", Work in Progress, Internet- 397 Draft, draft-ietf-quic-datagram-10, 4 February 2022, 398 . 401 [I-D.ietf-tls-dtls13] 402 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 403 Datagram Transport Layer Security (DTLS) Protocol Version 404 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 405 dtls13-43, 30 April 2021, 406 . 409 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 410 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 411 . 413 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 414 RFC 6455, DOI 10.17487/RFC6455, December 2011, 415 . 417 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 418 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 419 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 420 October 2015, . 422 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 423 RFC 8441, DOI 10.17487/RFC8441, September 2018, 424 . 426 [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data 427 Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, 428 . 430 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 431 Multiplexed and Secure Transport", RFC 9000, 432 DOI 10.17487/RFC9000, May 2021, 433 . 435 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 436 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 437 May 2021, . 439 Author's Address 441 Victor Vasiliev 442 Google 443 Email: vasilvv@google.com