idnits 2.17.1 draft-ietf-quic-http-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 (November 28, 2016) is 2705 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TRANSPORT' ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Bishop, Ed. 3 Internet-Draft Microsoft 4 Intended status: Standards Track November 28, 2016 5 Expires: June 1, 2017 7 Hypertext Transfer Protocol (HTTP) over QUIC 8 draft-ietf-quic-http-00 10 Abstract 12 The QUIC transport protocol has several features that are desirable 13 in a transport for HTTP/2, such as stream multiplexing, per-stream 14 flow control, and low-latency connection establishment. This 15 document describes a mapping of HTTP/2 semantics over QUIC. 16 Specifically, this document identifies HTTP/2 features that are 17 subsumed by QUIC, and describes how the other features can be 18 implemented atop QUIC. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 1, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 56 2. QUIC advertisement . . . . . . . . . . . . . . . . . . . . . 3 57 3. Connection establishment . . . . . . . . . . . . . . . . . . 3 58 4. Sending a request on an HTTP/2-over-QUIC connection . . . . . 4 59 4.1. Terminating a stream . . . . . . . . . . . . . . . . . . 4 60 5. Writing data to QUIC streams . . . . . . . . . . . . . . . . 5 61 6. Stream Mapping . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. Reserved Streams . . . . . . . . . . . . . . . . . . . . 5 63 6.1.1. Stream 3: headers . . . . . . . . . . . . . . . . . . 6 64 6.1.2. Stream states . . . . . . . . . . . . . . . . . . . . 6 65 7. Stream Priorities . . . . . . . . . . . . . . . . . . . . . . 7 66 8. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Server Push . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. Other HTTP/2 frames . . . . . . . . . . . . . . . . . . . . . 9 70 11.1. GOAWAY frame . . . . . . . . . . . . . . . . . . . . . . 9 71 11.2. PING frame . . . . . . . . . . . . . . . . . . . . . . . 10 72 11.3. PADDING frame . . . . . . . . . . . . . . . . . . . . . 10 73 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 14. Normative References . . . . . . . . . . . . . . . . . . . . 10 76 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The QUIC transport protocol has several features that are desirable 82 in a transport for HTTP/2, such as stream multiplexing, per-stream 83 flow control, and low-latency connection establishment. This 84 document describes a mapping of HTTP/2 semantics over QUIC. 85 Specifically, this document identifies HTTP/2 features that are 86 subsumed by QUIC, and describes how the other features can be 87 implemented atop QUIC. 89 QUIC is described in [QUIC-TRANSPORT]. For a full description of 90 HTTP/2, see [RFC7540]. 92 1.1. Notational Conventions 94 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 95 document. It's not shouting; when they are capitalized, they have 96 the special meaning defined in [RFC2119]. 98 2. QUIC advertisement 100 A server advertises that it can speak HTTP/2-over-QUIC via the Alt- 101 Svc HTTP response header. It does so by including the header in any 102 response sent over a non-QUIC (e.g. HTTP/2 over TLS) connection: 104 Alt-Svc: quic=":443" 106 In addition, the list of QUIC versions supported by the server can be 107 specified by the v= parameter. For example, if a server supported 108 both version 33 and 34 it would specify the following header: 110 Alt-Svc: quic=":443"; v="34,33" 112 On receipt of this header, a client may attempt to establish a QUIC 113 connection on port 443 and, if successful, send HTTP/2 requests using 114 the mapping described in this document. 116 Connectivity problems (e.g. firewall blocking UDP) may result in QUIC 117 connection establishment failure, in which case the client should 118 gracefully fallback to HTTP/2-over-TLS/TCP. 120 3. Connection establishment 122 HTTP/2-over-QUIC connections are established as described in 123 [QUIC-TRANSPORT]. The QUIC crypto handshake MUST use TLS [QUIC-TLS]. 125 While connection-level options pertaining to the core QUIC protocol 126 are set in the initial crypto handshake [QUIC-TLS]. HTTP/2-specific 127 settings are conveyed in the HTTP/2 SETTINGS frame. After the QUIC 128 connection is established, an HTTP/2 SETTINGS frame may be sent as 129 the initial frame of the QUIC headers stream (StreamID 3, See 130 Section 6). As in HTTP/2, additional SETTINGS frames may be sent 131 mid-connection by either endpoint. 133 TODO: Decide whether to acknowledge receipt of SETTINGS through 134 empty SETTINGS frames with ACK bit set, as in HTTP/2, or rely on 135 transport- level acknowledgment. 137 Some transport-level options that HTTP/2-over-TCP specifies via the 138 SETTINGS frame are superseded by QUIC transport parameters in HTTP/2- 139 over-QUIC. Below is a listing of how each HTTP/2 SETTINGS parameter 140 is mapped: 142 SETTINGS_HEADER_TABLE_SIZE: Sent in HTTP/2 SETTINGS frame. 144 SETTINGS_ENABLE_PUSH: Sent in HTTP/2 SETTINGS frame (TBD, currently 145 set using QUIC "SPSH" connection option) 147 SETTINGS_MAX_CONCURRENT_STREAMS QUIC requires the maximum number of 148 incoming streams per connection to be specified in the initial 149 crypto handshake, using the "MSPC" tag. Specifying 150 SETTINGS_MAX_CONCURRENT_STREAMS in the HTTP/2 SETTINGS frame is an 151 error. 153 SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and 154 connection flow control window sizes to be specified in the 155 initial crypto handshake, using the "SFCW" and "CFCW" tags, 156 respectively. Specifying SETTINGS_INITIAL_WINDOW_SIZE in the 157 HTTP/2 SETTINGS frame is an error. 159 SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in QUIC. 160 Specifying it in the HTTP/2 SETTINGS frame is an error. 162 SETTINGS_MAX_HEADER_LIST_SIZE Sent in HTTP/2 SETTINGS frame. 164 As with HTTP/2-over-TCP, unknown SETTINGS parameters are tolerated 165 but ignored. SETTINGS parameters are acknowledged by the receiving 166 peer, by sending an empty SETTINGS frame in response with the ACK bit 167 set. 169 4. Sending a request on an HTTP/2-over-QUIC connection 171 A high level overview of sending an HTTP/2 request on an established 172 QUIC connection is as follows, with further details in later sections 173 of this document. A client should first encode any HTTP headers 174 using HPACK [RFC7541] and frame them as HTTP/2 HEADERS frames. These 175 are sent on StreamID 3 (see Section 6). The exact layout of the 176 HEADERS frame is described in Section 6.2 of [RFC7540]. No HTTP/2 177 padding is required: QUIC provides a PADDING frame for this purpose. 179 While HEADERS are sent on stream 3, the mandatory stream identifier 180 in each HEADERS frame indicates the QUIC StreamID on which a 181 corresponding request body may be sent. If there is no non-header 182 data, the specified QUIC data stream will never be used. 184 4.1. Terminating a stream 186 A stream can be terminated in one of three ways: 188 o the request/response is headers only, in which case a HEADERS 189 frame with the END_STREAM bit set ends the stream specified in the 190 HEADERS frame 192 o the request/response has headers and body but no trailing headers, 193 in which case the final QUIC STREAM frame will have the FIN bit 194 set 196 o the request/response has headers, body, and trailing headers, in 197 which case the final QUIC STREAM frame will not have the FIN bit 198 set, and the trailing HEADERS frame will have the END_STREAM bit 199 set 201 (TODO: Describe mapping of HTTP/2 stream state machine to QUIC stream 202 state machine.) 204 5. Writing data to QUIC streams 206 A QUIC stream provides reliable in-order delivery of bytes, within 207 that stream. On the wire, data is framed into QUIC STREAM frames, 208 but this framing is invisible to the HTTP/2 layer. A QUIC receiver 209 buffers and orders received STREAM frames, exposing the data 210 contained within as a reliable byte stream to the application. 212 Bytes written to Stream 3 must be HTTP/2 HEADERS frames (or other 213 HTTP/2 non-data frames), whereas bytes written to data streams should 214 simply be request or response bodies. No further framing is required 215 by HTTP/2 (i.e. no HTTP/2 DATA frames are used). 217 If data arrives on a data stream before the corresponding HEADERS 218 have arrived on stream 3, then the data is buffered until the HEADERS 219 arrive. 221 6. Stream Mapping 223 When HTTP/2 headers and data are sent over QUIC, the QUIC layer 224 handles most of the stream management. HTTP/2 StreamIDs are replaced 225 by QUIC StreamIDs. HTTP/2 does not need to do any explicit stream 226 framing when using QUIC - data sent over a QUIC stream simply 227 consists of HTTP/2 headers or body. Requests and responses are 228 considered complete when the QUIC stream is closed in the 229 corresponding direction. 231 Like HTTP/2, QUIC uses odd-numbered StreamIDs for client initiated 232 streams, and even-numbered IDs for server initiated (i.e. server 233 push) streams. Unlike HTTP/2 there are a couple of reserved (or 234 dedicated) StreamIDs in QUIC. 236 6.1. Reserved Streams 238 StreamID 1 is reserved for crypto operations (the handshake, crypto 239 config updates), and MUST NOT be used for HTTP/2 headers or body, see 240 [QUIC-TRANSPORT]. StreamID 3 is reserved for sending and receiving 241 HTTP/2 HEADERS frames. Therefore the first client initiated data 242 stream has StreamID 5. 244 There are no reserved server initiated StreamIDs, so the first server 245 initiated (i.e. server push) stream has an ID of 2, followed by 4, 246 etc. 248 6.1.1. Stream 3: headers 250 HTTP/2-over-QUIC uses HPACK header compression as described in 251 [RFC7541]. HPACK was designed for HTTP/2 with the assumption of in- 252 order delivery such as that provided by TCP. A sequence of encoded 253 header blocks must arrive (and be decoded) at an endpoint in the same 254 order in which they were encoded. This ensures that the dynamic 255 state at the two endpoints remains in sync. 257 QUIC streams provide in-order delivery of data sent on those streams, 258 but there are no guarantees about order of delivery between streams. 259 To achieve in-order delivery of HEADERS frames in QUIC, they are all 260 sent on the reserved Stream 3. Data (request/response bodies) which 261 arrive on other data streams are buffered until the corresponding 262 HEADERS arrive and are read out of Stream 3. 264 This does introduce head-of-line blocking: if the packet containing 265 HEADERS for stream N is lost or reordered then stream N+2 cannot be 266 processed until they it has been retransmitted successfully, even 267 though the HEADERS for stream N+2 may have arrived. 269 Trailing headers (trailers) can also be sent on stream 3. These are 270 sent as HTTP/2 HEADERS frames, but MUST have the END_STREAM bit set, 271 and MUST include a ":final-offset" pseudo-header. Since QUIC 272 supports out of order delivery, receipt of a HEADERS frame with the 273 END_STREAM bit set does not guarantee that the entire request/ 274 response body has been fully received. Therefore, the extra ":final- 275 offset" pseudo-header is included in trailing HEADERS frames to 276 indicate the total number of body bytes sent on the corresponding 277 data stream. This is used by the QUIC layer to determine when the 278 full request has been received and therefore when it is safe to tear 279 down local stream state. The ":final-offset" pseudo header is 280 stripped from the HEADERS before passing to the HTTP/2 layer. 282 6.1.2. Stream states 284 The mapping of HTTP/2-over-QUIC with potential out of order delivery 285 of HEADERS frames results in some changes to the HTTP/2 stream state 286 transition diagram ([RFC7540], Section 5.1}}. Specifically the 287 transition from "open" to "half closed (remote)", and the transition 288 from "half closed (local)" to "closed" takes place only when: 290 o the peer has explicitly ended the stream via either 291 * an HTTP/2 HEADERS frame with END_STREAM bit set and, in the 292 case of trailing headers, the :final-offset pseudo-header 294 * or a QUIC stream frame with the FIN bit set. 296 o and the full request or response body has been received. 298 7. Stream Priorities 300 HTTP/2-over-QUIC uses the HTTP/2 priority scheme described in 301 [RFC7540] Section 5.3. In the HTTP/2 priority scheme, a given stream 302 can be designated as dependent upon another stream, which expresses 303 the preference that the latter stream (the "parent" stream) be 304 allocated resources before the former stream (the "dependent" 305 stream). Taken together, the dependencies across all streams in a 306 connection form a dependency tree. The structure of the dependency 307 tree changes as HTTP/2 HEADERS and PRIORITY frames add, remove, or 308 change the dependency links between streams. 310 Implicit in this scheme is the notion of in-order delivery of 311 priority changes (i.e., dependency tree mutations): since operations 312 on the dependency tree such as reparenting a subtree are not 313 commutative, both sender and receiver must apply them in the same 314 order to ensure that both sides have a consistent view of the stream 315 dependency tree. HTTP/2 specifies priority assignments in PRIORITY 316 frames and (optionally) in HEADERS frames. To achieve in-order 317 delivery of HTTP/2 priority changes in HTTP/2-over-QUIC, HTTP/2 318 PRIORITY frames, in addition to HEADERS frames, are also sent on 319 reserved stream 3. The semantics of the Stream Dependency, Weight, E 320 flag, and (for HEADERS frames) PRIORITY flag are the same as in 321 HTTP/2-over-TCP. 323 Since HEADERS and PRIORITY frames are sent on a different stream than 324 the STREAM frames for the streams they reference, they may be 325 delivered out-of-order with respect to the STREAM frames. There is 326 no special handling for this-the receiver should simply assign 327 resources according to the most recent stream priority information 328 that it has received. 330 ALTERNATIVE DESIGN: if the core QUIC protocol implements priorities, 331 then this document should map the HTTP/2 priorities scheme to that 332 provided by the core protocol. This would likely involve prohibiting 333 the sending of HTTP/2 PRIORITY frames and setting of the PRIORITY 334 flag in HTTP/2 HEADERS frames, to avoid conflicting directives. 336 8. Flow Control 338 QUIC provides stream and connection level flow control, similar in 339 principle to HTTP/2's flow control but with some implementation 340 differences. As flow control is handled by QUIC, the HTTP/2 mapping 341 need not concern itself with maintaining flow control state, or how/ 342 when to send flow control frames to the peer. The HTTP/2 mapping 343 must not send HTTP/2 WINDOW_UPDATE frames. 345 The initial flow control window sizes (stream and connection) are 346 communicated during the crypto handshake (see Section 3). Setting 347 these values to the maximum size (2^31 - 1) effectively disables flow 348 control. 350 Relatively small initial windows can be used, as QUIC will attempt to 351 auto-tune the flow control windows based on usage. See 352 [QUIC-TRANSPORT] for more details. 354 9. Server Push 356 HTTP/2-over-QUIC supports HTTP/2 server push. During connection 357 establishment, the client indicates whether or it is willing to 358 receive server pushes via the SETTINGS_ENABLE_PUSH setting in the 359 HTTP/2 SETTINGS frame (see Section 3), which defaults to 1 (true). 361 As with server push for HTTP/2-over-TCP, the server initiates a 362 server push by sending an HTTP/2 PUSH_PROMISE frame containing the 363 StreamID of the stream to be pushed, as well as request header fields 364 attributed to the request. The PUSH_PROMISE frame is sent on stream 365 3, to ensure proper ordering with respect to other HEADERS and non- 366 data frames. Within the PUSH_PROMISE frame, the StreamID in the 367 common HTTP/2 frame header indicates the associated (client- 368 initiated) stream for the new push stream, while the Promised Stream 369 ID field specifies the StreamID of the new push stream. 371 The server push response is conveyed in the same way as a non-server- 372 push response, with response headers and (if present) trailers 373 carried by HTTP/2 HEADERS frames sent on reserved stream 3, and 374 response body (if any) sent via QUIC stream frames on the stream 375 specified in the corresponding PUSH_PROMISE frame. 377 10. Error Codes 379 The HTTP/2 error codes defined in Section 7 of [RFC7540] map to QUIC 380 error codes as follows: 382 NO_ERROR (0x0): Maps to QUIC_NO_ERROR 383 PROTOCOL_ERROR (0x1): No single mapping? 385 INTERNAL_ERROR (0x2) QUIC_INTERNAL_ERROR? (not currently defined in 386 core protocol spec) 388 FLOW_CONTROL_ERROR (0x3): QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA? 389 (not currently defined in core protocol spec) 391 SETTINGS_TIMEOUT (0x4): (depends on whether we support SETTINGS 392 acks) 394 STREAM_CLOSED (0x5): QUIC_STREAM_DATA_AFTER_TERMINATION 396 FRAME_SIZE_ERROR (0x6) QUIC_INVALID_FRAME_DATA 398 REFUSED_STREAM (0x7): ? 400 CANCEL (0x8): ? 402 COMPRESSION_ERROR (0x9): QUIC_DECOMPRESSION_FAILURE (not currently 403 defined in core spec) 405 CONNECT_ERROR (0xa): ? (depends whether we decide to support 406 CONNECT) 408 ENHANCE_YOUR_CALM (0xb): ? 410 INADEQUATE_SECURITY (0xc): QUIC_HANDSHAKE_FAILED, 411 QUIC_CRYPTO_NO_SUPPORT 413 HTTP_1_1_REQUIRED (0xd): ? 415 TODO: fill in missing error code mappings. 417 11. Other HTTP/2 frames 419 QUIC includes some features (e.g. flow control) which are also 420 present in HTTP/2. In these cases the HTTP/2 mapping need not re- 421 implement them. As a result some HTTP/2 frame types are not required 422 when using QUIC, as they either are directly implemented in the QUIC 423 layer, or their functionality is provided via other means. This 424 section of the document describes these cases. 426 11.1. GOAWAY frame 428 QUIC has its own GOAWAY frame, and QUIC implementations may to expose 429 the sending of a GOAWAY to the application. The semantics of sending 430 a GOAWAY in QUIC are identical to HTTP/2: an endpoint sending a 431 GOAWAY will continue processing open streams, but will not accept 432 newly created streams. 434 QUIC's GOAWAY frame is described in detail in the [QUIC-TRANSPORT]. 436 11.2. PING frame 438 QUIC has its own PING frame, which is currently exposed to the 439 application. QUIC clients send periodic PINGs to servers if there 440 are no currently active data streams on the connection. 442 QUIC's PING frame is described in detail in the [QUIC-TRANSPORT]. 444 11.3. PADDING frame 446 There is no HTTP/2 padding in this mapping; padding is instead 447 provided at the QUIC layer by including QUIC PADDING frames in a 448 packet payload. An HTTP/2 over QUIC mapping should treat any HTTP/2 449 level padding as an error, to avoid any possibility of inconsistent 450 flow control states between endpoints (e.g. client sends HTTP/2 451 padding, counts it against flow control, server ignores). 453 12. Security Considerations 455 The security considerations of HTTP over QUIC should be comparable to 456 those of HTTP/2. 458 13. IANA Considerations 460 This document has no IANA actions. Yet. 462 14. Normative References 464 [QUIC-TLS] 465 Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport 466 Layer Security (TLS) to Secure QUIC", November 2016. 468 [QUIC-TRANSPORT] 469 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 470 Multiplexed and Secure Transport", November 2016. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 478 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 479 DOI 10.17487/RFC7540, May 2015, 480 . 482 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 483 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 484 . 486 Appendix A. Contributors 488 The original authors of this specification were Robbie Shade and Mike 489 Warres. 491 Author's Address 493 Mike Bishop (editor) 494 Microsoft 496 Email: Mike.Bishop@microsoft.com