idnits 2.17.1 draft-ietf-quic-transport-10.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2243 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 4278 -- Looks like a reference, but probably isn't: '2' on line 4280 -- Looks like a reference, but probably isn't: '3' on line 4282 -- Looks like a reference, but probably isn't: '4' on line 4284 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-10 -- Duplicate reference: RFC1191, mentioned in 'RFC1191', was also mentioned in 'PMTUDv4'. -- Duplicate reference: RFC4821, mentioned in 'RFC4821', was also mentioned in 'PLPMTUD'. -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-00 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Iyengar, Ed. 3 Internet-Draft Fastly 4 Intended status: Standards Track M. Thomson, Ed. 5 Expires: September 6, 2018 Mozilla 6 March 05, 2018 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-10 11 Abstract 13 This document defines the core of the QUIC transport protocol. This 14 document describes connection establishment, packet format, 15 multiplexing and reliability. Accompanying documents describe the 16 cryptographic handshake and loss detection. 18 Note to Readers 20 Discussion of this draft takes place on the QUIC working group 21 mailing list (quic@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 24 Working Group information can be found at https://github.com/quicwg 25 [2]; source code and issues list for this draft can be found at 26 https://github.com/quicwg/base-drafts/labels/-transport [3]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 64 2.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 65 3. A QUIC Overview . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Low-Latency Connection Establishment . . . . . . . . . . 7 67 3.2. Stream Multiplexing . . . . . . . . . . . . . . . . . . . 7 68 3.3. Rich Signaling for Congestion Control and Loss Recovery . 7 69 3.4. Stream and Connection Flow Control . . . . . . . . . . . 7 70 3.5. Authenticated and Encrypted Header and Payload . . . . . 8 71 3.6. Connection Migration and Resilience to NAT Rebinding . . 8 72 3.7. Version Negotiation . . . . . . . . . . . . . . . . . . . 9 73 4. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Packet Types and Formats . . . . . . . . . . . . . . . . . . 10 75 5.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 12 77 5.3. Version Negotiation Packet . . . . . . . . . . . . . . . 13 78 5.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 14 79 5.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 15 80 5.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 15 81 5.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 16 82 5.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 17 83 5.6. Connection ID . . . . . . . . . . . . . . . . . . . . . . 17 84 5.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18 85 5.7.1. Initial Packet Number . . . . . . . . . . . . . . . . 19 86 6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 19 87 7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 21 88 7.1. Matching Packets to Connections . . . . . . . . . . . . . 22 89 7.1.1. Client Packet Handling . . . . . . . . . . . . . . . 22 90 7.1.2. Server Packet Handling . . . . . . . . . . . . . . . 22 91 7.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 23 92 7.2.1. Sending Version Negotiation Packets . . . . . . . . . 23 93 7.2.2. Handling Version Negotiation Packets . . . . . . . . 24 94 7.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 24 95 7.3. Cryptographic and Transport Handshake . . . . . . . . . . 25 96 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 26 97 7.4.1. Transport Parameter Definitions . . . . . . . . . . . 28 98 7.4.2. Values of Transport Parameters for 0-RTT . . . . . . 30 99 7.4.3. New Transport Parameters . . . . . . . . . . . . . . 30 100 7.4.4. Version Negotiation Validation . . . . . . . . . . . 31 101 7.5. Stateless Retries . . . . . . . . . . . . . . . . . . . . 32 102 7.6. Proof of Source Address Ownership . . . . . . . . . . . . 33 103 7.6.1. Client Address Validation Procedure . . . . . . . . . 33 104 7.6.2. Address Validation on Session Resumption . . . . . . 34 105 7.6.3. Address Validation Token Integrity . . . . . . . . . 35 106 7.7. Connection Migration . . . . . . . . . . . . . . . . . . 35 107 7.7.1. Privacy Implications of Connection Migration . . . . 36 108 7.7.2. Address Validation for Migrated Connections . . . . . 37 109 7.8. Spurious Connection Migrations . . . . . . . . . . . . . 39 110 7.9. Connection Termination . . . . . . . . . . . . . . . . . 40 111 7.9.1. Closing and Draining Connection States . . . . . . . 40 112 7.9.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 41 113 7.9.3. Immediate Close . . . . . . . . . . . . . . . . . . . 41 114 7.9.4. Stateless Reset . . . . . . . . . . . . . . . . . . . 42 115 8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 45 116 8.1. Variable-Length Integer Encoding . . . . . . . . . . . . 45 117 8.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 46 118 8.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 46 119 8.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 47 120 8.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 48 121 8.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 48 122 8.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 49 123 8.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 50 124 8.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 50 125 8.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 51 126 8.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 51 127 8.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 52 128 8.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 52 129 8.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 53 130 8.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 54 131 8.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 55 132 8.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 57 133 8.15.3. ACK Frames and Packet Protection . . . . . . . . . . 58 134 8.16. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 59 135 8.17. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 59 136 8.18. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 60 137 9. Packetization and Reliability . . . . . . . . . . . . . . . . 61 138 9.1. Packet Processing and Acknowledgment . . . . . . . . . . 62 139 9.2. Retransmission of Information . . . . . . . . . . . . . . 62 140 9.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 64 141 9.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 64 142 9.4.1. Special Considerations for PMTU Discovery . . . . . . 65 143 9.4.2. Special Considerations for Packetization Layer PMTU 144 Discovery . . . . . . . . . . . . . . . . . . . . . . 66 145 10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 66 146 10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 67 147 10.2. Stream States . . . . . . . . . . . . . . . . . . . . . 68 148 10.2.1. Send Stream States . . . . . . . . . . . . . . . . . 69 149 10.2.2. Receive Stream States . . . . . . . . . . . . . . . 71 150 10.2.3. Permitted Frame Types . . . . . . . . . . . . . . . 74 151 10.2.4. Bidirectional Stream States . . . . . . . . . . . . 74 152 10.3. Solicited State Transitions . . . . . . . . . . . . . . 75 153 10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 76 154 10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 77 155 10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 77 156 11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 78 157 11.1. Edge Cases and Other Considerations . . . . . . . . . . 79 158 11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 80 159 11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 80 160 11.1.3. Handshake Exemption . . . . . . . . . . . . . . . . 81 161 11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 81 162 11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 81 163 11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 82 164 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 82 165 12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 83 166 12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 83 167 12.3. Transport Error Codes . . . . . . . . . . . . . . . . . 84 168 12.4. Application Protocol Error Codes . . . . . . . . . . . . 85 169 13. Security and Privacy Considerations . . . . . . . . . . . . . 85 170 13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 86 171 13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 86 172 13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 87 173 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 87 174 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 175 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 87 176 14.2. QUIC Transport Error Codes Registry . . . . . . . . . . 89 177 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 178 15.1. Normative References . . . . . . . . . . . . . . . . . . 90 179 15.2. Informative References . . . . . . . . . . . . . . . . . 92 180 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 93 181 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 93 182 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 93 183 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 93 184 C.1. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 94 185 C.2. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 94 186 C.3. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 95 187 C.4. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 96 188 C.5. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 96 189 C.6. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 96 190 C.7. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 97 191 C.8. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 97 192 C.9. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 98 193 C.10. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 100 194 C.11. Since draft-hamilton-quic-transport-protocol-01 . . . . . 100 195 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 197 1. Introduction 199 QUIC is a multiplexed and secure transport protocol that runs on top 200 of UDP. QUIC aims to provide a flexible set of features that allow 201 it to be a general-purpose transport for multiple applications. 203 QUIC implements techniques learned from experience with TCP, SCTP and 204 other transport protocols. QUIC uses UDP as substrate so as to not 205 require changes to legacy client operating systems and middleboxes to 206 be deployable. QUIC authenticates all of its headers and encrypts 207 most of the data it exchanges, including its signaling. This allows 208 the protocol to evolve without incurring a dependency on upgrades to 209 middleboxes. This document describes the core QUIC protocol, 210 including the conceptual design, wire format, and mechanisms of the 211 QUIC protocol for connection establishment, stream multiplexing, 212 stream and connection-level flow control, and data reliability. 214 Accompanying documents describe QUIC's loss detection and congestion 215 control [QUIC-RECOVERY], and the use of TLS 1.3 for key negotiation 216 [QUIC-TLS]. 218 QUIC version 1 conforms to the protocol invariants in 219 [QUIC-INVARIANTS]. 221 2. Conventions and Definitions 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 Definitions of terms that are used in this document: 231 Client: The endpoint initiating a QUIC connection. 233 Server: The endpoint accepting incoming QUIC connections. 235 Endpoint: The client or server end of a connection. 237 Stream: A logical, bi-directional channel of ordered bytes within a 238 QUIC connection. 240 Connection: A conversation between two QUIC endpoints with a single 241 encryption context that multiplexes streams within it. 243 Connection ID: The 64-bit unsigned number used as an identifier for 244 a QUIC connection. 246 QUIC packet: A well-formed UDP payload that can be parsed by a QUIC 247 receiver. 249 2.1. Notational Conventions 251 Packet and frame diagrams use the format described in Section 3.1 of 252 [RFC2360], with the following additional conventions: 254 [x] Indicates that x is optional 256 x (A) Indicates that x is A bits long 258 x (A/B/C) ... Indicates that x is one of A, B, or C bits long 260 x (i) ... Indicates that x uses the variable-length encoding in 261 Section 8.1 263 x (*) ... Indicates that x is variable-length 265 3. A QUIC Overview 267 This section briefly describes QUIC's key mechanisms and benefits. 268 Key strengths of QUIC include: 270 o Low-latency connection establishment 272 o Multiplexing without head-of-line blocking 274 o Authenticated and encrypted header and payload 276 o Rich signaling for congestion control and loss recovery 278 o Stream and connection flow control 280 o Connection migration and resilience to NAT rebinding 282 o Version negotiation 284 3.1. Low-Latency Connection Establishment 286 QUIC relies on a combined cryptographic and transport handshake for 287 setting up a secure transport connection. QUIC connections are 288 expected to commonly use 0-RTT handshakes, meaning that for most QUIC 289 connections, data can be sent immediately following the client 290 handshake packet, without waiting for a reply from the server. QUIC 291 provides a dedicated stream (Stream ID 0) to be used for performing 292 the cryptographic handshake and QUIC options negotiation. The format 293 of the QUIC options and parameters used during negotiation are 294 described in this document, but the handshake protocol that runs on 295 Stream ID 0 is described in the accompanying cryptographic handshake 296 draft [QUIC-TLS]. 298 3.2. Stream Multiplexing 300 When application messages are transported over TCP, independent 301 application messages can suffer from head-of-line blocking. When an 302 application multiplexes many streams atop TCP's single-bytestream 303 abstraction, a loss of a TCP segment results in blocking of all 304 subsequent segments until a retransmission arrives, irrespective of 305 the application streams that are encapsulated in subsequent segments. 306 QUIC ensures that lost packets carrying data for an individual stream 307 only impact that specific stream. Data received on other streams can 308 continue to be reassembled and delivered to the application. 310 3.3. Rich Signaling for Congestion Control and Loss Recovery 312 QUIC's packet framing and acknowledgments carry rich information that 313 help both congestion control and loss recovery in fundamental ways. 314 Each QUIC packet carries a new packet number, including those 315 carrying retransmitted data. This obviates the need for a separate 316 mechanism to distinguish acknowledgments for retransmissions from 317 those for original transmissions, avoiding TCP's retransmission 318 ambiguity problem. QUIC acknowledgments also explicitly encode the 319 delay between the receipt of a packet and its acknowledgment being 320 sent, and together with the monotonically-increasing packet numbers, 321 this allows for precise network roundtrip-time (RTT) calculation. 322 QUIC's ACK frames support multiple ACK blocks, so QUIC is more 323 resilient to reordering than TCP with SACK support, as well as able 324 to keep more bytes on the wire when there is reordering or loss. 326 3.4. Stream and Connection Flow Control 328 QUIC implements stream- and connection-level flow control. At a high 329 level, a QUIC receiver advertises the maximum amount of data that it 330 is willing to receive on each stream. As data is sent, received, and 331 delivered on a particular stream, the receiver sends MAX_STREAM_DATA 332 frames that increase the advertised limit for that stream, allowing 333 the peer to send more data on that stream. 335 In addition to this stream-level flow control, QUIC implements 336 connection-level flow control to limit the aggregate buffer that a 337 QUIC receiver is willing to allocate to all streams on a connection. 338 Connection-level flow control works in the same way as stream-level 339 flow control, but the bytes delivered and the limits are aggregated 340 across all streams. 342 3.5. Authenticated and Encrypted Header and Payload 344 TCP headers appear in plaintext on the wire and are not 345 authenticated, causing a plethora of injection and header 346 manipulation issues for TCP, such as receive-window manipulation and 347 sequence-number overwriting. While some of these are mechanisms used 348 by middleboxes to improve TCP performance, others are active attacks. 349 Even "performance-enhancing" middleboxes that routinely interpose on 350 the transport state machine end up limiting the evolvability of the 351 transport protocol, as has been observed in the design of MPTCP 352 [RFC6824] and in its subsequent deployability issues. 354 Generally, QUIC packets are always authenticated and the payload is 355 typically fully encrypted. The parts of the packet header which are 356 not encrypted are still authenticated by the receiver, so as to 357 thwart any packet injection or manipulation by third parties. Some 358 early handshake packets, such as the Version Negotiation packet, are 359 not encrypted, but information sent in these unencrypted handshake 360 packets is later verified as part of cryptographic processing. 362 3.6. Connection Migration and Resilience to NAT Rebinding 364 QUIC connections are identified by a Connection ID, a 64-bit unsigned 365 number randomly generated by the server. QUIC's consistent 366 connection ID allows connections to survive changes to the client's 367 IP and port, such as those caused by NAT rebindings or by the client 368 changing network connectivity to a new address. QUIC provides 369 automatic cryptographic verification of a rebound client, since the 370 client continues to use the same session key for encrypting and 371 decrypting packets. The consistent connection ID can be used to 372 allow migration of the connection to a new server IP address as well, 373 since the Connection ID remains consistent across changes in the 374 client's and the server's network addresses. 376 3.7. Version Negotiation 378 QUIC version negotiation allows for multiple versions of the protocol 379 to be deployed and used concurrently. Version negotiation is 380 described in Section 7.2. 382 4. Versions 384 QUIC versions are identified using a 32-bit unsigned number. 386 The version 0x00000000 is reserved to represent version negotiation. 387 This version of the specification is identified by the number 388 0x00000001. 390 Other versions of QUIC might have different properties to this 391 version. The properties of QUIC that are guaranteed to be consistent 392 across all versions of the protocol are described in 393 [QUIC-INVARIANTS]. 395 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 396 protocol, as described in [QUIC-TLS]. 398 Versions with the most significant 16 bits of the version number 399 cleared are reserved for use in future IETF consensus documents. 401 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 402 forcing version negotiation to be exercised. That is, any version 403 number where the low four bits of all octets is 1010 (in binary). A 404 client or server MAY advertise support for any of these reserved 405 versions. 407 Reserved version numbers will probably never represent a real 408 protocol; a client MAY use one of these version numbers with the 409 expectation that the server will initiate version negotiation; a 410 server MAY advertise support for one of these versions and can expect 411 that clients ignore the value. 413 [[RFC editor: please remove the remainder of this section before 414 publication.]] 416 The version number for the final version of this specification 417 (0x00000001), is reserved for the version of the protocol that is 418 published as an RFC. 420 Version numbers used to identify IETF drafts are created by adding 421 the draft number to 0xff000000. For example, draft-ietf-quic- 422 transport-13 would be identified as 0xff00000D. 424 Implementors are encouraged to register version numbers of QUIC that 425 they are using for private experimentation on the github wiki [4]. 427 5. Packet Types and Formats 429 We first describe QUIC's packet types and their formats, since some 430 are referenced in subsequent mechanisms. 432 All numeric values are encoded in network byte order (that is, big- 433 endian) and all field sizes are in bits. When discussing individual 434 bits of fields, the least significant bit is referred to as bit 0. 435 Hexadecimal notation is used for describing the value of fields. 437 Any QUIC packet has either a long or a short header, as indicated by 438 the Header Form bit. Long headers are expected to be used early in 439 the connection before version negotiation and establishment of 1-RTT 440 keys. Short headers are minimal version-specific headers, which are 441 used after version negotiation and 1-RTT keys are established. 443 5.1. Long Header 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+ 448 |1| Type (7) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 + Connection ID (64) + 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Version (32) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Packet Number (32) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Payload (*) ... 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 1: Long Header Format 463 Long headers are used for packets that are sent prior to the 464 completion of version negotiation and establishment of 1-RTT keys. 465 Once both conditions are met, a sender switches to sending packets 466 using the short header (Section 5.2). The long form allows for 467 special packets - such as the Version Negotiation packet - to be 468 represented in this uniform fixed-length packet format. A long 469 header contains the following fields: 471 Header Form: The most significant bit (0x80) of octet 0 (the first 472 octet) is set to 1 for long headers. 474 Long Packet Type: The remaining seven bits of octet 0 contain the 475 packet type. This field can indicate one of 128 packet types. 476 The types specified for this version are listed in Table 1. 478 Connection ID: Octets 1 through 8 contain the connection ID. 479 Section 5.6 describes the use of this field in more detail. 481 Version: Octets 9 to 12 contain the selected protocol version. This 482 field indicates which version of QUIC is in use and determines how 483 the rest of the protocol fields are interpreted. 485 Packet Number: Octets 13 to 16 contain the packet number. 486 Section 5.7 describes the use of packet numbers. 488 Payload: Octets from 17 onwards (the rest of QUIC packet) are the 489 payload of the packet. 491 The following packet types are defined: 493 +------+-----------------+---------------+ 494 | Type | Name | Section | 495 +------+-----------------+---------------+ 496 | 0x7F | Initial | Section 5.4.1 | 497 | | | | 498 | 0x7E | Retry | Section 5.4.2 | 499 | | | | 500 | 0x7D | Handshake | Section 5.4.3 | 501 | | | | 502 | 0x7C | 0-RTT Protected | Section 5.5 | 503 +------+-----------------+---------------+ 505 Table 1: Long Header Packet Types 507 The header form, packet type, connection ID, packet number and 508 version fields of a long header packet are version-independent. The 509 types of packets defined in Table 1 are version-specific. See 510 [QUIC-INVARIANTS] for details on how packets from different versions 511 of QUIC are interpreted. 513 The interpretation of the fields and the payload are specific to a 514 version and packet type. Type-specific semantics for this version 515 are described in the following sections. 517 5.2. Short Header 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+ 522 |0|C|K|1|0|T T T| 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 + [Connection ID (64)] + 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Packet Number (8/16/32) ... 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Protected Payload (*) ... 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 2: Short Header Format 535 The short header can be used after the version and 1-RTT keys are 536 negotiated. This header form has the following fields: 538 Header Form: The most significant bit (0x80) of octet 0 is set to 0 539 for the short header. 541 Omit Connection ID Flag: The second bit (0x40) of octet 0 indicates 542 whether the Connection ID field is omitted. If set to 0, then the 543 Connection ID field is present; if set to 1, the Connection ID 544 field is omitted. The Connection ID field can only be omitted if 545 the omit_connection_id transport parameter (Section 7.4.1) is 546 specified by the intended recipient of the packet. 548 Key Phase Bit: The third bit (0x20) of octet 0 indicates the key 549 phase, which allows a recipient of a packet to identify the packet 550 protection keys that are used to protect the packet. See 551 [QUIC-TLS] for details. 553 [[Editor's Note: this section should be removed and the bit 554 definitions changed before this draft goes to the IESG.]] 556 Fourth bit: The fourth bit (0x10) of octet 0 is set to 1. 558 [[Editor's Note: this section should be removed and the bit 559 definitions changed before this draft goes to the IESG.]] 561 Google QUIC Demultipexing Bit: The fifth bit (0x8) of octet 0 is set 562 to 0. This allows implementations of Google QUIC to distinguish 563 Google QUIC packets from short header packets sent by a client 564 because Google QUIC servers expect the connection ID to always be 565 present. The special interpretation of this bit SHOULD be removed 566 from this specification when Google QUIC has finished 567 transitioning to the new header format. 569 Short Packet Type: The remaining 3 bits of octet 0 include one of 8 570 packet types. Table 2 lists the types that are defined for short 571 packets. 573 Connection ID: If the Omit Connection ID Flag is not set, a 574 connection ID occupies octets 1 through 8 of the packet. See 575 Section 5.6 for more details. 577 Packet Number: The length of the packet number field depends on the 578 packet type. This field can be 1, 2 or 4 octets long depending on 579 the short packet type. 581 Protected Payload: Packets with a short header always include a 582 1-RTT protected payload. 584 The packet type in a short header currently determines only the size 585 of the packet number field. Additional types can be used to signal 586 the presence of other fields. 588 +------+--------------------+ 589 | Type | Packet Number Size | 590 +------+--------------------+ 591 | 0x0 | 1 octet | 592 | | | 593 | 0x1 | 2 octets | 594 | | | 595 | 0x2 | 4 octets | 596 +------+--------------------+ 598 Table 2: Short Header Packet Types 600 The header form, omit connection ID flag, and connection ID of a 601 short header packet are version-independent. The remaining fields 602 are specific to the selected QUIC version. See [QUIC-INVARIANTS] for 603 details on how packets from different versions of QUIC are 604 interpreted. 606 5.3. Version Negotiation Packet 608 A Version Negotiation packet is inherently not version-specific, and 609 does not use the packet headers defined above. Upon receipt by a 610 client, it will appear to be a packet using the long header, but will 611 be identified as a Version Negotiation packet based on the Version 612 field. 614 The Version Negotiation packet is a response to a client packet that 615 contains a version that is not supported by the server, and is only 616 sent by servers. 618 The layout of a Version Negotiation packet is: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+ 623 |1| Unused (7) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 + Connection ID (64) + 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Version (32) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Supported Version 1 (32) ... 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | [Supported Version 2 (32)] ... 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 ... 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | [Supported Version N (32)] ... 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Figure 3: Version Negotiation Packet 642 The value in the Unused field is selected randomly by the server. 643 The Connection ID field echoes the corresponding value from the 644 triggering client packet. This allows clients some assurance that 645 the server received the packet and that the Version Negotiation 646 packet is in fact from the server. The Version field MUST be set to 647 0x00000000. The remainder of the Version Negotiation packet is a 648 list of 32-bit versions which the server supports. 650 A Version Negotiation packet cannot be explicitly acknowledged in an 651 ACK frame by a client. Receiving another Initial packet implicitly 652 acknowledges a Version Negotiation packet. 654 See Section 7.2 for a description of the version negotiation process. 656 5.4. Cryptographic Handshake Packets 658 Once version negotiation is complete, the cryptographic handshake is 659 used to agree on cryptographic keys. The cryptographic handshake is 660 carried in Initial (Section 5.4.1), Retry (Section 5.4.2) and 661 Handshake (Section 5.4.3) packets. 663 All these packets use the long header and contain the current QUIC 664 version in the version field. 666 In order to prevent tampering by version-unaware middleboxes, 667 handshake packets are protected with a connection- and version- 668 specific key, as described in [QUIC-TLS]. This protection does not 669 provide confidentiality or integrity against on-path attackers, but 670 provides some level of protection against off-path attackers. 672 5.4.1. Initial Packet 674 The Initial packet uses long headers with a type value of 0x7F. It 675 carries the first cryptographic handshake message sent by the client. 677 The client populates the connection ID field with randomly selected 678 values, unless it has received a packet from the server. If the 679 client has received a packet from the server, the connection ID field 680 uses the value provided by the server. 682 The first Initial packet that is sent by a client contains a 683 randomized packet number. All subsequent packets contain a packet 684 number that is incremented by one, see (Section 5.7). 686 The payload of an Initial packet consists of a STREAM frame (or 687 frames) for stream 0 containing a cryptographic handshake message, 688 with enough PADDING frames that the packet is at least 1200 octets 689 (see Section 9). The stream in this packet always starts at an 690 offset of 0 (see Section 7.5) and the complete cryptographic 691 handshake message MUST fit in a single packet (see Section 7.3). 693 The client uses the Initial packet type for any packet that contains 694 an initial cryptographic handshake message. This includes all cases 695 where a new packet containing the initial cryptographic message needs 696 to be created, this includes the packets sent after receiving a 697 Version Negotiation (Section 5.3) or Retry packet (Section 5.4.2). 699 5.4.2. Retry Packet 701 A Retry packet uses long headers with a type value of 0x7E. It 702 carries cryptographic handshake messages and acknowledgments. It is 703 used by a server that wishes to perform a stateless retry (see 704 Section 7.5). 706 The server includes a connection ID of its choice in the connection 707 ID field. The client MUST use this connection ID for any subsequent 708 packets that it sends. 710 The packet number field echoes the packet number field from the 711 triggering client packet. 713 A Retry packet is never explicitly acknowledged in an ACK frame by a 714 client. Receiving another Initial packet implicitly acknowledges a 715 Retry packet. 717 After receiving a Retry packet, the client uses a new Initial packet 718 containing the next cryptographic handshake message. The client 719 retains the state of its cryptographic handshake, but discards all 720 transport state. The Initial packet that is generated in response to 721 a Retry packet includes STREAM frames on stream 0 that start again at 722 an offset of 0. 724 Continuing the cryptographic handshake is necessary to ensure that an 725 attacker cannot force a downgrade of any cryptographic parameters. 726 In addition to continuing the cryptographic handshake, the client 727 MUST remember the results of any version negotiation that occurred 728 (see Section 7.2). The client MAY also retain any observed RTT or 729 congestion state that it has accumulated for the flow, but other 730 transport state MUST be discarded. 732 The payload of the Retry packet contains a single STREAM frame on 733 stream 0 with offset 0 containing the server's cryptographic 734 stateless retry material. It MUST NOT contain any other frames. The 735 next STREAM frame sent by the server will also start at stream offset 736 0. 738 5.4.3. Handshake Packet 740 A Handshake packet uses long headers with a type value of 0x7D. It 741 is used to carry acknowledgments and cryptographic handshake messages 742 from the server and client. 744 The connection ID field in a Handshake packet contains a connection 745 ID that is chosen by the server (see Section 5.6). 747 The first Handshake packet sent by a server contains a randomized 748 packet number. This value is increased for each subsequent packet 749 sent by the server as described in Section 5.7. The client 750 increments the packet number from its previous packet by one for each 751 Handshake packet that it sends (which might be an Initial, 0-RTT 752 Protected, or Handshake packet). 754 Servers MUST NOT send more than three Handshake packets without 755 receiving a packet from a verified source address. Source addresses 756 can be verified through an address validation token, receipt of the 757 final cryptographic message from the client, or by receiving a valid 758 PATH_RESPONSE frame from the client. 760 If the server expects to generate more than three Handshake packets 761 in response to an Initial packet, it SHOULD include a PATH_CHALLENGE 762 frame in each Handshake packet that it sends. After receiving at 763 least one valid PATH_RESPONSE frame, the server can send its 764 remaining Handshake packets. Servers can instead perform address 765 validation using a Retry packet; this requires less state on the 766 server, but could involve additional computational effort depending 767 on implementation choices. 769 The payload of this packet contains STREAM frames and could contain 770 PADDING, ACK, PATH_CHALLENGE, or PATH_RESPONSE frames. 772 5.5. Protected Packets 774 Packets that are protected with 0-RTT keys are sent with long 775 headers; all packets protected with 1-RTT keys are sent with short 776 headers. The different packet types explicitly indicate the 777 encryption level and therefore the keys that are used to remove 778 packet protection. 780 Packets protected with 0-RTT keys use a type value of 0x7C. The 781 connection ID field for a 0-RTT packet is selected by the client. 783 The client can send 0-RTT packets after receiving a Handshake packet 784 (Section 5.4.3), if that packet does not complete the handshake. 785 Even if the client receives a different connection ID in the 786 Handshake packet, it MUST continue to use the connection ID selected 787 by the client for 0-RTT packets, see Section 5.6. 789 The version field for protected packets is the current QUIC version. 791 The packet number field contains a packet number, which increases 792 with each packet sent, see Section 5.7 for details. 794 The payload is protected using authenticated encryption. [QUIC-TLS] 795 describes packet protection in detail. After decryption, the 796 plaintext consists of a sequence of frames, as described in 797 Section 6. 799 5.6. Connection ID 801 QUIC connections are identified by their 64-bit Connection ID. All 802 long headers contain a Connection ID. Short headers indicate the 803 presence of a Connection ID using the Omit Connection ID flag. When 804 present, the Connection ID is in the same location in all packet 805 headers, making it straightforward for middleboxes, such as load 806 balancers, to locate and use it. 808 The client MUST choose a random connection ID and use it in Initial 809 packets (Section 5.4.1) and 0-RTT packets (Section 5.5). 811 When the server receives a Initial packet and decides to proceed with 812 the handshake, it chooses a new value for the connection ID and sends 813 that in a Retry (Section 5.4.2) or Handshake (Section 5.4.3) packet. 814 The server MAY choose to use the value that the client initially 815 selects. 817 Once the client receives the connection ID that the server has 818 chosen, it MUST use it for all subsequent Handshake (Section 5.4.3) 819 and 1-RTT (Section 5.5) packets but not for 0-RTT packets 820 (Section 5.5). 822 Server's Version Negotiation (Section 5.3) and Retry (Section 5.4.2) 823 packets MUST use connection ID selected by the client. 825 5.7. Packet Numbers 827 The packet number is an integer in the range 0 to 2^62-1. The value 828 is used in determining the cryptographic nonce for packet encryption. 829 Each endpoint maintains a separate packet number for sending and 830 receiving. The packet number for sending MUST increase by at least 831 one after sending any packet, unless otherwise specified (see 832 Section 5.7.1). 834 A QUIC endpoint MUST NOT reuse a packet number within the same 835 connection (that is, under the same cryptographic keys). If the 836 packet number for sending reaches 2^62 - 1, the sender MUST close the 837 connection without sending a CONNECTION_CLOSE frame or any further 838 packets; a server MAY send a Stateless Reset (Section 7.9.4) in 839 response to further packets that it receives. 841 For the packet header, the number of bits required to represent the 842 packet number are reduced by including only the least significant 843 bits of the packet number. The actual packet number for each packet 844 is reconstructed at the receiver based on the largest packet number 845 received on a successfully authenticated packet. 847 A packet number is decoded by finding the packet number value that is 848 closest to the next expected packet. The next expected packet is the 849 highest received packet number plus one. For example, if the highest 850 successfully authenticated packet had a packet number of 0xaa82f30e, 851 then a packet containing a 16-bit value of 0x1f94 will be decoded as 852 0xaa831f94. 854 The sender MUST use a packet number size able to represent more than 855 twice as large a range than the difference between the largest 856 acknowledged packet and packet number being sent. A peer receiving 857 the packet will then correctly decode the packet number, unless the 858 packet is delayed in transit such that it arrives after many higher- 859 numbered packets have been received. An endpoint SHOULD use a large 860 enough packet number encoding to allow the packet number to be 861 recovered even if the packet arrives after packets that are sent 862 afterwards. 864 As a result, the size of the packet number encoding is at least one 865 more than the base 2 logarithm of the number of contiguous 866 unacknowledged packet numbers, including the new packet. 868 For example, if an endpoint has received an acknowledgment for packet 869 0x6afa2f, sending a packet with a number of 0x6b4264 requires a 870 16-bit or larger packet number encoding; whereas a 32-bit packet 871 number is needed to send a packet with a number of 0x6bc107. 873 A Version Negotiation packet (Section 5.3) does not include a packet 874 number. The Retry packet (Section 5.4.2) has special rules for 875 populating the packet number field. 877 5.7.1. Initial Packet Number 879 The initial value for packet number MUST be selected randomly from a 880 range between 0 and 2^32 - 1025 (inclusive). This value is selected 881 so that Initial and Handshake packets exercise as many possible 882 values for the Packet Number field as possible. 884 Limiting the range allows both for loss of packets and for any 885 stateless exchanges. Packet numbers are incremented for subsequent 886 packets, but packet loss and stateless handling can both mean that 887 the first packet sent by an endpoint isn't necessarily the first 888 packet received by its peer. The first packet received by a peer 889 cannot be 2^32 or greater or the recipient will incorrectly assume a 890 packet number that is 2^32 values lower and discard the packet. 892 Use of a secure random number generator [RFC4086] is not necessary 893 for generating the initial packet number, nor is it necessary that 894 the value be uniformly distributed. 896 6. Frames and Frame Types 898 The payload of all packets, after removing packet protection, 899 consists of a sequence of frames, as shown in Figure 4. Version 900 Negotiation and Stateless Reset do not contain frames. 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Frame 1 (*) ... 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Frame 2 (*) ... 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 ... 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Frame N (*) ... 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 4: Contents of Protected Payload 916 Protected payloads MUST contain at least one frame, and MAY contain 917 multiple frames and multiple frame types. 919 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 920 packet boundary. Each frame begins with a Frame Type byte, 921 indicating its type, followed by additional type-dependent fields: 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type (8) | Type-Dependent Fields (*) ... 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Figure 5: Generic Frame Layout 931 Frame types are listed in Table 3. Note that the Frame Type byte in 932 STREAM and ACK frames is used to carry other frame-specific flags. 933 For all other frames, the Frame Type byte simply identifies the 934 frame. These frames are explained in more detail as they are 935 referenced later in the document. 937 +-------------+-------------------+--------------+ 938 | Type Value | Frame Type Name | Definition | 939 +-------------+-------------------+--------------+ 940 | 0x00 | PADDING | Section 8.2 | 941 | | | | 942 | 0x01 | RST_STREAM | Section 8.3 | 943 | | | | 944 | 0x02 | CONNECTION_CLOSE | Section 8.4 | 945 | | | | 946 | 0x03 | APPLICATION_CLOSE | Section 8.5 | 947 | | | | 948 | 0x04 | MAX_DATA | Section 8.6 | 949 | | | | 950 | 0x05 | MAX_STREAM_DATA | Section 8.7 | 951 | | | | 952 | 0x06 | MAX_STREAM_ID | Section 8.8 | 953 | | | | 954 | 0x07 | PING | Section 8.9 | 955 | | | | 956 | 0x08 | BLOCKED | Section 8.10 | 957 | | | | 958 | 0x09 | STREAM_BLOCKED | Section 8.11 | 959 | | | | 960 | 0x0a | STREAM_ID_BLOCKED | Section 8.12 | 961 | | | | 962 | 0x0b | NEW_CONNECTION_ID | Section 8.13 | 963 | | | | 964 | 0x0c | STOP_SENDING | Section 8.14 | 965 | | | | 966 | 0x0d | ACK | Section 8.15 | 967 | | | | 968 | 0x0e | PATH_CHALLENGE | Section 8.16 | 969 | | | | 970 | 0x0f | PATH_RESPONSE | Section 8.17 | 971 | | | | 972 | 0x10 - 0x17 | STREAM | Section 8.18 | 973 +-------------+-------------------+--------------+ 975 Table 3: Frame Types 977 7. Life of a Connection 979 A QUIC connection is a single conversation between two QUIC 980 endpoints. QUIC's connection establishment intertwines version 981 negotiation with the cryptographic and transport handshakes to reduce 982 connection establishment latency, as described in Section 7.3. Once 983 established, a connection may migrate to a different IP or port at 984 either endpoint, due to NAT rebinding or mobility, as described in 985 Section 7.7. Finally a connection may be terminated by either 986 endpoint, as described in Section 7.9. 988 7.1. Matching Packets to Connections 990 Incoming packets are classified on receipt. Packets can either be 991 associated with an existing connection, or - for servers - 992 potentially create a new connection. 994 Hosts try to associate the packet with an existing connection. If 995 the packet has a connection ID corresponding to an existing 996 connection, QUIC processes that packet accordingly. Note that a 997 NEW_CONNECTION_ID frame (Section 8.13) would associate more than one 998 connection ID with a connection. 1000 If there is no connection ID, but the packet matches the address/port 1001 tuple of a connection where the host did not require connection IDs, 1002 QUIC processes the packet as part of that connection. Endpoints MUST 1003 drop packets that omit connection IDs if they do not meet both of 1004 these criteria. 1006 7.1.1. Client Packet Handling 1008 If a client receives a packet with an unknown connection ID, and it 1009 matches the tuple of a connection with no received packets, it is a 1010 reply to an Initial packet with a server-generated connection ID and 1011 will be processed accordingly. Clients SHOULD discard any packets 1012 with new connection IDs that do not meet these criteria. 1014 Note that a successfully associated packet may be a Version 1015 Negotiation packet, which is handled in accordance with 1016 Section 7.2.2. 1018 Due to packet reordering or loss, clients might receive packets for a 1019 connection encrypted with a key it has not yet computed. Clients MAY 1020 drop these packets, or MAY buffer them in anticipation of later 1021 packets that allow it to compute the key. 1023 7.1.2. Server Packet Handling 1025 If a server receives a packet that has an unsupported version and 1026 sufficient length to be an Initial packet for some version supported 1027 by the server, it SHOULD send a Version Negotiation packet as 1028 described in Section 7.2.1. Servers MAY rate control these packets 1029 to avoid storms of Version Negotiation packets. 1031 Servers MUST drop other packets that contain unsupported versions. 1033 Packets with a supported version, or no version field, are matched to 1034 a connection as described in Section 7.1. If not matched, the server 1035 continues below. 1037 If the packet is an Initial packet fully conforming with the 1038 specification, the server proceeds with the handshake (Section 7.3). 1039 This commits the server to the version that the client selected. 1041 If a server isn't currently accepting any new connections, it SHOULD 1042 send a Handshake packet containing a CONNECTION_CLOSE frame with 1043 error code SERVER_BUSY. 1045 If the packet is a 0-RTT packet, the server MAY buffer a limited 1046 number of these packets in anticipation of a late-arriving Initial 1047 Packet. Clients are forbidden from sending Handshake packets prior 1048 to receiving a server response, so servers SHOULD ignore any such 1049 packets. 1051 Servers MUST drop incoming packets under all other circumstances. 1052 They SHOULD send a Stateless Reset (Section 7.9.4) if a connection ID 1053 is present in the header. 1055 7.2. Version Negotiation 1057 Version negotiation ensures that client and server agree to a QUIC 1058 version that is mutually supported. A server sends a Version 1059 Negotiation packet in response to each packet that might initiate a 1060 new connection, see Section 7.1 for details. 1062 The size of the first packet sent by a client will determine whether 1063 a server sends a Version Negotiation packet. Clients that support 1064 multiple QUIC versions SHOULD pad their Initial packets to reflect 1065 the largest minimum Initial packet size of all their versions. This 1066 ensures that that the server responds if there are any mutually 1067 supported versions. 1069 7.2.1. Sending Version Negotiation Packets 1071 If the version selected by the client is not acceptable to the 1072 server, the server responds with a Version Negotiation packet 1073 (Section 5.3). This includes a list of versions that the server will 1074 accept. 1076 This system allows a server to process packets with unsupported 1077 versions without retaining state. Though either the Initial packet 1078 or the Version Negotiation packet that is sent in response could be 1079 lost, the client will send new packets until it successfully receives 1080 a response or it abandons the connection attempt. 1082 7.2.2. Handling Version Negotiation Packets 1084 When the client receives a Version Negotiation packet, it first 1085 checks that the connection ID matches the connection ID the client 1086 sent. If this check fails, the packet MUST be discarded. 1088 Once the Version Negotiation packet is determined to be valid, the 1089 client then selects an acceptable protocol version from the list 1090 provided by the server. The client then attempts to create a 1091 connection using that version. Though the contents of the Client 1092 Initial packet the client sends might not change in response to 1093 version negotiation, a client MUST increase the packet number it uses 1094 on every packet it sends. Packets MUST continue to use long headers 1095 and MUST include the new negotiated protocol version. 1097 The client MUST use the long header format and include its selected 1098 version on all packets until it has 1-RTT keys and it has received a 1099 packet from the server which is not a Version Negotiation packet. 1101 A client MUST NOT change the version it uses unless it is in response 1102 to a Version Negotiation packet from the server. Once a client 1103 receives a packet from the server which is not a Version Negotiation 1104 packet, it MUST discard other Version Negotiation packets on the same 1105 connection. Similarly, a client MUST ignore a Version Negotiation 1106 packet if it has already received and acted on a Version Negotiation 1107 packet. 1109 A client MUST ignore a Version Negotiation packet that lists the 1110 client's chosen version. 1112 Version negotiation packets have no cryptographic protection. The 1113 result of the negotiation MUST be revalidated as part of the 1114 cryptographic handshake (see Section 7.4.4). 1116 7.2.3. Using Reserved Versions 1118 For a server to use a new version in the future, clients must 1119 correctly handle unsupported versions. To help ensure this, a server 1120 SHOULD include a reserved version (see Section 4) while generating a 1121 Version Negotiation packet. 1123 The design of version negotiation permits a server to avoid 1124 maintaining state for packets that it rejects in this fashion. The 1125 validation of version negotiation (see Section 7.4.4) only validates 1126 the result of version negotiation, which is the same no matter which 1127 reserved version was sent. A server MAY therefore send different 1128 reserved version numbers in the Version Negotiation Packet and in its 1129 transport parameters. 1131 A client MAY send a packet using a reserved version number. This can 1132 be used to solicit a list of supported versions from a server. 1134 7.3. Cryptographic and Transport Handshake 1136 QUIC relies on a combined cryptographic and transport handshake to 1137 minimize connection establishment latency. QUIC allocates stream 0 1138 for the cryptographic handshake. Version 0x00000001 of QUIC uses TLS 1139 1.3 as described in [QUIC-TLS]; a different QUIC version number could 1140 indicate that a different cryptographic handshake protocol is in use. 1142 QUIC provides this stream with reliable, ordered delivery of data. 1143 In return, the cryptographic handshake provides QUIC with: 1145 o authenticated key exchange, where 1147 * a server is always authenticated, 1149 * a client is optionally authenticated, 1151 * every connection produces distinct and unrelated keys, 1153 * keying material is usable for packet protection for both 0-RTT 1154 and 1-RTT packets, and 1156 * 1-RTT keys have forward secrecy 1158 o authenticated values for the transport parameters of the peer (see 1159 Section 7.4) 1161 o authenticated confirmation of version negotiation (see 1162 Section 7.4.4) 1164 o authenticated negotiation of an application protocol (TLS uses 1165 ALPN [RFC7301] for this purpose) 1167 o for the server, the ability to carry data that provides assurance 1168 that the client can receive packets that are addressed with the 1169 transport address that is claimed by the client (see Section 7.6) 1171 The initial cryptographic handshake message MUST be sent in a single 1172 packet. Any second attempt that is triggered by address validation 1173 MUST also be sent within a single packet. This avoids having to 1174 reassemble a message from multiple packets. Reassembling messages 1175 requires that a server maintain state prior to establishing a 1176 connection, exposing the server to a denial of service risk. 1178 The first client packet of the cryptographic handshake protocol MUST 1179 fit within a 1232 octet QUIC packet payload. This includes overheads 1180 that reduce the space available to the cryptographic handshake 1181 protocol. 1183 Details of how TLS is integrated with QUIC is provided in more detail 1184 in [QUIC-TLS]. 1186 7.4. Transport Parameters 1188 During connection establishment, both endpoints make authenticated 1189 declarations of their transport parameters. These declarations are 1190 made unilaterally by each endpoint. Endpoints are required to comply 1191 with the restrictions implied by these parameters; the description of 1192 each parameter includes rules for its handling. 1194 The format of the transport parameters is the TransportParameters 1195 struct from Figure 6. This is described using the presentation 1196 language from Section 3 of [I-D.ietf-tls-tls13]. 1198 uint32 QuicVersion; 1200 enum { 1201 initial_max_stream_data(0), 1202 initial_max_data(1), 1203 initial_max_stream_id_bidi(2), 1204 idle_timeout(3), 1205 omit_connection_id(4), 1206 max_packet_size(5), 1207 stateless_reset_token(6), 1208 ack_delay_exponent(7), 1209 initial_max_stream_id_uni(8), 1210 (65535) 1211 } TransportParameterId; 1213 struct { 1214 TransportParameterId parameter; 1215 opaque value<0..2^16-1>; 1216 } TransportParameter; 1218 struct { 1219 select (Handshake.msg_type) { 1220 case client_hello: 1221 QuicVersion initial_version; 1223 case encrypted_extensions: 1224 QuicVersion negotiated_version; 1225 QuicVersion supported_versions<4..2^8-4>; 1226 }; 1227 TransportParameter parameters<22..2^16-1>; 1228 } TransportParameters; 1230 Figure 6: Definition of TransportParameters 1232 The "extension_data" field of the quic_transport_parameters extension 1233 defined in [QUIC-TLS] contains a TransportParameters value. TLS 1234 encoding rules are therefore used to encode the transport parameters. 1236 QUIC encodes transport parameters into a sequence of octets, which 1237 are then included in the cryptographic handshake. Once the handshake 1238 completes, the transport parameters declared by the peer are 1239 available. Each endpoint validates the value provided by its peer. 1240 In particular, version negotiation MUST be validated (see 1241 Section 7.4.4) before the connection establishment is considered 1242 properly complete. 1244 Definitions for each of the defined transport parameters are included 1245 in Section 7.4.1. Any given parameter MUST appear at most once in a 1246 given transport parameters extension. An endpoint MUST treat receipt 1247 of duplicate transport parameters as a connection error of type 1248 TRANSPORT_PARAMETER_ERROR. 1250 7.4.1. Transport Parameter Definitions 1252 An endpoint MUST include the following parameters in its encoded 1253 TransportParameters: 1255 initial_max_stream_data (0x0000): The initial stream maximum data 1256 parameter contains the initial value for the maximum data that can 1257 be sent on any newly created stream. This parameter is encoded as 1258 an unsigned 32-bit integer in units of octets. This is equivalent 1259 to an implicit MAX_STREAM_DATA frame (Section 8.7) being sent on 1260 all streams immediately after opening. 1262 initial_max_data (0x0001): The initial maximum data parameter 1263 contains the initial value for the maximum amount of data that can 1264 be sent on the connection. This parameter is encoded as an 1265 unsigned 32-bit integer in units of octets. This is equivalent to 1266 sending a MAX_DATA (Section 8.6) for the connection immediately 1267 after completing the handshake. 1269 idle_timeout (0x0003): The idle timeout is a value in seconds that 1270 is encoded as an unsigned 16-bit integer. The maximum value is 1271 600 seconds (10 minutes). 1273 A server MUST include the following transport parameters: 1275 stateless_reset_token (0x0006): The Stateless Reset Token is used in 1276 verifying a stateless reset, see Section 7.9.4. This parameter is 1277 a sequence of 16 octets. 1279 A client MUST NOT include a stateless reset token. A server MUST 1280 treat receipt of a stateless_reset_token transport parameter as a 1281 connection error of type TRANSPORT_PARAMETER_ERROR. 1283 An endpoint MAY use the following transport parameters: 1285 initial_max_stream_id_bidi (0x0002): The initial maximum stream ID 1286 parameter contains the initial maximum stream number the peer may 1287 initiate for bidirectional streams, encoded as an unsigned 32-bit 1288 integer. This value MUST be a valid bidirectional stream ID for a 1289 peer-initiated stream (that is, the two least significant bits are 1290 set to 0 by a server and to 1 by a client). If an invalid value 1291 is provided, the recipient MUST generate a connection error of 1292 type TRANSPORT_PARAMETER_ERROR. Setting this parameter is 1293 equivalent to sending a MAX_STREAM_ID (Section 8.8) immediately 1294 after completing the handshake. The maximum bidirectional stream 1295 ID is set to 0 if this parameter is absent, preventing the 1296 creation of new bidirectional streams until a MAX_STREAM_ID frame 1297 is sent. Note that a default value of 0 does not prevent the 1298 cryptographic handshake stream (that is, stream 0) from being 1299 used. 1301 initial_max_stream_id_uni (0x0008): The initial maximum stream ID 1302 parameter contains the initial maximum stream number the peer may 1303 initiate for unidirectional streams, encoded as an unsigned 32-bit 1304 integer. The value MUST be a valid unidirectional ID for the 1305 recipient (that is, the two least significant bits are set to 2 by 1306 a server and to 3 by a client). If an invalid value is provided, 1307 the recipient MUST generate a connection error of type 1308 TRANSPORT_PARAMETER_ERROR. Setting this parameter is equivalent 1309 to sending a MAX_STREAM_ID (Section 8.8) immediately after 1310 completing the handshake. The maximum unidirectional stream ID is 1311 set to 0 if this parameter is absent, preventing the creation of 1312 new unidirectional streams until a MAX_STREAM_ID frame is sent. 1314 omit_connection_id (0x0004): The omit connection identifier 1315 parameter indicates that packets sent to the endpoint that 1316 advertises this parameter MAY omit the connection ID in packets 1317 using short header format. This can be used by an endpoint where 1318 it knows that source and destination IP address and port are 1319 sufficient for it to identify a connection. This parameter is 1320 zero length. Absence of this parameter means that the connection 1321 ID MUST be present in every packet sent to this endpoint. 1323 max_packet_size (0x0005): The maximum packet size parameter places a 1324 limit on the size of packets that the endpoint is willing to 1325 receive, encoded as an unsigned 16-bit integer. This indicates 1326 that packets larger than this limit will be dropped. The default 1327 for this parameter is the maximum permitted UDP payload of 65527. 1328 Values below 1200 are invalid. This limit only applies to 1329 protected packets (Section 5.5). 1331 ack_delay_exponent (0x0007): An 8-bit unsigned integer value 1332 indicating an exponent used to decode the ACK Delay field in the 1333 ACK frame, see Section 8.15. If this value is absent, a default 1334 value of 3 is assumed (indicating a multiplier of 8). The default 1335 value is also used for ACK frames that are sent in Initial, 1336 Handshake, and Retry packets. Values above 20 are invalid. 1338 7.4.2. Values of Transport Parameters for 0-RTT 1340 A client that attempts to send 0-RTT data MUST remember the transport 1341 parameters used by the server. The transport parameters that the 1342 server advertises during connection establishment apply to all 1343 connections that are resumed using the keying material established 1344 during that handshake. Remembered transport parameters apply to the 1345 new connection until the handshake completes and new transport 1346 parameters from the server can be provided. 1348 A server can remember the transport parameters that it advertised, or 1349 store an integrity-protected copy of the values in the ticket and 1350 recover the information when accepting 0-RTT data. A server uses the 1351 transport parameters in determining whether to accept 0-RTT data. 1353 A server MAY accept 0-RTT and subsequently provide different values 1354 for transport parameters for use in the new connection. If 0-RTT 1355 data is accepted by the server, the server MUST NOT reduce any limits 1356 or alter any values that might be violated by the client with its 1357 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1358 set values for initial_max_data or initial_max_stream_data that are 1359 smaller than the remembered value of those parameters. Similarly, a 1360 server MUST NOT reduce the value of initial_max_stream_id_bidi or 1361 initial_max_stream_id_uni. 1363 Omitting or setting a zero value for certain transport parameters can 1364 result in 0-RTT data being enabled, but not usable. The following 1365 transport parameters SHOULD be set to non-zero values for 0-RTT: 1366 initial_max_stream_id_bidi, initial_max_stream_id_uni, 1367 initial_max_data, initial_max_stream_data. 1369 A server MUST reject 0-RTT data or even abort a handshake if the 1370 implied values for transport parameters cannot be supported. 1372 7.4.3. New Transport Parameters 1374 New transport parameters can be used to negotiate new protocol 1375 behavior. An endpoint MUST ignore transport parameters that it does 1376 not support. Absence of a transport parameter therefore disables any 1377 optional protocol feature that is negotiated using the parameter. 1379 New transport parameters can be registered according to the rules in 1380 Section 14.1. 1382 7.4.4. Version Negotiation Validation 1384 Though the cryptographic handshake has integrity protection, two 1385 forms of QUIC version downgrade are possible. In the first, an 1386 attacker replaces the QUIC version in the Initial packet. In the 1387 second, a fake Version Negotiation packet is sent by an attacker. To 1388 protect against these attacks, the transport parameters include three 1389 fields that encode version information. These parameters are used to 1390 retroactively authenticate the choice of version (see Section 7.2). 1392 The cryptographic handshake provides integrity protection for the 1393 negotiated version as part of the transport parameters (see 1394 Section 7.4). As a result, attacks on version negotiation by an 1395 attacker can be detected. 1397 The client includes the initial_version field in its transport 1398 parameters. The initial_version is the version that the client 1399 initially attempted to use. If the server did not send a Version 1400 Negotiation packet Section 5.3, this will be identical to the 1401 negotiated_version field in the server transport parameters. 1403 A server that processes all packets in a stateful fashion can 1404 remember how version negotiation was performed and validate the 1405 initial_version value. 1407 A server that does not maintain state for every packet it receives 1408 (i.e., a stateless server) uses a different process. If the 1409 initial_version matches the version of QUIC that is in use, a 1410 stateless server can accept the value. 1412 If the initial_version is different from the version of QUIC that is 1413 in use, a stateless server MUST check that it would have sent a 1414 Version Negotiation packet if it had received a packet with the 1415 indicated initial_version. If a server would have accepted the 1416 version included in the initial_version and the value differs from 1417 the QUIC version that is in use, the server MUST terminate the 1418 connection with a VERSION_NEGOTIATION_ERROR error. 1420 The server includes both the version of QUIC that is in use and a 1421 list of the QUIC versions that the server supports. 1423 The negotiated_version field is the version that is in use. This 1424 MUST be set by the server to the value that is on the Initial packet 1425 that it accepts (not an Initial packet that triggers a Retry or 1426 Version Negotiation packet). A client that receives a 1427 negotiated_version that does not match the version of QUIC that is in 1428 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 1429 error code. 1431 The server includes a list of versions that it would send in any 1432 version negotiation packet (Section 5.3) in the supported_versions 1433 field. The server populates this field even if it did not send a 1434 version negotiation packet. 1436 The client validates that the negotiated_version is included in the 1437 supported_versions list and - if version negotiation was performed - 1438 that it would have selected the negotiated version. A client MUST 1439 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 1440 if the current QUIC version is not listed in the supported_versions 1441 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 1442 code if version negotiation occurred but it would have selected a 1443 different version based on the value of the supported_versions list. 1445 When an endpoint accepts multiple QUIC versions, it can potentially 1446 interpret transport parameters as they are defined by any of the QUIC 1447 versions it supports. The version field in the QUIC packet header is 1448 authenticated using transport parameters. The position and the 1449 format of the version fields in transport parameters MUST either be 1450 identical across different QUIC versions, or be unambiguously 1451 different to ensure no confusion about their interpretation. One way 1452 that a new format could be introduced is to define a TLS extension 1453 with a different codepoint. 1455 7.5. Stateless Retries 1457 A server can process an initial cryptographic handshake messages from 1458 a client without committing any state. This allows a server to 1459 perform address validation (Section 7.6, or to defer connection 1460 establishment costs. 1462 A server that generates a response to an initial packet without 1463 retaining connection state MUST use the Retry packet (Section 5.4.2). 1464 This packet causes a client to reset its transport state and to 1465 continue the connection attempt with new connection state while 1466 maintaining the state of the cryptographic handshake. 1468 A server MUST NOT send multiple Retry packets in response to a client 1469 handshake packet. Thus, any cryptographic handshake message that is 1470 sent MUST fit within a single packet. 1472 In TLS, the Retry packet type is used to carry the HelloRetryRequest 1473 message. 1475 7.6. Proof of Source Address Ownership 1477 Transport protocols commonly spend a round trip checking that a 1478 client owns the transport address (IP and port) that it claims. 1479 Verifying that a client can receive packets sent to its claimed 1480 transport address protects against spoofing of this information by 1481 malicious clients. 1483 This technique is used primarily to avoid QUIC from being used for 1484 traffic amplification attack. In such an attack, a packet is sent to 1485 a server with spoofed source address information that identifies a 1486 victim. If a server generates more or larger packets in response to 1487 that packet, the attacker can use the server to send more data toward 1488 the victim than it would be able to send on its own. 1490 Several methods are used in QUIC to mitigate this attack. Firstly, 1491 the initial handshake packet is padded to at least 1200 octets. This 1492 allows a server to send a similar amount of data without risking 1493 causing an amplification attack toward an unproven remote address. 1495 A server eventually confirms that a client has received its messages 1496 when the cryptographic handshake successfully completes. This might 1497 be insufficient, either because the server wishes to avoid the 1498 computational cost of completing the handshake, or it might be that 1499 the size of the packets that are sent during the handshake is too 1500 large. This is especially important for 0-RTT, where the server 1501 might wish to provide application data traffic - such as a response 1502 to a request - in response to the data carried in the early data from 1503 the client. 1505 To send additional data prior to completing the cryptographic 1506 handshake, the server then needs to validate that the client owns the 1507 address that it claims. 1509 Source address validation is therefore performed during the 1510 establishment of a connection. TLS provides the tools that support 1511 the feature, but basic validation is performed by the core transport 1512 protocol. 1514 A different type of source address validation is performed after a 1515 connection migration, see Section 7.7.2. 1517 7.6.1. Client Address Validation Procedure 1519 QUIC uses token-based address validation. Any time the server wishes 1520 to validate a client address, it provides the client with a token. 1521 As long as the token cannot be easily guessed (see Section 7.6.3), if 1522 the client is able to return that token, it proves to the server that 1523 it received the token. 1525 During the processing of the cryptographic handshake messages from a 1526 client, TLS will request that QUIC make a decision about whether to 1527 proceed based on the information it has. TLS will provide QUIC with 1528 any token that was provided by the client. For an initial packet, 1529 QUIC can decide to abort the connection, allow it to proceed, or 1530 request address validation. 1532 If QUIC decides to request address validation, it provides the 1533 cryptographic handshake with a token. The contents of this token are 1534 consumed by the server that generates the token, so there is no need 1535 for a single well-defined format. A token could include information 1536 about the claimed client address (IP and port), a timestamp, and any 1537 other supplementary information the server will need to validate the 1538 token in the future. 1540 The cryptographic handshake is responsible for enacting validation by 1541 sending the address validation token to the client. A legitimate 1542 client will include a copy of the token when it attempts to continue 1543 the handshake. The cryptographic handshake extracts the token then 1544 asks QUIC a second time whether the token is acceptable. In 1545 response, QUIC can either abort the connection or permit it to 1546 proceed. 1548 A connection MAY be accepted without address validation - or with 1549 only limited validation - but a server SHOULD limit the data it sends 1550 toward an unvalidated address. Successful completion of the 1551 cryptographic handshake implicitly provides proof that the client has 1552 received packets from the server. 1554 7.6.2. Address Validation on Session Resumption 1556 A server MAY provide clients with an address validation token during 1557 one connection that can be used on a subsequent connection. Address 1558 validation is especially important with 0-RTT because a server 1559 potentially sends a significant amount of data to a client in 1560 response to 0-RTT data. 1562 A different type of token is needed when resuming. Unlike the token 1563 that is created during a handshake, there might be some time between 1564 when the token is created and when the token is subsequently used. 1565 Thus, a resumption token SHOULD include an expiration time. It is 1566 also unlikely that the client port number is the same on two 1567 different connections; validating the port is therefore unlikely to 1568 be successful. 1570 This token can be provided to the cryptographic handshake immediately 1571 after establishing a connection. QUIC might also generate an updated 1572 token if significant time passes or the client address changes for 1573 any reason (see Section 7.7). The cryptographic handshake is 1574 responsible for providing the client with the token. In TLS the 1575 token is included in the ticket that is used for resumption and 1576 0-RTT, which is carried in a NewSessionTicket message. 1578 7.6.3. Address Validation Token Integrity 1580 An address validation token MUST be difficult to guess. Including a 1581 large enough random value in the token would be sufficient, but this 1582 depends on the server remembering the value it sends to clients. 1584 A token-based scheme allows the server to offload any state 1585 associated with validation to the client. For this design to work, 1586 the token MUST be covered by integrity protection against 1587 modification or falsification by clients. Without integrity 1588 protection, malicious clients could generate or guess values for 1589 tokens that would be accepted by the server. Only the server 1590 requires access to the integrity protection key for tokens. 1592 In TLS the address validation token is often bundled with the 1593 information that TLS requires, such as the resumption secret. In 1594 this case, adding integrity protection can be delegated to the 1595 cryptographic handshake protocol, avoiding redundant protection. If 1596 integrity protection is delegated to the cryptographic handshake, an 1597 integrity failure will result in immediate cryptographic handshake 1598 failure. If integrity protection is performed by QUIC, QUIC MUST 1599 abort the connection if the integrity check fails with a 1600 PROTOCOL_VIOLATION error code. 1602 7.7. Connection Migration 1604 QUIC connections are identified by their 64-bit Connection ID. 1605 QUIC's consistent connection ID allows connections to survive changes 1606 to the client's IP and/or port, such as those caused by client or 1607 server migrating to a new network. Connection migration allows a 1608 client to retain any shared state with a connection when they move 1609 networks. This includes state that can be hard to recover such as 1610 outstanding requests, which might otherwise be lost with no easy way 1611 to retry them. 1613 An endpoint that receives packets that contain a source IP address 1614 and port that has not yet been used can start sending new packets 1615 with those as a destination IP address and port. Packets exchanged 1616 between endpoints can then follow the new path. 1618 Due to variations in path latency or packet reordering, packets from 1619 different source addresses might be reordered. The packet with the 1620 highest packet number MUST be used to determine which path to use. 1621 Endpoints also need to be prepared to receive packets from an older 1622 source address. 1624 An endpoint MUST validate that its peer can receive packets at the 1625 new address before sending any significant quantity of data to that 1626 address, or it risks being used for denial of service. See 1627 Section 7.7.2 for details. 1629 7.7.1. Privacy Implications of Connection Migration 1631 Using a stable connection ID on multiple network paths allows a 1632 passive observer to correlate activity between those paths. A client 1633 that moves between networks might not wish to have their activity 1634 correlated by any entity other than a server. The NEW_CONNECTION_ID 1635 message can be sent by a server to provide an unlinkable connection 1636 ID for use in case the client wishes to explicitly break linkability 1637 between two points of network attachment. 1639 A client might need to send packets on multiple networks without 1640 receiving any response from the server. To ensure that the client is 1641 not linkable across each of these changes, a new connection ID and 1642 packet number gap are needed for each network. To support this, a 1643 server sends multiple NEW_CONNECTION_ID messages. Each 1644 NEW_CONNECTION_ID is marked with a sequence number. Connection IDs 1645 MUST be used in the order in which they are numbered. 1647 A client which wishes to break linkability upon changing networks 1648 MUST use the connection ID provided by the server as well as 1649 incrementing the packet sequence number by an externally 1650 unpredictable value computed as described in Section 7.7.1.1. Packet 1651 number gaps are cumulative. A client might skip connection IDs, but 1652 it MUST ensure that it applies the associated packet number gaps for 1653 connection IDs that it skips in addition to the packet number gap 1654 associated with the connection ID that it does use. 1656 A server that receives a packet that is marked with a new connection 1657 ID recovers the packet number by adding the cumulative packet number 1658 gap to its expected packet number. A server SHOULD discard packets 1659 that contain a smaller gap than it advertised. 1661 For instance, a server might provide a packet number gap of 7 1662 associated with a new connection ID. If the server received packet 1663 10 using the previous connection ID, it should expect packets on the 1664 new connection ID to start at 18. A packet with the new connection 1665 ID and a packet number of 17 is discarded as being in error. 1667 7.7.1.1. Packet Number Gap 1669 In order to avoid linkage, the packet number gap MUST be externally 1670 indistinguishable from random. The packet number gap for a 1671 connection ID with sequence number is computed by encoding the 1672 sequence number as a 32-bit integer in big-endian format, and then 1673 computing: 1675 Gap = HKDF-Expand-Label(packet_number_secret, 1676 "QUIC packet sequence gap", sequence, 4) 1678 The output of HKDF-Expand-Label is interpreted as a big-endian 1679 number. "packet_number_secret" is derived from the TLS key exchange, 1680 as described in Section 5.6 of [QUIC-TLS]. 1682 7.7.2. Address Validation for Migrated Connections 1684 An endpoint that receives a packet from a new remote IP address and 1685 port (or just a new remote port) on packets from its peer is likely 1686 seeing a connection migration at the peer. 1688 However, it is also possible that the peer is spoofing its source 1689 address in order to cause the endpoint to send excessive amounts of 1690 data to an unwilling host. If the endpoint sends significantly more 1691 data than the peer, connection migration might be used to amplify the 1692 volume of data that an attacker can generate toward a victim. 1694 Thus, when seeing a new remote transport address, an endpoint MUST 1695 verify that its peer can receive and respond to packets at that new 1696 address. By providing copies of the data that it receives, the peer 1697 proves that it is receiving packets at the new address and consents 1698 to receive data. 1700 Prior to validating the new remote address, and endpoint MUST limit 1701 the amount of data and packets that it sends to its peer. At a 1702 minimum, this needs to consider the possibility that packets are sent 1703 without congestion feedback. 1705 Once a connection is established, address validation is relatively 1706 simple (see Section 7.6 for the process that is used during the 1707 handshake). An endpoint validates a remote address by sending a 1708 PATH_CHALLENGE frame containing a payload that is hard to guess. 1709 This frame MUST be sent in a packet that is sent to the new address. 1710 Once a PATH_RESPONSE frame containing the same payload is received, 1711 the address is considered to be valid. 1713 The new address is not considered valid until a PATH_RESPONSE frame 1714 containing the same payload is received, even if the packet 1715 containing the PATH_CHALLENGE frame is acknowledged. 1717 The PATH_RESPONSE frame can use any path on its return. 1719 An endpoint MAY send multiple PATH_CHALLENGE frames to handle packet 1720 loss or to make additional measurements on a new network path. 1722 An endpoint MUST use fresh random data in every PATH_CHALLENGE frame 1723 so that it can associate the peer's response with the causative 1724 PATH_CHALLENGE. 1726 If the PATH_CHALLENGE frame is determined to be lost, a new 1727 PATH_CHALLENGE frame SHOULD be generated. This PATH_CHALLENGE frame 1728 MUST include new data that is similarly difficult to guess. 1730 If validation of the new remote address fails, after allowing enough 1731 time for recovering from possible loss of packets carrying 1732 PATH_CHALLENGE and PATH_RESPONSE frames, the endpoint MUST terminate 1733 the connection. When setting this timer, implementations are 1734 cautioned that the new path could have a longer round trip time than 1735 the original. The endpoint MUST NOT send a CONNECTION_CLOSE frame in 1736 this case; it has to assume that the remote peer cannot want to 1737 receive any more packets. 1739 If the remote address is validated successfully, the endpoint MAY 1740 increase the rate that it sends on the new path using the state from 1741 the previous path. The capacity available on the new path might not 1742 be the same as the old path. An endpoint MUST NOT restore its send 1743 rate unless it is reasonably sure that the path is the same as the 1744 previous path. For instance, a change in only port number is likely 1745 indicative of a rebinding in a middlebox and not a complete change in 1746 path. This determination likely depends on heuristics, which could 1747 be imperfect; if the new path capacity is significantly reduced, 1748 ultimately this relies on the congestion controller responding to 1749 congestion signals and reduce send rates appropriately. 1751 After verifying an address, the endpoint SHOULD update any address 1752 validation tokens (Section 7.6) that it has issued to its peer if 1753 those are no longer valid based on the changed address. 1755 Address validation using the PATH_CHALLENGE frame MAY be used at any 1756 time by either peer. For instance, an endpoint might check that a 1757 peer is still in possession of its address after a period of 1758 quiescence. 1760 Upon seeing a connection migration, an endpoint that sees a new 1761 address MUST abandon any address validation it is performing with 1762 other addresses on the expectation that the validation is likely to 1763 fail. Abandoning address validation primarily means not closing the 1764 connection when a PATH_RESPONSE frame is not received, but it could 1765 also mean ceasing subsequent transmissions of the PATH_CHALLENGE 1766 frame. An endpoint MUST ignore any subsequently received 1767 PATH_RESPONSE frames from that address. 1769 7.8. Spurious Connection Migrations 1771 A connection migration could be triggered by an attacker that is able 1772 to capture and forward a packet such that it arrives before the 1773 legitimate copy of that packet. Such a packet will appear to be a 1774 legitimate connection migration and the legitimate copy will be 1775 dropped as a duplicate. 1777 After a spurious migration, validation of the source address will 1778 fail because the entity at the source address does not have the 1779 necessary cryptographic keys to read or respond to the PATH_CHALLENGE 1780 frame that is sent to it, even if it wanted to. Such a spurious 1781 connection migration could result in the connection being dropped 1782 when the source address validation fails. This grants an attacker 1783 the ability to terminate the connection. 1785 Receipt of packets with higher packet numbers from the legitimate 1786 address will trigger another connection migration. This will cause 1787 the validation of the address of the spurious migration to be 1788 abandoned. 1790 To ensure that a peer sends packets from the legitimate address 1791 before the validation of the new address can fail, an endpoint SHOULD 1792 attempt to validate the old remote address before attempting to 1793 validate the new address. If the connection migration is spurious, 1794 then the legitimate address will be used to respond and the 1795 connection will migrate back to the old address. 1797 As with any address validation, packets containing a PATH_CHALLENGE 1798 frame validating an address MUST be sent to the address being 1799 validated. Consequently, during a migration of a peer, an endpoint 1800 could be sending to multiple remote addresses. 1802 An endpoint MAY abandon address validation for an address that it 1803 considers to be already valid. That is, if successive connection 1804 migrations occur in quick succession with the final remote address 1805 being identical to the initial remote address, the endpoint MAY 1806 abandon address validation for that address. 1808 7.9. Connection Termination 1810 Connections should remain open until they become idle for a pre- 1811 negotiated period of time. A QUIC connection, once established, can 1812 be terminated in one of three ways: 1814 o idle timeout (Section 7.9.2) 1816 o immediate close (Section 7.9.3) 1818 o stateless reset (Section 7.9.4) 1820 7.9.1. Closing and Draining Connection States 1822 The closing and draining connection states exist to ensure that 1823 connections close cleanly and that delayed or reordered packets are 1824 properly discarded. These states SHOULD persist for three times the 1825 current Retransmission Timeout (RTO) interval as defined in 1826 [QUIC-RECOVERY]. 1828 An endpoint enters a closing period after initiating an immediate 1829 close (Section 7.9.3) and optionally after an idle timeout 1830 (Section 7.9.2). While closing, an endpoint MUST NOT send packets 1831 unless they contain a CONNECTION_CLOSE or APPLICATION_CLOSE frame 1832 (see Section 7.9.3 for details). 1834 In the closing state, only a packet containing a closing frame can be 1835 sent. An endpoint retains only enough information to generate a 1836 packet containing a closing frame and to identify packets as 1837 belonging to the connection. The connection ID and QUIC version is 1838 sufficient information to identify packets for a closing connection; 1839 an endpoint can discard all other connection state. An endpoint MAY 1840 retain packet protection keys for incoming packets to allow it to 1841 read and process a closing frame. 1843 The draining state is entered once an endpoint receives a signal that 1844 its peer is closing or draining. While otherwise identical to the 1845 closing state, an endpoint in the draining state MUST NOT send any 1846 packets. Retaining packet protection keys is unnecessary once a 1847 connection is in the draining state. 1849 An endpoint MAY transition from the closing period to the draining 1850 period if it can confirm that its peer is also closing or draining. 1851 Receiving a closing frame is sufficient confirmation, as is receiving 1852 a stateless reset. The draining period SHOULD end when the closing 1853 period would have ended. In other words, the endpoint can use the 1854 same end time, but cease retransmission of the closing packet. 1856 Disposing of connection state prior to the end of the closing or 1857 draining period could cause delayed or reordered packets to be 1858 handled poorly. Endpoints that have some alternative means to ensure 1859 that late-arriving packets on the connection do not create QUIC 1860 state, such as those that are able to close the UDP socket, MAY use 1861 an abbreviated draining period which can allow for faster resource 1862 recovery. Servers that retain an open socket for accepting new 1863 connections SHOULD NOT exit the closing or draining period early. 1865 Once the closing or draining period has ended, an endpoint SHOULD 1866 discard all connection state. This results in new packets on the 1867 connection being handled generically. For instance, an endpoint MAY 1868 send a stateless reset in response to any further incoming packets. 1870 The draining and closing periods do not apply when a stateless reset 1871 (Section 7.9.4) is sent. 1873 An endpoint is not expected to handle key updates when it is closing 1874 or draining. A key update might prevent the endpoint from moving 1875 from the closing state to draining, but it otherwise has no impact. 1877 An endpoint could receive packets from a new source address, 1878 indicating a connection migration (Section 7.7), while in the closing 1879 period. An endpoint in the closing state MUST strictly limit the 1880 number of packets it sends to this new address as though the address 1881 were not validated (see Section 7.7.2). A server in the closing 1882 state MAY instead choose to discard packets received from a new 1883 source address. 1885 7.9.2. Idle Timeout 1887 A connection that remains idle for longer than the idle timeout (see 1888 Section 7.4.1) is closed. A connection enters the draining state 1889 when the idle timeout expires. 1891 The time at which an idle timeout takes effect won't be perfectly 1892 synchronized on both endpoints. An endpoint that sends packets near 1893 the end of an idle period could have those packets discarded if its 1894 peer enters the draining state before the packet is received. 1896 7.9.3. Immediate Close 1898 An endpoint sends a closing frame, either CONNECTION_CLOSE or 1899 APPLICATION_CLOSE, to terminate the connection immediately. Either 1900 closing frame causes all streams to immediately become closed; open 1901 streams can be assumed to be implicitly reset. 1903 After sending a closing frame, endpoints immediately enter the 1904 closing state. During the closing period, an endpoint that sends a 1905 closing frame SHOULD respond to any packet that it receives with 1906 another packet containing a closing frame. To minimize the state 1907 that an endpoint maintains for a closing connection, endpoints MAY 1908 send the exact same packet. However, endpoints SHOULD limit the 1909 number of packets they generate containing a closing frame. For 1910 instance, an endpoint could progressively increase the number of 1911 packets that it receives before sending additional packets or 1912 increase the time between packets. 1914 Note: Allowing retransmission of a packet contradicts other advice 1915 in this document that recommends the creation of new packet 1916 numbers for every packet. Sending new packet numbers is primarily 1917 of advantage to loss recovery and congestion control, which are 1918 not expected to be relevant for a closed connection. 1919 Retransmitting the final packet requires less state. 1921 After receiving a closing frame, endpoints enter the draining state. 1922 An endpoint that receives a closing frame MAY send a single packet 1923 containing a closing frame before entering the draining state, using 1924 a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An 1925 endpoint MUST NOT send further packets, which could result in a 1926 constant exchange of closing frames until the closing period on 1927 either peer ended. 1929 An immediate close can be used after an application protocol has 1930 arranged to close a connection. This might be after the application 1931 protocols negotiates a graceful shutdown. The application protocol 1932 exchanges whatever messages that are needed to cause both endpoints 1933 to agree to close the connection, after which the application 1934 requests that the connection be closed. The application protocol can 1935 use an APPLICATION_CLOSE message with an appropriate error code to 1936 signal closure. 1938 7.9.4. Stateless Reset 1940 A stateless reset is provided as an option of last resort for a 1941 server that does not have access to the state of a connection. A 1942 server crash or outage might result in clients continuing to send 1943 data to a server that is unable to properly continue the connection. 1944 A server that wishes to communicate a fatal connection error MUST use 1945 a closing frame if it has sufficient state to do so. 1947 To support this process, the server sends a stateless_reset_token 1948 value during the handshake in the transport parameters. This value 1949 is protected by encryption, so only client and server know this 1950 value. 1952 A server that receives packets that it cannot process sends a packet 1953 in the following layout: 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+ 1958 |0|C|K|Type (5) | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | | 1961 + [Connection ID (64)] + 1962 | | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | Packet Number (8/16/32) | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Random Octets (*) ... 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | | 1969 + + 1970 | | 1971 + Stateless Reset Token (128) + 1972 | | 1973 + + 1974 | | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 A server copies the connection ID field from the packet that triggers 1978 the stateless reset. A server omits the connection ID if explicitly 1979 configured to do so, or if the client packet did not include a 1980 connection ID. 1982 The Packet Number field is set to a randomized value. The server 1983 SHOULD send a packet with a short header and a type of 0x1F. This 1984 produces the shortest possible packet number encoding, which 1985 minimizes the perceived gap between the last packet that the server 1986 sent and this packet. A server MAY use a different short header 1987 type, indicating a different packet number length, but a longer 1988 packet number encoding might allow this message to be identified as a 1989 stateless reset more easily using heuristics. 1991 After the Packet Number, the server pads the message with an 1992 arbitrary number of octets containing random values. 1994 Finally, the last 16 octets of the packet are set to the value of the 1995 Stateless Reset Token. 1997 This design ensures that a stateless reset packet is - to the extent 1998 possible - indistinguishable from a regular packet. 2000 A stateless reset is not appropriate for signaling error conditions. 2001 An endpoint that wishes to communicate a fatal connection error MUST 2002 use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has 2003 sufficient state to do so. 2005 This stateless reset design is specific to QUIC version 1. A server 2006 that supports multiple versions of QUIC needs to generate a stateless 2007 reset that will be accepted by clients that support any version that 2008 the server might support (or might have supported prior to losing 2009 state). Designers of new versions of QUIC need to be aware of this 2010 and either reuse this design, or use a portion of the packet other 2011 than the last 16 octets for carrying data. 2013 7.9.4.1. Detecting a Stateless Reset 2015 A client detects a potential stateless reset when a packet with a 2016 short header either cannot be decrypted or is marked as a duplicate 2017 packet. The client then compares the last 16 octets of the packet 2018 with the Stateless Reset Token provided by the server in its 2019 transport parameters. If these values are identical, the client MUST 2020 enter the draining period and not send any further packets on this 2021 connection. If the comparison fails, the packet can be discarded. 2023 7.9.4.2. Calculating a Stateless Reset Token 2025 The stateless reset token MUST be difficult to guess. In order to 2026 create a Stateless Reset Token, a server could randomly generate 2027 [RFC4086] a secret for every connection that it creates. However, 2028 this presents a coordination problem when there are multiple servers 2029 in a cluster or a storage problem for a server that might lose state. 2030 Stateless reset specifically exists to handle the case where state is 2031 lost, so this approach is suboptimal. 2033 A single static key can be used across all connections to the same 2034 endpoint by generating the proof using a second iteration of a 2035 preimage-resistant function that takes three inputs: the static key, 2036 a the connection ID for the connection (see Section 5.6), and an 2037 identifier for the server instance. A server could use HMAC 2038 [RFC2104] (for example, HMAC(static_key, server_id || connection_id)) 2039 or HKDF [RFC5869] (for example, using the static key as input keying 2040 material, with server and connection identifiers as salt). The 2041 output of this function is truncated to 16 octets to produce the 2042 Stateless Reset Token for that connection. 2044 A server that loses state can use the same method to generate a valid 2045 Stateless Reset Secret. The connection ID comes from the packet that 2046 the server receives. 2048 This design relies on the client always sending a connection ID in 2049 its packets so that the server can use the connection ID from a 2050 packet to reset the connection. A server that uses this design 2051 cannot allow clients to omit a connection ID (that is, it cannot use 2052 the truncate_connection_id transport parameter Section 7.4.1). 2054 Revealing the Stateless Reset Token allows any entity to terminate 2055 the connection, so a value can only be used once. This method for 2056 choosing the Stateless Reset Token means that the combination of 2057 server instance, connection ID, and static key cannot occur for 2058 another connection. A connection ID from a connection that is reset 2059 by revealing the Stateless Reset Token cannot be reused for new 2060 connections at the same server without first changing to use a 2061 different static key or server identifier. 2063 Note that Stateless Reset messages do not have any cryptographic 2064 protection. 2066 8. Frame Types and Formats 2068 As described in Section 6, packets contain one or more frames. This 2069 section describes the format and semantics of the core QUIC frame 2070 types. 2072 8.1. Variable-Length Integer Encoding 2074 QUIC frames use a common variable-length encoding for all non- 2075 negative integer values. This encoding ensures that smaller integer 2076 values need fewer octets to encode. 2078 The QUIC variable-length integer encoding reserves the two most 2079 significant bits of the first octet to encode the base 2 logarithm of 2080 the integer encoding length in octets. The integer value is encoded 2081 on the remaining bits, in network byte order. 2083 This means that integers are encoded on 1, 2, 4, or 8 octets and can 2084 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 2085 the encoding properties. 2087 +------+--------+-------------+-----------------------+ 2088 | 2Bit | Length | Usable Bits | Range | 2089 +------+--------+-------------+-----------------------+ 2090 | 00 | 1 | 6 | 0-63 | 2091 | | | | | 2092 | 01 | 2 | 14 | 0-16383 | 2093 | | | | | 2094 | 10 | 4 | 30 | 0-1073741823 | 2095 | | | | | 2096 | 11 | 8 | 62 | 0-4611686018427387903 | 2097 +------+--------+-------------+-----------------------+ 2099 Table 4: Summary of Integer Encodings 2101 For example, the eight octet sequence c2 19 7c 5e ff 14 e8 8c (in 2102 hexadecimal) decodes to the decimal value 151288809941952652; the 2103 four octet sequence 9d 7f 3e 7d decodes to 494878333; the two octet 2104 sequence 7b bd decodes to 15293; and the single octet 25 decodes to 2105 37 (as does the two octet sequence 40 25). 2107 Error codes (Section 12.3) are described using integers, but do not 2108 use this encoding. 2110 8.2. PADDING Frame 2112 The PADDING frame (type=0x00) has no semantic value. PADDING frames 2113 can be used to increase the size of a packet. Padding can be used to 2114 increase an initial client packet to the minimum required size, or to 2115 provide protection against traffic analysis for protected packets. 2117 A PADDING frame has no content. That is, a PADDING frame consists of 2118 the single octet that identifies the frame as a PADDING frame. 2120 8.3. RST_STREAM Frame 2122 An endpoint may use a RST_STREAM frame (type=0x01) to abruptly 2123 terminate a stream. 2125 After sending a RST_STREAM, an endpoint ceases transmission and 2126 retransmission of STREAM frames on the identified stream. A receiver 2127 of RST_STREAM can discard any data that it already received on that 2128 stream. 2130 An endpoint that receives a RST_STREAM frame for a send-only stream 2131 MUST terminate the connection with error PROTOCOL_VIOLATION. 2133 The RST_STREAM frame is as follows: 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Stream ID (i) ... 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Application Error Code (16) | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | Final Offset (i) ... 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 The fields are: 2147 Stream ID: A variable-length integer encoding of the Stream ID of 2148 the stream being terminated. 2150 Application Protocol Error Code: A 16-bit application protocol error 2151 code (see Section 12.4) which indicates why the stream is being 2152 closed. 2154 Final Offset: A variable-length integer indicating the absolute byte 2155 offset of the end of data written on this stream by the RST_STREAM 2156 sender. 2158 8.4. CONNECTION_CLOSE frame 2160 An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its 2161 peer that the connection is being closed. CONNECTION_CLOSE is used 2162 to signal errors at the QUIC layer, or the absence of errors (with 2163 the NO_ERROR code). 2165 If there are open streams that haven't been explicitly closed, they 2166 are implicitly closed when the connection is closed. 2168 The CONNECTION_CLOSE frame is as follows: 2170 0 1 2 3 2171 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 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Error Code (16) | Reason Phrase Length (i) ... 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Reason Phrase (*) ... 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 The fields of a CONNECTION_CLOSE frame are as follows: 2180 Error Code: A 16-bit error code which indicates the reason for 2181 closing this connection. CONNECTION_CLOSE uses codes from the 2182 space defined in Section 12.3 (APPLICATION_CLOSE uses codes from 2183 the application protocol error code space, see Section 12.4). 2185 Reason Phrase Length: A variable-length integer specifying the 2186 length of the reason phrase in bytes. Note that a 2187 CONNECTION_CLOSE frame cannot be split between packets, so in 2188 practice any limits on packet size will also limit the space 2189 available for a reason phrase. 2191 Reason Phrase: A human-readable explanation for why the connection 2192 was closed. This can be zero length if the sender chooses to not 2193 give details beyond the Error Code. This SHOULD be a UTF-8 2194 encoded string [RFC3629]. 2196 8.5. APPLICATION_CLOSE frame 2198 An APPLICATION_CLOSE frame (type=0x03) uses the same format as the 2199 CONNECTION_CLOSE frame (Section 8.4), except that it uses error codes 2200 from the application protocol error code space (Section 12.4) instead 2201 of the transport error code space. 2203 Other than the error code space, the format and semantics of the 2204 APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame. 2206 8.6. MAX_DATA Frame 2208 The MAX_DATA frame (type=0x04) is used in flow control to inform the 2209 peer of the maximum amount of data that can be sent on the connection 2210 as a whole. 2212 The frame is as follows: 2214 0 1 2 3 2215 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 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | Maximum Data (i) ... 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 The fields in the MAX_DATA frame are as follows: 2222 Maximum Data: A variable-length integer indicating the maximum 2223 amount of data that can be sent on the entire connection, in units 2224 of octets. 2226 All data sent in STREAM frames counts toward this limit, with the 2227 exception of data on stream 0. The sum of the largest received 2228 offsets on all streams - including streams in terminal states, but 2229 excluding stream 0 - MUST NOT exceed the value advertised by a 2230 receiver. An endpoint MUST terminate a connection with a 2231 QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more 2232 data than the maximum data value that it has sent, unless this is a 2233 result of a change in the initial limits (see Section 7.4.2). 2235 8.7. MAX_STREAM_DATA Frame 2237 The MAX_STREAM_DATA frame (type=0x05) is used in flow control to 2238 inform a peer of the maximum amount of data that can be sent on a 2239 stream. 2241 An endpoint that receives a MAX_STREAM_DATA frame for a receive-only 2242 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 2244 An endpoint that receives a MAX_STREAM_DATA frame for a send-only 2245 stream it has not opened MUST terminate the connection with error 2246 PROTOCOL_VIOLATION. 2248 Note that an endpoint may legally receive a MAX_STREAM_DATA frame on 2249 a bidirectional stream it has not opened. 2251 The frame is as follows: 2253 0 1 2 3 2254 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 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | Stream ID (i) ... 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | Maximum Stream Data (i) ... 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 The fields in the MAX_STREAM_DATA frame are as follows: 2263 Stream ID: The stream ID of the stream that is affected encoded as a 2264 variable-length integer. 2266 Maximum Stream Data: A variable-length integer indicating the 2267 maximum amount of data that can be sent on the identified stream, 2268 in units of octets. 2270 When counting data toward this limit, an endpoint accounts for the 2271 largest received offset of data that is sent or received on the 2272 stream. Loss or reordering can mean that the largest received offset 2273 on a stream can be greater than the total size of data received on 2274 that stream. Receiving STREAM frames might not increase the largest 2275 received offset. 2277 The data sent on a stream MUST NOT exceed the largest maximum stream 2278 data value advertised by the receiver. An endpoint MUST terminate a 2279 connection with a FLOW_CONTROL_ERROR error if it receives more data 2280 than the largest maximum stream data that it has sent for the 2281 affected stream, unless this is a result of a change in the initial 2282 limits (see Section 7.4.2). 2284 8.8. MAX_STREAM_ID Frame 2286 The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum 2287 stream ID that they are permitted to open. 2289 The frame is as follows: 2291 0 1 2 3 2292 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 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | Maximum Stream ID (i) ... 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 The fields in the MAX_STREAM_ID frame are as follows: 2299 Maximum Stream ID: ID of the maximum unidirectional or bidirectional 2300 peer-initiated stream ID for the connection encoded as a variable- 2301 length integer. The limit applies to unidirectional steams if the 2302 second least signification bit of the stream ID is 1, and applies 2303 to bidirectional streams if it is 0. 2305 Loss or reordering can mean that a MAX_STREAM_ID frame can be 2306 received which states a lower stream limit than the client has 2307 previously received. MAX_STREAM_ID frames which do not increase the 2308 maximum stream ID MUST be ignored. 2310 A peer MUST NOT initiate a stream with a higher stream ID than the 2311 greatest maximum stream ID it has received. An endpoint MUST 2312 terminate a connection with a STREAM_ID_ERROR error if a peer 2313 initiates a stream with a higher stream ID than it has sent, unless 2314 this is a result of a change in the initial limits (see 2315 Section 7.4.2). 2317 8.9. PING Frame 2319 Endpoints can use PING frames (type=0x07) to verify that their peers 2320 are still alive or to check reachability to the peer. The PING frame 2321 contains no additional fields. 2323 The receiver of a PING frame simply needs to acknowledge the packet 2324 containing this frame. 2326 The PING frame can be used to keep a connection alive when an 2327 application or application protocol wishes to prevent the connection 2328 from timing out. An application protocol SHOULD provide guidance 2329 about the conditions under which generating a PING is recommended. 2330 This guidance SHOULD indicate whether it is the client or the server 2331 that is expected to send the PING. Having both endpoints send PING 2332 frames without coordination can produce an excessive number of 2333 packets and poor performance. 2335 A connection will time out if no packets are sent or received for a 2336 period longer than the time specified in the idle_timeout transport 2337 parameter (see Section 7.9). However, state in middleboxes might 2338 time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 2339 minute timeout interval, experience shows that sending packets every 2340 15 to 30 seconds is necessary to prevent the majority of middleboxes 2341 from losing state for UDP flows. 2343 8.10. BLOCKED Frame 2345 A sender SHOULD send a BLOCKED frame (type=0x08) when it wishes to 2346 send data, but is unable to due to connection-level flow control (see 2347 Section 11.2.1). BLOCKED frames can be used as input to tuning of 2348 flow control algorithms (see Section 11.1.2). 2350 The BLOCKED frame is as follows: 2352 0 1 2 3 2353 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 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | Offset (i) ... 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 The BLOCKED frame contains a single field. 2360 Offset: A variable-length integer indicating the connection-level 2361 offset at which the blocking occurred. 2363 8.11. STREAM_BLOCKED Frame 2365 A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it 2366 wishes to send data, but is unable to due to stream-level flow 2367 control. This frame is analogous to BLOCKED (Section 8.10). 2369 An endpoint that receives a STREAM_BLOCKED frame for a send-only 2370 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 2372 The STREAM_BLOCKED frame is as follows: 2374 0 1 2 3 2375 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 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | Stream ID (i) ... 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | Offset (i) ... 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 The STREAM_BLOCKED frame contains two fields: 2384 Stream ID: A variable-length integer indicating the stream which is 2385 flow control blocked. 2387 Offset: A variable-length integer indicating the offset of the 2388 stream at which the blocking occurred. 2390 8.12. STREAM_ID_BLOCKED Frame 2392 A sender MAY send a STREAM_ID_BLOCKED frame (type=0x0a) when it 2393 wishes to open a stream, but is unable to due to the maximum stream 2394 ID limit set by its peer (see Section 8.8). This does not open the 2395 stream, but informs the peer that a new stream was needed, but the 2396 stream limit prevented the creation of the stream. 2398 The STREAM_ID_BLOCKED frame is as follows: 2400 0 1 2 3 2401 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 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | Stream ID (i) ... 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 The STREAM_ID_BLOCKED frame contains a single field. 2408 Stream ID: A variable-length integer indicating the highest stream 2409 ID that the sender was permitted to open. 2411 8.13. NEW_CONNECTION_ID Frame 2413 A server sends a NEW_CONNECTION_ID frame (type=0x0b) to provide the 2414 client with alternative connection IDs that can be used to break 2415 linkability when migrating connections (see Section 7.7.1). 2417 The NEW_CONNECTION_ID is as follows: 2419 0 1 2 3 2420 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 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | Sequence (i) ... 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | | 2425 + Connection ID (64) + 2426 | | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | | 2429 + + 2430 | | 2431 + Stateless Reset Token (128) + 2432 | | 2433 + + 2434 | | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 The fields are: 2439 Sequence: A variable-length integer. This value starts at 0 and 2440 increases by 1 for each connection ID that is provided by the 2441 server. The connection ID that is assigned during the handshake 2442 is assumed to have a sequence of -1. That is, the value selected 2443 during the handshake comes immediately before the first value that 2444 a server can send. 2446 Connection ID: A 64-bit connection ID. 2448 Stateless Reset Token: A 128-bit value that will be used to for a 2449 stateless reset when the associated connection ID is used (see 2450 Section 7.9.4). 2452 8.14. STOP_SENDING Frame 2454 An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate 2455 that incoming data is being discarded on receipt at application 2456 request. This signals a peer to abruptly terminate transmission on a 2457 stream. 2459 An endpoint that receives a STOP_SENDING frame for a receive-only 2460 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 2462 The STOP_SENDING frame is as follows: 2464 0 1 2 3 2465 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 2466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 | Stream ID (i) ... 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | Application Error Code (16) | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 The fields are: 2474 Stream ID: A variable-length integer carrying the Stream ID of the 2475 stream being ignored. 2477 Application Error Code: A 16-bit, application-specified reason the 2478 sender is ignoring the stream (see Section 12.4). 2480 8.15. ACK Frame 2482 Receivers send ACK frames (type=0x0d) to inform senders which packets 2483 they have received and processed. A sent packet that has never been 2484 acknowledged is missing. The ACK frame contains any number of ACK 2485 blocks. ACK blocks are ranges of acknowledged packets. 2487 Unlike TCP SACKs, QUIC acknowledgements are irrevocable. Once a 2488 packet has been acknowledged, even if it does not appear in a future 2489 ACK frame, it remains acknowledged. 2491 A client MUST NOT acknowledge Retry packets. Retry packets include 2492 the packet number from the Initial packet it responds to. Version 2493 Negotiation packets cannot be acknowledged because they do not 2494 contain a packet number. Rather than relying on ACK frames, these 2495 packets are implicitly acknowledged by the next Initial packet sent 2496 by the client. 2498 A sender MAY intentionally skip packet numbers to introduce entropy 2499 into the connection, to avoid opportunistic acknowledgement attacks. 2500 The sender SHOULD close the connection if an unsent packet number is 2501 acknowledged. The format of the ACK frame is efficient at expressing 2502 even long blocks of missing packets, allowing for large, 2503 unpredictable gaps. 2505 An ACK frame is shown below. 2507 0 1 2 3 2508 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 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | Largest Acknowledged (i) ... 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | ACK Delay (i) ... 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | ACK Block Count (i) ... 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | ACK Blocks (*) ... 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 Figure 7: ACK Frame Format 2521 The fields in the ACK frame are as follows: 2523 Largest Acknowledged: A variable-length integer representing the 2524 largest packet number the peer is acknowledging; this is usually 2525 the largest packet number that the peer has received prior to 2526 generating the ACK frame. Unlike the packet number in the QUIC 2527 long or short header, the value in an ACK frame is not truncated. 2529 ACK Delay: A variable-length integer including the time in 2530 microseconds that the largest acknowledged packet, as indicated in 2531 the Largest Acknowledged field, was received by this peer to when 2532 this ACK was sent. The value of the ACK Delay field is scaled by 2533 multiplying the encoded value by the 2 to the power of the value 2534 of the "ack_delay_exponent" transport parameter set by the sender 2535 of the ACK frame. The "ack_delay_exponent" defaults to 3, or a 2536 multiplier of 8 (see Section 7.4.1). Scaling in this fashion 2537 allows for a larger range of values with a shorter encoding at the 2538 cost of lower resolution. 2540 ACK Block Count: The number of Additional ACK Block (and Gap) fields 2541 after the First ACK Block. 2543 ACK Blocks: Contains one or more blocks of packet numbers which have 2544 been successfully received, see Section 8.15.1. 2546 8.15.1. ACK Block Section 2548 The ACK Block Section consists of alternating Gap and ACK Block 2549 fields in descending packet number order. A First Ack Block field is 2550 followed by a variable number of alternating Gap and Additional ACK 2551 Blocks. The number of Gap and Additional ACK Block fields is 2552 determined by the ACK Block Count field. 2554 Gap and ACK Block fields use a relative integer encoding for 2555 efficiency. Though each encoded value is positive, the values are 2556 subtracted, so that each ACK Block describes progressively lower- 2557 numbered packets. As long as contiguous ranges of packets are small, 2558 the variable-length integer encoding ensures that each range can be 2559 expressed in a small number of octets. 2561 0 1 2 3 2562 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 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | First ACK Block (i) ... 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Gap (i) ... 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Additional ACK Block (i) ... 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 | Gap (i) ... 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | Additional ACK Block (i) ... 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 ... 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | Gap (i) ... 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Additional ACK Block (i) ... 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 Figure 8: ACK Block Section 2583 Each ACK Block acknowledges a contiguous range of packets by 2584 indicating the number of acknowledged packets that precede the 2585 largest packet number in that block. A value of zero indicates that 2586 only the largest packet number is acknowledged. Larger ACK Block 2587 values indicate a larger range, with corresponding lower values for 2588 the smallest packet number in the range. Thus, given a largest 2589 packet number for the ACK, the smallest value is determined by the 2590 formula: 2592 smallest = largest - ack_block 2594 The range of packets that are acknowledged by the ACK block include 2595 the range from the smallest packet number to the largest, inclusive. 2597 The largest value for the First ACK Block is determined by the 2598 Largest Acknowledged field; the largest for Additional ACK Blocks is 2599 determined by cumulatively subtracting the size of all preceding ACK 2600 Blocks and Gaps. 2602 Each Gap indicates a range of packets that are not being 2603 acknowledged. The number of packets in the gap is one higher than 2604 the encoded value of the Gap Field. 2606 The value of the Gap field establishes the largest packet number 2607 value for the ACK block that follows the gap using the following 2608 formula: 2610 largest = previous_smallest - gap - 2 2612 If the calculated value for largest or smallest packet number for any 2613 ACK Block is negative, an endpoint MUST generate a connection error 2614 of type FRAME_ERROR indicating an error in an ACK frame (that is, 2615 0x10d). 2617 The fields in the ACK Block Section are: 2619 First ACK Block: A variable-length integer indicating the number of 2620 contiguous packets preceding the Largest Acknowledged that are 2621 being acknowledged. 2623 Gap (repeated): A variable-length integer indicating the number of 2624 contiguous unacknowledged packets preceding the packet number one 2625 lower than the smallest in the preceding ACK Block. 2627 ACK Block (repeated): A variable-length integer indicating the 2628 number of contiguous acknowledged packets preceding the largest 2629 packet number, as determined by the preceding Gap. 2631 8.15.2. Sending ACK Frames 2633 Implementations MUST NOT generate packets that only contain ACK 2634 frames in response to packets which only contain ACK frames. 2635 However, they MUST acknowledge packets containing only ACK frames 2636 when sending ACK frames in response to other packets. 2637 Implementations MUST NOT send more than one ACK frame per received 2638 packet that contains frames other than ACK frames. Packets 2639 containing non-ACK frames MUST be acknowledged immediately or when a 2640 delayed ack timer expires. 2642 To limit ACK blocks to those that have not yet been received by the 2643 sender, the receiver SHOULD track which ACK frames have been 2644 acknowledged by its peer. Once an ACK frame has been acknowledged, 2645 the packets it acknowledges SHOULD NOT be acknowledged again. 2647 A receiver that is only sending ACK frames will not receive 2648 acknowledgments for its packets. Sending an occasional MAX_DATA or 2649 MAX_STREAM_DATA frame as data is received will ensure that 2650 acknowledgements are generated by a peer. Otherwise, an endpoint MAY 2651 send a PING frame once per RTT to solicit an acknowledgment. 2653 To limit receiver state or the size of ACK frames, a receiver MAY 2654 limit the number of ACK blocks it sends. A receiver can do this even 2655 without receiving acknowledgment of its ACK frames, with the 2656 knowledge this could cause the sender to unnecessarily retransmit 2657 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 2658 lost after sufficiently newer packets are acknowledged. Therefore, 2659 the receiver SHOULD repeatedly acknowledge newly received packets in 2660 preference to packets received in the past. 2662 8.15.3. ACK Frames and Packet Protection 2664 ACK frames that acknowledge protected packets MUST be carried in a 2665 packet that has an equivalent or greater level of packet protection. 2667 Packets that are protected with 1-RTT keys MUST be acknowledged in 2668 packets that are also protected with 1-RTT keys. 2670 A packet that is not protected and claims to acknowledge a packet 2671 number that was sent with packet protection is not valid. An 2672 unprotected packet that carries acknowledgments for protected packets 2673 MUST be discarded in its entirety. 2675 Packets that a client sends with 0-RTT packet protection MUST be 2676 acknowledged by the server in packets protected by 1-RTT keys. This 2677 can mean that the client is unable to use these acknowledgments if 2678 the server cryptographic handshake messages are delayed or lost. 2679 Note that the same limitation applies to other data sent by the 2680 server protected by the 1-RTT keys. 2682 Unprotected packets, such as those that carry the initial 2683 cryptographic handshake messages, MAY be acknowledged in unprotected 2684 packets. Unprotected packets are vulnerable to falsification or 2685 modification. Unprotected packets can be acknowledged along with 2686 protected packets in a protected packet. 2688 An endpoint SHOULD acknowledge packets containing cryptographic 2689 handshake messages in the next unprotected packet that it sends, 2690 unless it is able to acknowledge those packets in later packets 2691 protected by 1-RTT keys. At the completion of the cryptographic 2692 handshake, both peers send unprotected packets containing 2693 cryptographic handshake messages followed by packets protected by 2694 1-RTT keys. An endpoint SHOULD acknowledge the unprotected packets 2695 that complete the cryptographic handshake in a protected packet, 2696 because its peer is guaranteed to have access to 1-RTT packet 2697 protection keys. 2699 For instance, a server acknowledges a TLS ClientHello in the packet 2700 that carries the TLS ServerHello; similarly, a client can acknowledge 2701 a TLS HelloRetryRequest in the packet containing a second TLS 2702 ClientHello. The complete set of server handshake messages (TLS 2703 ServerHello through to Finished) might be acknowledged by a client in 2704 protected packets, because it is certain that the server is able to 2705 decipher the packet. 2707 8.16. PATH_CHALLENGE Frame 2709 Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check 2710 reachability to the peer and for address validation during connection 2711 establishment and connection migration. 2713 PATH_CHALLENGE frames contain an 8-byte payload. 2715 0 1 2 3 2716 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 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | | 2719 + Data (8) + 2720 | | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 Data: This 8-byte field contains arbitrary data. 2725 A PATH_CHALLENGE frame containing 8 octets that are hard to guess is 2726 sufficient to ensure that it is easier to receive the packet than it 2727 is to guess the value correctly. 2729 The recipient of this frame MUST generate a PATH_RESPONSE frame 2730 (Section 8.17) containing the same Data. 2732 8.17. PATH_RESPONSE Frame 2734 The PATH_RESPONSE frame (type=0x0f) is sent in response to a 2735 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 2736 frame (Section 8.16). 2738 If the content of a PATH_RESPONSE frame does not match the content of 2739 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 2740 MAY generate a connection error of type UNSOLICITED_PATH_RESPONSE. 2742 8.18. STREAM Frames 2744 STREAM frames implicitly create a stream and carry stream data. The 2745 STREAM frame takes the form 0b00010XXX (or the set of values from 2746 0x10 to 0x17). The value of the three low-order bits of the frame 2747 type determine the fields that are present in the frame. 2749 o The OFF bit (0x04) in the frame type is set to indicate that there 2750 is an Offset field present. When set to 1, the Offset field is 2751 present; when set to 0, the Offset field is absent and the Stream 2752 Data starts at an offset of 0 (that is, the frame contains the 2753 first octets of the stream, or the end of a stream that includes 2754 no data). 2756 o The LEN bit (0x02) in the frame type is set to indicate that there 2757 is a Length field present. If this bit is set to 0, the Length 2758 field is absent and the Stream Data field extends to the end of 2759 the packet. If this bit is set to 1, the Length field is present. 2761 o The FIN bit (0x01) of the frame type is set only on frames that 2762 contain the final offset of the stream. Setting this bit 2763 indicates that the frame marks the end of the stream. 2765 An endpoint that receives a STREAM frame for a send-only stream MUST 2766 terminate the connection with error PROTOCOL_VIOLATION. 2768 A STREAM frame is shown below. 2770 0 1 2 3 2771 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 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 | Stream ID (i) ... 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | [Offset (i)] ... 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | [Length (i)] ... 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Stream Data (*) ... 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 Figure 9: STREAM Frame Format 2784 The STREAM frame contains the following fields: 2786 Stream ID: A variable-length integer indicating the stream ID of the 2787 stream (see Section 10.1). 2789 Offset: A variable-length integer specifying the byte offset in the 2790 stream for the data in this STREAM frame. This field is present 2791 when the OFF bit is set to 1. When the Offset field is absent, 2792 the offset is 0. 2794 Length: A variable-length integer specifying the length of the 2795 Stream Data field in this STREAM frame. This field is present 2796 when the LEN bit is set to 1. When the LEN bit is set to 0, the 2797 Stream Data field consumes all the remaining octets in the packet. 2799 Stream Data: The bytes from the designated stream to be delivered. 2801 A stream frame's Stream Data MUST NOT be empty, unless the FIN bit is 2802 set. When the FIN flag is sent on an empty STREAM frame, the offset 2803 in the STREAM frame is the offset of the next byte that would be 2804 sent. 2806 The first byte in the stream has an offset of 0. The largest offset 2807 delivered on a stream - the sum of the re-constructed offset and data 2808 length - MUST be less than 2^62. 2810 Stream multiplexing is achieved by interleaving STREAM frames from 2811 multiple streams into one or more QUIC packets. A single QUIC packet 2812 can include multiple STREAM frames from one or more streams. 2814 Implementation note: One of the benefits of QUIC is avoidance of 2815 head-of-line blocking across multiple streams. When a packet loss 2816 occurs, only streams with data in that packet are blocked waiting for 2817 a retransmission to be received, while other streams can continue 2818 making progress. Note that when data from multiple streams is 2819 bundled into a single QUIC packet, loss of that packet blocks all 2820 those streams from making progress. An implementation is therefore 2821 advised to bundle as few streams as necessary in outgoing packets 2822 without losing transmission efficiency to underfilled packets. 2824 9. Packetization and Reliability 2826 A sender bundles one or more frames in a QUIC packet (see Section 6). 2828 A sender SHOULD minimize per-packet bandwidth and computational costs 2829 by bundling as many frames as possible within a QUIC packet. A 2830 sender MAY wait for a short period of time to bundle multiple frames 2831 before sending a packet that is not maximally packed, to avoid 2832 sending out large numbers of small packets. An implementation may 2833 use knowledge about application sending behavior or heuristics to 2834 determine whether and for how long to wait. This waiting period is 2835 an implementation decision, and an implementation should be careful 2836 to delay conservatively, since any delay is likely to increase 2837 application-visible latency. 2839 9.1. Packet Processing and Acknowledgment 2841 A packet MUST NOT be acknowledged until packet protection has been 2842 successfully removed and all frames contained in the packet have been 2843 processed. Any stream state transitions triggered by the frame MUST 2844 have occurred. For STREAM frames, this means the data has been 2845 enqueued in preparation to be received by the application protocol, 2846 but it does not require that data is delivered and consumed. 2848 Once the packet has been fully processed, a receiver acknowledges 2849 receipt by sending one or more ACK frames containing the packet 2850 number of the received packet. To avoid creating an indefinite 2851 feedback loop, an endpoint MUST NOT send an ACK frame in response to 2852 a packet containing only ACK or PADDING frames, even if there are 2853 packet gaps which precede the received packet. The endpoint MUST 2854 acknowledge packets containing only ACK or PADDING frames in the next 2855 ACK frame that it sends. 2857 Strategies and implications of the frequency of generating 2858 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 2860 9.2. Retransmission of Information 2862 QUIC packets that are determined to be lost are not retransmitted 2863 whole. The same applies to the frames that are contained within lost 2864 packets. Instead, the information that might be carried in frames is 2865 sent again in new frames as needed. 2867 New frames and packets are used to carry information that is 2868 determined to have been lost. In general, information is sent again 2869 when a packet containing that information is determined to be lost 2870 and sending ceases when a packet containing that information is 2871 acknowledged. 2873 o Application data sent in STREAM frames is retransmitted in new 2874 STREAM frames unless the endpoint has sent a RST_STREAM for that 2875 stream. Once an endpoint sends a RST_STREAM frame, no further 2876 STREAM frames are needed. 2878 o The most recent set of acknowledgments are sent in ACK frames. An 2879 ACK frame SHOULD contain all unacknowledged acknowledgments, as 2880 described in Section 8.15.2. 2882 o Cancellation of stream transmission, as carried in a RST_STREAM 2883 frame, is sent until acknowledged or until all stream data is 2884 acknowledged by the peer (that is, either the "Reset Recvd" or 2885 "Data Recvd" state is reached on the send stream). The content of 2886 a RST_STREAM frame MUST NOT change when it is sent again. 2888 o Similarly, a request to cancel stream transmission, as encoded in 2889 a STOP_SENDING frame, is sent until the receive stream enters 2890 either a "Data Recvd" or "Reset Recvd" state, see Section 10.3. 2892 o Connection close signals, including those that use 2893 CONNECTION_CLOSE and APPLICATION_CLOSE frames, are not sent again 2894 when packet loss is detected, but as described in Section 7.9. 2896 o The current connection maximum data is sent in MAX_DATA frames. 2897 An updated value is sent in a MAX_DATA frame if the packet 2898 containing the most recently sent MAX_DATA frame is declared lost, 2899 or when the endpoint decides to update the limit. Care is 2900 necessary to avoid sending this frame too often as the limit can 2901 increase frequently and cause an unnecessarily large number of 2902 MAX_DATA frames to be sent. 2904 o The current maximum stream data offset is sent in MAX_STREAM_DATA 2905 frames. Like MAX_DATA, an updated value is sent when the packet 2906 containing the most recent MAX_STREAM_DATA frame for a stream is 2907 lost or when the limit is updated, with care taken to prevent the 2908 frame from being sent too often. An endpoint SHOULD stop sending 2909 MAX_STREAM_DATA frames when the receive stream enters a "Size 2910 Known" state. 2912 o The maximum stream ID for a stream of a given type is sent in 2913 MAX_STREAM_ID frames. Like MAX_DATA, an updated value is sent 2914 when a packet containing the most recent MAX_STREAM_ID for a 2915 stream type frame is declared lost or when the limit is updated, 2916 with care taken to prevent the frame from being sent too often. 2918 o Blocked signals are carried in BLOCKED, STREAM_BLOCKED, and 2919 STREAM_ID_BLOCKED frames. BLOCKED streams have connection scope, 2920 STREAM_BLOCKED frames have stream scope, and STREAM_ID_BLOCKED 2921 frames are scoped to a specific stream type. New frames are sent 2922 if packets containing the most recent frame for a scope is lost, 2923 but only while the endpoint is blocked on the corresponding limit. 2924 These frames always include the limit that is causing blocking at 2925 the time that they are transmitted. 2927 o A liveness or path validation check using PATH_CHALLENGE frames is 2928 sent periodically until a matching PATH_RESPONSE frame is received 2929 or until there is no remaining need for liveness or path 2930 validation checking. PATH_CHALLENGE frames include a different 2931 payload each time they are sent. 2933 o Responses to path validation using PATH_RESPONSE frames are sent 2934 just once. A new PATH_CHALLENGE frame will be sent if another 2935 PATH_RESPONSE frame is needed. 2937 o New connection IDs are sent in NEW_CONNECTION_ID frames and 2938 retransmitted if the packet containing them is lost. 2940 o PADDING frames contain no information, so lost PADDING frames do 2941 not require repair. 2943 Upon detecting losses, a sender MUST take appropriate congestion 2944 control action. The details of loss detection and congestion control 2945 are described in [QUIC-RECOVERY]. 2947 9.3. Packet Size 2949 The QUIC packet size includes the QUIC header and integrity check, 2950 but not the UDP or IP header. 2952 Clients MUST pad any Initial packet it sends to have a QUIC packet 2953 size of at least 1200 octets. Sending an Initial packet of this size 2954 ensures that the network path supports a reasonably sized packet, and 2955 helps reduce the amplitude of amplification attacks caused by server 2956 responses toward an unverified client address. 2958 An Initial packet MAY exceed 1200 octets if the client knows that the 2959 Path Maximum Transmission Unit (PMTU) supports the size that it 2960 chooses. 2962 A server MAY send a CONNECTION_CLOSE frame with error code 2963 PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200 2964 octets. It MUST NOT send any other frame type in response, or 2965 otherwise behave as if any part of the offending packet was processed 2966 as valid. 2968 9.4. Path Maximum Transmission Unit 2970 The Path Maximum Transmission Unit (PMTU) is the maximum size of the 2971 entire IP header, UDP header, and UDP payload. The UDP payload 2972 includes the QUIC packet header, protected payload, and any 2973 authentication fields. 2975 All QUIC packets SHOULD be sized to fit within the estimated PMTU to 2976 avoid IP fragmentation or packet drops. To optimize bandwidth 2977 efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery 2978 ([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) 2979 for detecting the PMTU, setting the PMTU appropriately, and storing 2980 the result of previous PMTU determinations. 2982 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 2983 packets larger than 1280 octets. Assuming the minimum IP header 2984 size, this results in a QUIC packet size of 1232 octets for IPv6 and 2985 1252 octets for IPv4. Some QUIC implementations MAY wish to be more 2986 conservative in computing allowed QUIC packet size given unknown 2987 tunneling overheads or IP header options. 2989 QUIC endpoints that implement any kind of PMTU discovery SHOULD 2990 maintain an estimate for each combination of local and remote IP 2991 addresses. Each pairing of local and remote addresses could have a 2992 different maximum MTU in the path. 2994 QUIC depends on the network path supporting a MTU of at least 1280 2995 octets. This is the IPv6 minimum MTU and therefore also supported by 2996 most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below 2997 this number, even if it receives signals that indicate a smaller 2998 limit might exist. 3000 If a QUIC endpoint determines that the PMTU between any pair of local 3001 and remote IP addresses has fallen below 1280 octets, it MUST 3002 immediately cease sending QUIC packets on the affected path. This 3003 could result in termination of the connection if an alternative path 3004 cannot be found. 3006 9.4.1. Special Considerations for PMTU Discovery 3008 Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is 3009 potentially vulnerable to off-path attacks that successfully guess 3010 the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient 3011 value. TCP connections mitigate this risk by using the (at minimum) 3012 8 bytes of transport header echoed in the ICMP message to validate 3013 the TCP sequence number as valid for the current connection. 3014 However, as QUIC operates over UDP, in IPv4 the echoed information 3015 could consist only of the IP and UDP headers, which usually has 3016 insufficient entropy to mitigate off-path attacks. 3018 As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps 3019 to mitigate this risk. For instance, an application could: 3021 o Set the IPv4 Don't Fragment (DF) bit on a small proportion of 3022 packets, so that most invalid ICMP messages arrive when there are 3023 no DF packets outstanding, and can therefore be identified as 3024 spurious. 3026 o Store additional information from the IP or UDP headers from DF 3027 packets (for example, the IP ID or UDP checksum) to further 3028 authenticate incoming Datagram Too Big messages. 3030 o Any reduction in PMTU due to a report contained in an ICMP packet 3031 is provisional until QUIC's loss detection algorithm determines 3032 that the packet is actually lost. 3034 9.4.2. Special Considerations for Packetization Layer PMTU Discovery 3036 The PADDING frame provides a useful option for PMTU probe packets 3037 that does not exist in other transports. PADDING frames generate 3038 acknowledgements, but their content need not be delivered reliably. 3039 PADDING frames may delay the delivery of application data, as they 3040 consume the congestion window. However, by definition their likely 3041 loss in a probe packet does not require delay-inducing retransmission 3042 of application data. 3044 When implementing the algorithm in Section 7.2 of [RFC4821], the 3045 initial value of search_low SHOULD be consistent with the IPv6 3046 minimum packet size. Paths that do not support this size cannot 3047 deliver Initial packets, and therefore are not QUIC-compliant. 3049 Section 7.3 of [RFC4821] discusses tradeoffs between small and large 3050 increases in the size of probe packets. As QUIC probe packets need 3051 not contain application data, aggressive increases in probe size 3052 carry fewer consequences. 3054 10. Streams: QUIC's Data Structuring Abstraction 3056 Streams in QUIC provide a lightweight, ordered byte-stream 3057 abstraction. 3059 There are two basic types of stream in QUIC. Unidirectional streams 3060 carry data in one direction only; bidirectional streams allow for 3061 data to be sent in both directions. Different stream identifiers are 3062 used to distinguish between unidirectional and bidirectional streams, 3063 as well as to create a separation between streams that are initiated 3064 by the client and server (see Section 10.1). 3066 Either type of stream can be created by either endpoint, can 3067 concurrently send data interleaved with other streams, and can be 3068 cancelled. 3070 Stream offsets allow for the octets on a stream to be placed in 3071 order. An endpoint MUST be capable of delivering data received on a 3072 stream in order. Implementations MAY choose to offer the ability to 3073 deliver data out of order. There is no means of ensuring ordering 3074 between octets on different streams. 3076 The creation and destruction of streams are expected to have minimal 3077 bandwidth and computational cost. A single STREAM frame may create, 3078 carry data for, and terminate a stream, or a stream may last the 3079 entire duration of a connection. 3081 Streams are individually flow controlled, allowing an endpoint to 3082 limit memory commitment and to apply back pressure. The creation of 3083 streams is also flow controlled, with each peer declaring the maximum 3084 stream ID it is willing to accept at a given time. 3086 An alternative view of QUIC streams is as an elastic "message" 3087 abstraction, similar to the way ephemeral streams are used in SST 3088 [SST], which may be a more appealing description for some 3089 applications. 3091 10.1. Stream Identifiers 3093 Streams are identified by an unsigned 62-bit integer, referred to as 3094 the Stream ID. The least significant two bits of the Stream ID are 3095 used to identify the type of stream (unidirectional or bidirectional) 3096 and the initiator of the stream. 3098 The least significant bit (0x1) of the Stream ID identifies the 3099 initiator of the stream. Clients initiate even-numbered streams 3100 (those with the least significant bit set to 0); servers initiate 3101 odd-numbered streams (with the bit set to 1). Separation of the 3102 stream identifiers ensures that client and server are able to open 3103 streams without the latency imposed by negotiating for an identifier. 3105 If an endpoint receives a frame for a stream that it expects to 3106 initiate (i.e., odd-numbered for the client or even-numbered for the 3107 server), but which it has not yet opened, it MUST close the 3108 connection with error code STREAM_STATE_ERROR. 3110 The second least significant bit (0x2) of the Stream ID 3111 differentiates between unidirectional streams and bidirectional 3112 streams. Unidirectional streams always have this bit set to 1 and 3113 bidirectional streams have this bit set to 0. 3115 The two type bits from a Stream ID therefore identify streams as 3116 summarized in Table 5. 3118 +----------+----------------------------------+ 3119 | Low Bits | Stream Type | 3120 +----------+----------------------------------+ 3121 | 0x0 | Client-Initiated, Bidirectional | 3122 | | | 3123 | 0x1 | Server-Initiated, Bidirectional | 3124 | | | 3125 | 0x2 | Client-Initiated, Unidirectional | 3126 | | | 3127 | 0x3 | Server-Initiated, Unidirectional | 3128 +----------+----------------------------------+ 3130 Table 5: Stream ID Types 3132 Stream ID 0 (0x0) is a client-initiated, bidirectional stream that is 3133 used for the cryptographic handshake. Stream 0 MUST NOT be used for 3134 application data. 3136 A QUIC endpoint MUST NOT reuse a Stream ID. Open streams can be used 3137 in any order. Streams that are used out of order result in opening 3138 all lower-numbered streams of the same type in the same direction. 3140 Stream IDs are encoded as a variable-length integer (see 3141 Section 8.1). 3143 10.2. Stream States 3145 This section describes the two types of QUIC stream in terms of the 3146 states of their send or receive components. Two state machines are 3147 described: one for streams on which an endpoint transmits data 3148 (Section 10.2.1); another for streams from which an endpoint receives 3149 data (Section 10.2.2). 3151 Unidirectional streams use the applicable state machine directly. 3152 Bidirectional streams use both state machines. For the most part, 3153 the use of these state machines is the same whether the stream is 3154 unidirectional or bidirectional. The conditions for opening a stream 3155 are slightly more complex for a bidirectional stream because the 3156 opening of either send or receive causes the stream to open in both 3157 directions. 3159 Opening a stream causes all lower-numbered streams of the same type 3160 to implicitly open. This includes both send and receive streams if 3161 the stream is bidirectional. For bidirectional streams, an endpoint 3162 can send data on an implicitly opened stream. On both unidirectional 3163 and bidirectional streams, an endpoint MAY send MAX_STREAM_DATA or 3164 STOP_SENDING on implicitly opened streams. An endpoint SHOULD NOT 3165 implicitly open streams that it initiates, instead opening streams in 3166 order. 3168 Note: These states are largely informative. This document uses 3169 stream states to describe rules for when and how different types 3170 of frames can be sent and the reactions that are expected when 3171 different types of frames are received. Though these state 3172 machines are intended to be useful in implementing QUIC, these 3173 states aren't intended to constrain implementations. An 3174 implementation can define a different state machine as long as its 3175 behavior is consistent with an implementation that implements 3176 these states. 3178 10.2.1. Send Stream States 3180 Figure 10 shows the states for the part of a stream that sends data 3181 to a peer. 3183 o 3184 | Open Stream (Sending) 3185 | Open Bidirectional Stream (Receiving) 3186 v 3187 +-------+ 3188 | Open | Send RST_STREAM 3189 | |-----------------------. 3190 +-------+ | 3191 | | 3192 | Send STREAM / | 3193 | STREAM_BLOCKED | 3194 v | 3195 +-------+ | 3196 | Send | Send RST_STREAM | 3197 | |---------------------->| 3198 +-------+ | 3199 | | 3200 | Send STREAM + FIN | 3201 v v 3202 +-------+ +-------+ 3203 | Data | Send RST_STREAM | Reset | 3204 | Sent +------------------>| Sent | 3205 +-------+ +-------+ 3206 | | 3207 | Recv All ACKs | Recv ACK 3208 v v 3209 +-------+ +-------+ 3210 | Data | | Reset | 3211 | Recvd | | Recvd | 3212 +-------+ +-------+ 3214 Figure 10: States for Send Streams 3216 The sending part of stream that the endpoint initiates (types 0 and 2 3217 for clients, 1 and 3 for servers) is opened by the application or 3218 application protocol. The "Open" state represents a newly created 3219 stream that is able to accept data from the application. Stream data 3220 might be buffered in this state in preparation for sending. 3222 The sending part of a bidirectional stream initiated by a peer (type 3223 0 for a server, type 1 for a client) enters the "Open" state if the 3224 receiving part enters the "Recv" state. 3226 Sending the first STREAM or STREAM_BLOCKED frame causes a send stream 3227 to enter the "Send" state. An implementation might choose to defer 3228 allocating a Stream ID to a send stream until it sends the first 3229 frame and enters this state, which can allow for better stream 3230 prioritization. 3232 In the "Send" state, an endpoint transmits - and retransmits as 3233 necessary - data in STREAM frames. The endpoint respects the flow 3234 control limits of its peer, accepting MAX_STREAM_DATA frames. An 3235 endpoint in the "Send" state generates STREAM_BLOCKED frames if it 3236 encounters flow control limits. 3238 After the application indicates that stream data is complete and a 3239 STREAM frame containing the FIN bit is sent, the send stream enters 3240 the "Data Sent" state. From this state, the endpoint only 3241 retransmits stream data as necessary. The endpoint no longer needs 3242 to track flow control limits or send STREAM_BLOCKED frames for a send 3243 stream in this state. The endpoint can ignore any MAX_STREAM_DATA 3244 frames it receives from its peer in this state; MAX_STREAM_DATA 3245 frames might be received until the peer receives the final stream 3246 offset. 3248 Once all stream data has been successfully acknowledged, the send 3249 stream enters the "Data Recvd" state, which is a terminal state. 3251 From any of the "Open", "Send", or "Data Sent" states, an application 3252 can signal that it wishes to abandon transmission of stream data. 3253 Similarly, the endpoint might receive a STOP_SENDING frame from its 3254 peer. In either case, the endpoint sends a RST_STREAM frame, which 3255 causes the stream to enter the "Reset Sent" state. 3257 An endpoint MAY send a RST_STREAM as the first frame on a send 3258 stream; this causes the send stream to open and then immediately 3259 transition to the "Reset Sent" state. 3261 Once a packet containing a RST_STREAM has been acknowledged, the send 3262 stream enters the "Reset Recvd" state, which is a terminal state. 3264 10.2.2. Receive Stream States 3266 Figure 11 shows the states for the part of a stream that receives 3267 data from a peer. The states for a receive stream mirror only some 3268 of the states of the send stream at the peer. A receive stream 3269 doesn't track states on the send stream that cannot be observed, such 3270 as the "Open" state; instead, receive streams track the delivery of 3271 data to the application or application protocol some of which cannot 3272 be observed by the sender. 3274 o 3275 | Recv STREAM / STREAM_BLOCKED / RST_STREAM 3276 | Open Bidirectional Stream (Sending) 3277 | Recv MAX_STREAM_DATA 3278 v 3279 +-------+ 3280 | Recv | Recv RST_STREAM 3281 | |-----------------------. 3282 +-------+ | 3283 | | 3284 | Recv STREAM + FIN | 3285 v | 3286 +-------+ | 3287 | Size | Recv RST_STREAM | 3288 | Known +---------------------->| 3289 +-------+ | 3290 | | 3291 | Recv All Data | 3292 v v 3293 +-------+ +-------+ 3294 | Data | Recv RST_STREAM | Reset | 3295 | Recvd +<-- (optional) --->| Recvd | 3296 +-------+ +-------+ 3297 | | 3298 | App Read All Data | App Read RST 3299 v v 3300 +-------+ +-------+ 3301 | Data | | Reset | 3302 | Read | | Read | 3303 +-------+ +-------+ 3305 Figure 11: States for Receive Streams 3307 The receiving part of a stream initiated by a peer (types 1 and 3 for 3308 a client, or 0 and 2 for a server) are created when the first STREAM, 3309 STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only, 3310 see below) is received for that stream. The initial state for a 3311 receive stream is "Recv". Receiving a RST_STREAM frame causes the 3312 receive stream to immediately transition to the "Reset Recvd". 3314 The receive stream enters the "Recv" state when the sending part of a 3315 bidirectional stream initiated by the endpoint (type 0 for a client, 3316 type 1 for a server) enters the "Open" state. 3318 A bidirectional stream also opens when a MAX_STREAM_DATA frame is 3319 received. Receiving a MAX_STREAM_DATA frame implies that the remote 3320 peer has opened the stream and is providing flow control credit. A 3321 MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED 3322 frame if packets are lost or reordered. 3324 In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED 3325 frames. Incoming data is buffered and can be reassembled into the 3326 correct order for delivery to the application. As data is consumed 3327 by the application and buffer space becomes available, the endpoint 3328 sends MAX_STREAM_DATA frames to allow the peer to send more data. 3330 When a STREAM frame with a FIN bit is received, the final offset (see 3331 Section 11.3) is known. The receive stream enters the "Size Known" 3332 state. In this state, the endpoint no longer needs to send 3333 MAX_STREAM_DATA frames, it only receives any retransmissions of 3334 stream data. 3336 Once all data for the stream has been received, the receive stream 3337 enters the "Data Recvd" state. This might happen as a result of 3338 receiving the same STREAM frame that causes the transition to "Size 3339 Known". In this state, the endpoint has all stream data. Any STREAM 3340 or STREAM_BLOCKED frames it receives for the stream can be discarded. 3342 The "Data Recvd" state persists until stream data has been delivered 3343 to the application or application protocol. Once stream data has 3344 been delivered, the stream enters the "Data Read" state, which is a 3345 terminal state. 3347 Receiving a RST_STREAM frame in the "Recv" or "Size Known" states 3348 causes the stream to enter the "Reset Recvd" state. This might cause 3349 the delivery of stream data to the application to be interrupted. 3351 It is possible that all stream data is received when a RST_STREAM is 3352 received (that is, from the "Data Recvd" state). Similarly, it is 3353 possible for remaining stream data to arrive after receiving a 3354 RST_STREAM frame (the "Reset Recvd" state). An implementation is 3355 able to manage this situation as they choose. Sending RST_STREAM 3356 means that an endpoint cannot guarantee delivery of stream data; 3357 however there is no requirement that stream data not be delivered if 3358 a RST_STREAM is received. An implementation MAY interrupt delivery 3359 of stream data, discard any data that was not consumed, and signal 3360 the existence of the RST_STREAM immediately. Alternatively, the 3361 RST_STREAM signal might be suppressed or withheld if stream data is 3362 completely received. In the latter case, the receive stream 3363 effectively transitions to "Data Recvd" from "Reset Recvd". 3365 Once the application has been delivered the signal indicating that 3366 the receive stream was reset, the receive stream transitions to the 3367 "Reset Read" state, which is a terminal state. 3369 10.2.3. Permitted Frame Types 3371 The sender of a stream sends just three frame types that affect the 3372 state of a stream at either sender or receiver: STREAM 3373 (Section 8.18), STREAM_BLOCKED (Section 8.11), and RST_STREAM 3374 (Section 8.3). 3376 A sender MUST NOT send any of these frames from a terminal state 3377 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 3378 STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset 3379 Sent" state in addition to the terminal states. A receiver could 3380 receive any of these frames in any state, but only due to the 3381 possibility of delayed delivery of packets carrying them. 3383 The receiver of a stream sends MAX_STREAM_DATA (Section 8.7) and 3384 STOP_SENDING frames (Section 8.14). 3386 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 3387 receiver can send STOP_SENDING in any state where it has not received 3388 a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset 3389 Read". However there is little value in sending a STOP_SENDING frame 3390 after all stream data has been received in the "Data Recvd" state. A 3391 sender could receive these frames in any state as a result of delayed 3392 delivery of packets. 3394 10.2.4. Bidirectional Stream States 3396 A bidirectional stream is composed of a send stream and a receive 3397 stream. Implementations may represent states of the bidirectional 3398 stream as composites of send and receive stream states. The simplest 3399 model presents the stream as "open" when either send or receive 3400 stream is in a non-terminal state and "closed" when both send and 3401 receive streams are in a terminal state. 3403 Table 6 shows a more complex mapping of bidirectional stream states 3404 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 3405 shows that multiple states on send or receive streams are mapped to 3406 the same composite state. Note that this is just one possibility for 3407 such a mapping; this mapping requires that data is acknowledged 3408 before the transition to a "closed" or "half-closed" state. 3410 +-----------------------+---------------------+---------------------+ 3411 | Send Stream | Receive Stream | Composite State | 3412 +-----------------------+---------------------+---------------------+ 3413 | No Stream/Open | No Stream/Recv *1 | idle | 3414 | | | | 3415 | Open/Send/Data Sent | Recv/Size Known | open | 3416 | | | | 3417 | Open/Send/Data Sent | Data Recvd/Data | half-closed | 3418 | | Read | (remote) | 3419 | | | | 3420 | Open/Send/Data Sent | Reset Recvd/Reset | half-closed | 3421 | | Read | (remote) | 3422 | | | | 3423 | Data Recvd | Recv/Size Known | half-closed (local) | 3424 | | | | 3425 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 3426 | Recvd | | | 3427 | | | | 3428 | Data Recvd | Recv/Size Known | half-closed (local) | 3429 | | | | 3430 | Reset Sent/Reset | Data Recvd/Data | closed | 3431 | Recvd | Read | | 3432 | | | | 3433 | Reset Sent/Reset | Reset Recvd/Reset | closed | 3434 | Recvd | Read | | 3435 | | | | 3436 | Data Recvd | Data Recvd/Data | closed | 3437 | | Read | | 3438 | | | | 3439 | Data Recvd | Reset Recvd/Reset | closed | 3440 | | Read | | 3441 +-----------------------+---------------------+---------------------+ 3443 Table 6: Possible Mapping of Stream States to HTTP/2 3445 Note (*1): A stream is considered "idle" if it has not yet been 3446 created, or if the receive stream is in the "Recv" state without 3447 yet having received any frames. 3449 10.3. Solicited State Transitions 3451 If an endpoint is no longer interested in the data it is receiving on 3452 a stream, it MAY send a STOP_SENDING frame identifying that stream to 3453 prompt closure of the stream in the opposite direction. This 3454 typically indicates that the receiving application is no longer 3455 reading data it receives from the stream, but is not a guarantee that 3456 incoming data will be ignored. 3458 STREAM frames received after sending STOP_SENDING are still counted 3459 toward the connection and stream flow-control windows, even though 3460 these frames will be discarded upon receipt. This avoids potential 3461 ambiguity about which STREAM frames count toward flow control. 3463 A STOP_SENDING frame requests that the receiving endpoint send a 3464 RST_STREAM frame. An endpoint that receives a STOP_SENDING frame 3465 MUST send a RST_STREAM frame for that stream, and can use an error 3466 code of STOPPING. If the STOP_SENDING frame is received on a send 3467 stream that is already in the "Data Sent" state, a RST_STREAM frame 3468 MAY still be sent in order to cancel retransmission of previously- 3469 sent STREAM frames. 3471 STOP_SENDING SHOULD only be sent for a receive stream that has not 3472 been reset. STOP_SENDING is most useful for streams in the "Recv" or 3473 "Size Known" states. 3475 An endpoint is expected to send another STOP_SENDING frame if a 3476 packet containing a previous STOP_SENDING is lost. However, once 3477 either all stream data or a RST_STREAM frame has been received for 3478 the stream - that is, the stream is in any state other than "Recv" or 3479 "Size Known" - sending a STOP_SENDING frame is unnecessary. 3481 10.4. Stream Concurrency 3483 An endpoint limits the number of concurrently active incoming streams 3484 by adjusting the maximum stream ID. An initial value is set in the 3485 transport parameters (see Section 7.4.1) and is subsequently 3486 increased by MAX_STREAM_ID frames (see Section 8.8). 3488 The maximum stream ID is specific to each endpoint and applies only 3489 to the peer that receives the setting. That is, clients specify the 3490 maximum stream ID the server can initiate, and servers specify the 3491 maximum stream ID the client can initiate. Each endpoint may respond 3492 on streams initiated by the other peer, regardless of whether it is 3493 permitted to initiated new streams. 3495 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 3496 that receives a STREAM frame with an ID greater than the limit it has 3497 sent MUST treat this as a stream error of type STREAM_ID_ERROR 3498 (Section 12), unless this is a result of a change in the initial 3499 offsets (see Section 7.4.2). 3501 A receiver MUST NOT renege on an advertisement; that is, once a 3502 receiver advertises a stream ID via a MAX_STREAM_ID frame, it MUST 3503 NOT subsequently advertise a smaller maximum ID. A sender may 3504 receive MAX_STREAM_ID frames out of order; a sender MUST therefore 3505 ignore any MAX_STREAM_ID that does not increase the maximum. 3507 10.5. Sending and Receiving Data 3509 Once a stream is created, endpoints may use the stream to send and 3510 receive data. Each endpoint may send a series of STREAM frames 3511 encapsulating data on a stream until the stream is terminated in that 3512 direction. Streams are an ordered byte-stream abstraction, and they 3513 have no other structure within them. STREAM frame boundaries are not 3514 expected to be preserved in retransmissions from the sender or during 3515 delivery to the application at the receiver. 3517 When new data is to be sent on a stream, a sender MUST set the 3518 encapsulating STREAM frame's offset field to the stream offset of the 3519 first byte of this new data. The first octet of data on a stream has 3520 an offset of 0. An endpoint is expected to send every stream octet. 3521 The largest offset delivered on a stream MUST be less than 2^62. A 3522 receiver MUST ensure that received stream data is delivered to the 3523 application as an ordered byte-stream. Data received out of order 3524 MUST be buffered for later delivery, as long as it is not in 3525 violation of the receiver's flow control limits. 3527 An endpoint MUST NOT send data on any stream without ensuring that it 3528 is within the data limits set by its peer. The cryptographic 3529 handshake stream, Stream 0, is exempt from the connection-level data 3530 limits established by MAX_DATA. Data on stream 0 other than the 3531 initial cryptographic handshake message is still subject to stream- 3532 level data limits and MAX_STREAM_DATA. This message is exempt from 3533 flow control because it needs to be sent in a single packet 3534 regardless of the server's flow control state. This rule applies 3535 even for 0-RTT handshakes where the remembered value of 3536 MAX_STREAM_DATA would not permit sending a full initial cryptographic 3537 handshake message. 3539 Flow control is described in detail in Section 11, and congestion 3540 control is described in the companion document [QUIC-RECOVERY]. 3542 10.6. Stream Prioritization 3544 Stream multiplexing has a significant effect on application 3545 performance if resources allocated to streams are correctly 3546 prioritized. Experience with other multiplexed protocols, such as 3547 HTTP/2 [HTTP2], shows that effective prioritization strategies have a 3548 significant positive impact on performance. 3550 QUIC does not provide frames for exchanging prioritization 3551 information. Instead it relies on receiving priority information 3552 from the application that uses QUIC. Protocols that use QUIC are 3553 able to define any prioritization scheme that suits their application 3554 semantics. A protocol might define explicit messages for signaling 3555 priority, such as those defined in HTTP/2; it could define rules that 3556 allow an endpoint to determine priority based on context; or it could 3557 leave the determination to the application. 3559 A QUIC implementation SHOULD provide ways in which an application can 3560 indicate the relative priority of streams. When deciding which 3561 streams to dedicate resources to, QUIC SHOULD use the information 3562 provided by the application. Failure to account for priority of 3563 streams can result in suboptimal performance. 3565 Stream priority is most relevant when deciding which stream data will 3566 be transmitted. Often, there will be limits on what can be 3567 transmitted as a result of connection flow control or the current 3568 congestion controller state. 3570 Giving preference to the transmission of its own management frames 3571 ensures that the protocol functions efficiently. That is, 3572 prioritizing frames other than STREAM frames ensures that loss 3573 recovery, congestion control, and flow control operate effectively. 3575 Stream 0 MUST be prioritized over other streams prior to the 3576 completion of the cryptographic handshake. This includes the 3577 retransmission of the second flight of client handshake messages, 3578 that is, the TLS Finished and any client authentication messages. 3580 STREAM frames that are determined to be lost SHOULD be retransmitted 3581 before sending new data, unless application priorities indicate 3582 otherwise. Retransmitting lost stream data can fill in gaps, which 3583 allows the peer to consume already received data and free up flow 3584 control window. 3586 11. Flow Control 3588 It is necessary to limit the amount of data that a sender may have 3589 outstanding at any time, so as to prevent a fast sender from 3590 overwhelming a slow receiver, or to prevent a malicious sender from 3591 consuming significant resources at a receiver. This section 3592 describes QUIC's flow-control mechanisms. 3594 QUIC employs a credit-based flow-control scheme similar to HTTP/2's 3595 flow control [HTTP2]. A receiver advertises the number of octets it 3596 is prepared to receive on a given stream and for the entire 3597 connection. This leads to two levels of flow control in QUIC: (i) 3598 Connection flow control, which prevents senders from exceeding a 3599 receiver's buffer capacity for the connection, and (ii) Stream flow 3600 control, which prevents a single stream from consuming the entire 3601 receive buffer for a connection. 3603 A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the 3604 sender to advertise additional credit. MAX_STREAM_DATA frames send 3605 the the maximum absolute byte offset of a stream, while MAX_DATA 3606 sends the maximum sum of the absolute byte offsets of all streams 3607 other than stream 0. 3609 A receiver MAY advertise a larger offset at any point by sending 3610 MAX_DATA or MAX_STREAM_DATA frames. A receiver MUST NOT renege on an 3611 advertisement; that is, once a receiver advertises an offset, it MUST 3612 NOT subsequently advertise a smaller offset. A sender could receive 3613 MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST 3614 therefore ignore any flow control offset that does not move the 3615 window forward. 3617 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 3618 (Section 12) if the peer violates the advertised connection or stream 3619 data limits. 3621 A sender SHOULD send BLOCKED or STREAM_BLOCKED frames to indicate it 3622 has data to write but is blocked by flow control limits. These 3623 frames are expected to be sent infrequently in common cases, but they 3624 are considered useful for debugging and monitoring purposes. 3626 A receiver advertises credit for a stream by sending a 3627 MAX_STREAM_DATA frame with the Stream ID set appropriately. A 3628 receiver could use the current offset of data consumed to determine 3629 the flow control offset to be advertised. A receiver MAY send 3630 MAX_STREAM_DATA frames in multiple packets in order to make sure that 3631 the sender receives an update before running out of flow control 3632 credit, even if one of the packets is lost. 3634 Connection flow control is a limit to the total bytes of stream data 3635 sent in STREAM frames on all streams except stream 0. A receiver 3636 advertises credit for a connection by sending a MAX_DATA frame. A 3637 receiver maintains a cumulative sum of bytes received on all 3638 contributing streams, which are used to check for flow control 3639 violations. A receiver might use a sum of bytes consumed on all 3640 contributing streams to determine the maximum data limit to be 3641 advertised. 3643 11.1. Edge Cases and Other Considerations 3645 There are some edge cases which must be considered when dealing with 3646 stream and connection level flow control. Given enough time, both 3647 endpoints must agree on flow control state. If one end believes it 3648 can send more than the other end is willing to receive, the 3649 connection will be torn down when too much data arrives. 3651 Conversely if a sender believes it is blocked, while endpoint B 3652 expects more data can be received, then the connection can be in a 3653 deadlock, with the sender waiting for a MAX_DATA or MAX_STREAM_DATA 3654 frame which will never come. 3656 On receipt of a RST_STREAM frame, an endpoint will tear down state 3657 for the matching stream and ignore further data arriving on that 3658 stream. This could result in the endpoints getting out of sync, 3659 since the RST_STREAM frame may have arrived out of order and there 3660 may be further bytes in flight. The data sender would have counted 3661 the data against its connection level flow control budget, but a 3662 receiver that has not received these bytes would not know to include 3663 them as well. The receiver must learn the number of bytes that were 3664 sent on the stream to make the same adjustment in its connection flow 3665 controller. 3667 To avoid this de-synchronization, a RST_STREAM sender MUST include 3668 the final byte offset sent on the stream in the RST_STREAM frame. On 3669 receiving a RST_STREAM frame, a receiver definitively knows how many 3670 bytes were sent on that stream before the RST_STREAM frame, and the 3671 receiver MUST use the final offset to account for all bytes sent on 3672 the stream in its connection level flow controller. 3674 11.1.1. Response to a RST_STREAM 3676 RST_STREAM terminates one direction of a stream abruptly. Whether 3677 any action or response can or should be taken on the data already 3678 received is an application-specific issue, but it will often be the 3679 case that upon receipt of a RST_STREAM an endpoint will choose to 3680 stop sending data in its own direction. If the sender of a 3681 RST_STREAM wishes to explicitly state that no future data will be 3682 processed, that endpoint MAY send a STOP_SENDING frame at the same 3683 time. 3685 11.1.2. Data Limit Increments 3687 This document leaves when and how many bytes to advertise in a 3688 MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few 3689 considerations. These frames contribute to connection overhead. 3690 Therefore frequently sending frames with small changes is 3691 undesirable. At the same time, infrequent updates require larger 3692 increments to limits if blocking is to be avoided. Thus, larger 3693 updates require a receiver to commit to larger resource commitments. 3694 Thus there is a tradeoff between resource commitment and overhead 3695 when determining how large a limit is advertised. 3697 A receiver MAY use an autotuning mechanism to tune the frequency and 3698 amount that it increases data limits based on a roundtrip time 3699 estimate and the rate at which the receiving application consumes 3700 data, similar to common TCP implementations. 3702 11.1.3. Handshake Exemption 3704 During the initial handshake, an endpoint could need to send a larger 3705 message on stream 0 than would ordinarily be permitted by the peer's 3706 initial stream flow control window. Since MAX_STREAM_DATA frames are 3707 not permitted in these early packets, the peer cannot provide 3708 additional flow control window in order to complete the handshake. 3710 Endpoints MAY exceed the flow control limits on stream 0 prior to the 3711 completion of the cryptographic handshake. (That is, in Initial, 3712 Retry, and Handshake packets.) However, once the handshake is 3713 complete, endpoints MUST NOT send additional data beyond the peer's 3714 permitted offset. If the amount of data sent during the handshake 3715 exceeds the peer's maximum offset, the endpoint cannot send 3716 additional data on stream 0 until the peer has sent a MAX_STREAM_DATA 3717 frame indicating a larger maximum offset. 3719 11.2. Stream Limit Increment 3721 As with flow control, this document leaves when and how many streams 3722 to make available to a peer via MAX_STREAM_ID to implementations, but 3723 offers a few considerations. MAX_STREAM_ID frames constitute minimal 3724 overhead, while withholding MAX_STREAM_ID frames can prevent the peer 3725 from using the available parallelism. 3727 Implementations will likely want to increase the maximum stream ID as 3728 peer-initiated streams close. A receiver MAY also advance the 3729 maximum stream ID based on current activity, system conditions, and 3730 other environmental factors. 3732 11.2.1. Blocking on Flow Control 3734 If a sender does not receive a MAX_DATA or MAX_STREAM_DATA frame when 3735 it has run out of flow control credit, the sender will be blocked and 3736 SHOULD send a BLOCKED or STREAM_BLOCKED frame. These frames are 3737 expected to be useful for debugging at the receiver; they do not 3738 require any other action. A receiver SHOULD NOT wait for a BLOCKED 3739 or STREAM_BLOCKED frame before sending MAX_DATA or MAX_STREAM_DATA, 3740 since doing so will mean that a sender is unable to send for an 3741 entire round trip. 3743 For smooth operation of the congestion controller, it is generally 3744 considered best to not let the sender go into quiescence if 3745 avoidable. To avoid blocking a sender, and to reasonably account for 3746 the possibiity of loss, a receiver should send a MAX_DATA or 3747 MAX_STREAM_DATA frame at least two roundtrips before it expects the 3748 sender to get blocked. 3750 A sender sends a single BLOCKED or STREAM_BLOCKED frame only once 3751 when it reaches a data limit. A sender SHOULD NOT send multiple 3752 BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the 3753 original frame is determined to be lost. Another BLOCKED or 3754 STREAM_BLOCKED frame can be sent after the data limit is increased. 3756 11.3. Stream Final Offset 3758 The final offset is the count of the number of octets that are 3759 transmitted on a stream. For a stream that is reset, the final 3760 offset is carried explicitly in a RST_STREAM frame. Otherwise, the 3761 final offset is the offset of the end of the data carried in a STREAM 3762 frame marked with a FIN flag, or 0 in the case of incoming 3763 unidirectional streams. 3765 An endpoint will know the final offset for a stream when the receive 3766 stream enters the "Size Known" or "Reset Recvd" state. 3768 An endpoint MUST NOT send data on a stream at or beyond the final 3769 offset. 3771 Once a final offset for a stream is known, it cannot change. If a 3772 RST_STREAM or STREAM frame causes the final offset to change for a 3773 stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error 3774 (see Section 12). A receiver SHOULD treat receipt of data at or 3775 beyond the final offset as a FINAL_OFFSET_ERROR error, even after a 3776 stream is closed. Generating these errors is not mandatory, but only 3777 because requiring that an endpoint generate these errors also means 3778 that the endpoint needs to maintain the final offset state for closed 3779 streams, which could mean a significant state commitment. 3781 12. Error Handling 3783 An endpoint that detects an error SHOULD signal the existence of that 3784 error to its peer. Errors can affect an entire connection (see 3785 Section 12.1), or a single stream (see Section 12.2). 3787 The most appropriate error code (Section 12.3) SHOULD be included in 3788 the frame that signals the error. Where this specification 3789 identifies error conditions, it also identifies the error code that 3790 is used. 3792 A stateless reset (Section 7.9.4) is not suitable for any error that 3793 can be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or 3794 RST_STREAM frame. A stateless reset MUST NOT be used by an endpoint 3795 that has the state necessary to send a frame on the connection. 3797 12.1. Connection Errors 3799 Errors that result in the connection being unusable, such as an 3800 obvious violation of protocol semantics or corruption of state that 3801 affects an entire connection, MUST be signaled using a 3802 CONNECTION_CLOSE or APPLICATION_CLOSE frame (Section 8.4, 3803 Section 8.5). An endpoint MAY close the connection in this manner 3804 even if the error only affects a single stream. 3806 Application protocols can signal application-specific protocol errors 3807 using the APPLICATION_CLOSE frame. Errors that are specific to the 3808 transport, including all those described in this document, are 3809 carried in a CONNECTION_CLOSE frame. Other than the type of error 3810 code they carry, these frames are identical in format and semantics. 3812 A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a 3813 packet that is lost. An endpoint SHOULD be prepared to retransmit a 3814 packet containing either frame type if it receives more packets on a 3815 terminated connection. Limiting the number of retransmissions and 3816 the time over which this final packet is sent limits the effort 3817 expended on terminated connections. 3819 An endpoint that chooses not to retransmit packets containing 3820 CONNECTION_CLOSE or APPLICATION_CLOSE risks a peer missing the first 3821 such packet. The only mechanism available to an endpoint that 3822 continues to receive data for a terminated connection is to use the 3823 stateless reset process (Section 7.9.4). 3825 An endpoint that receives an invalid CONNECTION_CLOSE or 3826 APPLICATION_CLOSE frame MUST NOT signal the existence of the error to 3827 its peer. 3829 12.2. Stream Errors 3831 If the error affects a single stream, but otherwise leaves the 3832 connection in a recoverable state, the endpoint can send a RST_STREAM 3833 frame (Section 8.3) with an appropriate error code to terminate just 3834 the affected stream. 3836 Stream 0 is critical to the functioning of the entire connection. If 3837 stream 0 is closed with either a RST_STREAM or STREAM frame bearing 3838 the FIN flag, an endpoint MUST generate a connection error of type 3839 PROTOCOL_VIOLATION. 3841 RST_STREAM MUST be instigated by the application and MUST carry an 3842 application error code. Resetting a stream without knowledge of the 3843 application protocol could cause the protocol to enter an 3844 unrecoverable state. Application protocols might require certain 3845 streams to be reliably delivered in order to guarantee consistent 3846 state between endpoints. 3848 12.3. Transport Error Codes 3850 QUIC error codes are 16-bit unsigned integers. 3852 This section lists the defined QUIC transport error codes that may be 3853 used in a CONNECTION_CLOSE frame. These errors apply to the entire 3854 connection. 3856 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 3857 signal that the connection is being closed abruptly in the absence 3858 of any error. 3860 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 3861 cannot continue with the connection. 3863 SERVER_BUSY (0x2): The server is currently busy and does not accept 3864 any new connections. 3866 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 3867 permitted in its advertised data limits (see Section 11). 3869 STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream 3870 identifier that exceeded its advertised maximum stream ID. 3872 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 3873 that was not in a state that permitted that frame (see 3874 Section 10.2). 3876 FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame 3877 containing data that exceeded the previously established final 3878 offset. Or an endpoint received a RST_STREAM frame containing a 3879 final offset that was lower than the maximum offset of data that 3880 was already received. Or an endpoint received a RST_STREAM frame 3881 containing a different final offset to the one already 3882 established. 3884 FRAME_FORMAT_ERROR (0x7): An endpoint received a frame that was 3885 badly formatted. For instance, an empty STREAM frame that omitted 3886 the FIN flag, or an ACK frame that has more acknowledgment ranges 3887 than the remainder of the packet could carry. This is a generic 3888 error code; an endpoint SHOULD use the more specific frame format 3889 error codes (0x1XX) if possible. 3891 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 3892 parameters that were badly formatted, included an invalid value, 3893 was absent even though it is mandatory, was present though it is 3894 forbidden, or is otherwise in error. 3896 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 3897 parameters that contained version negotiation parameters that 3898 disagreed with the version negotiation that it performed. This 3899 error code indicates a potential version downgrade attack. 3901 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 3902 protocol compliance that was not covered by more specific error 3903 codes. 3905 UNSOLICITED_PATH_RESPONSE (0xB): An endpoint received a 3906 PATH_RESPONSE frame that did not correspond to any PATH_CHALLENGE 3907 frame that it previously sent. 3909 FRAME_ERROR (0x1XX): An endpoint detected an error in a specific 3910 frame type. The frame type is included as the last octet of the 3911 error code. For example, an error in a MAX_STREAM_ID frame would 3912 be indicated with the code (0x106). 3914 Codes for errors occuring when TLS is used for the crypto handshake 3915 are defined in Section 11 of [QUIC-TLS]. See Section 14.2 for 3916 details of registering new error codes. 3918 12.4. Application Protocol Error Codes 3920 Application protocol error codes are 16-bit unsigned integers, but 3921 the management of application error codes are left to application 3922 protocols. Application protocol error codes are used for the 3923 RST_STREAM (Section 8.3) and APPLICATION_CLOSE (Section 8.5) frames. 3925 There is no restriction on the use of the 16-bit error code space for 3926 application protocols. However, QUIC reserves the error code with a 3927 value of 0 to mean STOPPING. The application error code of STOPPING 3928 (0) is used by the transport to cancel a stream in response to 3929 receipt of a STOP_SENDING frame. 3931 13. Security and Privacy Considerations 3932 13.1. Spoofed ACK Attack 3934 An attacker might be able to receive an address validation token 3935 (Section 7.6) from the server and then release the IP address it used 3936 to acquire that token. The attacker may, in the future, spoof this 3937 same address (which now presumably addresses a different endpoint), 3938 and initiate a 0-RTT connection with a server on the victim's behalf. 3939 The attacker can then spoof ACK frames to the server which cause the 3940 server to send excessive amounts of data toward the new owner of the 3941 IP address. 3943 There are two possible mitigations to this attack. The simplest one 3944 is that a server can unilaterally create a gap in packet-number 3945 space. In the non-attack scenario, the client will send an ACK frame 3946 with the larger value for largest acknowledged. In the attack 3947 scenario, the attacker could acknowledge a packet in the gap. If the 3948 server sees an acknowledgment for a packet that was never sent, the 3949 connection can be aborted. 3951 The second mitigation is that the server can require that 3952 acknowledgments for sent packets match the encryption level of the 3953 sent packet. This mitigation is useful if the connection has an 3954 ephemeral forward-secure key that is generated and used for every new 3955 connection. If a packet sent is protected with a forward-secure key, 3956 then any acknowledgments that are received for them MUST also be 3957 forward-secure protected. Since the attacker will not have the 3958 forward secure key, the attacker will not be able to generate 3959 forward-secure protected packets with ACK frames. 3961 13.2. Slowloris Attacks 3963 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 3964 connections to the target endpoint open and hold them open as long as 3965 possible. These attacks can be executed against a QUIC endpoint by 3966 generating the minimum amount of activity necessary to avoid being 3967 closed for inactivity. This might involve sending small amounts of 3968 data, gradually opening flow control windows in order to control the 3969 sender rate, or manufacturing ACK frames that simulate a high loss 3970 rate. 3972 QUIC deployments SHOULD provide mitigations for the Slowloris 3973 attacks, such as increasing the maximum number of clients the server 3974 will allow, limiting the number of connections a single IP address is 3975 allowed to make, imposing restrictions on the minimum transfer speed 3976 a connection is allowed to have, and restricting the length of time 3977 an endpoint is allowed to stay connected. 3979 13.3. Stream Fragmentation and Reassembly Attacks 3981 An adversarial endpoint might intentionally fragment the data on 3982 stream buffers in order to cause disproportionate memory commitment. 3983 An adversarial endpoint could open a stream and send some STREAM 3984 frames containing arbitrary fragments of the stream content. 3986 The attack is mitigated if flow control windows correspond to 3987 available memory. However, some receivers will over-commit memory 3988 and advertise flow control offsets in the aggregate that exceed 3989 actual available memory. The over-commitment strategy can lead to 3990 better performance when endpoints are well behaved, but renders 3991 endpoints vulnerable to the stream fragmentation attack. 3993 QUIC deployments SHOULD provide mitigations against the stream 3994 fragmentation attack. Mitigations could consist of avoiding over- 3995 committing memory, delaying reassembly of STREAM frames, implementing 3996 heuristics based on the age and duration of reassembly holes, or some 3997 combination. 3999 13.4. Stream Commitment Attack 4001 An adversarial endpoint can open lots of streams, exhausting state on 4002 an endpoint. The adversarial endpoint could repeat the process on a 4003 large number of connections, in a manner similar to SYN flooding 4004 attacks in TCP. 4006 Normally, clients will open streams sequentially, as explained in 4007 Section 10.1. However, when several streams are initiated at short 4008 intervals, transmission error may cause STREAM DATA frames opening 4009 streams to be received out of sequence. A receiver is obligated to 4010 open intervening streams if a higher-numbered stream ID is received. 4011 Thus, on a new connection, opening stream 2000001 opens 1 million 4012 streams, as required by the specification. 4014 The number of active streams is limited by the concurrent stream 4015 limit transport parameter, as explained in Section 10.4. If chosen 4016 judisciously, this limit mitigates the effect of the stream 4017 commitment attack. However, setting the limit too low could affect 4018 performance when applications expect to open large number of streams. 4020 14. IANA Considerations 4022 14.1. QUIC Transport Parameter Registry 4024 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 4025 under a "QUIC Protocol" heading. 4027 The "QUIC Transport Parameters" registry governs a 16-bit space. 4028 This space is split into two spaces that are governed by different 4029 policies. Values with the first byte in the range 0x00 to 0xfe (in 4030 hexadecimal) are assigned via the Specification Required policy 4031 [RFC8126]. Values with the first byte 0xff are reserved for Private 4032 Use [RFC8126]. 4034 Registrations MUST include the following fields: 4036 Value: The numeric value of the assignment (registrations will be 4037 between 0x0000 and 0xfeff). 4039 Parameter Name: A short mnemonic for the parameter. 4041 Specification: A reference to a publicly available specification for 4042 the value. 4044 The nominated expert(s) verify that a specification exists and is 4045 readily accessible. The expert(s) are encouraged to be biased 4046 towards approving registrations unless they are abusive, frivolous, 4047 or actively harmful (not merely aesthetically displeasing, or 4048 architecturally dubious). 4050 The initial contents of this registry are shown in Table 7. 4052 +--------+----------------------------+---------------+ 4053 | Value | Parameter Name | Specification | 4054 +--------+----------------------------+---------------+ 4055 | 0x0000 | initial_max_stream_data | Section 7.4.1 | 4056 | | | | 4057 | 0x0001 | initial_max_data | Section 7.4.1 | 4058 | | | | 4059 | 0x0002 | initial_max_stream_id_bidi | Section 7.4.1 | 4060 | | | | 4061 | 0x0003 | idle_timeout | Section 7.4.1 | 4062 | | | | 4063 | 0x0004 | omit_connection_id | Section 7.4.1 | 4064 | | | | 4065 | 0x0005 | max_packet_size | Section 7.4.1 | 4066 | | | | 4067 | 0x0006 | stateless_reset_token | Section 7.4.1 | 4068 | | | | 4069 | 0x0007 | ack_delay_exponent | Section 7.4.1 | 4070 | | | | 4071 | 0x0008 | initial_max_stream_id_uni | Section 7.4.1 | 4072 +--------+----------------------------+---------------+ 4074 Table 7: Initial QUIC Transport Parameters Entries 4076 14.2. QUIC Transport Error Codes Registry 4078 IANA [SHALL add/has added] a registry for "QUIC Transport Error 4079 Codes" under a "QUIC Protocol" heading. 4081 The "QUIC Transport Error Codes" registry governs a 16-bit space. 4082 This space is split into two spaces that are governed by different 4083 policies. Values with the first byte in the range 0x00 to 0xfe (in 4084 hexadecimal) are assigned via the Specification Required policy 4085 [RFC8126]. Values with the first byte 0xff are reserved for Private 4086 Use [RFC8126]. 4088 Registrations MUST include the following fields: 4090 Value: The numeric value of the assignment (registrations will be 4091 between 0x0000 and 0xfeff). 4093 Code: A short mnemonic for the parameter. 4095 Description: A brief description of the error code semantics, which 4096 MAY be a summary if a specification reference is provided. 4098 Specification: A reference to a publicly available specification for 4099 the value. 4101 The initial contents of this registry are shown in Table 8. Note 4102 that FRAME_ERROR takes the range from 0x100 to 0x1FF and private use 4103 occupies the range from 0xFE00 to 0xFFFF. 4105 +-----------+------------------------+---------------+--------------+ 4106 | Value | Error | Description | Specificatio | 4107 | | | | n | 4108 +-----------+------------------------+---------------+--------------+ 4109 | 0x0 | NO_ERROR | No error | Section 12.3 | 4110 | | | | | 4111 | 0x1 | INTERNAL_ERROR | Implementatio | Section 12.3 | 4112 | | | n error | | 4113 | | | | | 4114 | 0x2 | SERVER_BUSY | Server | Section 12.3 | 4115 | | | currently | | 4116 | | | busy | | 4117 | | | | | 4118 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 12.3 | 4119 | | | error | | 4120 | | | | | 4121 | 0x4 | STREAM_ID_ERROR | Invalid | Section 12.3 | 4122 | | | stream ID | | 4123 | | | | | 4124 | 0x5 | STREAM_STATE_ERROR | Frame | Section 12.3 | 4125 | | | received in | | 4126 | | | invalid | | 4127 | | | stream state | | 4128 | | | | | 4129 | 0x6 | FINAL_OFFSET_ERROR | Change to | Section 12.3 | 4130 | | | final stream | | 4131 | | | offset | | 4132 | | | | | 4133 | 0x7 | FRAME_FORMAT_ERROR | Generic frame | Section 12.3 | 4134 | | | format error | | 4135 | | | | | 4136 | 0x8 | TRANSPORT_PARAMETER_ER | Error in | Section 12.3 | 4137 | | ROR | transport | | 4138 | | | parameters | | 4139 | | | | | 4140 | 0x9 | VERSION_NEGOTIATION_ER | Version | Section 12.3 | 4141 | | ROR | negotiation | | 4142 | | | failure | | 4143 | | | | | 4144 | 0xA | PROTOCOL_VIOLATION | Generic | Section 12.3 | 4145 | | | protocol | | 4146 | | | violation | | 4147 | | | | | 4148 | 0xB | UNSOLICITED_PATH_RESPO | Unsolicited | Section 12.3 | 4149 | | NSE | PATH_RESPONSE | | 4150 | | | frame | | 4151 | | | | | 4152 | 0x100-0x1 | FRAME_ERROR | Specific | Section 12.3 | 4153 | FF | | frame format | | 4154 | | | error | | 4155 +-----------+------------------------+---------------+--------------+ 4157 Table 8: Initial QUIC Transport Error Codes Entries 4159 15. References 4161 15.1. Normative References 4163 [I-D.ietf-tls-tls13] 4164 Rescorla, E., "The Transport Layer Security (TLS) Protocol 4165 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 4166 July 2017. 4168 [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 4169 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 4170 . 4172 [PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4173 DOI 10.17487/RFC1191, November 1990, 4174 . 4176 [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 4177 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 4178 DOI 10.17487/RFC8201, July 2017, 4179 . 4181 [QUIC-RECOVERY] 4182 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 4183 and Congestion Control", draft-ietf-quic-recovery-10 (work 4184 in progress), March 2018. 4186 [QUIC-TLS] 4187 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 4188 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 4189 tls-10 (work in progress), March 2018. 4191 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4192 DOI 10.17487/RFC1191, November 1990, 4193 . 4195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4196 Requirement Levels", BCP 14, RFC 2119, 4197 DOI 10.17487/RFC2119, March 1997, 4198 . 4200 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 4201 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 4202 2003, . 4204 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 4205 "Randomness Requirements for Security", BCP 106, RFC 4086, 4206 DOI 10.17487/RFC4086, June 2005, 4207 . 4209 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 4210 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 4211 . 4213 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4214 Writing an IANA Considerations Section in RFCs", BCP 26, 4215 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4216 . 4218 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4219 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4220 May 2017, . 4222 15.2. Informative References 4224 [EARLY-DESIGN] 4225 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 4226 December 2013, . 4228 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 4229 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 4230 DOI 10.17487/RFC7540, May 2015, 4231 . 4233 [QUIC-INVARIANTS] 4234 Thomson, M., "Version-Independent Properties of QUIC", 4235 draft-ietf-quic-invariants-00 (work in progress), March 4236 2018. 4238 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4239 Hashing for Message Authentication", RFC 2104, 4240 DOI 10.17487/RFC2104, February 1997, 4241 . 4243 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 4244 RFC 2360, DOI 10.17487/RFC2360, June 1998, 4245 . 4247 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 4248 Translation (NAT) Behavioral Requirements for Unicast 4249 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 4250 2007, . 4252 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 4253 Key Derivation Function (HKDF)", RFC 5869, 4254 DOI 10.17487/RFC5869, May 2010, 4255 . 4257 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 4258 "TCP Extensions for Multipath Operation with Multiple 4259 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 4260 . 4262 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 4263 "Transport Layer Security (TLS) Application-Layer Protocol 4264 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 4265 July 2014, . 4267 [SLOWLORIS] 4268 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 4269 . 4272 [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer 4273 Communication Review Vol. 37, pp. 361, 4274 DOI 10.1145/1282427.1282421, October 2007. 4276 15.3. URIs 4278 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 4280 [2] https://github.com/quicwg 4282 [3] https://github.com/quicwg/base-drafts/labels/-transport 4284 [4] https://github.com/quicwg/base-drafts/wiki/QUIC-Versions 4286 Appendix A. Contributors 4288 The original authors of this specification were Ryan Hamilton, Jana 4289 Iyengar, Ian Swett, and Alyssa Wilk. 4291 The original design and rationale behind this protocol draw 4292 significantly from work by Jim Roskind [EARLY-DESIGN]. In 4293 alphabetical order, the contributors to the pre-IETF QUIC project at 4294 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 4295 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 4296 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 4297 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 4298 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 4300 Appendix B. Acknowledgments 4302 Special thanks are due to the following for helping shape pre-IETF 4303 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 4304 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 4306 This document has benefited immensely from various private 4307 discussions and public ones on the quic@ietf.org and proto- 4308 quic@chromium.org mailing lists. Our thanks to all. 4310 Appendix C. Change Log 4312 *RFC Editor's Note:* Please remove this section prior to 4313 publication of a final version of this document. 4315 Issue and pull request numbers are listed with a leading octothorp. 4317 C.1. Since draft-ietf-quic-transport-09 4319 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 4320 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 4321 (#1091, #1086) 4323 o A server can now only send 3 packets without validating the client 4324 address (#38, #1090) 4326 o Delivery order of stream data is no longer strongly specified 4327 (#252, #1070) 4329 o Rework of packet handling and version negotiation (#1038) 4331 o Stream 0 is now exempt from flow control until the handshake 4332 completes (#1074, #725, #1082) 4334 o Improved retransmission rules for all frame types: information is 4335 retransmitted, not packets or frames (#463, #765, #1095, #1053) 4337 o Added an error code for server busy signals (#1137) 4339 C.2. Since draft-ietf-quic-transport-08 4341 o Clarified requirements for BLOCKED usage (#65, #924) 4343 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 4344 #928) 4346 o GAP limitation in ACK Frame (#613) 4348 o Improved PMTUD description (#614, #1036) 4350 o Clarified stream state machine (#634, #662, #894) 4352 o Reserved versions don't need to be generated deterministically 4353 (#831, #931) 4355 o You don't always need the draining period (#871) 4357 o Stateless reset clarified as version-specific (#930, #986) 4359 o initial_max_stream_id_x transport parameters are optional (#970, 4360 #971) 4362 o Ack Delay assumes a default value during the handshake (#1007, 4363 #1009) 4365 o Removed transport parameters from NewSessionTicket (#1015) 4367 C.3. Since draft-ietf-quic-transport-07 4369 o The long header now has version before packet number (#926, #939) 4371 o Rename and consolidate packet types (#846, #822, #847) 4373 o Packet types are assigned new codepoints and the Connection ID 4374 Flag is inverted (#426, #956) 4376 o Removed type for Version Negotiation and use Version 0 (#963, 4377 #968) 4379 o Streams are split into unidirectional and bidirectional (#643, 4380 #656, #720, #872, #175, #885) 4382 * Stream limits now have separate uni- and bi-directinal 4383 transport parameters (#909, #958) 4385 * Stream limit transport parameters are now optional and default 4386 to 0 (#970, #971) 4388 o The stream state machine has been split into read and write (#634, 4389 #894) 4391 o Employ variable-length integer encodings throughout (#595) 4393 o Improvements to connection close 4395 * Added distinct closing and draining states (#899, #871) 4397 * Draining period can terminate early (#869, #870) 4399 * Clarifications about stateless reset (#889, #890) 4401 o Address validation for connection migration (#161, #732, #878) 4403 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 4405 o negotiated_version is sent in server transport parameters (#710, 4406 #959) 4408 o Increased the range over which packet numbers are randomized 4409 (#864, #850, #964) 4411 C.4. Since draft-ietf-quic-transport-06 4413 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 4415 o Split error code space between application and transport (#485) 4417 o Stateless reset token moved to end (#820) 4419 o 1-RTT-protected long header types removed (#848) 4421 o No acknowledgments during draining period (#852) 4423 o Remove "application close" as a separate close type (#854) 4425 o Remove timestamps from the ACK frame (#841) 4427 o Require transport parameters to only appear once (#792) 4429 C.5. Since draft-ietf-quic-transport-05 4431 o Stateless token is server-only (#726) 4433 o Refactor section on connection termination (#733, #748, #328, 4434 #177) 4436 o Limit size of Version Negotiation packet (#585) 4438 o Clarify when and what to ack (#736) 4440 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 4442 o Clarify Keep-alive requirements (#729) 4444 C.6. Since draft-ietf-quic-transport-04 4446 o Introduce STOP_SENDING frame, RST_STREAM only resets in one 4447 direction (#165) 4449 o Removed GOAWAY; application protocols are responsible for graceful 4450 shutdown (#696) 4452 o Reduced the number of error codes (#96, #177, #184, #211) 4454 o Version validation fields can't move or change (#121) 4456 o Removed versions from the transport parameters in a 4457 NewSessionTicket message (#547) 4459 o Clarify the meaning of "bytes in flight" (#550) 4461 o Public reset is now stateless reset and not visible to the path 4462 (#215) 4464 o Reordered bits and fields in STREAM frame (#620) 4466 o Clarifications to the stream state machine (#572, #571) 4468 o Increased the maximum length of the Largest Acknowledged field in 4469 ACK frames to 64 bits (#629) 4471 o truncate_connection_id is renamed to omit_connection_id (#659) 4473 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 4474 #328) 4476 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 4478 C.7. Since draft-ietf-quic-transport-03 4480 o Change STREAM and RST_STREAM layout 4482 o Add MAX_STREAM_ID settings 4484 C.8. Since draft-ietf-quic-transport-02 4486 o The size of the initial packet payload has a fixed minimum (#267, 4487 #472) 4489 o Define when Version Negotiation packets are ignored (#284, #294, 4490 #241, #143, #474) 4492 o The 64-bit FNV-1a algorithm is used for integrity protection of 4493 unprotected packets (#167, #480, #481, #517) 4495 o Rework initial packet types to change how the connection ID is 4496 chosen (#482, #442, #493) 4498 o No timestamps are forbidden in unprotected packets (#542, #429) 4500 o Cryptographic handshake is now on stream 0 (#456) 4502 o Remove congestion control exemption for cryptographic handshake 4503 (#248, #476) 4505 o Version 1 of QUIC uses TLS; a new version is needed to use a 4506 different handshake protocol (#516) 4508 o STREAM frames have a reduced number of offset lengths (#543, #430) 4510 o Split some frames into separate connection- and stream- level 4511 frames (#443) 4513 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 4515 * BLOCKED split to match WINDOW_UPDATE split (#454) 4517 * Define STREAM_ID_NEEDED frame (#455) 4519 o A NEW_CONNECTION_ID frame supports connection migration without 4520 linkability (#232, #491, #496) 4522 o Transport parameters for 0-RTT are retained from a previous 4523 connection (#405, #513, #512) 4525 * A client in 0-RTT no longer required to reset excess streams 4526 (#425, #479) 4528 o Expanded security considerations (#440, #444, #445, #448) 4530 C.9. Since draft-ietf-quic-transport-01 4532 o Defined short and long packet headers (#40, #148, #361) 4534 o Defined a versioning scheme and stable fields (#51, #361) 4536 o Define reserved version values for "greasing" negotiation (#112, 4537 #278) 4539 o The initial packet number is randomized (#35, #283) 4541 o Narrow the packet number encoding range requirement (#67, #286, 4542 #299, #323, #356) 4544 o Defined client address validation (#52, #118, #120, #275) 4546 o Define transport parameters as a TLS extension (#49, #122) 4548 o SCUP and COPT parameters are no longer valid (#116, #117) 4550 o Transport parameters for 0-RTT are either remembered from before, 4551 or assume default values (#126) 4553 o The server chooses connection IDs in its final flight (#119, #349, 4554 #361) 4556 o The server echoes the Connection ID and packet number fields when 4557 sending a Version Negotiation packet (#133, #295, #244) 4559 o Defined a minimum packet size for the initial handshake packet 4560 from the client (#69, #136, #139, #164) 4562 o Path MTU Discovery (#64, #106) 4564 o The initial handshake packet from the client needs to fit in a 4565 single packet (#338) 4567 o Forbid acknowledgment of packets containing only ACK and PADDING 4568 (#291) 4570 o Require that frames are processed when packets are acknowledged 4571 (#381, #341) 4573 o Removed the STOP_WAITING frame (#66) 4575 o Don't require retransmission of old timestamps for lost ACK frames 4576 (#308) 4578 o Clarified that frames are not retransmitted, but the information 4579 in them can be (#157, #298) 4581 o Error handling definitions (#335) 4583 o Split error codes into four sections (#74) 4585 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 4586 (#289) 4588 o Define packet protection rules (#336) 4590 o Require that stream be entirely delivered or reset, including 4591 acknowledgment of all STREAM frames or the RST_STREAM, before it 4592 closes (#381) 4594 o Remove stream reservation from state machine (#174, #280) 4596 o Only stream 1 does not contribute to connection-level flow control 4597 (#204) 4599 o Stream 1 counts towards the maximum concurrent stream limit (#201, 4600 #282) 4602 o Remove connection-level flow control exclusion for some streams 4603 (except 1) (#246) 4605 o RST_STREAM affects connection-level flow control (#162, #163) 4607 o Flow control accounting uses the maximum data offset on each 4608 stream, rather than bytes received (#378) 4610 o Moved length-determining fields to the start of STREAM and ACK 4611 (#168, #277) 4613 o Added the ability to pad between frames (#158, #276) 4615 o Remove error code and reason phrase from GOAWAY (#352, #355) 4617 o GOAWAY includes a final stream number for both directions (#347) 4619 o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a 4620 consistent offset (#249) 4622 o Defined priority as the responsibility of the application protocol 4623 (#104, #303) 4625 C.10. Since draft-ietf-quic-transport-00 4627 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 4629 o Defined versioning 4631 o Reworked description of packet and frame layout 4633 o Error code space is divided into regions for each component 4635 o Use big endian for all numeric values 4637 C.11. Since draft-hamilton-quic-transport-protocol-01 4639 o Adopted as base for draft-ietf-quic-tls 4641 o Updated authors/editors list 4643 o Added IANA Considerations section 4645 o Moved Contributors and Acknowledgments to appendices 4647 Authors' Addresses 4649 Jana Iyengar (editor) 4650 Fastly 4652 Email: jri.ietf@gmail.com 4653 Martin Thomson (editor) 4654 Mozilla 4656 Email: martin.thomson@gmail.com