idnits 2.17.1 draft-ietf-webtrans-overview-02.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 (28 July 2021) is 1001 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) == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-03 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 28 July 2021 5 Expires: 29 January 2022 7 The WebTransport Protocol Framework 8 draft-ietf-webtrans-overview-02 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 29 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3. Protocol-Specific Features . . . . . . . . . . . . . . . 8 75 4.4. Bandwidth Prediction . . . . . . . . . . . . . . . . . . 8 76 5. Buffering and Prioritization . . . . . . . . . . . . . . . . 8 77 6. Transport Properties . . . . . . . . . . . . . . . . . . . . 9 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The WebTransport Protocol Framework enables clients constrained by 88 the Web security model to communicate with a remote server using a 89 secure multiplexed transport. It consists of a set of individual 90 protocols that are safe to expose to untrusted applications, combined 91 with a model that allows them to be used interchangeably. 93 This document defines the overall requirements on the protocols used 94 in WebTransport, as well as the common features of the protocols, 95 support for some of which may be optional. 97 1.1. Background 99 Historically, web applications that needed a bidirectional data 100 stream between a client and a server could rely on WebSockets 101 [RFC6455], a message-based protocol compatible with the Web security 102 model. However, since the abstraction it provides is a single 103 ordered stream of messages, it suffers from head-of-line blocking 104 (HOLB), meaning that all messages must be sent and received in order 105 even if they are independent and some of them are no longer needed. 106 This makes it a poor fit for latency-sensitive applications which 107 rely on partial reliability and stream independence for performance. 109 One existing option available to Web developers are WebRTC data 110 channels [RFC8831], which provide a WebSocket-like API for a peer-to- 111 peer SCTP channel protected by DTLS. In theory, it is possible to 112 use it for the use cases addressed by this specification. However, 113 in practice, its use in non-browser-to-browser settings has been 114 quite low due to its dependency on ICE (which fits poorly with the 115 Web model) and userspace SCTP (which has very few implementations 116 available). 118 An alternative design would be to layer WebSockets over HTTP/3 119 [I-D.ietf-quic-http] in a manner similar to how they are currently 120 layered over HTTP/2 [RFC8441]. That would avoid head-of-line 121 blocking and provide an ability to cancel a stream by closing the 122 corresponding WebSocket object. However, this approach has a number 123 of drawbacks, which all stem primarily from the fact that 124 semantically each WebSocket is a completely independent entity: 126 * Each new stream would require a WebSocket handshake to agree on 127 application protocol used, meaning that it would take at least one 128 RTT to establish each new stream before the client can write to 129 it. 131 * Only clients can initiate streams. Server-initiated streams and 132 other alternative modes of communication (such as the QUIC 133 DATAGRAM frame [I-D.ietf-quic-datagram]) are not available. 135 * While the streams would normally be pooled by the user agent, this 136 is not guaranteed, and the general process of mapping a WebSocket 137 to a server is opaque to the client. This introduces 138 unpredictable performance properties into the system, and prevents 139 optimizations which rely on the streams being on the same 140 connection (for instance, it might be possible for the client to 141 request different retransmission priorities for different streams, 142 but that would be much more complex unless they are all on the 143 same connection). 145 The WebTransport protocol framework avoids all of those issues by 146 letting applications create a single transport object that can 147 contain multiple streams multiplexed together in a single context 148 (similar to SCTP, HTTP/2, QUIC and others), and can be also used to 149 send unreliable datagrams (similar to UDP). 151 1.2. Conventions and Definitions 153 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 WebTransport is a framework that aims to abstract away the underlying 160 transport protocol while still exposing a few key transport-layer 161 aspects to application developers. It is structured around the 162 following concepts: 164 WebTransport session: A WebTransport session is a single 165 communication context established between a client and a server. 166 It may correspond to a specific transport-layer connection, or it 167 may be a logical entity within an existing multiplexed transport- 168 layer connection. Transport sessions are logically independent 169 from one another even if some sessions can share an underlying 170 transport-layer connection. 172 WebTransport protocol: A WebTransport protocol is a specific 173 protocol that can be used to establish a WebTransport session. 175 Datagram: A datagram is a unit of transmission that is treated 176 atomically. 178 Stream: A stream is a sequence of bytes that is reliably delivered 179 to the receiving application in the same order as it was 180 transmitted by the sender. Streams can be of arbitrary length, 181 and therefore cannot always be buffered entirely in memory. 182 WebTransport protocols and APIs are expected to provide partial 183 stream data to the application before the stream has been entirely 184 received. 186 Message: A message is a stream that is sufficiently small that it 187 can be fully buffered before being passed to the application. 188 WebTransport does not define messages as a primitive, since from 189 the transport perspective they can be simulated by fully buffering 190 a stream before passing it to the application. However, this 191 distinction is important to highlight since some of the similar 192 protocols and APIs (notably WebSocket [RFC6455]) use messages as a 193 core abstraction. 195 Transport property: A transport property is a specific behavior that 196 may or may not be exhibited by a WebTransport protocol. Some of 197 those are inherent for all instances of a given transport protocol 198 (TCP-based transport cannot support unreliable delivery), while 199 others can vary even within the same protocol (QUIC connections 200 may or may not support connection migration). 202 Server: A WebTransport server is an application that accepts 203 incoming WebTransport sessions. 205 Client: A WebTransport client is an application that initiates the 206 transport session and may be running in a constrained security 207 context, for instance, a JavaScript application running inside a 208 browser. 210 User agent: A WebTransport user agent is a software system that has 211 an unrestricted access to the host network stack and can create 212 transports on behalf of the client. 214 2. Common Transport Requirements 216 Since clients are not necessarily trusted and have to be constrained 217 by the Web security model, WebTransport imposes certain requirements 218 on any specific protocol used. 220 Any WebTransport protocol MUST use TLS [RFC8446] or a semantically 221 equivalent security protocol (for instance, DTLS 222 [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or 223 later, unless they aim for backwards compatibility with legacy 224 systems. 226 Any WebTransport protocol MUST require the user agent to obtain and 227 maintain explicit consent from the server to send data. For 228 connection-oriented protocols (such as TCP or QUIC), the connection 229 establishment and keep-alive mechanisms suffice. STUN Consent 230 Freshness [RFC7675] is another example of the mechanism satisfying 231 this requirement. 233 Any WebTransport protocol MUST limit the rate at which the client 234 sends data. This SHOULD be accomplished via a feedback-based 235 congestion control mechanism (such as [RFC5681] or [RFC9002]). 237 Any WebTransport protocol MUST support simultaneously establishing 238 multiple sessions between the same client and server. 240 Any WebTransport protocol MUST prevent the clients from establishing 241 transport sessions to network endpoints that are not WebTransport 242 servers. 244 Any WebTransport protocol MUST provide a way for servers to filter 245 clients that can access it by checking the initiating origin 246 [RFC6454]. 248 Any WebTransport protocol MUST provide a way for a server endpoint 249 location to be described using a URI [RFC3986]. This enables 250 integration with various Web platform features that represent 251 resources as URIs, such as Content Security Policy [CSP]. 253 3. Session Establishment 255 WebTransport session establishment is most often asynchronous, 256 although in some transports it can succeed instantaneously (for 257 instance, if a transport is immediately pooled with an existing 258 connection). A session MUST NOT be considered established until it 259 is secure against replay attacks. For instance, in protocols 260 creating a new TLS 1.3 session [RFC8446], this would mean that the 261 user agent MUST NOT treat the session as established until it 262 received a Finished message from the server. 264 In some cases, a WebTransport protocol might allow transmitting data 265 before the session is established; an example is TLS 0-RTT data. 266 Since this data can be replayed by attackers, it MUST NOT be used 267 unless the client has explicitly requested 0-RTT for specific streams 268 or datagrams it knows to be safely replayable. 270 4. Transport Features 272 The following transport features are defined in this document. This 273 list is not meant to be comprehensive; future documents may define 274 new features for both new and already existing transports. 276 All transport protocols MUST provide datagrams, unidirectional and 277 bidirectional streams in order to make the transport protocols easily 278 interchangeable. 280 4.1. Datagrams 282 A datagram is a sequence of bytes that is limited in size (generally 283 to the path MTU) and is not expected to be transmitted reliably. The 284 general goal for WebTransport datagrams is to be similar in behavior 285 to UDP while being subject to common requirements expressed in 286 Section 2. 288 The WebTransport sender is not expected to retransmit datagrams, 289 though it may if it is using a TCP-based protocol or some other 290 underlying protocol that requires reliable delivery. WebTransport 291 datagrams are not expected to be flow controlled, meaning that the 292 receiver might drop datagrams if the application is not consuming 293 them fast enough. 295 The application MUST be provided with the maxiumum datagram size that 296 it can send. The size SHOULD be derived from the result of 297 performing path MTU discovery. 299 4.2. Streams 301 A unidirectional stream is a one-way reliable in-order stream of 302 bytes where the initiator is the only endpoint that can send data. A 303 bidirectional stream allows both endpoints to send data and can be 304 conceptually represented as a pair of unidirectional streams. 306 The streams are in general expected to follow the semantics and the 307 state machine of QUIC streams ([RFC9000], Sections 2 and 3). TODO: 308 describe the stream state machine explicitly. 310 A WebTransport stream can be reset, indicating that the endpoint is 311 not interested in either sending or receiving any data related to the 312 stream. In that case, the sender is expected to not retransmit any 313 data that was already sent on that stream. 315 Streams SHOULD be sufficiently lightweight that they can be used as 316 messages. 318 Data sent on a stream is flow controlled by the transport protocol. 319 In addition to flow controlling stream data, the creation of new 320 streams is flow controlled as well: an endpoint may only open a 321 limited number of streams until the peer explicitly allows creating 322 more streams. 324 Every stream within a transport has a unique 64-bit number 325 identifying it. Both unidirectional and bidirectional streams share 326 the number space. The client and the server have to agree on the 327 numbering, so it can be referenced in the application payload. 329 WebTransport does not impose any other specific restrictions on the 330 structure of stream IDs, and they should be treated as opaque 64-bit 331 blobs. 333 4.3. Protocol-Specific Features 335 In addition to features described above, there are some capabilities 336 that may be provided by an individual protocol but are not 337 universally applicable to all protocols. Those are allowed, but any 338 protocol is expected to be useful without those features, and 339 portable clients should not rely on them. 341 A notable class of protocol-specific features are features available 342 only in non-pooled transports. Since those transports have a 343 dedicated connection, a user agent can provide clients with an 344 extensive amount of transport-level data that would be too noisy and 345 difficult to interpret when the connection is shared with unrelated 346 traffic. For instance, a user agent can provide the number of 347 packets lost, or the number of times stream data was delayed due to 348 flow control. It can also expose variables related to congestion 349 control, such as the size of the congestion window or the current 350 pacing rate. 352 4.4. Bandwidth Prediction 354 Using congestion control state and transport metrics, the client can 355 predict the rate at which it can send data. That is essential for 356 many WebTransport use cases; for instance, real time media 357 applications adapt the video bitrate to be a fraction of the 358 throughput they expect to be available. While not all transport 359 protocols can provide low-level transport details, all protocols 360 SHOULD provide the client with an estimate of the available 361 bandwidth. 363 5. Buffering and Prioritization 365 TODO: expand this outline into a full summary. 367 * Datagrams are intended for low-latency communications, so the 368 buffers for them should be small, and prioritized over stream 369 data. 371 * In general, the transport should not apply aggregation algorithms 372 (e.g., Nagle's algorithm [RFC0896]) to datagrams. 374 6. Transport Properties 376 In addition to common requirements, each transport can have multiple 377 optional properties associated with it. Querying them allows the 378 client to ascertain the presence of features it can use without 379 requiring knowledge of all protocols. This allows introducing new 380 transports as drop-in replacements for existing ones. 382 The following properties are defined in this specification: 384 * Stream independence. This indicates that there is no head of line 385 blocking between different streams. 387 * Partial reliability. This indicates that if a stream is reset, 388 none of the data sent on it will be retransmitted. This also 389 indicates that datagrams will not be retransmitted. 391 * Pooling support. Indicates that multiple transports using this 392 transport protocol may end up sharing the same transport layer 393 connection, and thus share a congestion controller and other 394 contexts. 396 * Connection mobility. Indicates that the transport may continue 397 existing even if the network path between the client and the 398 server changes. 400 7. Security Considerations 402 Providing untrusted clients with a reasonably low-level access to the 403 network comes with risks. This document mitigates those risks by 404 imposing a set of common requirements described in Section 2. 406 WebTransport mandates the use of TLS for all protocols implementing 407 it. This has a dual purpose. On one hand, it protects the transport 408 from the network, including both potential attackers and ossification 409 by middleboxes. On the other hand, it protects the network elements 410 from potential confusion attacks such as the one discussed in 411 Section 10.3 of [RFC6455]. 413 One potential concern is that even when a transport cannot be 414 created, the connection error would reveal enough information to 415 allow an attacker to scan the network addresses that would normally 416 be inaccessible. Because of that, the user agent that runs untrusted 417 clients MUST NOT provide any detailed error information until the 418 server has confirmed that it is a WebTransport endpoint. For 419 example, the client must not be able to distinguish between a network 420 address that is unreachable and one that is reachable but is not a 421 WebTransport server. 423 WebTransport does not support any traditional means of HTTP-based 424 authentication. It is not necessarily based on HTTP, and hence does 425 not support HTTP cookies or HTTP authentication. Since it requires 426 TLS, individual transport protocols MAY expose TLS-based 427 authentication capabilities such as client certificates. 429 8. IANA Considerations 431 There are no requests to IANA in this document. 433 9. References 435 9.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 443 Resource Identifier (URI): Generic Syntax", STD 66, 444 RFC 3986, DOI 10.17487/RFC3986, January 2005, 445 . 447 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 448 DOI 10.17487/RFC6454, December 2011, 449 . 451 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 452 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 453 May 2017, . 455 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 456 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 457 . 459 9.2. Informative References 461 [CSP] W3C, "Content Security Policy Level 3", July 2021, 462 . 464 [I-D.ietf-quic-datagram] 465 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 466 Datagram Extension to QUIC", Work in Progress, Internet- 467 Draft, draft-ietf-quic-datagram-03, 12 July 2021, 468 . 471 [I-D.ietf-quic-http] 472 Bishop, M., "Hypertext Transfer Protocol Version 3 473 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 474 quic-http-34, 2 February 2021, 475 . 478 [I-D.ietf-tls-dtls13] 479 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 480 Datagram Transport Layer Security (DTLS) Protocol Version 481 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 482 dtls13-43, 30 April 2021, 483 . 486 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 487 RFC 896, DOI 10.17487/RFC0896, January 1984, 488 . 490 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 491 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 492 . 494 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 495 RFC 6455, DOI 10.17487/RFC6455, December 2011, 496 . 498 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 499 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 500 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 501 October 2015, . 503 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 504 RFC 8441, DOI 10.17487/RFC8441, September 2018, 505 . 507 [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data 508 Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, 509 . 511 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 512 Multiplexed and Secure Transport", RFC 9000, 513 DOI 10.17487/RFC9000, May 2021, 514 . 516 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 517 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 518 May 2021, . 520 Author's Address 522 Victor Vasiliev 523 Google 525 Email: vasilvv@google.com