idnits 2.17.1 draft-kinnear-webtransport-http2-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 date (13 July 2020) is 1355 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) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-03) exists of draft-vvv-webtransport-http3-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 webtrans A. Frindell 3 Internet-Draft Facebook Inc. 4 Intended status: Standards Track E. Kinnear 5 Expires: 14 January 2021 T. Pauly 6 Apple Inc. 7 V. Vasiliev 8 Google 9 G. Xie 10 Facebook Inc. 11 13 July 2020 13 WebTransport using HTTP/2 14 draft-kinnear-webtransport-http2-01 16 Abstract 18 WebTransport is a protocol framework that enables clients constrained 19 by the Web security model to communicate with a remote server using a 20 secure multiplexed transport. This document describes 21 Http2Transport, a WebTransport protocol that is based on HTTP/2 and 22 provides support for either endpoint to initiate streams multiplexed 23 within the same HTTP/2 connection. 25 Note to Readers 27 Discussion of this draft takes place on the WebTransport mailing list 28 (webtransport@ietf.org), which is archived at 29 . 31 The repository tracking the issues for this draft can be found at 32 . The 33 web API draft corresponding to this document can be found at 34 . 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 14 January 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 71 3. Http2Transport Overview . . . . . . . . . . . . . . . . . . . 4 72 3.1. WebTransport Connect Streams . . . . . . . . . . . . . . 4 73 3.2. WebTransport Streams . . . . . . . . . . . . . . . . . . 5 74 3.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.4. The SETTINGS_ENABLE_WEBTRANSPORT SETTINGS parameter . . . 5 76 3.5. The WTHEADERS Frame . . . . . . . . . . . . . . . . . . . 6 77 3.6. Initiating the Extended CONNECT Handshake . . . . . . . . 7 78 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Using WebTransport Streams . . . . . . . . . . . . . . . . . 10 80 4.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 10 81 4.2. Interaction with HTTP/2 Features . . . . . . . . . . . . 11 82 4.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . 11 83 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 12 84 5. Transport Properties . . . . . . . . . . . . . . . . . . . . 12 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 7.1. HTTP/2 Frame Type Registry . . . . . . . . . . . . . . . 14 88 7.2. HTTP/2 Settings Registry . . . . . . . . . . . . . . . . 14 89 7.3. HTTP/2 Error Code Registry . . . . . . . . . . . . . . . 14 90 7.4. Upgrade Token Registration . . . . . . . . . . . . . . . 15 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 8.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction 100 HTTP/2 [RFC7540] transports HTTP messages via a framing layer that 101 includes many optimizations designed to make communication more 102 efficient between clients and servers. These include multiplexing of 103 multiple streams on a single underlying transport connection, flow 104 control, priorities, header compression, and exchange of 105 configuration information between endpoints. 107 Currently, the only mechanism in HTTP/2 for server to client 108 communication is server push. That is, servers can initiate 109 unidirectional push promised streams to clients, but clients cannot 110 respond to them; they can only accept them or discard them. 111 Additionally, intermediaries along the path may have different server 112 push policies and may not forward push promised streams to the 113 downstream client. This best effort mechanism is not sufficient to 114 reliably deliver messages from servers to clients, limiting server to 115 client use-cases such as chat messages or notifications. 117 Several techniques have been developed to workaround these 118 limitations: long polling [RFC6202], WebSocket [RFC8441], and 119 tunneling using the CONNECT method. All of these approaches layer an 120 application protocol on top of HTTP/2, using HTTP/2 streams as 121 transport connections. This layering defeats the optimizations 122 provided by HTTP/2. For example, application metadata is 123 encapsulated in DATA frames rather than HEADERS frames, bypassing the 124 advantages of HPACK header compression. Further, application data 125 might be framed multiple times at different protocol layers, reducing 126 the wire efficiency of the protocol. 128 This document defines Http2Transport, a mechanism for multiplexing 129 non-request/response streams with HTTP/2 in a manner that conforms 130 with the WebTransport protocol framework 131 [I-D.vvv-webtransport-overview]. Using the mechanism described, 132 multiple Http2Transport instances can be multiplexed simultaneously 133 with regular HTTP traffic on the same HTTP/2 connection. 135 2. Conventions and Definitions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 This document follows terminology defined in Section 1.2 of 144 [I-D.vvv-webtransport-overview]. Note that this document 145 distinguishes between a WebTransport server and an HTTP/2 server. An 146 HTTP/2 server is the server that terminates HTTP/2 connections; a 147 WebTransport server is an application that accepts WebTransport 148 sessions, which can be accessed via an HTTP/2 server. 150 3. Http2Transport Overview 152 Section 8.3 of [RFC7540] defines the HTTP CONNECT method for HTTP/2, 153 which converts an HTTP/2 stream into a tunnel for arbitrary data. 154 [RFC8441] describes the use of the extended CONNECT method to 155 negotiate the use of the WebSocket Protocol [RFC6455] on an HTTP/2 156 stream. Http2Transport uses the extended CONNECT handshake to allow 157 WebTransport endpoints to multiplex arbitrary data streams on HTTP/2 158 connections. 160 Http2Transport introduces a new HTTP/2 frame which carries structured 161 metadata like the HEADERS and PUSH_PROMISE frames but without the 162 constraints of the request/response state machine and semantics. 164 The WebTransport over HTTP/2 extension: 166 1. Enables bidirectional and symmetric communication over HTTP/2. 167 After a WebTransport session is established, a server can 168 initiate a WebTransport stream to the client at any time, and the 169 client can respond to server-initiated streams. 171 2. Allows WebTransport streams to take advantage of HTTP/2 features 172 such as header compression, prioritization, and flow-control. 174 3. Provides a mechanism for intermediaries to route server initiated 175 messages to the correct client. 177 4. Allows clients and servers to group streams and route them 178 together. 180 3.1. WebTransport Connect Streams 182 After negotiating the use of this extension, clients initiate one or 183 more WebTransport Connect Streams to a Http2Transport Server. 184 Http2Transport servers are identified by a pair of authority value 185 and path value (defined in [RFC3986] Sections 3.2 and 3.3 186 respectively). The client uses the extended CONNECT method with a 187 :protocol token "webtransport" to establish a WebTransport Connect 188 Stream. This stream is only used to establish a WebTransport session 189 and is not intended for data exchange. 191 3.2. WebTransport Streams 193 Following the establishment of a WebTransport Connect stream, either 194 the client or the server can initiate a WebTransport Stream by 195 sending the WTHEADERS frame, defined in Section 3.5. This frame 196 references an open WebTransport Connect stream which is used by any 197 intermediaries to correctly forward the stream to the destination 198 endpoint. The only frames allowed on WebTransport Streams are 199 WTHEADERS, CONTINUATION, DATA and any negotiated extension frames. 201 3.3. Negotiation 203 Clients negotiate the use of WebTransport over HTTP/2 using both the 204 SETTINGS frame and one or more extended CONNECT requests as defined 205 in [RFC8441]. 207 Use of the extended CONNECT method extension requires the 208 SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client 209 prior to its use. An endpoint that supports receiving the extended 210 CONNECT method SHOULD send this setting with a value of 1. 212 The extended CONNECT method extension uses the ":protocol" pseudo- 213 header field to negotiate the protocol that will be used on a given 214 stream in an HTTP/2 connection. This document registers a new token, 215 "webtransport", in the "Hypertext Transfer Protocol (HTTP) Upgrade 216 Token Registry" established by [RFC7230] and located at 217 https://www.iana.org/assignments/http-upgrade-tokens/ 218 (https://www.iana.org/assignments/http-upgrade-tokens/). 220 This token is used in the ":protocol" pseudo-header field to indicate 221 that the endpoint wishes to use the WebTransport protocol on the new 222 stream. 224 3.4. The SETTINGS_ENABLE_WEBTRANSPORT SETTINGS parameter 226 As described in Section 5.5 of [RFC7540], SETTINGS parameters allow 227 endpoints to negotiate use of protocol extensions that would 228 otherwise generate protocol errors. 230 This document introduces a new SETTINGS parameter, 231 SETTINGS_ENABLE_WEBTRANSPORT, which MUST have a value of 0 or 1. 233 Once a SETTINGS_ENABLE_WEBTRANSPORT parameter has been sent with a 234 value of 1, an endpoint MUST NOT send the parameter with a value of 235 0. 237 Upon receipt of SETTINGS_ENABLE_WEBTRANSPORT with a value of 1, an 238 endpoint MAY use the WTHEADERS frame type defined in this document. 239 An endpoint that supports receiving the WTHEADERS as part of the 240 WebTransport protocol SHOULD send this setting with a value of 1. 242 3.5. The WTHEADERS Frame 244 A new HTTP/2 frame called WTHEADERS is introduced for either endpoint 245 to establish streams. A stream opened by a WTHEADERS frame is 246 referred to as a WebTransport Stream, and it MAY be continued by 247 CONTINUATION and DATA frames. WebTransport Streams can be initiated 248 by either clients or servers via a WTHEADERS frame that refers to the 249 corresponding WebTransport Connect Stream on which the WebTransport 250 protocol was negotiated. 252 The WTHEADERS frame (type=0xfb) has all the fields and frame header 253 flags defined by HEADERS frame in HEADERS [RFC7540], Section 6.2. 255 The WTHEADERS frame has one extra field, Connect Stream ID. 256 WTHEADERS frames can be sent on a stream in the "idle", "open", or 257 "half-closed (remote)" state, see Section 4.1. 259 Like HEADERS, the CONTINUATION frame (type=0x9) is used to continue a 260 sequence of header block fragments, if the headers do not fit into 261 one WTHEADERS frame. 263 The WTHEADERS frame is shown in Figure 1. 265 0 1 2 3 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 267 +---------------+ 268 |Pad Length? (8)| 269 +-+-------------+-----------------------------------------------+ 270 |E| Stream Dependency? (31) | 271 +-+-------------+-----------------------------------------------+ 272 | Weight? (8) | 273 +-+-------------+-----------------------------------------------+ 274 |R| Connect Stream ID (31) | 275 +-+-------------------------------------------------------------+ 276 | Header Block Fragment (*) ... 277 +---------------------------------------------------------------+ 278 | Padding (*) ... 279 +---------------------------------------------------------------+ 281 Figure 1: WTHEADERS Frame Format 283 The Connect Stream specified in a WTHEADERS frame MUST be an open 284 stream negotiated via the extended CONNECT protocol with a 285 ":protocol" value of "webtransport". 287 The recipient MUST respond with a connection error of type 288 WTHEADERS_STREAM_ERROR if the specified WebTransport Connect Stream 289 does not exist, is not a stream established via extended CONNECT to 290 use the "webtransport" protocol, or if it is in the closed or half- 291 closed (remote) stream state. This allows WebTransport Streams to 292 participate in header compression and flow control. 294 3.6. Initiating the Extended CONNECT Handshake 296 An endpoint that wishes to establish a WebTransport session over an 297 HTTP/2 stream follows the extended CONNECT handshake procedure 298 defined in [RFC8441], specifying "webtransport" for the :protocol 299 pseudo-header field. 301 The :scheme and :path pseudo-headers are required by [RFC6455]. The 302 scheme of the target URI MUST be set to "https" for all :protocol 303 values. The path is used to identify the specific WebTransport 304 server instance for negotiation and MAY be set to "/" (an empty path 305 component). 307 Implementations should note that the Origin, Sec-WebSocket-Version, 308 Sec-WebSocket-Protocol, and Sec-WebSocket-Extensions header fields 309 are not required to be included in the CONNECT request and response 310 header fields, since this handshake mechanism is not being used to 311 negotiate a WebSocket connection. 313 If the response to the extended CONNECT request indicates success of 314 the handshake, then all further data sent or received on the new 315 HTTP/2 stream is considered to be that of the WebTransport protocol 316 and follows the semantics defined by that protocol. If the response 317 indicates failure of the handshake, any WebTransport Streams that 318 reference the WebTransport Connect Stream that failed to establish 319 MUST also be reset. 321 3.7. Examples 323 An example of negotiating a WebTransport Stream on an HTTP/2 324 connection follows. This example is intended to closely follow the 325 example in Section 5.1 of [RFC8441] to help illustrate the 326 differences defined in this document. 328 [[ From Client ]] [[ From Server ]] 330 SETTINGS 331 SETTINGS_ENABLE_CONNECT_[..] = 1 332 SETTINGS_ENABLE_WEBTRANSPORT = 1 334 SETTINGS 335 SETTINGS_ENABLE_CONNECT_[..] = 1 336 SETTINGS_ENABLE_WEBTRANSPORT = 1 338 HEADERS + END_HEADERS 339 + STREAM_ID = 3 340 :method = CONNECT 341 :protocol = webtransport 342 :scheme = https 343 :path = / 344 :authority = server.example.com 346 HEADERS + END_HEADERS 347 + STREAM_ID = 3 348 :status = 200 350 WTHEADERS + END_HEADERS 351 + STREAM_ID = 5 352 + CONNECT_STREAM = 3 353 :method = GET 354 :scheme = https 355 :path = / 356 :authority = server.example.com 358 WTHEADERS + END_HEADERS 359 + STREAM_ID = 5 360 + CONNECT_STREAM = 3 361 :status = 200 363 DATA + STREAM_ID = 5 364 WebTransport Data 366 DATA + STREAM_ID = 5 + END_STREAM 367 WebTransport Data 369 DATA + STREAM_ID = 5 + END_STREAM 370 WebTransport Data 372 An example of the server initiating a WebTransport Stream follows. 373 The only difference here is the endpoint that sends the first 374 WTHEADERS frame. 376 [[ From Client ]] [[ From Server ]] 378 SETTINGS 379 SETTINGS_ENABLE_CONNECT_[..] = 1 380 SETTINGS_ENABLE_WEBTRANSPORT = 1 382 SETTINGS 383 SETTINGS_ENABLE_CONNECT_[..] = 1 384 SETTINGS_ENABLE_WEBTRANSPORT = 1 386 HEADERS + END_HEADERS 387 + STREAM_ID = 3 388 :method = CONNECT 389 :protocol = webtransport 390 :scheme = https 391 :path = / 392 :authority = server.example.com 394 HEADERS + END_HEADERS 395 + STREAM_ID = 3 396 :status = 200 398 WTHEADERS + END_HEADERS 399 + STREAM_ID = 2 400 + CONNECT_STREAM = 3 401 :method = GET 402 :scheme = https 403 :path = / 404 :authority = client.example.com 406 WTHEADERS + END_HEADERS 407 + STREAM_ID = 2 408 + CONNECT_STREAM = 3 409 :status = 200 411 DATA + STREAM_ID = 2 412 WebTransport Data 414 DATA + STREAM_ID = 2 + END_STREAM 415 WebTransport Data 417 DATA + STREAM_ID = 2 + END_STREAM 418 WebTransport Data 420 4. Using WebTransport Streams 422 Once the extended CONNECT handshake has completed and a WebTransport 423 connect stream has been established, WTHEADERS frames can be sent 424 that reference that stream in the Connect Stream ID field to 425 establish WebTransport Streams. WebTransport Connect Streams are 426 intended for exchanging metadata only and are RECOMMENDED to be long 427 lived streams. Once a WebTransport Connect Stream is closed, all 428 routing information it carries is lost, and subsequent WebTransport 429 Streams cannot be created with WTHEADERS frames until the client 430 completes another extended CONNECT handshake to establish a new 431 WebTransport Connect Stream. 433 In contrast, WebTransport Streams established with WTHEADERS frames 434 can be opened at any time by either endpoint and therefore need not 435 remain open beyond their immediate usage as part of the WebTransport 436 protocol. 438 An endpoint MUST NOT send DATA frames with a non-zero payload length 439 on a WebTransport Connect Stream beyond the completion of the 440 extended CONNECT handshake. If data is received by an endpoint on a 441 WebTransport Connect Stream, it MUST reset that stream with a new 442 error code, PROHIBITED_WT_CONNECT_DATA, indicating that additional 443 data is prohibited on the Connect Stream when using "webtransport" as 444 the ":protocol" value. 446 4.1. Stream States 448 WebTransport Connect Streams are regular HTTP/2 streams that follow 449 the stream lifecycle described in Section 5.1 of [RFC7540]. 450 WebTransport Streams established with the WTHEADERS frame also follow 451 the same lifecycle as regular HTTP/2 streams, but have an additional 452 dependency on the Connect Stream that they reference via their 453 Connect Stream ID. 455 If the corresponding Connect Stream is reset, endpoints MUST reset 456 the WebTransport Streams associated with that Connect Stream. If the 457 Connect Stream is closed gracefully, endpoints SHOULD allow any 458 existing WebTransport Streams to complete normally, however the 459 Connect Stream SHOULD remain open while communication is expected to 460 continue. 462 Endpoints SHOULD take measures to prevent a peer or intermediary from 463 timing out the Connect Stream while its associated WebTransport 464 Streams are expected to remain open. For example, an endpoint might 465 choose to refresh a timeout on a Connect Stream any time a 466 corresponding timeout is refreshed on a corresponding WebTransport 467 Stream, such as when any data is sent or received on that 468 WebTransport Stream. 470 An endpoint MUST NOT initiate new WebTransport Streams that reference 471 a Connect Stream that is in the closed or half closed (remote) state. 472 Endpoints process new WebTransport Streams only when the associated 473 Connect Stream is in the open or half closed (local) state. 475 4.2. Interaction with HTTP/2 Features 477 WebTransport Streams are extended HTTP/2 streams, and all of the 478 standard HTTP/2 features for streams still apply to WebTransport 479 Streams. For example, WebTransport Streams are counted against the 480 concurrent stream limit, which is defined in Section 5.1.2 of 481 [RFC7540]. The connection level and stream level flow control limits 482 are still valid for WebTransport Streams. Prioritizing the 483 WebTransport Streams across different Connect Stream groupings does 484 not make sense because they belong to different services. 486 Note that while HTTP/2 Stream IDs are used by WebTransport Streams to 487 refer to their corresponding WebTransport Connect Streams, the Stream 488 IDs themselves are an implementation detail and SHOULD NOT be vended 489 to clients via a WebTransport API. 491 4.3. Intermediaries 493 WebTransport Connect Streams, and their corresponding WebTransport 494 Streams, can be independently routed by intermediaries on the network 495 path. The main purpose for a WebTransport Connect Stream is to 496 facilitate intermediary traversal by WebTransport Streams. 498 Any segment on which SETTINGS_ENABLE_WEBTRANSPORT has been negotiated 499 MUST route all WebTransport Streams established by WTHEADERS frames 500 on the same connection as their corresponding WebTransport Connect 501 Streams. 503 If an intermediary cannot route WebTransport Streams on a subsequent 504 segment of the path, it can fail the extended CONNECT handshake and 505 prevent a WebTransport Connect Stream from being established for a 506 given endpoint. In the event that additional WebTransport Streams 507 reference that WebTransport Connect Stream, they will also be reset. 509 An example of such routing, for both client-initiated and server- 510 initiated WebTransport streams, is shown in Figure 2 and in Figure 3. 511 Note that "webtransport" is specified as the ":protocol" being 512 negotiated by the CONNECT frame on both segments, and the 513 corresponding stream is referenced by the Connect Stream ID field in 514 the WTHEADERS frames. 516 +--------+ CONNECT (5) +---------+ CONNECT (1) +--------+ 517 | client |>--------------->| proxy |>---------------->| server | 518 +--------+ +---------+ +--------+ 519 v ^ v ^ 520 | WTHEADERS(7, CS=5) | | WTHEADERS(3, CS=1) | 521 +------------------------+ +------------------------+ 523 Figure 2: A client initiates a WebTransport Stream to a server. 525 +--------+ CONNECT (5) +---------+ CONNECT (1) +--------+ 526 | client |>--------------->| proxy |>---------------->| server | 527 +--------+ +---------+ +--------+ 528 ^ v ^ v 529 | WTHEADERS(4, CS=5) | | WTHEADERS(2, CS=1) | 530 +------------------------+ +------------------------+ 532 Figure 3: A server initiates a WebTransport Stream to a client. 534 4.4. Session Termination 536 An Http2Transport session is terminated when either endpoint closes 537 the stream associated with the CONNECT request that initiated the 538 session. Upon learning about the session being terminated, both 539 endpoints MUST stop sending new frames on the WebTransport Connect 540 Stream associated with the CONNECT request and reset all WebTransport 541 Streams associated with the session. 543 5. Transport Properties 545 The WebTransport framework [I-D.vvv-webtransport-overview] defines a 546 set of optional transport properties that clients can use to 547 determine the presence of features which might allow additional 548 optimizations beyond the common set of properties available via all 549 WebTransport protocols. Below are details about support in 550 Http2Transport for those properties. 552 Stream Independence: Http2Transport does not support stream 553 independence, as HTTP/2 inherently has head of line blocking. 555 Partial Reliability: Http2Transport does not support partial 556 reliability, as HTTP/2 retransmits any lost data. This means that 557 any datagrams sent via Http2Transport will be retransmitted 558 regardless of the preference of the application. 560 Pooling Support: Http2Transport supports pooling, as multiple 561 transports using Http2Transport may share the same underlying 562 HTTP/2 connection and therefore share a congestion controller and 563 other transport context. 565 Connection Mobility: Http2Transport does not support connection 566 mobility, unless an underlying transport protocol that supports 567 multipath or migration, such as MPTCP [RFC7540], is used 568 underneath HTTP/2 and TLS. Without such support, Http2Transport 569 connections cannot survive network transitions. 571 6. Security Considerations 573 WebTransport Streams established by the CONNECT handshake and the 574 WTHEADERS frame are expected to be protected with a TLS connection. 575 They inherit the security properties of this cryptographic context, 576 as well as the security properties of client-server communication via 577 HTTP/2 as described in [RFC7540]. 579 The security considerations of [RFC8441] Section 8 and [RFC7540] 580 Section 10, and Section 10.5.2 especially, apply to this use of the 581 CONNECT method. 583 Http2Transport requires explicit opt-in through the use of an HTTP/2 584 SETTINGS parameter, avoiding potential protocol confusion attacks by 585 ensuring the HTTP/2 server explicitly supports the WebTransport 586 protocol. It also requires the use of the Origin header, providing 587 the server with the ability to deny access to Web-based clients that 588 do not originate from a trusted origin. 590 Just like HTTP/2 itself, Http2Transport pools traffic to different 591 origins within a single connection. Different origins imply 592 different trust domains, meaning that the implementations have to 593 treat each transport as potentially hostile towards others on the 594 same connection. One potential attack is a resource exhaustion 595 attack: since all of the transports share both congestion control and 596 flow control context, a single client aggressively using up those 597 resources can cause other transports to stall. The user agent thus 598 SHOULD implement a fairness scheme that ensures that each 599 WebTransport session within a connection is allocated a reasonable 600 share of controlled resources, both when sending data and opening new 601 streams. 603 7. IANA Considerations 605 This document adds an entry to the "HTTP/2 Frame Type" registry, the 606 "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all 607 defined in [RFC7540]. It also registers an HTTP upgrade token in the 608 registry established by [RFC7230]. 610 7.1. HTTP/2 Frame Type Registry 612 The following entry is added to the "HTTP/2 Frame Type" registry 613 established by Section 11.2 of [RFC7540]. 615 Frame Type: WTHEADERS 617 Code: 0xFB 619 Specification: _RFC Editor: Please fill in this value with the RFC 620 number for this document_ 622 7.2. HTTP/2 Settings Registry 624 The following entry is added to the "HTTP/2 Settings" registry that 625 was established by Section 11.3 of [RFC7540]. 627 Code: 0xFB 629 Name: SETTINGS_ENABLE_WEBTRANSPORT 631 Initial Value: 0 633 Specification: _RFC Editor: Please fill in this value with the RFC 634 number for this document_ 636 7.3. HTTP/2 Error Code Registry 638 The following entries are added to the "HTTP/2 Error Code" registry 639 that was established by Section 11.2 of [RFC7540]. 641 Name: WTHEADERS_STREAM_ERROR 643 Code: 0xFB 645 Description: Invalid use of WTHEADERS frame 647 Specification: _RFC Editor: Please fill in this value with the RFC 648 number for this document_ 650 Name: PROHIBITED_WT_CONNECT_DATA 651 Code: 0xFC 653 Description: Prohibited data sent on WebTransport Connect Stream 655 Specification: _RFC Editor: Please fill in this value with the RFC 656 number for this document_ 658 7.4. Upgrade Token Registration 660 The following entry is added to the "Hypertext Transfer Protocol 661 (HTTP) Upgrade Token Registry" registry established by [RFC7230]. 663 Value: webtransport 665 Description: WebTransport over HTTP 667 Expected Version Tokens: 669 Reference: _RFC Editor: Please fill in this value with the RFC 670 number for this document_ and [I-D.vvv-webtransport-http3] 672 8. References 674 8.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 682 Resource Identifier (URI): Generic Syntax", STD 66, 683 RFC 3986, DOI 10.17487/RFC3986, January 2005, 684 . 686 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 687 RFC 6455, DOI 10.17487/RFC6455, December 2011, 688 . 690 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 691 Protocol (HTTP/1.1): Message Syntax and Routing", 692 RFC 7230, DOI 10.17487/RFC7230, June 2014, 693 . 695 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 696 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 697 DOI 10.17487/RFC7540, May 2015, 698 . 700 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 701 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 702 May 2017, . 704 [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", 705 RFC 8441, DOI 10.17487/RFC8441, September 2018, 706 . 708 8.2. Informative References 710 [I-D.vvv-webtransport-http3] 711 Vasiliev, V., "WebTransport over HTTP/3", Work in 712 Progress, Internet-Draft, draft-vvv-webtransport-http3-02, 713 30 June 2020, . 716 [I-D.vvv-webtransport-overview] 717 Vasiliev, V., "The WebTransport Protocol Framework", Work 718 in Progress, Internet-Draft, draft-vvv-webtransport- 719 overview-01, 3 November 2019, . 722 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 723 "Known Issues and Best Practices for the Use of Long 724 Polling and Streaming in Bidirectional HTTP", RFC 6202, 725 DOI 10.17487/RFC6202, April 2011, 726 . 728 Acknowledgments 730 Thanks to Anthony Chivetta, Joshua Otto, and Valentin Pistol for 731 their contributions in the design and implementation of this work. 733 Authors' Addresses 735 Alan Frindell 736 Facebook Inc. 738 Email: afrind@fb.com 740 Eric Kinnear 741 Apple Inc. 742 One Apple Park Way 743 Cupertino, California 95014, 744 United States of America 746 Email: ekinnear@apple.com 747 Tommy Pauly 748 Apple Inc. 749 One Apple Park Way 750 Cupertino, California 95014, 751 United States of America 753 Email: tpauly@apple.com 755 Victor Vasiliev 756 Google 758 Email: vasilvv@google.com 760 Guowu Xie 761 Facebook Inc. 763 Email: woo@fb.com