idnits 2.17.1 draft-vvv-webtransport-overview-01.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 (November 2, 2019) is 1636 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 (-34) exists of draft-ietf-quic-recovery-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-33 == Outdated reference: A later version (-05) exists of draft-pauly-quic-datagram-04 -- 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 Network Working Group V. Vasiliev 3 Internet-Draft Google 4 Intended status: Standards Track November 2, 2019 5 Expires: May 5, 2020 7 The WebTransport Protocol Framework 8 draft-vvv-webtransport-overview-01 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 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 5, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4 59 2. Common Transport Requirements . . . . . . . . . . . . . . . . 5 60 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 6 61 4. Transport Features . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Protocol-Specific Features . . . . . . . . . . . . . . . 7 65 4.4. Bandwidth Prediction . . . . . . . . . . . . . . . . . . 8 66 5. Buffering and Prioritization . . . . . . . . . . . . . . . . 8 67 6. Transport Properties . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 The WebTransport Protocol Framework enables clients constrained by 78 the Web security model to communicate with a remote server using a 79 secure multiplexed transport. It consists of a set of individual 80 protocols that are safe to expose to untrusted applications, combined 81 with a model that allows them to be used interchangeably. 83 This document defines the overall requirements on the protocols used 84 in WebTransport, as well as the common features of the protocols, 85 support for some of which may be optional. 87 1.1. Background 89 Historically, web applications that needed a bidirectional data 90 stream between a client and a server could rely on WebSockets 91 [RFC6455], a message-based protocol compatible with the Web security 92 model. However, since the abstraction it provides is a single 93 ordered stream of messages, it suffers from head-of-line blocking 94 (HOLB), meaning that all messages must be sent and received in order 95 even if they are independent and some of them are no longer needed. 97 This makes it a poor fit for latency-sensitive applications which 98 rely on partial reliability and stream independence for performance. 100 One existing option available to Web developers are WebRTC data 101 channels [I-D.ietf-rtcweb-data-channel], which provide a WebSocket- 102 like API for a peer-to-peer SCTP channel protected by DTLS. In 103 theory, it is possible to use it for the use cases addressed by this 104 specification. However, in practice, its user in non-browser-to- 105 browser settings has been quite low due to its dependency on ICE 106 (which fits poorly with the Web model) and userspace SCTP (which has 107 very few implementations available). 109 An alternative design would be to layer WebSockets over HTTP/3 110 [I-D.ietf-quic-http] in a manner similar to how they are currently 111 layered over HTTP/2 [RFC8441]. That would avoid head-of-line 112 blocking and provide an ability to cancel a stream by closing the 113 corresponding WebSocket object. However, this approach has a number 114 of drawbacks, which all stem primarily from the fact that 115 semantically each WebSocket is a completely independent entity: 117 o Each new stream would require a WebSocket handshake to agree on 118 application protocol used, meaning that it would take at least one 119 RTT to establish each new stream before the client can write to 120 it. 122 o Only clients can initiate streams. Server-initiated streams and 123 other alternative modes of communication (such as the QUIC 124 DATAGRAM frame [I-D.pauly-quic-datagram]) are not available. 126 o While the streams would normally be pooled by the user agent, this 127 is not guaranteed, and the general process of mapping a WebSocket 128 to a server is opaque to the client. This introduces 129 unpredictable performance properties into the system, and prevents 130 optimizations which rely on the streams being on the same 131 connection (for instance, it might be possible for the client to 132 request different retransmission priorities for different streams, 133 but that would be much more complex unless they are all on the 134 same connection). 136 The WebTransport protocol framework avoids all of those issues by 137 letting applications create a single transport object that can 138 contain multiple streams multiplexed together in a single context 139 (similar to SCTP, HTTP/2, QUIC and others), and can be also used to 140 send unreliable datagrams (similar to UDP). 142 1.2. Conventions and Definitions 144 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 WebTransport is a framework that aims to abstract away the underlying 151 transport protocol while still exposing a few key transport-layer 152 aspects to application developers. It is structured around the 153 following concepts: 155 Transport session: A transport session is a single communication 156 context established between a client and a server. It may 157 correspond to a specific transport-layer connection, or it may be 158 a logical entity within an existing multiplexed transport-layer 159 connection. Transport sessions are logically independent from one 160 another even if some sessions can share an underlying transport- 161 layer connection. 163 Transport protocol: A transport protocol (WebTransport protocol in 164 contexts where this might be ambiguous) is an instantiation of 165 WebTransport over a given transport-layer protocol. 167 Datagram: A datagram is a unit of transmission that is treated 168 atomically. 170 Stream: A stream is a sequence of bytes that is reliably delivered 171 to the receiving application in the same order as it was 172 transmitted by the sender. Streams can be of arbitrary length, 173 and therefore cannot always be buffered entirely in memory. It is 174 expected for transport protocols and APIs to provide partial 175 stream data to the application before the stream has been entirely 176 received. 178 Message: A message is a stream that is sufficiently small that it 179 can be fully buffered before being passed to the application. 180 WebTransport does not define messages as a primitive, since from 181 the transport perspective they can be simulated by fully buffering 182 a stream before passing it to the application. However, this 183 distinction is important to highlight since some of the similar 184 protocols and APIs (notably WebSocket [RFC6455]) use messages as a 185 core abstraction. 187 Transport property: A transport property is a specific behavior that 188 may or may not be exhibited by a transport. Some of those are 189 inherent for all instances of a given transport protocol (TCP- 190 based transport cannot support unreliable delivery), while others 191 can vary even within the same protocol (QUIC connections may or 192 may not support connection migration). 194 Server: A WebTransport server is an application that accepts 195 incoming transport sessions. 197 Client: A WebTransport client is an application that initiates the 198 transport session and may be running in a constrained security 199 context, for instance, a JavaScript application running inside a 200 browser. 202 User agent: A WebTransport user agent is a software system that has 203 an unrestricted access to the host network stack and can create 204 transports on behalf of the client. 206 2. Common Transport Requirements 208 Since clients are not necessarily trusted and have to be constrained 209 by the Web security model, WebTransport imposes certain requirements 210 on any specific transport protocol used. 212 Any transport protocol used MUST use TLS [RFC8446] or a semantically 213 equivalent security protocol (for instance, DTLS 214 [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or 215 later, unless they aim for backwards compatibility with legacy 216 systems. 218 Any transport protocol used MUST require the user agent to obtain and 219 maintain explicit consent from the server to send data. For 220 connection-oriented protocols (such as TCP or QUIC), the connection 221 establishment and keep-alive mechanisms suffice. For other 222 protocols, a mechanism such as ICE [RFC8445] can be used. 224 Any transport protocol used 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 227 [I-D.ietf-quic-recovery]). 229 Any transport protocol used MUST support simultaneously establishing 230 multiple sessions between the same client and server. 232 Any transport protocol used MUST prevent the clients from 233 establishing transport sessions to network endpoints that are not 234 WebTransport servers. 236 Any transport protocol used MUST provide a way for servers to filter 237 clients that can access it by checking the initiating origin 238 [RFC6454]. 240 Any transport protocol used MUST provide a way for a server endpoint 241 location to be described using a URI [RFC3986]. This enables 242 integration with various Web platform features that represent 243 resources as URIs, such as Content Security Policy [CSP]. 245 3. Session Establishment 247 WebTransport session establishment is most often asynchronous, 248 although in some transports it can succeed instantaneously (for 249 instance, if a transport is immediately pooled with an existing 250 connection). A session MUST NOT be considered established until it 251 is secure against replay attacks. For instance, in protocols 252 creating a new TLS 1.3 session [RFC8446], this would mean that the 253 user agent MUST NOT treat the session as established until it 254 received a Finished message from the server. 256 In some cases, the transport protocol might allow transmitting data 257 before the session is established; an example is TLS 0-RTT data. 258 Since this data can be replayed by attackers, it MUST NOT be used 259 unless the client has explicitly requested 0-RTT for specific streams 260 or datagrams it knows to be safely replayable. 262 4. Transport Features 264 The following transport features are defined in this document. This 265 list is not meant to be comprehensive; future documents may define 266 new features for both new and already existing transports. 268 All transport protocols MUST provide datagrams, unidirectional and 269 bidirectional streams in order to make the transport protocols easily 270 interchangeable. 272 4.1. Datagrams 274 A datagram is a sequence of bytes that is limited in size (generally 275 to the path MTU) and is not expected to be transmitted reliably. The 276 general goal for WebTransport datagrams is to be similar in behavior 277 to UDP while being subject to common requirements expressed in 278 Section 2. 280 The WebTransport sender is not expected to retransmit datagrams, 281 though it may if it is using a TCP-based protocol or some other 282 underlying protocol that requires reliable delivery. WebTransport 283 datagrams are not expected to be flow controlled, meaning that the 284 receiver might drop datagrams if the application is not consuming 285 them fast enough. 287 The application MUST be provided with the maxiumum datagram size that 288 it can send. The size SHOULD be derived from the result of 289 performing path MTU discovery. 291 4.2. Streams 293 A unidirectional stream is a one-way reliable in-order stream of 294 bytes where the initiator is the only endpoint that can send data. A 295 bidirectional stream allows both endpoints to send data and can be 296 conceptually represented as a pair of unidirectional streams. 298 The streams are in general expected to follow the semantics and the 299 state machine of QUIC streams ([I-D.ietf-quic-transport], Sections 2 300 and 3). TODO: describe the stream state machine explicitly. 302 A WebTransport stream can be reset, indicating that the endpoint is 303 not interested in either sending or receiving any data related to the 304 stream. In that case, the sender is expected to not retransmit any 305 data that was already sent on that stream. 307 Streams SHOULD be sufficiently lightweight that they can be used as 308 messages. 310 Data sent on a stream is flow controlled by the transport protocol. 311 In addition to flow controlling stream data, the creation of new 312 streams is flow controlled as well: an endpoint may only open a 313 limited number of streams until the peer explicitly allows creating 314 more streams. 316 Every stream within a transport has a unique 64-bit number 317 identifying it. Both unidirectional and bidirectional streams share 318 the number space. The client and the server have to agree on the 319 numbering, so it can be referenced in the application payload. 320 WebTransport does not impose any other specific restrictions on the 321 structure of stream IDs, and they should be treated as opaque 64-bit 322 blobs. 324 4.3. Protocol-Specific Features 326 In addition to features described above, there are some capabilities 327 that may be provided by an individual protocol but are not 328 universally applicable to all protocols. Those are allowed, but any 329 protocol is expected to be useful without those features, and 330 portable clients should not rely on them. 332 A notable class of protocol-specific features are features available 333 only in non-pooled transports. Since those transports have a 334 dedicated connection, a user agent can provide clients with an 335 extensive amount of transport-level data that would be too noisy and 336 difficult to interpret when the connection is shared with unrelated 337 traffic. For instance, a user agent can provide the number of 338 packets lost, or the number of times stream data was delayed due to 339 flow control. It can also expose variables related to congestion 340 control, such as the size of the congestion window or the current 341 pacing rate. 343 4.4. Bandwidth Prediction 345 Using congestion control state and transport metrics, the client can 346 predict the rate at which it can send data. That is essential for 347 many WebTransport use cases; for instance, real time media 348 applications adapt the video bitrate to be a fraction of the 349 throughput they expect to be available. While not all transport 350 protocols can provide low-level transport details, all protocols 351 SHOULD provide the client with an estimate of the available 352 bandwidth. 354 5. Buffering and Prioritization 356 TODO: expand this outline into a full summary. 358 o Datagrams are intended for low-latency communications, so the 359 buffers for them should be small, and prioritized over stream 360 data. 362 o In general, the transport should not apply aggregation algorithms 363 (e.g., Nagle's algorithm [RFC0896]) to datagrams. 365 6. Transport Properties 367 In addition to common requirements, each transport can have multiple 368 optional properties associated with it. Querying them allows the 369 client to ascertain the presence of features it can use without 370 requiring knowledge of all protocols. This allows introducing new 371 transports as drop-in replacements for existing ones. 373 The following properties are defined in this specification: 375 o Stream independence. This indicates that there is no head of line 376 blocking between different streams. 378 o Partial reliability. This indicates that if a stream is reset, 379 none of the data sent on it will be retransmitted. This also 380 indicates that datagrams will not be retransmitted. 382 o Pooling support. Indicates that multiple transports using this 383 transport protocol may end up sharing the same transport layer 384 connection, and thus share a congestion controller and other 385 contexts. 387 o Connection mobility. Indicates that the transport may continue 388 existing even if the network path between the client and the 389 server changes. 391 7. Security Considerations 393 Providing untrusted clients with a reasonably low-level access to the 394 network comes with risks. This document mitigates those risks by 395 imposing a set of common requirements described in Section 2. 397 WebTransport mandates the use of TLS for all protocols implementing 398 it. This has a dual purpose. On one hand, it protects the transport 399 from the network, including both potential attackers and ossification 400 by middleboxes. On the other hand, it protects the network elements 401 from potential confusion attacks such as the one discussed in 402 Section 10.3 of [RFC6455]. 404 One potential concern is that even when a transport cannot be 405 created, the connection error would reveal enough information to 406 allow an attacker to scan the network addresses that would normally 407 be inaccessible. Because of that, the user agent that runs untrusted 408 clients MUST NOT provide any detailed error information until the 409 server has confirmed that it is a WebTransport endpoint. For 410 example, the client must not be able to distinguish between a network 411 address that is unreachable and one that is reachable but is not a 412 WebTransport server. 414 WebTransport does not support any traditional means of HTTP-based 415 authentication. It is not necessarily based on HTTP, and hence does 416 not support HTTP cookies or HTTP authentication. Since it requires 417 TLS, individual transport protocols MAY expose TLS-based 418 authentication capabilities such as client certificates. 420 8. IANA Considerations 422 There are no requests to IANA in this document. 424 9. References 426 9.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 434 Resource Identifier (URI): Generic Syntax", STD 66, 435 RFC 3986, DOI 10.17487/RFC3986, January 2005, 436 . 438 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 439 DOI 10.17487/RFC6454, December 2011, 440 . 442 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 443 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 444 May 2017, . 446 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 447 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 448 . 450 9.2. Informative References 452 [CSP] W3C, "Content Security Policy Level 3", November 2019, 453 . 455 [I-D.ietf-quic-http] 456 Bishop, M., "Hypertext Transfer Protocol Version 3 457 (HTTP/3)", draft-ietf-quic-http-23 (work in progress), 458 September 2019. 460 [I-D.ietf-quic-recovery] 461 Iyengar, J. and I. Swett, "QUIC Loss Detection and 462 Congestion Control", draft-ietf-quic-recovery-23 (work in 463 progress), September 2019. 465 [I-D.ietf-quic-transport] 466 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 467 and Secure Transport", draft-ietf-quic-transport-23 (work 468 in progress), September 2019. 470 [I-D.ietf-rtcweb-data-channel] 471 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 472 Channels", draft-ietf-rtcweb-data-channel-13 (work in 473 progress), January 2015. 475 [I-D.ietf-tls-dtls13] 476 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 477 Datagram Transport Layer Security (DTLS) Protocol Version 478 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 479 2019. 481 [I-D.pauly-quic-datagram] 482 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 483 Datagram Extension to QUIC", draft-pauly-quic-datagram-04 484 (work in progress), October 2019. 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 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 499 RFC 8441, DOI 10.17487/RFC8441, September 2018, 500 . 502 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 503 Connectivity Establishment (ICE): A Protocol for Network 504 Address Translator (NAT) Traversal", RFC 8445, 505 DOI 10.17487/RFC8445, July 2018, 506 . 508 Author's Address 510 Victor Vasiliev 511 Google 513 Email: vasilvv@google.com