idnits 2.17.1 draft-vvv-webtransport-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 (May 3, 2019) is 1813 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-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) Summary: 0 errors (**), 0 flaws (~~), 6 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 May 3, 2019 5 Expires: November 4, 2019 7 The WebTransport Protocol Framework 8 draft-vvv-webtransport-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 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 November 4, 2019. 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Common Transport Requirements . . . . . . . . . . . . . . . . 5 60 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 5 61 4. Transport Features . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. Protocol-Specific Features . . . . . . . . . . . . . . . 7 65 4.4. Bandwidth Prediction . . . . . . . . . . . . . . . . . . 7 66 5. Buffering and Prioritization . . . . . . . . . . . . . . . . 8 67 6. Transport Properties . . . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 1.1. Background 79 Historically, web applications that needed bidirectional data stream 80 between a client and a server could rely on WebSockets [RFC6455], a 81 message-based protocol compatible with Web security model. However, 82 since the abstraction it provides is a single ordered stream of 83 messages, it suffers from head-of-line blocking (HOLB), meaning that 84 all messages must be sent and received in order even if they are 85 independent and some of them are no longer needed. This makes it a 86 poor fit for latency sensitive applications which rely on partial 87 reliability and stream independence for performance. 89 One existing option available to the Web developers are WebRTC data 90 channels [I-D.ietf-rtcweb-data-channel], which provide a WebSocket- 91 like API for a peer-to-peer SCTP channel protected by DTLS. In 92 general, it is possible to use it for the use cases addressed by this 93 specification; however, in practice, its adoption in a non-browser- 94 to-browser by the web developers has been quite low due to dependency 95 on ICE (which fits poorly with the Web model) and userspace SCTP 96 (which has very few implementations available). 98 Another option potentially available is layering WebSockets over 99 HTTP/3 [I-D.ietf-quic-http] in a manner similar to how they are 100 currently layered over HTTP/2 [RFC8441]. That would avoid head-of- 101 line blocking and provide an ability to cancel a stream by closing 102 the corresponding WebSocket object. However, this approach has a 103 number of drawbacks, which all stem primarily from the fact that 104 semantically each WebSocket is a completely independent entity: 106 o Each new stream would require a WebSocket handshake to agree on 107 application protocol used, meaning that it would take at least one 108 RTT for each new stream before the client can write to it. 110 o Only clients can initiate streams. Server-initiated streams and 111 other alternative modes of communication (such as QUIC DATAGRAM 112 frame) are not available. 114 o While the streams would normally be pooled by the user agent, this 115 is not guaranteed, and the general process of mapping a WebSocket 116 to the end is opaque to the client. This introduces unpredictable 117 performance properties into the system, and prevents optimizations 118 which rely on the streams being on the same connection (for 119 instance, it might be possible for the client to request different 120 retransmission priorities for different streams, but that would be 121 impossible unless they are all on the same connection). 123 The WebTransport protocol framework avoids all of those issues by 124 letting applications create a single transport object that can 125 contain multiple streams multiplexed together in a single context 126 (similar to SCTP, HTTP/2, QUIC and others), and can be also used to 127 send unreliable datagrams (similar to UDP). 129 1.2. Definitions 131 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 WebTransport is a framework that aims to abstract away the underlying 138 transport protocol while still exposing the specific transport-layer 139 aspects of it to the application developers. It is structured around 140 the following concepts: 142 Transport: A transport is a session established between a client and 143 a server. It may correspond to a specific physical connection on 144 the transport layer, or it may be a logical entity within an 145 existing multiplexed connection. Each instance of a transport is 146 logically independent of each other even if some transports can 147 share same connection underneath. 149 Transport protocol: A transport protocol (WebTransprot protocol in 150 context where this might be ambiguos) is a protocol that can be 151 used to back a transport on the wire. It can provide the 152 transport features described in this document, and is expected to 153 fulfill all of the requirements described herein. 155 Datagram: A datagram is a unit of transmission that is generally 156 treated as a single PDU by underlying network layer protocols, 157 and, absent fragmentation, is expected to be treated atomically by 158 the queues in the network. 160 Stream: A stream is a sequence of bytes that is delivered to the 161 receiving application in the same order as it is transmitted by 162 the sender. Streams are assumed to be sufficiently long that they 163 cannot be buffered entirely into memory, thus requiring the 164 transport protocol and the API to provide stream data before the 165 stream is finished. 167 Message: A message is a stream that is sufficiently small that it 168 can be fully buffered before being passed to the application. 169 WebTransport does not define messages as a primitive, since from 170 the transport perspective they can be simulated by fully buffering 171 a stream before passing it to the application. However, this 172 distinction is important to highlight since some of the similar 173 protocols and APIs (notably WebSocket [RFC6455]) use messages as a 174 core abstraction. 176 Transport feature: A transport feature refers to the ability of a 177 specific transport to provide a specific way of communicating 178 data, such as supporting datagrams or streams. 180 Transport property: A transport property is a specific behavior that 181 may or may not be exhibited by a transport. Some of those are 182 inherent for all instances of a given transport protocol (TCP- 183 based transport cannot support unreliable delivery), while others 184 can vary even within the same protocol (QUIC connections may or 185 may not support connection migration). 187 Server: A WebTransport server is an application that accepts 188 incoming transport sessions. 190 Client: A WebTransport client is an application that initiates the 191 transport session and may be running in a constrained security 192 context, for instance, a JavaScript application running inside the 193 browser. 195 User agent: A WebTransport user agent is a software system that has 196 an unrestricted access to the host network stack and can create 197 transports on behalf of the client, for instance, the web browser. 199 2. Common Transport Requirements 201 Since the clients are potentially untrusted and have to be 202 constrained by the Web security model, WebTransport imposes certain 203 requirements on any specific transport protocol used. 205 Any transport protocol used MUST use TLS [RFC8446] or a semantically 206 equivalent security protocol (for instance, DTLS 207 [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or 208 later, unless they aim for backwards compatibility with legacy 209 systems. 211 Any transport protocol used MUST require the user agent to obtain and 212 maintain an explicit consent from the server to send data. For 213 connection-oriented protocols (such as TCP or QUIC), the connection 214 establishment and keep-alive mechanisms suffice. For other 215 protocols, a mechanism such as ICE [RFC8445] may be used. 217 Any transport protocol used MUST limit the rate at which the client 218 sends data. This SHOULD be accomplished via a feedback-based 219 congestion control mechanism (such as [RFC5681] or 220 [I-D.ietf-quic-recovery]). 222 Any transport protocol used MUST support simultaneously establishing 223 multiple sessions between the same client and server. 225 Any transport protocol used MUST prevent the clients from 226 establishing transport sessions to the network endpoints that are not 227 WebTransport servers. 229 Any transport protocol used MUST provide a way for the server to 230 filter the clients that can access it by the origin [RFC6454]. 232 3. Session Establishment 234 WebTransport session establishment is in general asynchronous, 235 although in some transports it can succeed instantaneously (for 236 instance, if a transport is immediately pooled with an existing 237 connection). A session MUST NOT be considered established until it 238 is secure against replay attacks. For instance, in protocols 239 creating a new TLS 1.3 session [RFC8446] this would mean that the 240 user agent MUST NOT treat the session as established until it 241 received a Finished message from the server. 243 The client MUST NOT open streams or send datagrams until the session 244 is established. In some situations, it might be possible for the 245 client to be able to start sending data earlier, notably using TLS 246 0-RTT. In those situations, the user agent MAY provide client with 247 ability to send a limited amount of data (using either streams or 248 datagrams). The client MUST explicitly request for 0-RTT to be used. 250 4. Transport Features 252 The following transport features are defined in this document. This 253 list is not meant to be comprehensive; future documents may define 254 new features for both new and already existing transports. 256 All transport protocols SHOULD provide datagrams, unidirectional and 257 bidirectional streams in order to make the transport protocols easily 258 interchangeable. 260 4.1. Datagrams 262 A datagram is a sequence of bytes that is limited in size (generally 263 to the path MTU) and is not expected to be reliable. The general 264 goal for WebTransport datagrams is to be similar in behavior to UDP 265 while being subject to common requirements expressed in Section 2. 267 The WebTransport sender is not expected to retransmit datagrams, 268 though it may if it is using a TCP-based protocol or some other 269 underlying protocol that requires reliable delivery. WebTransport 270 datagrams are not expected to be flow controlled, meaning that the 271 receiver might drop datagrams if the application is not consuming 272 them fast enough. 274 The application MUST be provided with the maxiumum 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 ([I-D.ietf-quic-transport], Sections 2 287 and 3). TODO: 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 As streams are reliable, the data sent on a stream has to be flow 298 controlled by the transport protocol. In addition to the flow 299 control for the stream data, the creation of new streams has to be 300 flow controlled as well: an endpoint may only open a limited number 301 of streams until the peer explicitly allows creating more streams. 303 Every stream within a transport has a unique 64-bit number 304 identifying it. Both unidirectional and bidirectional streams share 305 the number space. The client and the server have to agree on the 306 numbering, so it can be referenced in the application payload. 307 WebTransport does not impose any other specific restrictions on the 308 structure of stream IDs, and they should be treated as opaque 64-bit 309 blobs. 311 4.3. Protocol-Specific Features 313 In addition to features described above, there are some capabilities 314 that may be provided by an individual protocol but are not 315 universally applicable to all protocols. Those are allowed, but any 316 protocol is expected to be useful without those features, and 317 portable clients should not rely on them. 319 A notable class of protocol-specific features are features available 320 only in non-pooled transports. Since those transports have a 321 dedicated connection, a user agent can provide clients with an 322 extensive amount of transport-level data that would be too noisy and 323 difficult to interpret when the connection is shared with unrelated 324 traffic. For instance, a user agent can provide the number of 325 packets lost, or the number of times stream data was delayed due to 326 flow control. It can also expose variables related to congestion 327 control, such as the size of the congestion window or the current 328 pacing rate. 330 4.4. Bandwidth Prediction 332 Using congestion control state and transport metrics, the client can 333 predict the rate at which it can send data. That is essential for a 334 lot of WebTransport use cases; for instance, real time media 335 applications adapt the video bitrate to be a fraction of throughput 336 they expect to be available. While not all transport protocols can 337 provide low-level transport details, any protocol SHOULD provide a 338 way to estimate the bandwidth available to the client. 340 5. Buffering and Prioritization 342 TODO: expand this outline into a full summary. 344 o Datagrams are intended for low-latency communications, so the 345 buffers for them should be small, and prioritized over stream 346 data. 348 o In general, the transport should not use any aggregation 349 algorithms, e.g. Nagle's algorithm [RFC0896]. 351 6. Transport Properties 353 In addition to common requirements, each transport can have multiple 354 optional properties associated with it. Querying them allows the 355 client to ascertain the nature of transport without being aware of a 356 specific implementation, thus simplifying introducing new transports 357 as a drop-in replacement. 359 The following properties are defined in this specification: 361 o Stream independence. Indicates that there is no head of line 362 blocking between different streams. 364 o Partial reliability. Indicates that if stream is reset, none of 365 the data sent on it will be retransmitted. Indicates that 366 datagrams will not be retransmitted. 368 o Pooling support. Indicates that multiple transports using this 369 transport protocol may end up sharing the same transport layer 370 connection, and thus share the congestion control and other 371 context. 373 o Connection mobility. Indicates that the transport may continue 374 existing even if the network path between the client and the 375 server changes. 377 7. Security Considerations 379 Providing untrusted clients with a reasonably low-level access to the 380 network comes with a lot of risks. This document mitigates those 381 risks by imposing a set of common requirements described in 382 Section 2. 384 WebTransport mandates the use of TLS for all protocols implementing 385 it. This has a dual purpose. On one hand, it protects the transport 386 from the network, including both potential attackers and ossification 387 by middleboxes. On the other hand, it protects the network elements 388 from potential confusion attacks such as the one discussed in 389 Section 10.3 of [RFC6455]. 391 One potential concern is that even when a transport cannot be 392 created, the connection error would reveal enough information to 393 allow an attacker to scan the network addresses that would normally 394 be inaccessible. Because of that, the user agent that runs untrusted 395 clients MUST NOT provide any detailed error information until the 396 server has confirmed that it is a WebTransport endpoint. For 397 example, the client must not be able to distinguish between a network 398 address that is unreachable and that is reachable but is not a 399 WebTransport server. 401 WebTransport does not support any traditional means of browser-based 402 authentication. It is not based on HTTP, and hence does not support 403 HTTP cookies or HTTP authentication. Since it uses TLS, individual 404 transport protocols MAY expose TLS-based authentication capabilities 405 such as client certificates. However, since in some of those 406 protocols, multiple transports can be pooled within the same TLS 407 connection, such features would not be universally available. 409 8. IANA Considerations 411 There are no requests to IANA in this document. 413 9. References 415 9.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 423 DOI 10.17487/RFC6454, December 2011, 424 . 426 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 427 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 428 May 2017, . 430 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 431 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 432 . 434 9.2. Informative References 436 [I-D.ietf-quic-http] 437 Bishop, M., "Hypertext Transfer Protocol Version 3 438 (HTTP/3)", draft-ietf-quic-http-20 (work in progress), 439 April 2019. 441 [I-D.ietf-quic-recovery] 442 Iyengar, J. and I. Swett, "QUIC Loss Detection and 443 Congestion Control", draft-ietf-quic-recovery-20 (work in 444 progress), April 2019. 446 [I-D.ietf-quic-transport] 447 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 448 and Secure Transport", draft-ietf-quic-transport-20 (work 449 in progress), April 2019. 451 [I-D.ietf-rtcweb-data-channel] 452 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 453 Channels", draft-ietf-rtcweb-data-channel-13 (work in 454 progress), January 2015. 456 [I-D.ietf-tls-dtls13] 457 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 458 Datagram Transport Layer Security (DTLS) Protocol Version 459 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 460 2019. 462 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 463 RFC 896, DOI 10.17487/RFC0896, January 1984, 464 . 466 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 467 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 468 . 470 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 471 RFC 6455, DOI 10.17487/RFC6455, December 2011, 472 . 474 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 475 RFC 8441, DOI 10.17487/RFC8441, September 2018, 476 . 478 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 479 Connectivity Establishment (ICE): A Protocol for Network 480 Address Translator (NAT) Traversal", RFC 8445, 481 DOI 10.17487/RFC8445, July 2018, 482 . 484 Author's Address 486 Victor Vasiliev 487 Google 489 Email: vasilvv@google.com