idnits 2.17.1 draft-ietf-webtrans-overview-00.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: ---------------------------------------------------------------------------- No issues found here. 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 (17 April 2020) is 1469 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 (-34) exists of draft-ietf-quic-http-23 == Outdated reference: A later version (-05) exists of draft-pauly-quic-datagram-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-33 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) Summary: 0 errors (**), 0 flaws (~~), 7 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 17 April 2020 5 Expires: 19 October 2020 7 The WebTransport Protocol Framework 8 draft-ietf-webtrans-overview-00 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 19 October 2020. 50 Copyright Notice 52 Copyright (c) 2020 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 [I-D.ietf-rtcweb-data-channel], which provide a WebSocket- 111 like API for a peer-to-peer SCTP channel protected by DTLS. In 112 theory, it is possible to use it for the use cases addressed by this 113 specification. However, in practice, its use in non-browser-to- 114 browser settings has been quite low due to its dependency on ICE 115 (which fits poorly with the Web model) and userspace SCTP (which has 116 very few implementations 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.pauly-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 Transport session: A transport session is a single communication 165 context established between a client and a server. It may 166 correspond to a specific transport-layer connection, or it may be 167 a logical entity within an existing multiplexed transport-layer 168 connection. Transport sessions are logically independent from one 169 another even if some sessions can share an underlying transport- 170 layer connection. 172 Transport protocol: A transport protocol (WebTransport protocol in 173 contexts where this might be ambiguous) is an instantiation of 174 WebTransport over a given transport-layer protocol. 176 Datagram: A datagram is a unit of transmission that is treated 177 atomically. 179 Stream: A stream is a sequence of bytes that is reliably delivered 180 to the receiving application in the same order as it was 181 transmitted by the sender. Streams can be of arbitrary length, 182 and therefore cannot always be buffered entirely in memory. It is 183 expected for transport protocols and APIs to provide partial 184 stream data to the application before the stream has been entirely 185 received. 187 Message: A message is a stream that is sufficiently small that it 188 can be fully buffered before being passed to the application. 189 WebTransport does not define messages as a primitive, since from 190 the transport perspective they can be simulated by fully buffering 191 a stream before passing it to the application. However, this 192 distinction is important to highlight since some of the similar 193 protocols and APIs (notably WebSocket [RFC6455]) use messages as a 194 core abstraction. 196 Transport property: A transport property is a specific behavior that 197 may or may not be exhibited by a transport. Some of those are 198 inherent for all instances of a given transport protocol (TCP- 199 based transport cannot support unreliable delivery), while others 200 can vary even within the same protocol (QUIC connections may or 201 may not support connection migration). 203 Server: A WebTransport server is an application that accepts 204 incoming transport sessions. 206 Client: A WebTransport client is an application that initiates the 207 transport session and may be running in a constrained security 208 context, for instance, a JavaScript application running inside a 209 browser. 211 User agent: A WebTransport user agent is a software system that has 212 an unrestricted access to the host network stack and can create 213 transports on behalf of the client. 215 2. Common Transport Requirements 217 Since clients are not necessarily trusted and have to be constrained 218 by the Web security model, WebTransport imposes certain requirements 219 on any specific transport protocol used. 221 Any transport protocol used MUST use TLS [RFC8446] or a semantically 222 equivalent security protocol (for instance, DTLS 223 [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or 224 later, unless they aim for backwards compatibility with legacy 225 systems. 227 Any transport protocol used MUST require the user agent to obtain and 228 maintain explicit consent from the server to send data. For 229 connection-oriented protocols (such as TCP or QUIC), the connection 230 establishment and keep-alive mechanisms suffice. STUN Consent 231 Freshness [RFC7675] is another example of the mechanism satisfying 232 this requirement. 234 Any transport protocol used MUST limit the rate at which the client 235 sends data. This SHOULD be accomplished via a feedback-based 236 congestion control mechanism (such as [RFC5681] or 237 [I-D.ietf-quic-recovery]). 239 Any transport protocol used MUST support simultaneously establishing 240 multiple sessions between the same client and server. 242 Any transport protocol used MUST prevent the clients from 243 establishing transport sessions to network endpoints that are not 244 WebTransport servers. 246 Any transport protocol used MUST provide a way for servers to filter 247 clients that can access it by checking the initiating origin 248 [RFC6454]. 250 Any transport protocol used MUST provide a way for a server endpoint 251 location to be described using a URI [RFC3986]. This enables 252 integration with various Web platform features that represent 253 resources as URIs, such as Content Security Policy [CSP]. 255 3. Session Establishment 257 WebTransport session establishment is most often asynchronous, 258 although in some transports it can succeed instantaneously (for 259 instance, if a transport is immediately pooled with an existing 260 connection). A session MUST NOT be considered established until it 261 is secure against replay attacks. For instance, in protocols 262 creating a new TLS 1.3 session [RFC8446], this would mean that the 263 user agent MUST NOT treat the session as established until it 264 received a Finished message from the server. 266 In some cases, the transport protocol might allow transmitting data 267 before the session is established; an example is TLS 0-RTT data. 268 Since this data can be replayed by attackers, it MUST NOT be used 269 unless the client has explicitly requested 0-RTT for specific streams 270 or datagrams it knows to be safely replayable. 272 4. Transport Features 274 The following transport features are defined in this document. This 275 list is not meant to be comprehensive; future documents may define 276 new features for both new and already existing transports. 278 All transport protocols MUST provide datagrams, unidirectional and 279 bidirectional streams in order to make the transport protocols easily 280 interchangeable. 282 4.1. Datagrams 284 A datagram is a sequence of bytes that is limited in size (generally 285 to the path MTU) and is not expected to be transmitted reliably. The 286 general goal for WebTransport datagrams is to be similar in behavior 287 to UDP while being subject to common requirements expressed in 288 Section 2. 290 The WebTransport sender is not expected to retransmit datagrams, 291 though it may if it is using a TCP-based protocol or some other 292 underlying protocol that requires reliable delivery. WebTransport 293 datagrams are not expected to be flow controlled, meaning that the 294 receiver might drop datagrams if the application is not consuming 295 them fast enough. 297 The application MUST be provided with the maxiumum datagram size that 298 it can send. The size SHOULD be derived from the result of 299 performing path MTU discovery. 301 4.2. Streams 303 A unidirectional stream is a one-way reliable in-order stream of 304 bytes where the initiator is the only endpoint that can send data. A 305 bidirectional stream allows both endpoints to send data and can be 306 conceptually represented as a pair of unidirectional streams. 308 The streams are in general expected to follow the semantics and the 309 state machine of QUIC streams ([I-D.ietf-quic-transport], Sections 2 310 and 3). TODO: describe the stream state machine explicitly. 312 A WebTransport stream can be reset, indicating that the endpoint is 313 not interested in either sending or receiving any data related to the 314 stream. In that case, the sender is expected to not retransmit any 315 data that was already sent on that stream. 317 Streams SHOULD be sufficiently lightweight that they can be used as 318 messages. 320 Data sent on a stream is flow controlled by the transport protocol. 321 In addition to flow controlling stream data, the creation of new 322 streams is flow controlled as well: an endpoint may only open a 323 limited number of streams until the peer explicitly allows creating 324 more streams. 326 Every stream within a transport has a unique 64-bit number 327 identifying it. Both unidirectional and bidirectional streams share 328 the number space. The client and the server have to agree on the 329 numbering, so it can be referenced in the application payload. 331 WebTransport does not impose any other specific restrictions on the 332 structure of stream IDs, and they should be treated as opaque 64-bit 333 blobs. 335 4.3. Protocol-Specific Features 337 In addition to features described above, there are some capabilities 338 that may be provided by an individual protocol but are not 339 universally applicable to all protocols. Those are allowed, but any 340 protocol is expected to be useful without those features, and 341 portable clients should not rely on them. 343 A notable class of protocol-specific features are features available 344 only in non-pooled transports. Since those transports have a 345 dedicated connection, a user agent can provide clients with an 346 extensive amount of transport-level data that would be too noisy and 347 difficult to interpret when the connection is shared with unrelated 348 traffic. For instance, a user agent can provide the number of 349 packets lost, or the number of times stream data was delayed due to 350 flow control. It can also expose variables related to congestion 351 control, such as the size of the congestion window or the current 352 pacing rate. 354 4.4. Bandwidth Prediction 356 Using congestion control state and transport metrics, the client can 357 predict the rate at which it can send data. That is essential for 358 many WebTransport use cases; for instance, real time media 359 applications adapt the video bitrate to be a fraction of the 360 throughput they expect to be available. While not all transport 361 protocols can provide low-level transport details, all protocols 362 SHOULD provide the client with an estimate of the available 363 bandwidth. 365 5. Buffering and Prioritization 367 TODO: expand this outline into a full summary. 369 * Datagrams are intended for low-latency communications, so the 370 buffers for them should be small, and prioritized over stream 371 data. 373 * In general, the transport should not apply aggregation algorithms 374 (e.g., Nagle's algorithm [RFC0896]) to datagrams. 376 6. Transport Properties 378 In addition to common requirements, each transport can have multiple 379 optional properties associated with it. Querying them allows the 380 client to ascertain the presence of features it can use without 381 requiring knowledge of all protocols. This allows introducing new 382 transports as drop-in replacements for existing ones. 384 The following properties are defined in this specification: 386 * Stream independence. This indicates that there is no head of line 387 blocking between different streams. 389 * Partial reliability. This indicates that if a stream is reset, 390 none of the data sent on it will be retransmitted. This also 391 indicates that datagrams will not be retransmitted. 393 * Pooling support. Indicates that multiple transports using this 394 transport protocol may end up sharing the same transport layer 395 connection, and thus share a congestion controller and other 396 contexts. 398 * Connection mobility. Indicates that the transport may continue 399 existing even if the network path between the client and the 400 server changes. 402 7. Security Considerations 404 Providing untrusted clients with a reasonably low-level access to the 405 network comes with risks. This document mitigates those risks by 406 imposing a set of common requirements described in Section 2. 408 WebTransport mandates the use of TLS for all protocols implementing 409 it. This has a dual purpose. On one hand, it protects the transport 410 from the network, including both potential attackers and ossification 411 by middleboxes. On the other hand, it protects the network elements 412 from potential confusion attacks such as the one discussed in 413 Section 10.3 of [RFC6455]. 415 One potential concern is that even when a transport cannot be 416 created, the connection error would reveal enough information to 417 allow an attacker to scan the network addresses that would normally 418 be inaccessible. Because of that, the user agent that runs untrusted 419 clients MUST NOT provide any detailed error information until the 420 server has confirmed that it is a WebTransport endpoint. For 421 example, the client must not be able to distinguish between a network 422 address that is unreachable and one that is reachable but is not a 423 WebTransport server. 425 WebTransport does not support any traditional means of HTTP-based 426 authentication. It is not necessarily based on HTTP, and hence does 427 not support HTTP cookies or HTTP authentication. Since it requires 428 TLS, individual transport protocols MAY expose TLS-based 429 authentication capabilities such as client certificates. 431 8. IANA Considerations 433 There are no requests to IANA in this document. 435 9. References 437 9.1. Normative References 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 445 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 446 May 2017, . 448 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 449 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 450 . 452 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 453 DOI 10.17487/RFC6454, December 2011, 454 . 456 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 457 Resource Identifier (URI): Generic Syntax", STD 66, 458 RFC 3986, DOI 10.17487/RFC3986, January 2005, 459 . 461 9.2. Informative References 463 [CSP] W3C, "Content Security Policy Level 3", April 2020, 464 . 466 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 467 RFC 6455, DOI 10.17487/RFC6455, December 2011, 468 . 470 [I-D.ietf-rtcweb-data-channel] 471 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 472 Channels", Work in Progress, Internet-Draft, draft-ietf- 473 rtcweb-data-channel-13, 4 January 2015, 474 . 477 [I-D.ietf-quic-http] 478 Bishop, M., "Hypertext Transfer Protocol Version 3 479 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 480 quic-http-23, 12 September 2019, . 483 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 484 RFC 8441, DOI 10.17487/RFC8441, September 2018, 485 . 487 [I-D.pauly-quic-datagram] 488 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 489 Datagram Extension to QUIC", Work in Progress, Internet- 490 Draft, draft-pauly-quic-datagram-04, 22 October 2019, 491 . 494 [I-D.ietf-tls-dtls13] 495 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 496 Datagram Transport Layer Security (DTLS) Protocol Version 497 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 498 dtls13-33, 11 October 2019, . 501 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 502 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 503 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 504 October 2015, . 506 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 507 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 508 . 510 [I-D.ietf-quic-recovery] 511 Iyengar, J. and I. Swett, "QUIC Loss Detection and 512 Congestion Control", Work in Progress, Internet-Draft, 513 draft-ietf-quic-recovery-23, 11 September 2019, 514 . 517 [I-D.ietf-quic-transport] 518 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 519 and Secure Transport", Work in Progress, Internet-Draft, 520 draft-ietf-quic-transport-23, 11 September 2019, 521 . 524 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 525 RFC 896, DOI 10.17487/RFC0896, January 1984, 526 . 528 Author's Address 530 Victor Vasiliev 531 Google 533 Email: vasilvv@google.com