idnits 2.17.1 draft-ietf-quic-transport-09.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 (January 28, 2018) is 2279 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 4134 -- Looks like a reference, but probably isn't: '2' on line 4136 -- Looks like a reference, but probably isn't: '3' on line 4138 -- Looks like a reference, but probably isn't: '4' on line 4140 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-09 -- 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) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 4 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 Google 4 Intended status: Standards Track M. Thomson, Ed. 5 Expires: August 1, 2018 Mozilla 6 January 28, 2018 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-09 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 August 1, 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 . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 8 73 4. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Packet Types and Formats . . . . . . . . . . . . . . . . . . 9 75 5.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Version Negotiation Packet . . . . . . . . . . . . . . . 13 78 5.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 14 79 5.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 14 80 5.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 15 81 5.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 15 82 5.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 16 83 5.6. Connection ID . . . . . . . . . . . . . . . . . . . . . . 16 84 5.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 17 85 5.7.1. Initial Packet Number . . . . . . . . . . . . . . . . 18 86 5.8. Handling Packets from Different Versions . . . . . . . . 18 87 6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 19 88 7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 20 89 7.1. Matching Packets to Connections . . . . . . . . . . . . . 21 90 7.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 22 91 7.2.1. Sending Version Negotiation Packets . . . . . . . . . 22 92 7.2.2. Handling Version Negotiation Packets . . . . . . . . 23 93 7.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 23 94 7.3. Cryptographic and Transport Handshake . . . . . . . . . . 24 95 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 25 96 7.4.1. Transport Parameter Definitions . . . . . . . . . . . 27 97 7.4.2. Values of Transport Parameters for 0-RTT . . . . . . 29 98 7.4.3. New Transport Parameters . . . . . . . . . . . . . . 29 99 7.4.4. Version Negotiation Validation . . . . . . . . . . . 30 100 7.5. Stateless Retries . . . . . . . . . . . . . . . . . . . . 31 101 7.6. Proof of Source Address Ownership . . . . . . . . . . . . 32 102 7.6.1. Client Address Validation Procedure . . . . . . . . . 32 103 7.6.2. Address Validation on Session Resumption . . . . . . 33 104 7.6.3. Address Validation Token Integrity . . . . . . . . . 34 105 7.7. Connection Migration . . . . . . . . . . . . . . . . . . 34 106 7.7.1. Privacy Implications of Connection Migration . . . . 35 107 7.7.2. Address Validation for Migrated Connections . . . . . 36 108 7.8. Spurious Connection Migrations . . . . . . . . . . . . . 37 109 7.9. Connection Termination . . . . . . . . . . . . . . . . . 38 110 7.9.1. Closing and Draining Connection States . . . . . . . 38 111 7.9.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 40 112 7.9.3. Immediate Close . . . . . . . . . . . . . . . . . . . 40 113 7.9.4. Stateless Reset . . . . . . . . . . . . . . . . . . . 41 114 8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 44 115 8.1. Variable-Length Integer Encoding . . . . . . . . . . . . 44 116 8.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 45 117 8.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 45 118 8.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 46 119 8.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 47 120 8.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 47 121 8.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 48 122 8.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 49 123 8.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 49 124 8.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 50 125 8.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 51 126 8.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 51 127 8.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 52 128 8.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 52 129 8.15. PONG Frame . . . . . . . . . . . . . . . . . . . . . . . 53 130 8.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 53 131 8.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 55 132 8.16.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 56 133 8.16.3. ACK Frames and Packet Protection . . . . . . . . . . 57 134 8.17. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 58 135 9. Packetization and Reliability . . . . . . . . . . . . . . . . 60 136 9.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 61 137 9.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 62 138 9.2.1. Special Considerations for PMTU Discovery . . . . . . 63 139 9.2.2. Special Considerations for Packetization Layer PMTU 140 Discovery . . . . . . . . . . . . . . . . . . . . . . 63 142 10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 64 143 10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 64 144 10.2. Stream States . . . . . . . . . . . . . . . . . . . . . 65 145 10.2.1. Send Stream States . . . . . . . . . . . . . . . . . 66 146 10.2.2. Receive Stream States . . . . . . . . . . . . . . . 68 147 10.2.3. Permitted Frame Types . . . . . . . . . . . . . . . 71 148 10.2.4. Bidirectional Stream States . . . . . . . . . . . . 71 149 10.3. Solicited State Transitions . . . . . . . . . . . . . . 72 150 10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 73 151 10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 74 152 10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 74 153 11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 75 154 11.1. Edge Cases and Other Considerations . . . . . . . . . . 76 155 11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 77 156 11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 77 157 11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 78 158 11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 78 159 11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 78 160 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 79 161 12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79 162 12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 80 163 12.3. Transport Error Codes . . . . . . . . . . . . . . . . . 80 164 12.4. Application Protocol Error Codes . . . . . . . . . . . . 82 165 13. Security and Privacy Considerations . . . . . . . . . . . . . 82 166 13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 82 167 13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 83 168 13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 83 169 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 83 170 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 171 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 84 172 14.2. QUIC Transport Error Codes Registry . . . . . . . . . . 85 173 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 174 15.1. Normative References . . . . . . . . . . . . . . . . . . 88 175 15.2. Informative References . . . . . . . . . . . . . . . . . 89 176 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 90 177 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 90 178 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 90 179 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 91 180 C.1. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 91 181 C.2. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 91 182 C.3. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 92 183 C.4. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 93 184 C.5. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 93 185 C.6. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 94 186 C.7. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 94 187 C.8. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 95 188 C.9. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 97 189 C.10. Since draft-hamilton-quic-transport-protocol-01 . . . . . 97 191 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 193 1. Introduction 195 QUIC is a multiplexed and secure transport protocol that runs on top 196 of UDP. QUIC aims to provide a flexible set of features that allow 197 it to be a general-purpose transport for multiple applications. 199 QUIC implements techniques learned from experience with TCP, SCTP and 200 other transport protocols. QUIC uses UDP as substrate so as to not 201 require changes to legacy client operating systems and middleboxes to 202 be deployable. QUIC authenticates all of its headers and encrypts 203 most of the data it exchanges, including its signaling. This allows 204 the protocol to evolve without incurring a dependency on upgrades to 205 middleboxes. This document describes the core QUIC protocol, 206 including the conceptual design, wire format, and mechanisms of the 207 QUIC protocol for connection establishment, stream multiplexing, 208 stream and connection-level flow control, and data reliability. 210 Accompanying documents describe QUIC's loss detection and congestion 211 control [QUIC-RECOVERY], and the use of TLS 1.3 for key negotiation 212 [QUIC-TLS]. 214 2. Conventions and Definitions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 Definitions of terms that are used in this document: 224 Client: The endpoint initiating a QUIC connection. 226 Server: The endpoint accepting incoming QUIC connections. 228 Endpoint: The client or server end of a connection. 230 Stream: A logical, bi-directional channel of ordered bytes within a 231 QUIC connection. 233 Connection: A conversation between two QUIC endpoints with a single 234 encryption context that multiplexes streams within it. 236 Connection ID: The 64-bit unsigned number used as an identifier for 237 a QUIC connection. 239 QUIC packet: A well-formed UDP payload that can be parsed by a QUIC 240 receiver. 242 2.1. Notational Conventions 244 Packet and frame diagrams use the format described in Section 3.1 of 245 [RFC2360], with the following additional conventions: 247 [x] Indicates that x is optional 249 x (A) Indicates that x is A bits long 251 x (A/B/C) ... Indicates that x is one of A, B, or C bits long 253 x (i) ... Indicates that x uses the variable-length encoding in 254 Section 8.1 256 x (*) ... Indicates that x is variable-length 258 3. A QUIC Overview 260 This section briefly describes QUIC's key mechanisms and benefits. 261 Key strengths of QUIC include: 263 o Low-latency connection establishment 265 o Multiplexing without head-of-line blocking 267 o Authenticated and encrypted header and payload 269 o Rich signaling for congestion control and loss recovery 271 o Stream and connection flow control 273 o Connection migration and resilience to NAT rebinding 275 o Version negotiation 277 3.1. Low-Latency Connection Establishment 279 QUIC relies on a combined cryptographic and transport handshake for 280 setting up a secure transport connection. QUIC connections are 281 expected to commonly use 0-RTT handshakes, meaning that for most QUIC 282 connections, data can be sent immediately following the client 283 handshake packet, without waiting for a reply from the server. QUIC 284 provides a dedicated stream (Stream ID 0) to be used for performing 285 the cryptographic handshake and QUIC options negotiation. The format 286 of the QUIC options and parameters used during negotiation are 287 described in this document, but the handshake protocol that runs on 288 Stream ID 0 is described in the accompanying cryptographic handshake 289 draft [QUIC-TLS]. 291 3.2. Stream Multiplexing 293 When application messages are transported over TCP, independent 294 application messages can suffer from head-of-line blocking. When an 295 application multiplexes many streams atop TCP's single-bytestream 296 abstraction, a loss of a TCP segment results in blocking of all 297 subsequent segments until a retransmission arrives, irrespective of 298 the application streams that are encapsulated in subsequent segments. 299 QUIC ensures that lost packets carrying data for an individual stream 300 only impact that specific stream. Data received on other streams can 301 continue to be reassembled and delivered to the application. 303 3.3. Rich Signaling for Congestion Control and Loss Recovery 305 QUIC's packet framing and acknowledgments carry rich information that 306 help both congestion control and loss recovery in fundamental ways. 307 Each QUIC packet carries a new packet number, including those 308 carrying retransmitted data. This obviates the need for a separate 309 mechanism to distinguish acknowledgments for retransmissions from 310 those for original transmissions, avoiding TCP's retransmission 311 ambiguity problem. QUIC acknowledgments also explicitly encode the 312 delay between the receipt of a packet and its acknowledgment being 313 sent, and together with the monotonically-increasing packet numbers, 314 this allows for precise network roundtrip-time (RTT) calculation. 315 QUIC's ACK frames support multiple ACK blocks, so QUIC is more 316 resilient to reordering than TCP with SACK support, as well as able 317 to keep more bytes on the wire when there is reordering or loss. 319 3.4. Stream and Connection Flow Control 321 QUIC implements stream- and connection-level flow control. At a high 322 level, a QUIC receiver advertises the maximum amount of data that it 323 is willing to receive on each stream. As data is sent, received, and 324 delivered on a particular stream, the receiver sends MAX_STREAM_DATA 325 frames that increase the advertised limit for that stream, allowing 326 the peer to send more data on that stream. 328 In addition to this stream-level flow control, QUIC implements 329 connection-level flow control to limit the aggregate buffer that a 330 QUIC receiver is willing to allocate to all streams on a connection. 331 Connection-level flow control works in the same way as stream-level 332 flow control, but the bytes delivered and the limits are aggregated 333 across all streams. 335 3.5. Authenticated and Encrypted Header and Payload 337 TCP headers appear in plaintext on the wire and are not 338 authenticated, causing a plethora of injection and header 339 manipulation issues for TCP, such as receive-window manipulation and 340 sequence-number overwriting. While some of these are mechanisms used 341 by middleboxes to improve TCP performance, others are active attacks. 342 Even "performance-enhancing" middleboxes that routinely interpose on 343 the transport state machine end up limiting the evolvability of the 344 transport protocol, as has been observed in the design of MPTCP 345 [RFC6824] and in its subsequent deployability issues. 347 Generally, QUIC packets are always authenticated and the payload is 348 typically fully encrypted. The parts of the packet header which are 349 not encrypted are still authenticated by the receiver, so as to 350 thwart any packet injection or manipulation by third parties. Some 351 early handshake packets, such as the Version Negotiation packet, are 352 not encrypted, but information sent in these unencrypted handshake 353 packets is later verified as part of cryptographic processing. 355 3.6. Connection Migration and Resilience to NAT Rebinding 357 QUIC connections are identified by a Connection ID, a 64-bit unsigned 358 number randomly generated by the server. QUIC's consistent 359 connection ID allows connections to survive changes to the client's 360 IP and port, such as those caused by NAT rebindings or by the client 361 changing network connectivity to a new address. QUIC provides 362 automatic cryptographic verification of a rebound client, since the 363 client continues to use the same session key for encrypting and 364 decrypting packets. The consistent connection ID can be used to 365 allow migration of the connection to a new server IP address as well, 366 since the Connection ID remains consistent across changes in the 367 client's and the server's network addresses. 369 3.7. Version Negotiation 371 QUIC version negotiation allows for multiple versions of the protocol 372 to be deployed and used concurrently. Version negotiation is 373 described in Section 7.2. 375 4. Versions 377 QUIC versions are identified using a 32-bit unsigned number. 379 The version 0x00000000 is reserved to represent version negotiation. 380 This version of the specification is identified by the number 381 0x00000001. 383 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 384 protocol, as described in [QUIC-TLS]. 386 Versions with the most significant 16 bits of the version number 387 cleared are reserved for use in future IETF consensus documents. 389 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 390 forcing version negotiation to be exercised. That is, any version 391 number where the low four bits of all octets is 1010 (in binary). A 392 client or server MAY advertise support for any of these reserved 393 versions. 395 Reserved version numbers will probably never represent a real 396 protocol; a client MAY use one of these version numbers with the 397 expectation that the server will initiate version negotiation; a 398 server MAY advertise support for one of these versions and can expect 399 that clients ignore the value. 401 [[RFC editor: please remove the remainder of this section before 402 publication.]] 404 The version number for the final version of this specification 405 (0x00000001), is reserved for the version of the protocol that is 406 published as an RFC. 408 Version numbers used to identify IETF drafts are created by adding 409 the draft number to 0xff000000. For example, draft-ietf-quic- 410 transport-13 would be identified as 0xff00000D. 412 Implementors are encouraged to register version numbers of QUIC that 413 they are using for private experimentation on the github wiki [4]. 415 5. Packet Types and Formats 417 We first describe QUIC's packet types and their formats, since some 418 are referenced in subsequent mechanisms. 420 All numeric values are encoded in network byte order (that is, big- 421 endian) and all field sizes are in bits. When discussing individual 422 bits of fields, the least significant bit is referred to as bit 0. 423 Hexadecimal notation is used for describing the value of fields. 425 Any QUIC packet has either a long or a short header, as indicated by 426 the Header Form bit. Long headers are expected to be used early in 427 the connection before version negotiation and establishment of 1-RTT 428 keys. Short headers are minimal version-specific headers, which are 429 used after version negotiation and 1-RTT keys are established. 431 5.1. Long Header 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+ 436 |1| Type (7) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 + Connection ID (64) + 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Version (32) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Packet Number (32) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Payload (*) ... 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Figure 1: Long Header Format 451 Long headers are used for packets that are sent prior to the 452 completion of version negotiation and establishment of 1-RTT keys. 453 Once both conditions are met, a sender switches to sending packets 454 using the short header (Section 5.2). The long form allows for 455 special packets - such as the Version Negotiation packet - to be 456 represented in this uniform fixed-length packet format. A long 457 header contains the following fields: 459 Header Form: The most significant bit (0x80) of octet 0 (the first 460 octet) is set to 1 for long headers. 462 Long Packet Type: The remaining seven bits of octet 0 contain the 463 packet type. This field can indicate one of 128 packet types. 464 The types specified for this version are listed in Table 1. 466 Connection ID: Octets 1 through 8 contain the connection ID. 467 Section 5.6 describes the use of this field in more detail. 469 Version: Octets 9 to 12 contain the selected protocol version. This 470 field indicates which version of QUIC is in use and determines how 471 the rest of the protocol fields are interpreted. 473 Packet Number: Octets 13 to 16 contain the packet number. 474 Section 5.7 describes the use of packet numbers. 476 Payload: Octets from 17 onwards (the rest of QUIC packet) are the 477 payload of the packet. 479 The following packet types are defined: 481 +------+-----------------+---------------+ 482 | Type | Name | Section | 483 +------+-----------------+---------------+ 484 | 0x7F | Initial | Section 5.4.1 | 485 | | | | 486 | 0x7E | Retry | Section 5.4.2 | 487 | | | | 488 | 0x7D | Handshake | Section 5.4.3 | 489 | | | | 490 | 0x7C | 0-RTT Protected | Section 5.5 | 491 +------+-----------------+---------------+ 493 Table 1: Long Header Packet Types 495 The header form, packet type, connection ID, packet number and 496 version fields of a long header packet are version-independent. The 497 types of packets defined in Table 1 are version-specific. See 498 Section 5.8 for details on how packets from different versions of 499 QUIC are interpreted. 501 The interpretation of the fields and the payload are specific to a 502 version and packet type. Type-specific semantics for this version 503 are described in the following sections. 505 5.2. Short Header 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+ 510 |0|C|K| Type (5)| 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 + [Connection ID (64)] + 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Packet Number (8/16/32) ... 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Protected Payload (*) ... 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 2: Short Header Format 523 The short header can be used after the version and 1-RTT keys are 524 negotiated. This header form has the following fields: 526 Header Form: The most significant bit (0x80) of octet 0 is set to 0 527 for the short header. 529 Omit Connection ID Flag: The second bit (0x40) of octet 0 indicates 530 whether the Connection ID field is omitted. If set to 0, then the 531 Connection ID field is present; if set to 1, the Connection ID 532 field is omitted. The Connection ID field can only be omitted if 533 the omit_connection_id transport parameter (Section 7.4.1) is 534 specified by the intended recipient of the packet. 536 Key Phase Bit: The third bit (0x20) of octet 0 indicates the key 537 phase, which allows a recipient of a packet to identify the packet 538 protection keys that are used to protect the packet. See 539 [QUIC-TLS] for details. 541 Short Packet Type: The remaining 5 bits of octet 0 include one of 32 542 packet types. Table 2 lists the types that are defined for short 543 packets. 545 Connection ID: If the Omit Connection ID Flag is not set, a 546 connection ID occupies octets 1 through 8 of the packet. See 547 Section 5.6 for more details. 549 Packet Number: The length of the packet number field depends on the 550 packet type. This field can be 1, 2 or 4 octets long depending on 551 the short packet type. 553 Protected Payload: Packets with a short header always include a 554 1-RTT protected payload. 556 The packet type in a short header currently determines only the size 557 of the packet number field. Additional types can be used to signal 558 the presence of other fields. 560 +------+--------------------+ 561 | Type | Packet Number Size | 562 +------+--------------------+ 563 | 0x1F | 1 octet | 564 | | | 565 | 0x1E | 2 octets | 566 | | | 567 | 0x1D | 4 octets | 568 +------+--------------------+ 570 Table 2: Short Header Packet Types 572 The header form, omit connection ID flag, and connection ID of a 573 short header packet are version-independent. The remaining fields 574 are specific to the selected QUIC version. See Section 5.8 for 575 details on how packets from different versions of QUIC are 576 interpreted. 578 5.3. Version Negotiation Packet 580 A Version Negotiation packet is inherently not version-specific, and 581 does not use the packet headers defined above. Upon receipt by a 582 client, it will appear to be a packet using the long header, but will 583 be identified as a Version Negotiation packet based on the Version 584 field. 586 The Version Negotiation packet is a response to a client packet that 587 contains a version that is not supported by the server, and is only 588 sent by servers. 590 The layout of a Version Negotiation packet is: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+ 595 |1| Unused (7) | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 + Connection ID (64) + 599 | | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Version (32) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Supported Version 1 (32) ... 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | [Supported Version 2 (32)] ... 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 ... 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | [Supported Version N (32)] ... 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure 3: Version Negotiation Packet 614 The value in the Unused field is selected randomly by the server. 615 The Connection ID field echoes the corresponding value from the 616 triggering client packet. This allows clients some assurance that 617 the server received the packet and that the Version Negotiation 618 packet is in fact from the server. The Version field MUST be set to 619 0x00000000. The remainder of the Version Negotiation packet is a 620 list of 32-bit versions which the server supports. 622 A Version Negotiation packet cannot be explicitly acknowledged in an 623 ACK frame by a client. Receiving another Initial packet implicitly 624 acknowledges a Version Negotiation packet. 626 See Section 7.2 for a description of the version negotiation process. 628 5.4. Cryptographic Handshake Packets 630 Once version negotiation is complete, the cryptographic handshake is 631 used to agree on cryptographic keys. The cryptographic handshake is 632 carried in Initial (Section 5.4.1), Retry (Section 5.4.2) and 633 Handshake (Section 5.4.3) packets. 635 All these packets use the long header and contain the current QUIC 636 version in the version field. 638 In order to prevent tampering by version-unaware middleboxes, 639 handshake packets are protected with a connection- and version- 640 specific key, as described in [QUIC-TLS]. This protection does not 641 provide confidentiality or integrity against on-path attackers, but 642 provides some level of protection against off-path attackers. 644 5.4.1. Initial Packet 646 The Initial packet uses long headers with a type value of 0x7F. It 647 carries the first cryptographic handshake message sent by the client. 649 The client populates the connection ID field with randomly selected 650 values, unless it has received a packet from the server. If the 651 client has received a packet from the server, the connection ID field 652 uses the value provided by the server. 654 The first Initial packet that is sent by a client contains a 655 randomized packet number. All subsequent packets contain a packet 656 number that is incremented by one, see (Section 5.7). 658 The payload of a Initial packet consists of a STREAM frame (or 659 frames) for stream 0 containing a cryptographic handshake message, 660 with enough PADDING frames that the packet is at least 1200 octets 661 (see Section 9). The stream in this packet always starts at an 662 offset of 0 (see Section 7.5) and the complete cryptographic 663 handshake message MUST fit in a single packet (see Section 7.3). 665 The client uses the Initial packet type for any packet that contains 666 an initial cryptographic handshake message. This includes all cases 667 where a new packet containing the initial cryptographic message needs 668 to be created, this includes the packets sent after receiving a 669 Version Negotiation (Section 5.3) or Retry packet (Section 5.4.2). 671 5.4.2. Retry Packet 673 A Retry packet uses long headers with a type value of 0x7E. It 674 carries cryptographic handshake messages and acknowledgments. It is 675 used by a server that wishes to perform a stateless retry (see 676 Section 7.5). 678 The server includes a connection ID of its choice in the connection 679 ID field. The client MUST use this connection ID for any subsequent 680 packets that it sends. 682 The packet number field echoes the packet number field from the 683 triggering client packet. 685 A Retry packet is never explicitly acknowledged in an ACK frame by a 686 client. Receiving another Initial packet implicitly acknowledges a 687 Retry packet. 689 After receiving a Retry packet, the client uses a new Initial packet 690 containing the next cryptographic handshake message. The client 691 retains the state of its cryptographic handshake, but discards all 692 transport state. The Initial packet that is generated in response to 693 a Retry packet includes STREAM frames on stream 0 that start again at 694 an offset of 0. 696 Continuing the cryptographic handshake is necessary to ensure that an 697 attacker cannot force a downgrade of any cryptographic parameters. 698 In addition to continuing the cryptographic handshake, the client 699 MUST remember the results of any version negotiation that occurred 700 (see Section 7.2). The client MAY also retain any observed RTT or 701 congestion state that it has accumulated for the flow, but other 702 transport state MUST be discarded. 704 The payload of the Retry packet contains a single STREAM frame on 705 stream 0 with offset 0 containing the server's cryptographic 706 stateless retry material. It MUST NOT contain any other frames. The 707 next STREAM frame sent by the server will also start at stream offset 708 0. 710 5.4.3. Handshake Packet 712 A Handshake packet uses long headers with a type value of 0x7D. It 713 is used to carry acknowledgments and cryptographic handshake messages 714 from the server and client. 716 The connection ID field in a Handshake packet contains a connection 717 ID that is chosen by the server (see Section 5.6). 719 The first Handshake packet sent by a server contains a randomized 720 packet number. This value is increased for each subsequent packet 721 sent by the server as described in Section 5.7. The client 722 increments the packet number from its previous packet by one for each 723 Handshake packet that it sends (which might be an Initial, 0-RTT 724 Protected, or Handshake packet). 726 The payload of this packet contains STREAM frames and could contain 727 PADDING and ACK frames. 729 5.5. Protected Packets 731 Packets that are protected with 0-RTT keys are sent with long 732 headers; all packets protected with 1-RTT keys are sent with short 733 headers. The different packet types explicitly indicate the 734 encryption level and therefore the keys that are used to remove 735 packet protection. 737 Packets protected with 0-RTT keys use a type value of 0x7C. The 738 connection ID field for a 0-RTT packet is selected by the client. 740 The client can send 0-RTT packets after receiving a Handshake packet 741 (Section 5.4.3), if that packet does not complete the handshake. 742 Even if the client receives a different connection ID in the 743 Handshake packet, it MUST continue to use the connection ID selected 744 by the client for 0-RTT packets, see Section 5.6. 746 The version field for protected packets is the current QUIC version. 748 The packet number field contains a packet number, which increases 749 with each packet sent, see Section 5.7 for details. 751 The payload is protected using authenticated encryption. [QUIC-TLS] 752 describes packet protection in detail. After decryption, the 753 plaintext consists of a sequence of frames, as described in 754 Section 6. 756 5.6. Connection ID 758 QUIC connections are identified by their 64-bit Connection ID. All 759 long headers contain a Connection ID. Short headers indicate the 760 presence of a Connection ID using the Omit Connection ID flag. When 761 present, the Connection ID is in the same location in all packet 762 headers, making it straightforward for middleboxes, such as load 763 balancers, to locate and use it. 765 The client MUST choose a random connection ID and use it in Initial 766 packets (Section 5.4.1) and 0-RTT packets (Section 5.5). 768 When the server receives a Initial packet and decides to proceed with 769 the handshake, it chooses a new value for the connection ID and sends 770 that in a Retry (Section 5.4.2) or Handshake (Section 5.4.3) packet. 771 The server MAY choose to use the value that the client initially 772 selects. 774 Once the client receives the connection ID that the server has 775 chosen, it MUST use it for all subsequent Handshake (Section 5.4.3) 776 and 1-RTT (Section 5.5) packets but not for 0-RTT packets 777 (Section 5.5). 779 Server's Version Negotiation (Section 5.3) and Retry (Section 5.4.2) 780 packets MUST use connection ID selected by the client. 782 5.7. Packet Numbers 784 The packet number is an integer in the range 0 to 2^62-1. The value 785 is used in determining the cryptographic nonce for packet encryption. 786 Each endpoint maintains a separate packet number for sending and 787 receiving. The packet number for sending MUST increase by at least 788 one after sending any packet, unless otherwise specified (see 789 Section 5.7.1). 791 A QUIC endpoint MUST NOT reuse a packet number within the same 792 connection (that is, under the same cryptographic keys). If the 793 packet number for sending reaches 2^62 - 1, the sender MUST close the 794 connection without sending a CONNECTION_CLOSE frame or any further 795 packets; a server MAY send a Stateless Reset (Section 7.9.4) in 796 response to further packets that it receives. 798 For the packet header, the number of bits required to represent the 799 packet number are reduced by including only the least significant 800 bits of the packet number. The actual packet number for each packet 801 is reconstructed at the receiver based on the largest packet number 802 received on a successfully authenticated packet. 804 A packet number is decoded by finding the packet number value that is 805 closest to the next expected packet. The next expected packet is the 806 highest received packet number plus one. For example, if the highest 807 successfully authenticated packet had a packet number of 0xaa82f30e, 808 then a packet containing a 16-bit value of 0x1f94 will be decoded as 809 0xaa831f94. 811 The sender MUST use a packet number size able to represent more than 812 twice as large a range than the difference between the largest 813 acknowledged packet and packet number being sent. A peer receiving 814 the packet will then correctly decode the packet number, unless the 815 packet is delayed in transit such that it arrives after many higher- 816 numbered packets have been received. An endpoint SHOULD use a large 817 enough packet number encoding to allow the packet number to be 818 recovered even if the packet arrives after packets that are sent 819 afterwards. 821 As a result, the size of the packet number encoding is at least one 822 more than the base 2 logarithm of the number of contiguous 823 unacknowledged packet numbers, including the new packet. 825 For example, if an endpoint has received an acknowledgment for packet 826 0x6afa2f, sending a packet with a number of 0x6b4264 requires a 827 16-bit or larger packet number encoding; whereas a 32-bit packet 828 number is needed to send a packet with a number of 0x6bc107. 830 Version Negotiation (Section 5.3) and Retry (Section 5.4.2) packets 831 have special rules for populating the packet number field. 833 5.7.1. Initial Packet Number 835 The initial value for packet number MUST be selected randomly from a 836 range between 0 and 2^32 - 1025 (inclusive). This value is selected 837 so that Initial and Handshake packets exercise as many possible 838 values for the Packet Number field as possible. 840 Limiting the range allows both for loss of packets and for any 841 stateless exchanges. Packet numbers are incremented for subsequent 842 packets, but packet loss and stateless handling can both mean that 843 the first packet sent by an endpoint isn't necessarily the first 844 packet received by its peer. The first packet received by a peer 845 cannot be 2^32 or greater or the recipient will incorrectly assume a 846 packet number that is 2^32 values lower and discard the packet. 848 Use of a secure random number generator [RFC4086] is not necessary 849 for generating the initial packet number, nor is it necessary that 850 the value be uniformly distributed. 852 5.8. Handling Packets from Different Versions 854 Between different versions the following things are guaranteed to 855 remain constant: 857 o the location of the header form flag, 859 o the location of the Omit Connection ID flag in short headers, 861 o the location and size of the Connection ID field in both header 862 forms, 864 o the location and size of the Version field in long headers, 866 o the format and semantics of the Version Negotiation packet. 868 Implementations MUST assume that an unsupported version uses an 869 unknown packet format. All other fields MUST be ignored when 870 processing a packet that contains an unsupported version. 872 6. Frames and Frame Types 874 The payload of all packets, after removing packet protection, 875 consists of a sequence of frames, as shown in Figure 4. Version 876 Negotiation and Stateless Reset do not contain frames. 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Frame 1 (*) ... 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Frame 2 (*) ... 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 ... 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Frame N (*) ... 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Figure 4: Contents of Protected Payload 892 Protected payloads MUST contain at least one frame, and MAY contain 893 multiple frames and multiple frame types. 895 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 896 packet boundary. Each frame begins with a Frame Type byte, 897 indicating its type, followed by additional type-dependent fields: 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type (8) | Type-Dependent Fields (*) ... 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Figure 5: Generic Frame Layout 907 Frame types are listed in Table 3. Note that the Frame Type byte in 908 STREAM and ACK frames is used to carry other frame-specific flags. 909 For all other frames, the Frame Type byte simply identifies the 910 frame. These frames are explained in more detail as they are 911 referenced later in the document. 913 +-------------+-------------------+--------------+ 914 | Type Value | Frame Type Name | Definition | 915 +-------------+-------------------+--------------+ 916 | 0x00 | PADDING | Section 8.2 | 917 | | | | 918 | 0x01 | RST_STREAM | Section 8.3 | 919 | | | | 920 | 0x02 | CONNECTION_CLOSE | Section 8.4 | 921 | | | | 922 | 0x03 | APPLICATION_CLOSE | Section 8.5 | 923 | | | | 924 | 0x04 | MAX_DATA | Section 8.6 | 925 | | | | 926 | 0x05 | MAX_STREAM_DATA | Section 8.7 | 927 | | | | 928 | 0x06 | MAX_STREAM_ID | Section 8.8 | 929 | | | | 930 | 0x07 | PING | Section 8.9 | 931 | | | | 932 | 0x08 | BLOCKED | Section 8.10 | 933 | | | | 934 | 0x09 | STREAM_BLOCKED | Section 8.11 | 935 | | | | 936 | 0x0a | STREAM_ID_BLOCKED | Section 8.12 | 937 | | | | 938 | 0x0b | NEW_CONNECTION_ID | Section 8.13 | 939 | | | | 940 | 0x0c | STOP_SENDING | Section 8.14 | 941 | | | | 942 | 0x0d | PONG | Section 8.15 | 943 | | | | 944 | 0x0e | ACK | Section 8.16 | 945 | | | | 946 | 0x10 - 0x17 | STREAM | Section 8.17 | 947 +-------------+-------------------+--------------+ 949 Table 3: Frame Types 951 7. Life of a Connection 953 A QUIC connection is a single conversation between two QUIC 954 endpoints. QUIC's connection establishment intertwines version 955 negotiation with the cryptographic and transport handshakes to reduce 956 connection establishment latency, as described in Section 7.3. Once 957 established, a connection may migrate to a different IP or port at 958 either endpoint, due to NAT rebinding or mobility, as described in 959 Section 7.7. Finally a connection may be terminated by either 960 endpoint, as described in Section 7.9. 962 7.1. Matching Packets to Connections 964 Incoming packets are classified on receipt. Packets can either be 965 associated with an existing connection, be discarded, or - for 966 servers - potentially create a new connection. 968 Packets that can be associated with an existing connection are 969 handled according to the current state of that connection. Packets 970 are associated with existing connections using connection ID if it is 971 present; this might include connection IDs that were advertised using 972 NEW_CONNECTION_ID (Section 8.13). Packets without connection IDs and 973 long-form packets for connections that have incomplete cryptographic 974 handshakes are associated with an existing connection using the tuple 975 of source and destination IP addresses and ports. 977 A packet that uses the short header could be associated with an 978 existing connection with an incomplete cryptographic handshake. Such 979 a packet could be a valid packet that has been reordered with respect 980 to the long-form packets that will complete the cryptographic 981 handshake. This might happen after the final set of cryptographic 982 handshake messages from either peer. These packets are expected to 983 be correlated with a connection using the tuple of IP addresses and 984 ports. Packets that might be reordered in this fashion SHOULD be 985 buffered in anticipation of the handshake completing. 987 0-RTT packets might be received prior to a Client Initial packet at a 988 server. If the version of these packets is acceptable to the server, 989 it MAY buffer these packets in anticipation of receiving a reordered 990 Client Initial packet. 992 Buffering ensures that data is not lost, which improves performance; 993 conversely, discarding these packets could create false loss signals 994 for the congestion controllers. However, limiting the number and 995 size of buffered packets might be needed to prevent exposure to 996 denial of service. 998 For clients, any packet that cannot be associated with an existing 999 connection SHOULD be discarded if it is not buffered. Discarded 1000 packets MAY be logged for diagnostic or security purposes. 1002 For servers, packets that aren't associated with a connection 1003 potentially create a new connection. However, only packets that use 1004 the long packet header and that are at least the minimum size defined 1005 for the protocol version can be initial packets. A server MAY 1006 discard packets with a short header or packets that are smaller than 1007 the smallest minimum size for any version that the server supports. 1008 A server that discards a packet that cannot be associated with a 1009 connection MAY also generate a stateless reset (Section 7.9.4). 1011 This version of QUIC defines a minimum size for initial packets of 1012 1200 octets (see Section 9). Versions of QUIC that define smaller 1013 minimum initial packet sizes need to be aware that initial packets 1014 will be discarded without action by servers that only support 1015 versions with larger minimums. Clients that support multiple QUIC 1016 versions can avoid this problem by ensuring that they increase the 1017 size of their initial packets to the largest minimum size across all 1018 of the QUIC versions they support. Servers need to recognize initial 1019 packets that are the minimum size of all QUIC versions they support. 1021 7.2. Version Negotiation 1023 QUIC's connection establishment begins with version negotiation, 1024 since all communication between the endpoints, including packet and 1025 frame formats, relies on the two endpoints agreeing on a version. 1027 A QUIC connection begins with a client sending an Initial packet 1028 (Section 5.4.1). The details of the handshake mechanisms are 1029 described in Section 7.3, but any Initial packet sent from the client 1030 to the server MUST use the long header format - which includes the 1031 version of the protocol being used - and they MUST be padded to at 1032 least 1200 octets. 1034 The server receives this packet and determines whether it potentially 1035 creates a new connection (see Section 7.1). If the packet might 1036 generate a new connection, the server then checks whether it 1037 understands the version that the client has selected. 1039 If the packet contains a version that is acceptable to the server, 1040 the server proceeds with the handshake (Section 7.3). This commits 1041 the server to the version that the client selected. 1043 7.2.1. Sending Version Negotiation Packets 1045 If the version selected by the client is not acceptable to the 1046 server, the server responds with a Version Negotiation packet 1047 (Section 5.3). This includes a list of versions that the server will 1048 accept. 1050 A server sends a Version Negotiation packet for any packet with an 1051 unacceptable version if that packet could create a new connection. 1052 This allows a server to process packets with unsupported versions 1053 without retaining state. Though either the Client Initial packet or 1054 the version negotiation packet that is sent in response could be 1055 lost, the client will send new packets until it successfully receives 1056 a response or it abandons the connection attempt. 1058 7.2.2. Handling Version Negotiation Packets 1060 When the client receives a Version Negotiation packet, it first 1061 checks that the connection ID matches the connection ID the client 1062 sent. If this check fails, the packet MUST be discarded. 1064 Once the Version Negotiation packet is determined to be valid, the 1065 client then selects an acceptable protocol version from the list 1066 provided by the server. The client then attempts to create a 1067 connection using that version. Though the contents of the Client 1068 Initial packet the client sends might not change in response to 1069 version negotiation, a client MUST increase the packet number it uses 1070 on every packet it sends. Packets MUST continue to use long headers 1071 and MUST include the new negotiated protocol version. 1073 The client MUST use the long header format and include its selected 1074 version on all packets until it has 1-RTT keys and it has received a 1075 packet from the server which is not a Version Negotiation packet. 1077 A client MUST NOT change the version it uses unless it is in response 1078 to a Version Negotiation packet from the server. Once a client 1079 receives a packet from the server which is not a Version Negotiation 1080 packet, it MUST discard other Version Negotiation packets on the same 1081 connection. Similarly, a client MUST ignore a Version Negotiation 1082 packet if it has already received and acted on a Version Negotiation 1083 packet. 1085 A client MUST ignore a Version Negotiation packet that lists the 1086 client's chosen version. 1088 Version negotiation packets have no cryptographic protection. The 1089 result of the negotiation MUST be revalidated as part of the 1090 cryptographic handshake (see Section 7.4.4). 1092 7.2.3. Using Reserved Versions 1094 For a server to use a new version in the future, clients must 1095 correctly handle unsupported versions. To help ensure this, a server 1096 SHOULD include a reserved version (see Section 4) while generating a 1097 Version Negotiation packet. 1099 The design of version negotiation permits a server to avoid 1100 maintaining state for packets that it rejects in this fashion. The 1101 validation of version negotiation (see Section 7.4.4) only validates 1102 the result of version negotiation, which is the same no matter which 1103 reserved version was sent. A server MAY therefore send different 1104 reserved version numbers in the Version Negotiation Packet and in its 1105 transport parameters. 1107 A client MAY send a packet using a reserved version number. This can 1108 be used to solicit a list of supported versions from a server. 1110 7.3. Cryptographic and Transport Handshake 1112 QUIC relies on a combined cryptographic and transport handshake to 1113 minimize connection establishment latency. QUIC allocates stream 0 1114 for the cryptographic handshake. Version 0x00000001 of QUIC uses TLS 1115 1.3 as described in [QUIC-TLS]; a different QUIC version number could 1116 indicate that a different cryptographic handshake protocol is in use. 1118 QUIC provides this stream with reliable, ordered delivery of data. 1119 In return, the cryptographic handshake provides QUIC with: 1121 o authenticated key exchange, where 1123 * a server is always authenticated, 1125 * a client is optionally authenticated, 1127 * every connection produces distinct and unrelated keys, 1129 * keying material is usable for packet protection for both 0-RTT 1130 and 1-RTT packets, and 1132 * 1-RTT keys have forward secrecy 1134 o authenticated values for the transport parameters of the peer (see 1135 Section 7.4) 1137 o authenticated confirmation of version negotiation (see 1138 Section 7.4.4) 1140 o authenticated negotiation of an application protocol (TLS uses 1141 ALPN [RFC7301] for this purpose) 1143 o for the server, the ability to carry data that provides assurance 1144 that the client can receive packets that are addressed with the 1145 transport address that is claimed by the client (see Section 7.6) 1147 The initial cryptographic handshake message MUST be sent in a single 1148 packet. Any second attempt that is triggered by address validation 1149 MUST also be sent within a single packet. This avoids having to 1150 reassemble a message from multiple packets. Reassembling messages 1151 requires that a server maintain state prior to establishing a 1152 connection, exposing the server to a denial of service risk. 1154 The first client packet of the cryptographic handshake protocol MUST 1155 fit within a 1232 octet QUIC packet payload. This includes overheads 1156 that reduce the space available to the cryptographic handshake 1157 protocol. 1159 Details of how TLS is integrated with QUIC is provided in more detail 1160 in [QUIC-TLS]. 1162 7.4. Transport Parameters 1164 During connection establishment, both endpoints make authenticated 1165 declarations of their transport parameters. These declarations are 1166 made unilaterally by each endpoint. Endpoints are required to comply 1167 with the restrictions implied by these parameters; the description of 1168 each parameter includes rules for its handling. 1170 The format of the transport parameters is the TransportParameters 1171 struct from Figure 6. This is described using the presentation 1172 language from Section 3 of [I-D.ietf-tls-tls13]. 1174 uint32 QuicVersion; 1176 enum { 1177 initial_max_stream_data(0), 1178 initial_max_data(1), 1179 initial_max_stream_id_bidi(2), 1180 idle_timeout(3), 1181 omit_connection_id(4), 1182 max_packet_size(5), 1183 stateless_reset_token(6), 1184 ack_delay_exponent(7), 1185 initial_max_stream_id_uni(8), 1186 (65535) 1187 } TransportParameterId; 1189 struct { 1190 TransportParameterId parameter; 1191 opaque value<0..2^16-1>; 1192 } TransportParameter; 1194 struct { 1195 select (Handshake.msg_type) { 1196 case client_hello: 1197 QuicVersion initial_version; 1199 case encrypted_extensions: 1200 QuicVersion negotiated_version; 1201 QuicVersion supported_versions<4..2^8-4>; 1202 }; 1203 TransportParameter parameters<22..2^16-1>; 1204 } TransportParameters; 1206 Figure 6: Definition of TransportParameters 1208 The "extension_data" field of the quic_transport_parameters extension 1209 defined in [QUIC-TLS] contains a TransportParameters value. TLS 1210 encoding rules are therefore used to encode the transport parameters. 1212 QUIC encodes transport parameters into a sequence of octets, which 1213 are then included in the cryptographic handshake. Once the handshake 1214 completes, the transport parameters declared by the peer are 1215 available. Each endpoint validates the value provided by its peer. 1216 In particular, version negotiation MUST be validated (see 1217 Section 7.4.4) before the connection establishment is considered 1218 properly complete. 1220 Definitions for each of the defined transport parameters are included 1221 in Section 7.4.1. Any given parameter MUST appear at most once in a 1222 given transport parameters extension. An endpoint MUST treat receipt 1223 of duplicate transport parameters as a connection error of type 1224 TRANSPORT_PARAMETER_ERROR. 1226 7.4.1. Transport Parameter Definitions 1228 An endpoint MUST include the following parameters in its encoded 1229 TransportParameters: 1231 initial_max_stream_data (0x0000): The initial stream maximum data 1232 parameter contains the initial value for the maximum data that can 1233 be sent on any newly created stream. This parameter is encoded as 1234 an unsigned 32-bit integer in units of octets. This is equivalent 1235 to an implicit MAX_STREAM_DATA frame (Section 8.7) being sent on 1236 all streams immediately after opening. 1238 initial_max_data (0x0001): The initial maximum data parameter 1239 contains the initial value for the maximum amount of data that can 1240 be sent on the connection. This parameter is encoded as an 1241 unsigned 32-bit integer in units of octets. This is equivalent to 1242 sending a MAX_DATA (Section 8.6) for the connection immediately 1243 after completing the handshake. 1245 idle_timeout (0x0003): The idle timeout is a value in seconds that 1246 is encoded as an unsigned 16-bit integer. The maximum value is 1247 600 seconds (10 minutes). 1249 A server MUST include the following transport parameters: 1251 stateless_reset_token (0x0006): The Stateless Reset Token is used in 1252 verifying a stateless reset, see Section 7.9.4. This parameter is 1253 a sequence of 16 octets. 1255 A client MUST NOT include a stateless reset token. A server MUST 1256 treat receipt of a stateless_reset_token transport parameter as a 1257 connection error of type TRANSPORT_PARAMETER_ERROR. 1259 An endpoint MAY use the following transport parameters: 1261 initial_max_stream_id_bidi (0x0002): The initial maximum stream ID 1262 parameter contains the initial maximum stream number the peer may 1263 initiate for bidirectional streams, encoded as an unsigned 32-bit 1264 integer. This value MUST be a valid bidirectional stream ID for a 1265 peer-initiated stream (that is, the two least significant bits are 1266 set to 0 by a server and to 1 by a client). If an invalid value 1267 is provided, the recipient MUST generate a connection error of 1268 type TRANSPORT_PARAMETER_ERROR. Setting this parameter is 1269 equivalent to sending a MAX_STREAM_ID (Section 8.8) immediately 1270 after completing the handshake. The maximum bidirectional stream 1271 ID is set to 0 if this parameter is absent, preventing the 1272 creation of new bidirectional streams until a MAX_STREAM_ID frame 1273 is sent. Note that a default value of 0 does not prevent the 1274 cryptographic handshake stream (that is, stream 0) from being 1275 used. 1277 initial_max_stream_id_uni (0x0008): The initial maximum stream ID 1278 parameter contains the initial maximum stream number the peer may 1279 initiate for unidirectional streams, encoded as an unsigned 32-bit 1280 integer. The value MUST be a valid unidirectional ID for the 1281 recipient (that is, the two least significant bits are set to 2 by 1282 a server and to 3 by a client). If an invalid value is provided, 1283 the recipient MUST generate a connection error of type 1284 TRANSPORT_PARAMETER_ERROR. Setting this parameter is equivalent 1285 to sending a MAX_STREAM_ID (Section 8.8) immediately after 1286 completing the handshake. The maximum unidirectional stream ID is 1287 set to 0 if this parameter is absent, preventing the creation of 1288 new unidirectional streams until a MAX_STREAM_ID frame is sent. 1290 omit_connection_id (0x0004): The omit connection identifier 1291 parameter indicates that packets sent to the endpoint that 1292 advertises this parameter MAY omit the connection ID in packets 1293 using short header format. This can be used by an endpoint where 1294 it knows that source and destination IP address and port are 1295 sufficient for it to identify a connection. This parameter is 1296 zero length. Absence of this parameter means that the connection 1297 ID MUST be present in every packet sent to this endpoint. 1299 max_packet_size (0x0005): The maximum packet size parameter places a 1300 limit on the size of packets that the endpoint is willing to 1301 receive, encoded as an unsigned 16-bit integer. This indicates 1302 that packets larger than this limit will be dropped. The default 1303 for this parameter is the maximum permitted UDP payload of 65527. 1304 Values below 1200 are invalid. This limit only applies to 1305 protected packets (Section 5.5). 1307 ack_delay_exponent (0x0007): An 8-bit unsigned integer value 1308 indicating an exponent used to decode the ACK Delay field in the 1309 ACK frame, see Section 8.16. If this value is absent, a default 1310 value of 3 is assumed (indicating a multiplier of 8). The default 1311 value is also used for ACK frames that are sent in Initial, 1312 Handshake, and Retry packets. Values above 20 are invalid. 1314 7.4.2. Values of Transport Parameters for 0-RTT 1316 A client that attempts to send 0-RTT data MUST remember the transport 1317 parameters used by the server. The transport parameters that the 1318 server advertises during connection establishment apply to all 1319 connections that are resumed using the keying material established 1320 during that handshake. Remembered transport parameters apply to the 1321 new connection until the handshake completes and new transport 1322 parameters from the server can be provided. 1324 A server can remember the transport parameters that it advertised, or 1325 store an integrity-protected copy of the values in the ticket and 1326 recover the information when accepting 0-RTT data. A server uses the 1327 transport parameters in determining whether to accept 0-RTT data. 1329 A server MAY accept 0-RTT and subsequently provide different values 1330 for transport parameters for use in the new connection. If 0-RTT 1331 data is accepted by the server, the server MUST NOT reduce any limits 1332 or alter any values that might be violated by the client with its 1333 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1334 set values for initial_max_data or initial_max_stream_data that are 1335 smaller than the remembered value of those parameters. Similarly, a 1336 server MUST NOT reduce the value of initial_max_stream_id_bidi or 1337 initial_max_stream_id_uni. 1339 Omitting or setting a zero value for certain transport parameters can 1340 result in 0-RTT data being enabled, but not usable. The following 1341 transport parameters SHOULD be set to non-zero values for 0-RTT: 1342 initial_max_stream_id_bidi, initial_max_stream_id_uni, 1343 initial_max_data, initial_max_stream_data. 1345 A server MUST reject 0-RTT data or even abort a handshake if the 1346 implied values for transport parameters cannot be supported. 1348 7.4.3. New Transport Parameters 1350 New transport parameters can be used to negotiate new protocol 1351 behavior. An endpoint MUST ignore transport parameters that it does 1352 not support. Absence of a transport parameter therefore disables any 1353 optional protocol feature that is negotiated using the parameter. 1355 New transport parameters can be registered according to the rules in 1356 Section 14.1. 1358 7.4.4. Version Negotiation Validation 1360 Though the cryptographic handshake has integrity protection, two 1361 forms of QUIC version downgrade are possible. In the first, an 1362 attacker replaces the QUIC version in the Initial packet. In the 1363 second, a fake Version Negotiation packet is sent by an attacker. To 1364 protect against these attacks, the transport parameters include three 1365 fields that encode version information. These parameters are used to 1366 retroactively authenticate the choice of version (see Section 7.2). 1368 The cryptographic handshake provides integrity protection for the 1369 negotiated version as part of the transport parameters (see 1370 Section 7.4). As a result, attacks on version negotiation by an 1371 attacker can be detected. 1373 The client includes the initial_version field in its transport 1374 parameters. The initial_version is the version that the client 1375 initially attempted to use. If the server did not send a version 1376 negotiation packet Section 5.3, this will be identical to the 1377 negotiated_version field in the server transport parameters. 1379 A server that processes all packets in a stateful fashion can 1380 remember how version negotiation was performed and validate the 1381 initial_version value. 1383 A server that does not maintain state for every packet it receives 1384 (i.e., a stateless server) uses a different process. If the 1385 initial_version matches the version of QUIC that is in use, a 1386 stateless server can accept the value. 1388 If the initial_version is different from the version of QUIC that is 1389 in use, a stateless server MUST check that it would have sent a 1390 version negotiation packet if it had received a packet with the 1391 indicated initial_version. If a server would have accepted the 1392 version included in the initial_version and the value differs from 1393 the QUIC version that is in use, the server MUST terminate the 1394 connection with a VERSION_NEGOTIATION_ERROR error. 1396 The server includes both the version of QUIC that is in use and a 1397 list of the QUIC versions that the server supports. 1399 The negotiated_version field is the version that is in use. This 1400 MUST be set by the server to the value that is on the Initial packet 1401 that it accepts (not an Initial packet that triggers a Retry or 1402 Version Negotiation packet). A client that receives a 1403 negotiated_version that does not match the version of QUIC that is in 1404 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 1405 error code. 1407 The server includes a list of versions that it would send in any 1408 version negotiation packet (Section 5.3) in the supported_versions 1409 field. The server populates this field even if it did not send a 1410 version negotiation packet. 1412 The client validates that the negotiated_version is included in the 1413 supported_versions list and - if version negotiation was performed - 1414 that it would have selected the negotiated version. A client MUST 1415 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 1416 if the current QUIC version is not listed in the supported_versions 1417 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 1418 code if version negotiation occurred but it would have selected a 1419 different version based on the value of the supported_versions list. 1421 When an endpoint accepts multiple QUIC versions, it can potentially 1422 interpret transport parameters as they are defined by any of the QUIC 1423 versions it supports. The version field in the QUIC packet header is 1424 authenticated using transport parameters. The position and the 1425 format of the version fields in transport parameters MUST either be 1426 identical across different QUIC versions, or be unambiguously 1427 different to ensure no confusion about their interpretation. One way 1428 that a new format could be introduced is to define a TLS extension 1429 with a different codepoint. 1431 7.5. Stateless Retries 1433 A server can process an initial cryptographic handshake messages from 1434 a client without committing any state. This allows a server to 1435 perform address validation (Section 7.6, or to defer connection 1436 establishment costs. 1438 A server that generates a response to an initial packet without 1439 retaining connection state MUST use the Retry packet (Section 5.4.2). 1440 This packet causes a client to reset its transport state and to 1441 continue the connection attempt with new connection state while 1442 maintaining the state of the cryptographic handshake. 1444 A server MUST NOT send multiple Retry packets in response to a client 1445 handshake packet. Thus, any cryptographic handshake message that is 1446 sent MUST fit within a single packet. 1448 In TLS, the Retry packet type is used to carry the HelloRetryRequest 1449 message. 1451 7.6. Proof of Source Address Ownership 1453 Transport protocols commonly spend a round trip checking that a 1454 client owns the transport address (IP and port) that it claims. 1455 Verifying that a client can receive packets sent to its claimed 1456 transport address protects against spoofing of this information by 1457 malicious clients. 1459 This technique is used primarily to avoid QUIC from being used for 1460 traffic amplification attack. In such an attack, a packet is sent to 1461 a server with spoofed source address information that identifies a 1462 victim. If a server generates more or larger packets in response to 1463 that packet, the attacker can use the server to send more data toward 1464 the victim than it would be able to send on its own. 1466 Several methods are used in QUIC to mitigate this attack. Firstly, 1467 the initial handshake packet is padded to at least 1200 octets. This 1468 allows a server to send a similar amount of data without risking 1469 causing an amplification attack toward an unproven remote address. 1471 A server eventually confirms that a client has received its messages 1472 when the cryptographic handshake successfully completes. This might 1473 be insufficient, either because the server wishes to avoid the 1474 computational cost of completing the handshake, or it might be that 1475 the size of the packets that are sent during the handshake is too 1476 large. This is especially important for 0-RTT, where the server 1477 might wish to provide application data traffic - such as a response 1478 to a request - in response to the data carried in the early data from 1479 the client. 1481 To send additional data prior to completing the cryptographic 1482 handshake, the server then needs to validate that the client owns the 1483 address that it claims. 1485 Source address validation is therefore performed during the 1486 establishment of a connection. TLS provides the tools that support 1487 the feature, but basic validation is performed by the core transport 1488 protocol. 1490 A different type of source address validation is performed after a 1491 connection migration, see Section 7.7.2. 1493 7.6.1. Client Address Validation Procedure 1495 QUIC uses token-based address validation. Any time the server wishes 1496 to validate a client address, it provides the client with a token. 1497 As long as the token cannot be easily guessed (see Section 7.6.3), if 1498 the client is able to return that token, it proves to the server that 1499 it received the token. 1501 During the processing of the cryptographic handshake messages from a 1502 client, TLS will request that QUIC make a decision about whether to 1503 proceed based on the information it has. TLS will provide QUIC with 1504 any token that was provided by the client. For an initial packet, 1505 QUIC can decide to abort the connection, allow it to proceed, or 1506 request address validation. 1508 If QUIC decides to request address validation, it provides the 1509 cryptographic handshake with a token. The contents of this token are 1510 consumed by the server that generates the token, so there is no need 1511 for a single well-defined format. A token could include information 1512 about the claimed client address (IP and port), a timestamp, and any 1513 other supplementary information the server will need to validate the 1514 token in the future. 1516 The cryptographic handshake is responsible for enacting validation by 1517 sending the address validation token to the client. A legitimate 1518 client will include a copy of the token when it attempts to continue 1519 the handshake. The cryptographic handshake extracts the token then 1520 asks QUIC a second time whether the token is acceptable. In 1521 response, QUIC can either abort the connection or permit it to 1522 proceed. 1524 A connection MAY be accepted without address validation - or with 1525 only limited validation - but a server SHOULD limit the data it sends 1526 toward an unvalidated address. Successful completion of the 1527 cryptographic handshake implicitly provides proof that the client has 1528 received packets from the server. 1530 7.6.2. Address Validation on Session Resumption 1532 A server MAY provide clients with an address validation token during 1533 one connection that can be used on a subsequent connection. Address 1534 validation is especially important with 0-RTT because a server 1535 potentially sends a significant amount of data to a client in 1536 response to 0-RTT data. 1538 A different type of token is needed when resuming. Unlike the token 1539 that is created during a handshake, there might be some time between 1540 when the token is created and when the token is subsequently used. 1541 Thus, a resumption token SHOULD include an expiration time. It is 1542 also unlikely that the client port number is the same on two 1543 different connections; validating the port is therefore unlikely to 1544 be successful. 1546 This token can be provided to the cryptographic handshake immediately 1547 after establishing a connection. QUIC might also generate an updated 1548 token if significant time passes or the client address changes for 1549 any reason (see Section 7.7). The cryptographic handshake is 1550 responsible for providing the client with the token. In TLS the 1551 token is included in the ticket that is used for resumption and 1552 0-RTT, which is carried in a NewSessionTicket message. 1554 7.6.3. Address Validation Token Integrity 1556 An address validation token MUST be difficult to guess. Including a 1557 large enough random value in the token would be sufficient, but this 1558 depends on the server remembering the value it sends to clients. 1560 A token-based scheme allows the server to offload any state 1561 associated with validation to the client. For this design to work, 1562 the token MUST be covered by integrity protection against 1563 modification or falsification by clients. Without integrity 1564 protection, malicious clients could generate or guess values for 1565 tokens that would be accepted by the server. Only the server 1566 requires access to the integrity protection key for tokens. 1568 In TLS the address validation token is often bundled with the 1569 information that TLS requires, such as the resumption secret. In 1570 this case, adding integrity protection can be delegated to the 1571 cryptographic handshake protocol, avoiding redundant protection. If 1572 integrity protection is delegated to the cryptographic handshake, an 1573 integrity failure will result in immediate cryptographic handshake 1574 failure. If integrity protection is performed by QUIC, QUIC MUST 1575 abort the connection if the integrity check fails with a 1576 PROTOCOL_VIOLATION error code. 1578 7.7. Connection Migration 1580 QUIC connections are identified by their 64-bit Connection ID. 1581 QUIC's consistent connection ID allows connections to survive changes 1582 to the client's IP and/or port, such as those caused by client or 1583 server migrating to a new network. Connection migration allows a 1584 client to retain any shared state with a connection when they move 1585 networks. This includes state that can be hard to recover such as 1586 outstanding requests, which might otherwise be lost with no easy way 1587 to retry them. 1589 An endpoint that receives packets that contain a source IP address 1590 and port that has not yet been used can start sending new packets 1591 with those as a destination IP address and port. Packets exchanged 1592 between endpoints can then follow the new path. 1594 Due to variations in path latency or packet reordering, packets from 1595 different source addresses might be reordered. The packet with the 1596 highest packet number MUST be used to determine which path to use. 1597 Endpoints also need to be prepared to receive packets from an older 1598 source address. 1600 An endpoint MUST validate that its peer can receive packets at the 1601 new address before sending any significant quantity of data to that 1602 address, or it risks being used for denial of service. See 1603 Section 7.7.2 for details. 1605 7.7.1. Privacy Implications of Connection Migration 1607 Using a stable connection ID on multiple network paths allows a 1608 passive observer to correlate activity between those paths. A client 1609 that moves between networks might not wish to have their activity 1610 correlated by any entity other than a server. The NEW_CONNECTION_ID 1611 message can be sent by a server to provide an unlinkable connection 1612 ID for use in case the client wishes to explicitly break linkability 1613 between two points of network attachment. 1615 A client might need to send packets on multiple networks without 1616 receiving any response from the server. To ensure that the client is 1617 not linkable across each of these changes, a new connection ID and 1618 packet number gap are needed for each network. To support this, a 1619 server sends multiple NEW_CONNECTION_ID messages. Each 1620 NEW_CONNECTION_ID is marked with a sequence number. Connection IDs 1621 MUST be used in the order in which they are numbered. 1623 A client which wishes to break linkability upon changing networks 1624 MUST use the connection ID provided by the server as well as 1625 incrementing the packet sequence number by an externally 1626 unpredictable value computed as described in Section 7.7.1.1. Packet 1627 number gaps are cumulative. A client might skip connection IDs, but 1628 it MUST ensure that it applies the associated packet number gaps for 1629 connection IDs that it skips in addition to the packet number gap 1630 associated with the connection ID that it does use. 1632 A server that receives a packet that is marked with a new connection 1633 ID recovers the packet number by adding the cumulative packet number 1634 gap to its expected packet number. A server SHOULD discard packets 1635 that contain a smaller gap than it advertised. 1637 For instance, a server might provide a packet number gap of 7 1638 associated with a new connection ID. If the server received packet 1639 10 using the previous connection ID, it should expect packets on the 1640 new connection ID to start at 18. A packet with the new connection 1641 ID and a packet number of 17 is discarded as being in error. 1643 7.7.1.1. Packet Number Gap 1645 In order to avoid linkage, the packet number gap MUST be externally 1646 indistinguishable from random. The packet number gap for a 1647 connection ID with sequence number is computed by encoding the 1648 sequence number as a 32-bit integer in big-endian format, and then 1649 computing: 1651 Gap = HKDF-Expand-Label(packet_number_secret, 1652 "QUIC packet sequence gap", sequence, 4) 1654 The output of HKDF-Expand-Label is interpreted as a big-endian 1655 number. "packet_number_secret" is derived from the TLS key exchange, 1656 as described in Section 5.6 of [QUIC-TLS]. 1658 7.7.2. Address Validation for Migrated Connections 1660 An endpoint that receives a packet from a new remote IP address and 1661 port (or just a new remote port) on packets from its peer is likely 1662 seeing a connection migration at the peer. 1664 However, it is also possible that the peer is spoofing its source 1665 address in order to cause the endpoint to send excessive amounts of 1666 data to an unwilling host. If the endpoint sends significantly more 1667 data than the peer, connection migration might be used to amplify the 1668 volume of data that an attacker can generate toward a victim. 1670 Thus, when seeing a new remote transport address, an endpoint MUST 1671 verify that its peer can receive and respond to packets at that new 1672 address. By providing copies of the data that it receives, the peer 1673 proves that it is receiving packets at the new address and consents 1674 to receive data. 1676 Prior to validating the new remote address, and endpoint MUST limit 1677 the amount of data and packets that it sends to its peer. At a 1678 minimum, this needs to consider the possibility that packets are sent 1679 without congestion feedback. 1681 Once a connection is established, address validation is relatively 1682 simple (see Section 7.6 for the process that is used during the 1683 handshake). An endpoint validates a remote address by sending a PING 1684 frame containing a payload that is hard to guess. This frame MUST be 1685 sent in a packet that is sent to the new address. Once a PONG frame 1686 containing the same payload is received, the address is considered to 1687 be valid. The PONG frame can use any path on its return. A PING 1688 frame containing 12 randomly generated [RFC4086] octets is sufficient 1689 to ensure that it is easier to receive the packet than it is to guess 1690 the value correctly. 1692 If the PING frame is determined to be lost, a new PING frame SHOULD 1693 be generated. This PING frame MUST include a new Data field that is 1694 similarly difficult to guess. 1696 If validation of the new remote address fails, after allowing enough 1697 time for possible loss and recovery of packets carrying PING and PONG 1698 frames, the endpoint MUST terminate the connection. When setting 1699 this timer, implementations are cautioned that the new path could 1700 have a longer round trip time than the original. The endpoint MUST 1701 NOT send a CONNECTION_CLOSE frame in this case; it has to assume that 1702 the remote peer does not want to receive any more packets. 1704 If the remote address is validated successfully, the endpoint MAY 1705 increase the rate that it sends on the new path using the state from 1706 the previous path. The capacity available on the new path might not 1707 be the same as the old path. An endpoint MUST NOT restore its send 1708 rate unless it is reasonably sure that the path is the same as the 1709 previous path. For instance, a change in only port number is likely 1710 indicative of a rebinding in a middlebox and not a complete change in 1711 path. This determination likely depends on heuristics, which could 1712 be imperfect; if the new path capacity is significantly reduced, 1713 ultimately this relies on the congestion controller responding to 1714 congestion signals and reduce send rates appropriately. 1716 After verifying an address, the endpoint SHOULD update any address 1717 validation tokens (Section 7.6) that it has issued to its peer if 1718 those are no longer valid based on the changed address. 1720 Address validation using the PING frame MAY be used at any time by 1721 either peer. For instance, an endpoint might check that a peer is 1722 still in possession of its address after a period of quiescence. 1724 Upon seeing a connection migration, an endpoint that sees a new 1725 address MUST abandon any address validation it is performing with 1726 other addresses on the expectation that the validation is likely to 1727 fail. Abandoning address validation primarily means not closing the 1728 connection when a PONG frame is not received, but it could also mean 1729 ceasing retransmissions of the PING frame. An endpoint that doesn't 1730 retransmit a PING frame might receive a PONG frame, which it MUST 1731 ignore. 1733 7.8. Spurious Connection Migrations 1735 A connection migration could be triggered by an attacker that is able 1736 to capture and forward a packet such that it arrives before the 1737 legitimate copy of that packet. Such a packet will appear to be a 1738 legitimate connection migration and the legitimate copy will be 1739 dropped as a duplicate. 1741 After a spurious migration, validation of the source address will 1742 fail because the entity at the source address does not have the 1743 necessary cryptographic keys to read or respond to the PING frame 1744 that is sent to it, even if it wanted to. Such a spurious connection 1745 migration could result in the connection being dropped when the 1746 source address validation fails. This grants an attacker the ability 1747 to terminate the connection. 1749 Receipt of packets with higher packet numbers from the legitimate 1750 address will trigger another connection migration. This will cause 1751 the validation of the address of the spurious migration to be 1752 abandoned. 1754 To ensure that a peer sends packets from the legitimate address 1755 before the validation of the new address can fail, an endpoint SHOULD 1756 attempt to validate the old remote address before attempting to 1757 validate the new address. If the connection migration is spurious, 1758 then the legitimate address will be used to respond and the 1759 connection will migrate back to the old address. 1761 As with any address validation, packets containing retransmissions of 1762 the PING frame validating an address MUST be sent to the address 1763 being validated. Consequently, during a migration of a peer, an 1764 endpoint could be sending to multiple remote addresses. 1766 An endpoint MAY abandon address validation for an address that it 1767 considers to be already valid. That is, if successive connection 1768 migrations occur in quick succession with the final remote address 1769 being identical to the initial remote address, the endpoint MAY 1770 abandon address validation for that address. 1772 7.9. Connection Termination 1774 Connections should remain open until they become idle for a pre- 1775 negotiated period of time. A QUIC connection, once established, can 1776 be terminated in one of three ways: 1778 o idle timeout (Section 7.9.2) 1780 o immediate close (Section 7.9.3) 1782 o stateless reset (Section 7.9.4) 1784 7.9.1. Closing and Draining Connection States 1786 The closing and draining connection states exist to ensure that 1787 connections close cleanly and that delayed or reordered packets are 1788 properly discarded. These states SHOULD persist for three times the 1789 current Retransmission Timeout (RTO) interval as defined in 1790 [QUIC-RECOVERY]. 1792 An endpoint enters a closing period after initiating an immediate 1793 close (Section 7.9.3) and optionally after an idle timeout 1794 (Section 7.9.2). While closing, an endpoint MUST NOT send packets 1795 unless they contain a CONNECTION_CLOSE or APPLICATION_CLOSE frame 1796 (see Section 7.9.3 for details). 1798 In the closing state, only a packet containing a closing frame can be 1799 sent. An endpoint retains only enough information to generate a 1800 packet containing a closing frame and to identify packets as 1801 belonging to the connection. The connection ID and QUIC version is 1802 sufficient information to identify packets for a closing connection; 1803 an endpoint can discard all other connection state. An endpoint MAY 1804 retain packet protection keys for incoming packets to allow it to 1805 read and process a closing frame. 1807 The draining state is entered once an endpoint receives a signal that 1808 its peer is closing or draining. While otherwise identical to the 1809 closing state, an endpoint in the draining state MUST NOT send any 1810 packets. Retaining packet protection keys is unnecessary once a 1811 connection is in the draining state. 1813 An endpoint MAY transition from the closing period to the draining 1814 period if it can confirm that its peer is also closing or draining. 1815 Receiving a closing frame is sufficient confirmation, as is receiving 1816 a stateless reset. The draining period SHOULD end when the closing 1817 period would have ended. In other words, the endpoint can use the 1818 same end time, but cease retransmission of the closing packet. 1820 Disposing of connection state prior to the end of the closing or 1821 draining period could cause delayed or reordered packets to be 1822 handled poorly. Endpoints that have some alternative means to ensure 1823 that late-arriving packets on the connection do not create QUIC 1824 state, such as those that are able to close the UDP socket, MAY use 1825 an abbreviated draining period which can allow for faster resource 1826 recovery. Servers that retain an open socket for accepting new 1827 connections SHOULD NOT exit the closing or draining period early. 1829 Once the closing or draining period has ended, an endpoint SHOULD 1830 discard all connection state. This results in new packets on the 1831 connection being handled generically. For instance, an endpoint MAY 1832 send a stateless reset in response to any further incoming packets. 1834 The draining and closing periods do not apply when a stateless reset 1835 (Section 7.9.4) is sent. 1837 An endpoint is not expected to handle key updates when it is closing 1838 or draining. A key update might prevent the endpoint from moving 1839 from the closing state to draining, but it otherwise has no impact. 1841 An endpoint could receive packets from a new source address, 1842 indicating a connection migration (Section 7.7), while in the closing 1843 period. An endpoint in the closing state MUST strictly limit the 1844 number of packets it sends to this new address as though the address 1845 were not validated (see Section 7.7.2). A server in the closing 1846 state MAY instead choose to discard packets received from a new 1847 source address. 1849 7.9.2. Idle Timeout 1851 A connection that remains idle for longer than the idle timeout (see 1852 Section 7.4.1) is closed. A connection enters the draining state 1853 when the idle timeout expires. 1855 The time at which an idle timeout takes effect won't be perfectly 1856 synchronized on both endpoints. An endpoint that sends packets near 1857 the end of an idle period could have those packets discarded if its 1858 peer enters the draining state before the packet is received. 1860 7.9.3. Immediate Close 1862 An endpoint sends a closing frame, either CONNECTION_CLOSE or 1863 APPLICATION_CLOSE, to terminate the connection immediately. Either 1864 closing frame causes all streams to immediately become closed; open 1865 streams can be assumed to be implicitly reset. 1867 After sending a closing frame, endpoints immediately enter the 1868 closing state. During the closing period, an endpoint that sends a 1869 closing frame SHOULD respond to any packet that it receives with 1870 another packet containing a closing frame. To minimize the state 1871 that an endpoint maintains for a closing connection, endpoints MAY 1872 send the exact same packet. However, endpoints SHOULD limit the 1873 number of packets they generate containing a closing frame. For 1874 instance, an endpoint could progressively increase the number of 1875 packets that it receives before sending additional packets or 1876 increase the time between packets. 1878 Note: Allowing retransmission of a packet contradicts other advice 1879 in this document that recommends the creation of new packet 1880 numbers for every packet. Sending new packet numbers is primarily 1881 of advantage to loss recovery and congestion control, which are 1882 not expected to be relevant for a closed connection. 1883 Retransmitting the final packet requires less state. 1885 After receiving a closing frame, endpoints enter the draining state. 1886 An endpoint that receives a closing frame MAY send a single packet 1887 containing a closing frame before entering the draining state, using 1888 a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An 1889 endpoint MUST NOT send further packets, which could result in a 1890 constant exchange of closing frames until the closing period on 1891 either peer ended. 1893 An immediate close can be used after an application protocol has 1894 arranged to close a connection. This might be after the application 1895 protocols negotiates a graceful shutdown. The application protocol 1896 exchanges whatever messages that are needed to cause both endpoints 1897 to agree to close the connection, after which the application 1898 requests that the connection be closed. The application protocol can 1899 use an APPLICATION_CLOSE message with an appropriate error code to 1900 signal closure. 1902 7.9.4. Stateless Reset 1904 A stateless reset is provided as an option of last resort for a 1905 server that does not have access to the state of a connection. A 1906 server crash or outage might result in clients continuing to send 1907 data to a server that is unable to properly continue the connection. 1908 A server that wishes to communicate a fatal connection error MUST use 1909 a closing frame if it has sufficient state to do so. 1911 To support this process, the server sends a stateless_reset_token 1912 value during the handshake in the transport parameters. This value 1913 is protected by encryption, so only client and server know this 1914 value. 1916 A server that receives packets that it cannot process sends a packet 1917 in the following layout: 1919 0 1 2 3 1920 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 1921 +-+-+-+-+-+-+-+-+ 1922 |0|C|K|Type (5) | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | | 1925 + [Connection ID (64)] + 1926 | | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | Packet Number (8/16/32) | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Random Octets (*) ... 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | | 1933 + + 1934 | | 1935 + Stateless Reset Token (128) + 1936 | | 1937 + + 1938 | | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 A server copies the connection ID field from the packet that triggers 1942 the stateless reset. A server omits the connection ID if explicitly 1943 configured to do so, or if the client packet did not include a 1944 connection ID. 1946 The Packet Number field is set to a randomized value. The server 1947 SHOULD send a packet with a short header and a type of 0x1F. This 1948 produces the shortest possible packet number encoding, which 1949 minimizes the perceived gap between the last packet that the server 1950 sent and this packet. A server MAY use a different short header 1951 type, indicating a different packet number length, but a longer 1952 packet number encoding might allow this message to be identified as a 1953 stateless reset more easily using heuristics. 1955 After the Packet Number, the server pads the message with an 1956 arbitrary number of octets containing random values. 1958 Finally, the last 16 octets of the packet are set to the value of the 1959 Stateless Reset Token. 1961 This design ensures that a stateless reset packet is - to the extent 1962 possible - indistinguishable from a regular packet. 1964 A stateless reset is not appropriate for signaling error conditions. 1965 An endpoint that wishes to communicate a fatal connection error MUST 1966 use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has 1967 sufficient state to do so. 1969 This stateless reset design is specific to QUIC version 1. A server 1970 that supports multiple versions of QUIC needs to generate a stateless 1971 reset that will be accepted by clients that support any version that 1972 the server might support (or might have supported prior to losing 1973 state). Designers of new versions of QUIC need to be aware of this 1974 and either reuse this design, or use a portion of the packet other 1975 than the last 16 octets for carrying data. 1977 7.9.4.1. Detecting a Stateless Reset 1979 A client detects a potential stateless reset when a packet with a 1980 short header either cannot be decrypted or is marked as a duplicate 1981 packet. The client then compares the last 16 octets of the packet 1982 with the Stateless Reset Token provided by the server in its 1983 transport parameters. If these values are identical, the client MUST 1984 enter the draining period and not send any further packets on this 1985 connection. If the comparison fails, the packet can be discarded. 1987 7.9.4.2. Calculating a Stateless Reset Token 1989 The stateless reset token MUST be difficult to guess. In order to 1990 create a Stateless Reset Token, a server could randomly generate 1991 [RFC4086] a secret for every connection that it creates. However, 1992 this presents a coordination problem when there are multiple servers 1993 in a cluster or a storage problem for a server that might lose state. 1994 Stateless reset specifically exists to handle the case where state is 1995 lost, so this approach is suboptimal. 1997 A single static key can be used across all connections to the same 1998 endpoint by generating the proof using a second iteration of a 1999 preimage-resistant function that takes three inputs: the static key, 2000 a the connection ID for the connection (see Section 5.6), and an 2001 identifier for the server instance. A server could use HMAC 2002 [RFC2104] (for example, HMAC(static_key, server_id || connection_id)) 2003 or HKDF [RFC5869] (for example, using the static key as input keying 2004 material, with server and connection identifiers as salt). The 2005 output of this function is truncated to 16 octets to produce the 2006 Stateless Reset Token for that connection. 2008 A server that loses state can use the same method to generate a valid 2009 Stateless Reset Secret. The connection ID comes from the packet that 2010 the server receives. 2012 This design relies on the client always sending a connection ID in 2013 its packets so that the server can use the connection ID from a 2014 packet to reset the connection. A server that uses this design 2015 cannot allow clients to omit a connection ID (that is, it cannot use 2016 the truncate_connection_id transport parameter Section 7.4.1). 2018 Revealing the Stateless Reset Token allows any entity to terminate 2019 the connection, so a value can only be used once. This method for 2020 choosing the Stateless Reset Token means that the combination of 2021 server instance, connection ID, and static key cannot occur for 2022 another connection. A connection ID from a connection that is reset 2023 by revealing the Stateless Reset Token cannot be reused for new 2024 connections at the same server without first changing to use a 2025 different static key or server identifier. 2027 Note that Stateless Reset messages do not have any cryptographic 2028 protection. 2030 8. Frame Types and Formats 2032 As described in Section 6, Regular packets contain one or more 2033 frames. We now describe the various QUIC frame types that can be 2034 present in a Regular packet. The use of these frames and various 2035 frame header bits are described in subsequent sections. 2037 8.1. Variable-Length Integer Encoding 2039 QUIC frames use a common variable-length encoding for all non- 2040 negative integer values. This encoding ensures that smaller integer 2041 values need fewer octets to encode. 2043 The QUIC variable-length integer encoding reserves the two most 2044 significant bits of the first octet to encode the base 2 logarithm of 2045 the integer encoding length in octets. The integer value is encoded 2046 on the remaining bits, in network byte order. 2048 This means that integers are encoded on 1, 2, 4, or 8 octets and can 2049 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 2050 the encoding properties. 2052 +------+--------+-------------+-----------------------+ 2053 | 2Bit | Length | Usable Bits | Range | 2054 +------+--------+-------------+-----------------------+ 2055 | 00 | 1 | 6 | 0-63 | 2056 | | | | | 2057 | 01 | 2 | 14 | 0-16383 | 2058 | | | | | 2059 | 10 | 4 | 30 | 0-1073741823 | 2060 | | | | | 2061 | 11 | 8 | 62 | 0-4611686018427387903 | 2062 +------+--------+-------------+-----------------------+ 2064 Table 4: Summary of Integer Encodings 2066 For example, the eight octet sequence c2 19 7c 5e ff 14 e8 8c (in 2067 hexadecimal) decodes to the decimal value 151288809941952652; the 2068 four octet sequence 9d 7f 3e 7d decodes to 494878333; the two octet 2069 sequence 7b bd decodes to 15293; and the single octet 25 decodes to 2070 37 (as does the two octet sequence 40 25). 2072 Error codes (Section 12.3) are described using integers, but do not 2073 use this encoding. 2075 8.2. PADDING Frame 2077 The PADDING frame (type=0x00) has no semantic value. PADDING frames 2078 can be used to increase the size of a packet. Padding can be used to 2079 increase an initial client packet to the minimum required size, or to 2080 provide protection against traffic analysis for protected packets. 2082 A PADDING frame has no content. That is, a PADDING frame consists of 2083 the single octet that identifies the frame as a PADDING frame. 2085 8.3. RST_STREAM Frame 2087 An endpoint may use a RST_STREAM frame (type=0x01) to abruptly 2088 terminate a stream. 2090 After sending a RST_STREAM, an endpoint ceases transmission and 2091 retransmission of STREAM frames on the identified stream. A receiver 2092 of RST_STREAM can discard any data that it already received on that 2093 stream. 2095 The RST_STREAM frame is as follows: 2097 0 1 2 3 2098 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 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | Stream ID (i) ... 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | Application Error Code (16) | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Final Offset (i) ... 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 The fields are: 2109 Stream ID: A variable-length integer encoding of the Stream ID of 2110 the stream being terminated. 2112 Application Protocol Error Code: A 16-bit application protocol error 2113 code (see Section 12.4) which indicates why the stream is being 2114 closed. 2116 Final Offset: A variable-length integer indicating the absolute byte 2117 offset of the end of data written on this stream by the RST_STREAM 2118 sender. 2120 8.4. CONNECTION_CLOSE frame 2122 An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its 2123 peer that the connection is being closed. CONNECTION_CLOSE is used 2124 to signal errors at the QUIC layer, or the absence of errors (with 2125 the NO_ERROR code). 2127 If there are open streams that haven't been explicitly closed, they 2128 are implicitly closed when the connection is closed. 2130 The CONNECTION_CLOSE frame is as follows: 2132 0 1 2 3 2133 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 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Error Code (16) | Reason Phrase Length (i) ... 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Reason Phrase (*) ... 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 The fields of a CONNECTION_CLOSE frame are as follows: 2142 Error Code: A 16-bit error code which indicates the reason for 2143 closing this connection. CONNECTION_CLOSE uses codes from the 2144 space defined in Section 12.3 (APPLICATION_CLOSE uses codes from 2145 the application protocol error code space, see Section 12.4). 2147 Reason Phrase Length: A variable-length integer specifying the 2148 length of the reason phrase in bytes. Note that a 2149 CONNECTION_CLOSE frame cannot be split between packets, so in 2150 practice any limits on packet size will also limit the space 2151 available for a reason phrase. 2153 Reason Phrase: A human-readable explanation for why the connection 2154 was closed. This can be zero length if the sender chooses to not 2155 give details beyond the Error Code. This SHOULD be a UTF-8 2156 encoded string [RFC3629]. 2158 8.5. APPLICATION_CLOSE frame 2160 An APPLICATION_CLOSE frame (type=0x03) uses the same format as the 2161 CONNECTION_CLOSE frame (Section 8.4), except that it uses error codes 2162 from the application protocol error code space (Section 12.4) instead 2163 of the transport error code space. 2165 Other than the error code space, the format and semantics of the 2166 APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame. 2168 8.6. MAX_DATA Frame 2170 The MAX_DATA frame (type=0x04) is used in flow control to inform the 2171 peer of the maximum amount of data that can be sent on the connection 2172 as a whole. 2174 The frame is as follows: 2176 0 1 2 3 2177 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 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | Maximum Data (i) ... 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 The fields in the MAX_DATA frame are as follows: 2184 Maximum Data: A variable-length integer indicating the maximum 2185 amount of data that can be sent on the entire connection, in units 2186 of octets. 2188 All data sent in STREAM frames counts toward this limit, with the 2189 exception of data on stream 0. The sum of the largest received 2190 offsets on all streams - including streams in terminal states, but 2191 excluding stream 0 - MUST NOT exceed the value advertised by a 2192 receiver. An endpoint MUST terminate a connection with a 2193 QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more 2194 data than the maximum data value that it has sent, unless this is a 2195 result of a change in the initial limits (see Section 7.4.2). 2197 8.7. MAX_STREAM_DATA Frame 2199 The MAX_STREAM_DATA frame (type=0x05) is used in flow control to 2200 inform a peer of the maximum amount of data that can be sent on a 2201 stream. 2203 The frame is as follows: 2205 0 1 2 3 2206 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 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | Stream ID (i) ... 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | Maximum Stream Data (i) ... 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 The fields in the MAX_STREAM_DATA frame are as follows: 2215 Stream ID: The stream ID of the stream that is affected encoded as a 2216 variable-length integer. 2218 Maximum Stream Data: A variable-length integer indicating the 2219 maximum amount of data that can be sent on the identified stream, 2220 in units of octets. 2222 When counting data toward this limit, an endpoint accounts for the 2223 largest received offset of data that is sent or received on the 2224 stream. Loss or reordering can mean that the largest received offset 2225 on a stream can be greater than the total size of data received on 2226 that stream. Receiving STREAM frames might not increase the largest 2227 received offset. 2229 The data sent on a stream MUST NOT exceed the largest maximum stream 2230 data value advertised by the receiver. An endpoint MUST terminate a 2231 connection with a FLOW_CONTROL_ERROR error if it receives more data 2232 than the largest maximum stream data that it has sent for the 2233 affected stream, unless this is a result of a change in the initial 2234 limits (see Section 7.4.2). 2236 8.8. MAX_STREAM_ID Frame 2238 The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum 2239 stream ID that they are permitted to open. 2241 The frame is as follows: 2243 0 1 2 3 2244 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 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Maximum Stream ID (i) ... 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 The fields in the MAX_STREAM_ID frame are as follows: 2251 Maximum Stream ID: ID of the maximum unidirectional or bidirectional 2252 peer-initiated stream ID for the connection encoded as a variable- 2253 length integer. The limit applies to unidirectional steams if the 2254 second least signification bit of the stream ID is 1, and applies 2255 to bidirectional streams if it is 0. 2257 Loss or reordering can mean that a MAX_STREAM_ID frame can be 2258 received which states a lower stream limit than the client has 2259 previously received. MAX_STREAM_ID frames which do not increase the 2260 maximum stream ID MUST be ignored. 2262 A peer MUST NOT initiate a stream with a higher stream ID than the 2263 greatest maximum stream ID it has received. An endpoint MUST 2264 terminate a connection with a STREAM_ID_ERROR error if a peer 2265 initiates a stream with a higher stream ID than it has sent, unless 2266 this is a result of a change in the initial limits (see 2267 Section 7.4.2). 2269 8.9. PING Frame 2271 Endpoints can use PING frames (type=0x07) to verify that their peers 2272 are still alive or to check reachability to the peer. 2274 The PING frame contains a variable-length payload. 2276 0 1 2 3 2277 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 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Length(8) | Data (*) ... 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 Length: This 8-bit value describes the length of the Data field. 2284 Data: This variable-length field contains arbitrary data. 2286 A PING frame with an empty Data field causes the packet containing it 2287 to be acknowledged as normal. No other action is required of the 2288 recipient. 2290 An empty PING frame can be used to keep a connection alive when an 2291 application or application protocol wishes to prevent the connection 2292 from timing out. An application protocol SHOULD provide guidance 2293 about the conditions under which generating a PING is recommended. 2294 This guidance SHOULD indicate whether it is the client or the server 2295 that is expected to send the PING. Having both endpoints send PING 2296 frames without coordination can produce an excessive number of 2297 packets and poor performance. 2299 If the Data field is not empty, the recipient of this frame MUST 2300 generate a PONG frame (Section 8.15) containing the same Data. A 2301 PING frame with data is not appropriate for use in keeping a 2302 connection alive, because the PONG frame elicits an acknowledgement, 2303 causing the sender of the original PING to send two packets. 2305 A connection will time out if no packets are sent or received for a 2306 period longer than the time specified in the idle_timeout transport 2307 parameter (see Section 7.9). However, state in middleboxes might 2308 time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 2309 minute timeout interval, experience shows that sending packets every 2310 15 to 30 seconds is necessary to prevent the majority of middleboxes 2311 from losing state for UDP flows. 2313 8.10. BLOCKED Frame 2315 A sender SHOULD send a BLOCKED frame (type=0x08) when it wishes to 2316 send data, but is unable to due to connection-level flow control (see 2317 Section 11.2.1). BLOCKED frames can be used as input to tuning of 2318 flow control algorithms (see Section 11.1.2). 2320 The BLOCKED frame is as follows: 2322 0 1 2 3 2323 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 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | Offset (i) ... 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 The BLOCKED frame contains a single field. 2330 Offset: A variable-length integer indicating the connection-level 2331 offset at which the blocking occurred. 2333 8.11. STREAM_BLOCKED Frame 2335 A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it 2336 wishes to send data, but is unable to due to stream-level flow 2337 control. This frame is analogous to BLOCKED (Section 8.10). 2339 The STREAM_BLOCKED frame is as follows: 2341 0 1 2 3 2342 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 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Stream ID (i) ... 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | Offset (i) ... 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 The STREAM_BLOCKED frame contains two fields: 2351 Stream ID: A variable-length integer indicating the stream which is 2352 flow control blocked. 2354 Offset: A variable-length integer indicating the offset of the 2355 stream at which the blocking occurred. 2357 8.12. STREAM_ID_BLOCKED Frame 2359 A sender MAY send a STREAM_ID_BLOCKED frame (type=0x0a) when it 2360 wishes to open a stream, but is unable to due to the maximum stream 2361 ID limit set by its peer (see Section 8.8). This does not open the 2362 stream, but informs the peer that a new stream was needed, but the 2363 stream limit prevented the creation of the stream. 2365 The STREAM_ID_BLOCKED frame is as follows: 2367 0 1 2 3 2368 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 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | Stream ID (i) ... 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 The STREAM_ID_BLOCKED frame contains a single field. 2375 Stream ID: A variable-length integer indicating the highest stream 2376 ID that the sender was permitted to open. 2378 8.13. NEW_CONNECTION_ID Frame 2380 A server sends a NEW_CONNECTION_ID frame (type=0x0b) to provide the 2381 client with alternative connection IDs that can be used to break 2382 linkability when migrating connections (see Section 7.7.1). 2384 The NEW_CONNECTION_ID is as follows: 2386 0 1 2 3 2387 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 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Sequence (i) ... 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | | 2392 + Connection ID (64) + 2393 | | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | | 2396 + + 2397 | | 2398 + Stateless Reset Token (128) + 2399 | | 2400 + + 2401 | | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 The fields are: 2406 Sequence: A variable-length integer. This value starts at 0 and 2407 increases by 1 for each connection ID that is provided by the 2408 server. The connection ID that is assigned during the handshake 2409 is assumed to have a sequence of -1. That is, the value selected 2410 during the handshake comes immediately before the first value that 2411 a server can send. 2413 Connection ID: A 64-bit connection ID. 2415 Stateless Reset Token: A 128-bit value that will be used to for a 2416 stateless reset when the associated connection ID is used (see 2417 Section 7.9.4). 2419 8.14. STOP_SENDING Frame 2421 An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate 2422 that incoming data is being discarded on receipt at application 2423 request. This signals a peer to abruptly terminate transmission on a 2424 stream. 2426 The STOP_SENDING frame is as follows: 2428 0 1 2 3 2429 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 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | Stream ID (i) ... 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 | Application Error Code (16) | 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 The fields are: 2438 Stream ID: A variable-length integer carrying the Stream ID of the 2439 stream being ignored. 2441 Application Error Code: A 16-bit, application-specified reason the 2442 sender is ignoring the stream (see Section 12.4). 2444 8.15. PONG Frame 2446 The PONG frame (type=0x0d) is sent in response to a PING frame that 2447 contains data. Its format is identical to the PING frame 2448 (Section 8.9). 2450 An endpoint that receives an unsolicited PONG frame - that is, a PONG 2451 frame containing a payload that is empty MUST generate a connection 2452 error of type FRAME_ERROR, indicating the PONG frame (that is, 2453 0x10d). If the content of a PONG frame does not match the content of 2454 a PING frame previously sent by the endpoint, the endpoint MAY 2455 generate a connection error of type UNSOLICITED_PONG. 2457 8.16. ACK Frame 2459 Receivers send ACK frames (type=0xe) to inform senders which packets 2460 they have received and processed. A sent packet that has never been 2461 acknowledged is missing. The ACK frame contains any number of ACK 2462 blocks. ACK blocks are ranges of acknowledged packets. 2464 Unlike TCP SACKs, QUIC acknowledgements are irrevocable. Once a 2465 packet has been acknowledged, even if it does not appear in a future 2466 ACK frame, it remains acknowledged. 2468 A client MUST NOT acknowledge Version Negotiation or Retry packets. 2469 These packet types contain packet numbers selected by the client, not 2470 the server. 2472 A sender MAY intentionally skip packet numbers to introduce entropy 2473 into the connection, to avoid opportunistic acknowledgement attacks. 2475 The sender SHOULD close the connection if an unsent packet number is 2476 acknowledged. The format of the ACK frame is efficient at expressing 2477 even long blocks of missing packets, allowing for large, 2478 unpredictable gaps. 2480 An ACK frame is shown below. 2482 0 1 2 3 2483 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 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | Largest Acknowledged (i) ... 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | ACK Delay (i) ... 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | ACK Block Count (i) ... 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | ACK Blocks (*) ... 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 Figure 7: ACK Frame Format 2496 The fields in the ACK frame are as follows: 2498 Largest Acknowledged: A variable-length integer representing the 2499 largest packet number the peer is acknowledging; this is usually 2500 the largest packet number that the peer has received prior to 2501 generating the ACK frame. Unlike the packet number in the QUIC 2502 long or short header, the value in an ACK frame is not truncated. 2504 ACK Delay: A variable-length integer including the time in 2505 microseconds that the largest acknowledged packet, as indicated in 2506 the Largest Acknowledged field, was received by this peer to when 2507 this ACK was sent. The value of the ACK Delay field is scaled by 2508 multiplying the encoded value by the 2 to the power of the value 2509 of the "ack_delay_exponent" transport parameter set by the sender 2510 of the ACK frame. The "ack_delay_exponent" defaults to 3, or a 2511 multiplier of 8 (see Section 7.4.1). Scaling in this fashion 2512 allows for a larger range of values with a shorter encoding at the 2513 cost of lower resolution. 2515 ACK Block Count: The number of Additional ACK Block (and Gap) fields 2516 after the First ACK Block. 2518 ACK Blocks: Contains one or more blocks of packet numbers which have 2519 been successfully received, see Section 8.16.1. 2521 8.16.1. ACK Block Section 2523 The ACK Block Section consists of alternating Gap and ACK Block 2524 fields in descending packet number order. A First Ack Block field is 2525 followed by a variable number of alternating Gap and Additional ACK 2526 Blocks. The number of Gap and Additional ACK Block fields is 2527 determined by the ACK Block Count field. 2529 Gap and ACK Block fields use a relative integer encoding for 2530 efficiency. Though each encoded value is positive, the values are 2531 subtracted, so that each ACK Block describes progressively lower- 2532 numbered packets. As long as contiguous ranges of packets are small, 2533 the variable-length integer encoding ensures that each range can be 2534 expressed in a small number of octets. 2536 0 1 2 3 2537 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 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | First ACK Block (i) ... 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | Gap (i) ... 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Additional ACK Block (i) ... 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Gap (i) ... 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Additional ACK Block (i) ... 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 ... 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Gap (i) ... 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Additional ACK Block (i) ... 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 Figure 8: ACK Block Section 2558 Each ACK Block acknowledges a contiguous range of packets by 2559 indicating the number of acknowledged packets that precede the 2560 largest packet number in that block. A value of zero indicates that 2561 only the largest packet number is acknowledged. Larger ACK Block 2562 values indicate a larger range, with corresponding lower values for 2563 the smallest packet number in the range. Thus, given a largest 2564 packet number for the ACK, the smallest value is determined by the 2565 formula: 2567 smallest = largest - ack_block 2569 The range of packets that are acknowledged by the ACK block include 2570 the range from the smallest packet number to the largest, inclusive. 2572 The largest value for the First ACK Block is determined by the 2573 Largest Acknowledged field; the largest for Additional ACK Blocks is 2574 determined by cumulatively subtracting the size of all preceding ACK 2575 Blocks and Gaps. 2577 Each Gap indicates a range of packets that are not being 2578 acknowledged. The number of packets in the gap is one higher than 2579 the encoded value of the Gap Field. 2581 The value of the Gap field establishes the largest packet number 2582 value for the ACK block that follows the gap using the following 2583 formula: 2585 largest = previous_smallest - gap - 2 2587 If the calculated value for largest or smallest packet number for any 2588 ACK Block is negative, an endpoint MUST generate a connection error 2589 of type FRAME_ERROR indicating an error in an ACK frame (that is, 2590 0x10d). 2592 The fields in the ACK Block Section are: 2594 First ACK Block: A variable-length integer indicating the number of 2595 contiguous packets preceding the Largest Acknowledged that are 2596 being acknowledged. 2598 Gap (repeated): A variable-length integer indicating the number of 2599 contiguous unacknowledged packets preceding the packet number one 2600 lower than the smallest in the preceding ACK Block. 2602 ACK Block (repeated): A variable-length integer indicating the 2603 number of contiguous acknowledged packets preceding the largest 2604 packet number, as determined by the preceding Gap. 2606 8.16.2. Sending ACK Frames 2608 Implementations MUST NOT generate packets that only contain ACK 2609 frames in response to packets which only contain ACK frames. 2610 However, they MUST acknowledge packets containing only ACK frames 2611 when sending ACK frames in response to other packets. 2612 Implementations MUST NOT send more than one ACK frame per received 2613 packet that contains frames other than ACK frames. Packets 2614 containing non-ACK frames MUST be acknowledged immediately or when a 2615 delayed ack timer expires. 2617 To limit ACK blocks to those that have not yet been received by the 2618 sender, the receiver SHOULD track which ACK frames have been 2619 acknowledged by its peer. Once an ACK frame has been acknowledged, 2620 the packets it acknowledges SHOULD NOT be acknowledged again. 2622 A receiver that is only sending ACK frames will not receive 2623 acknowledgments for its packets. Sending an occasional MAX_DATA or 2624 MAX_STREAM_DATA frame as data is received will ensure that 2625 acknowledgements are generated by a peer. Otherwise, an endpoint MAY 2626 send a PING frame once per RTT to solicit an acknowledgment. 2628 To limit receiver state or the size of ACK frames, a receiver MAY 2629 limit the number of ACK blocks it sends. A receiver can do this even 2630 without receiving acknowledgment of its ACK frames, with the 2631 knowledge this could cause the sender to unnecessarily retransmit 2632 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 2633 lost after sufficiently newer packets are acknowledged. Therefore, 2634 the receiver SHOULD repeatedly acknowledge newly received packets in 2635 preference to packets received in the past. 2637 8.16.3. ACK Frames and Packet Protection 2639 ACK frames that acknowledge protected packets MUST be carried in a 2640 packet that has an equivalent or greater level of packet protection. 2642 Packets that are protected with 1-RTT keys MUST be acknowledged in 2643 packets that are also protected with 1-RTT keys. 2645 A packet that is not protected and claims to acknowledge a packet 2646 number that was sent with packet protection is not valid. An 2647 unprotected packet that carries acknowledgments for protected packets 2648 MUST be discarded in its entirety. 2650 Packets that a client sends with 0-RTT packet protection MUST be 2651 acknowledged by the server in packets protected by 1-RTT keys. This 2652 can mean that the client is unable to use these acknowledgments if 2653 the server cryptographic handshake messages are delayed or lost. 2654 Note that the same limitation applies to other data sent by the 2655 server protected by the 1-RTT keys. 2657 Unprotected packets, such as those that carry the initial 2658 cryptographic handshake messages, MAY be acknowledged in unprotected 2659 packets. Unprotected packets are vulnerable to falsification or 2660 modification. Unprotected packets can be acknowledged along with 2661 protected packets in a protected packet. 2663 An endpoint SHOULD acknowledge packets containing cryptographic 2664 handshake messages in the next unprotected packet that it sends, 2665 unless it is able to acknowledge those packets in later packets 2666 protected by 1-RTT keys. At the completion of the cryptographic 2667 handshake, both peers send unprotected packets containing 2668 cryptographic handshake messages followed by packets protected by 2669 1-RTT keys. An endpoint SHOULD acknowledge the unprotected packets 2670 that complete the cryptographic handshake in a protected packet, 2671 because its peer is guaranteed to have access to 1-RTT packet 2672 protection keys. 2674 For instance, a server acknowledges a TLS ClientHello in the packet 2675 that carries the TLS ServerHello; similarly, a client can acknowledge 2676 a TLS HelloRetryRequest in the packet containing a second TLS 2677 ClientHello. The complete set of server handshake messages (TLS 2678 ServerHello through to Finished) might be acknowledged by a client in 2679 protected packets, because it is certain that the server is able to 2680 decipher the packet. 2682 8.17. STREAM Frames 2684 STREAM frames implicitly create a stream and carry stream data. The 2685 STREAM frame takes the form 0b00010XXX (or the set of values from 2686 0x10 to 0x17). The value of the three low-order bits of the frame 2687 type determine the fields that are present in the frame. 2689 o The OFF bit (0x04) in the frame type is set to indicate that there 2690 is an Offset field present. When set to 1, the Offset field is 2691 present; when set to 0, the Offset field is absent and the Stream 2692 Data starts at an offset of 0 (that is, the frame contains the 2693 first octets of the stream, or the end of a stream that includes 2694 no data). 2696 o The LEN bit (0x02) in the frame type is set to indicate that there 2697 is a Length field present. If this bit is set to 0, the Length 2698 field is absent and the Stream Data field extends to the end of 2699 the packet. If this bit is set to 1, the Length field is present. 2701 o The FIN bit (0x01) of the frame type is set only on frames that 2702 contain the final offset of the stream. Setting this bit 2703 indicates that the frame marks the end of the stream. 2705 A STREAM frame is shown below. 2707 0 1 2 3 2708 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 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | Stream ID (i) ... 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | [Offset (i)] ... 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 | [Length (i)] ... 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 | Stream Data (*) ... 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 Figure 9: STREAM Frame Format 2721 The STREAM frame contains the following fields: 2723 Stream ID: A variable-length integer indicating the stream ID of the 2724 stream (see Section 10.1). 2726 Offset: A variable-length integer specifying the byte offset in the 2727 stream for the data in this STREAM frame. This field is present 2728 when the OFF bit is set to 1. When the Offset field is absent, 2729 the offset is 0. 2731 Length: A variable-length integer specifying the length of the 2732 Stream Data field in this STREAM frame. This field is present 2733 when the LEN bit is set to 1. When the LEN bit is set to 0, the 2734 Stream Data field consumes all the remaining octets in the packet. 2736 Stream Data: The bytes from the designated stream to be delivered. 2738 A stream frame's Stream Data MUST NOT be empty, unless the FIN bit is 2739 set. When the FIN flag is sent on an empty STREAM frame, the offset 2740 in the STREAM frame is the offset of the next byte that would be 2741 sent. 2743 The first byte in the stream has an offset of 0. The largest offset 2744 delivered on a stream - the sum of the re-constructed offset and data 2745 length - MUST be less than 2^62. 2747 Stream multiplexing is achieved by interleaving STREAM frames from 2748 multiple streams into one or more QUIC packets. A single QUIC packet 2749 can include multiple STREAM frames from one or more streams. 2751 Implementation note: One of the benefits of QUIC is avoidance of 2752 head-of-line blocking across multiple streams. When a packet loss 2753 occurs, only streams with data in that packet are blocked waiting for 2754 a retransmission to be received, while other streams can continue 2755 making progress. Note that when data from multiple streams is 2756 bundled into a single QUIC packet, loss of that packet blocks all 2757 those streams from making progress. An implementation is therefore 2758 advised to bundle as few streams as necessary in outgoing packets 2759 without losing transmission efficiency to underfilled packets. 2761 9. Packetization and Reliability 2763 A sender bundles one or more frames in a Regular QUIC packet (see 2764 Section 6). 2766 A sender SHOULD minimize per-packet bandwidth and computational costs 2767 by bundling as many frames as possible within a QUIC packet. A 2768 sender MAY wait for a short period of time to bundle multiple frames 2769 before sending a packet that is not maximally packed, to avoid 2770 sending out large numbers of small packets. An implementation may 2771 use heuristics about expected application sending behavior to 2772 determine whether and for how long to wait. This waiting period is 2773 an implementation decision, and an implementation should be careful 2774 to delay conservatively, since any delay is likely to increase 2775 application-visible latency. 2777 Regular QUIC packets are "containers" of frames; a packet is never 2778 retransmitted whole. How an endpoint handles the loss of the frame 2779 depends on the type of the frame. Some frames are simply 2780 retransmitted, some have their contents moved to new frames, and 2781 others are never retransmitted. 2783 When a packet is detected as lost, the sender re-sends any frames as 2784 necessary: 2786 o All application data sent in STREAM frames MUST be retransmitted, 2787 unless the endpoint has sent a RST_STREAM for that stream. When 2788 an endpoint sends a RST_STREAM frame, data outstanding on that 2789 stream SHOULD NOT be retransmitted, since subsequent data on this 2790 stream is expected to not be delivered by the receiver. 2792 o ACK and PADDING frames MUST NOT be retransmitted. ACK frames 2793 containing updated information will be sent as described in 2794 Section 8.16. 2796 o STOP_SENDING frames MUST be retransmitted until the receive stream 2797 enters either a "Data Recvd" or "Reset Recvd" state. See 2798 Section 10.3. 2800 o The most recent MAX_STREAM_DATA frame for a stream MUST be 2801 retransmitted until the receive stream enters a "Size Known" 2802 state. Any previous unacknowledged MAX_STREAM_DATA frame for the 2803 same stream SHOULD NOT be retransmitted since a newer 2804 MAX_STREAM_DATA frame for a stream obviates the need for 2805 delivering older ones. Similarly, the most recent MAX_DATA frame 2806 MUST be retransmitted; previous unacknowledged ones SHOULD NOT be 2807 retransmitted. 2809 o BLOCKED, STREAM_BLOCKED, and STREAM_ID_BLOCKED frames SHOULD be 2810 retransmitted if the sender is still blocked on the same limit. 2811 If the limit has been increased since the frame was originally 2812 sent, the frame SHOULD NOT be retransmitted. 2814 o All other frames MUST be retransmitted. 2816 Upon detecting losses, a sender MUST take appropriate congestion 2817 control action. The details of loss detection and congestion control 2818 are described in [QUIC-RECOVERY]. 2820 A packet MUST NOT be acknowledged until packet protection has been 2821 successfully removed and all frames contained in the packet have been 2822 processed. For STREAM frames, this means the data has been queued 2823 (but not necessarily delivered to the application). This also means 2824 that any stream state transitions triggered by STREAM or RST_STREAM 2825 frames have occurred. Once the packet has been fully processed, a 2826 receiver acknowledges receipt by sending one or more ACK frames 2827 containing the packet number of the received packet. 2829 To avoid creating an indefinite feedback loop, an endpoint MUST NOT 2830 send an ACK frame in response to a packet containing only ACK or 2831 PADDING frames, even if there are packet gaps which precede the 2832 received packet. The endpoint MUST acknowledge packets containing 2833 only ACK or PADDING frames in the next ACK frame that it sends. 2835 Strategies and implications of the frequency of generating 2836 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 2838 9.1. Packet Size 2840 The QUIC packet size includes the QUIC header and integrity check, 2841 but not the UDP or IP header. 2843 Clients MUST pad any Initial packet it sends to have a QUIC packet 2844 size of at least 1200 octets. Sending an Initial packet of this size 2845 ensures that the network path supports a reasonably sized packet, and 2846 helps reduce the amplitude of amplification attacks caused by server 2847 responses toward an unverified client address. 2849 An Initial packet MAY exceed 1200 octets if the client knows that the 2850 Path Maximum Transmission Unit (PMTU) supports the size that it 2851 chooses. 2853 A server MAY send a CONNECTION_CLOSE frame with error code 2854 PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200 2855 octets. It MUST NOT send any other frame type in response, or 2856 otherwise behave as if any part of the offending packet was processed 2857 as valid. 2859 9.2. Path Maximum Transmission Unit 2861 The Path Maximum Transmission Unit (PMTU) is the maximum size of the 2862 entire IP header, UDP header, and UDP payload. The UDP payload 2863 includes the QUIC packet header, protected payload, and any 2864 authentication fields. 2866 All QUIC packets SHOULD be sized to fit within the estimated PMTU to 2867 avoid IP fragmentation or packet drops. To optimize bandwidth 2868 efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery 2869 ([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) 2870 for detecting the PMTU, setting the PMTU appropriately, and storing 2871 the result of previous PMTU determinations. 2873 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 2874 packets larger than 1280 octets. Assuming the minimum IP header 2875 size, this results in a QUIC packet size of 1232 octets for IPv6 and 2876 1252 octets for IPv4. Some QUIC implementations MAY wish to be more 2877 conservative in computing allowed QUIC packet size given unknown 2878 tunneling overheads or IP header options. 2880 QUIC endpoints that implement any kind of PMTU discovery SHOULD 2881 maintain an estimate for each combination of local and remote IP 2882 addresses. Each pairing of local and remote addresses could have a 2883 different maximum MTU in the path. 2885 QUIC depends on the network path supporting a MTU of at least 1280 2886 octets. This is the IPv6 minimum MTU and therefore also supported by 2887 most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below 2888 this number, even if it receives signals that indicate a smaller 2889 limit might exist. 2891 If a QUIC endpoint determines that the PMTU between any pair of local 2892 and remote IP addresses has fallen below 1280 octets, it MUST 2893 immediately cease sending QUIC packets on the affected path. This 2894 could result in termination of the connection if an alternative path 2895 cannot be found. 2897 9.2.1. Special Considerations for PMTU Discovery 2899 Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is 2900 potentially vulnerable to off-path attacks that successfully guess 2901 the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient 2902 value. TCP connections mitigate this risk by using the (at minimum) 2903 8 bytes of transport header echoed in the ICMP message to validate 2904 the TCP sequence number as valid for the current connection. 2905 However, as QUIC operates over UDP, in IPv4 the echoed information 2906 could consist only of the IP and UDP headers, which usually has 2907 insufficient entropy to mitigate off-path attacks. 2909 As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps 2910 to mitigate this risk. For instance, an application could: 2912 o Set the IPv4 Don't Fragment (DF) bit on a small proportion of 2913 packets, so that most invalid ICMP messages arrive when there are 2914 no DF packets outstanding, and can therefore be identified as 2915 spurious. 2917 o Store additional information from the IP or UDP headers from DF 2918 packets (for example, the IP ID or UDP checksum) to further 2919 authenticate incoming Datagram Too Big messages. 2921 o Any reduction in PMTU due to a report contained in an ICMP packet 2922 is provisional until QUIC's loss detection algorithm determines 2923 that the packet is actually lost. 2925 9.2.2. Special Considerations for Packetization Layer PMTU Discovery 2927 The PADDING frame provides a useful option for PMTU probe packets 2928 that does not exist in other transports. PADDING frames generate 2929 acknowledgements, but their content need not be delivered reliably. 2930 PADDING frames may delay the delivery of application data, as they 2931 consume the congestion window. However, by definition their likely 2932 loss in a probe packet does not require delay-inducing retransmission 2933 of application data. 2935 When implementing the algorithm in Section 7.2 of [RFC4821], the 2936 initial value of search_low SHOULD be consistent with the IPv6 2937 minimum packet size. Paths that do not support this size cannot 2938 deliver Initial packets, and therefore are not QUIC-compliant. 2940 Section 7.3 of [RFC4821] discusses tradeoffs between small and large 2941 increases in the size of probe packets. As QUIC probe packets need 2942 not contain application data, aggressive increases in probe size 2943 carry fewer consequences. 2945 10. Streams: QUIC's Data Structuring Abstraction 2947 Streams in QUIC provide a lightweight, ordered byte-stream 2948 abstraction. 2950 There are two basic types of stream in QUIC. Unidirectional streams 2951 carry data in one direction only; bidirectional streams allow for 2952 data to be sent in both directions. Different stream identifiers are 2953 used to distinguish between unidirectional and bidirectional streams, 2954 as well as to create a separation between streams that are initiated 2955 by the client and server (see Section 10.1). 2957 Either type of stream can be created by either endpoint, can 2958 concurrently send data interleaved with other streams, and can be 2959 cancelled. 2961 Data that is received on a stream is delivered in order within that 2962 stream, but there is no particular delivery order across streams. 2963 Transmit ordering among streams is left to the implementation. 2965 The creation and destruction of streams are expected to have minimal 2966 bandwidth and computational cost. A single STREAM frame may create, 2967 carry data for, and terminate a stream, or a stream may last the 2968 entire duration of a connection. 2970 Streams are individually flow controlled, allowing an endpoint to 2971 limit memory commitment and to apply back pressure. The creation of 2972 streams is also flow controlled, with each peer declaring the maximum 2973 stream ID it is willing to accept at a given time. 2975 An alternative view of QUIC streams is as an elastic "message" 2976 abstraction, similar to the way ephemeral streams are used in SST 2977 [SST], which may be a more appealing description for some 2978 applications. 2980 10.1. Stream Identifiers 2982 Streams are identified by an unsigned 62-bit integer, referred to as 2983 the Stream ID. The least significant two bits of the Stream ID are 2984 used to identify the type of stream (unidirectional or bidirectional) 2985 and the initiator of the stream. 2987 The least significant bit (0x1) of the Stream ID identifies the 2988 initiator of the stream. Clients initiate even-numbered streams 2989 (those with the least significant bit set to 0); servers initiate 2990 odd-numbered streams (with the bit set to 1). Separation of the 2991 stream identifiers ensures that client and server are able to open 2992 streams without the latency imposed by negotiating for an identifier. 2994 If an endpoint receives a frame for a stream that it expects to 2995 initiate (i.e., odd-numbered for the client or even-numbered for the 2996 server), but which it has not yet opened, it MUST close the 2997 connection with error code STREAM_STATE_ERROR. 2999 The second least significant bit (0x2) of the Stream ID 3000 differentiates between unidirectional streams and bidirectional 3001 streams. Unidirectional streams always have this bit set to 1 and 3002 bidirectional streams have this bit set to 0. 3004 The two type bits from a Stream ID therefore identify streams as 3005 summarized in Table 5. 3007 +----------+----------------------------------+ 3008 | Low Bits | Stream Type | 3009 +----------+----------------------------------+ 3010 | 0x0 | Client-Initiated, Bidirectional | 3011 | | | 3012 | 0x1 | Server-Initiated, Bidirectional | 3013 | | | 3014 | 0x2 | Client-Initiated, Unidirectional | 3015 | | | 3016 | 0x3 | Server-Initiated, Unidirectional | 3017 +----------+----------------------------------+ 3019 Table 5: Stream ID Types 3021 Stream ID 0 (0x0) is a client-initiated, bidirectional stream that is 3022 used for the cryptographic handshake. Stream 0 MUST NOT be used for 3023 application data. 3025 A QUIC endpoint MUST NOT reuse a Stream ID. Open streams can be used 3026 in any order. Streams that are used out of order result in opening 3027 all lower-numbered streams of the same type in the same direction. 3029 Stream IDs are encoded as a variable-length integer (see 3030 Section 8.1). 3032 10.2. Stream States 3034 This section describes the two types of QUIC stream in terms of the 3035 states of their send or receive components. Two state machines are 3036 described: one for streams on which an endpoint transmits data 3037 (Section 10.2.1); another for streams from which an endpoint receives 3038 data (Section 10.2.2). 3040 Unidirectional streams use the applicable state machine directly. 3041 Bidirectional streams use both state machines. For the most part, 3042 the use of these state machines is the same whether the stream is 3043 unidirectional or bidirectional. The conditions for opening a stream 3044 are slightly more complex for a bidirectional stream because the 3045 opening of either send or receive causes the stream to open in both 3046 directions. 3048 Opening a stream causes all lower-numbered streams of the same type 3049 to implicitly open. This includes both send and receive streams if 3050 the stream is bidirectional. For bidirectional streams, an endpoint 3051 can send data on an implicitly opened stream. On both unidirectional 3052 and bidirectional streams, an endpoint MAY send MAX_STREAM_DATA or 3053 STOP_SENDING on implicitly opened streams. An endpoint SHOULD NOT 3054 implicitly open streams that it initiates, instead opening streams in 3055 order. 3057 Note: These states are largely informative. This document uses 3058 stream states to describe rules for when and how different types 3059 of frames can be sent and the reactions that are expected when 3060 different types of frames are received. Though these state 3061 machines are intended to be useful in implementing QUIC, these 3062 states aren't intended to constrain implementations. An 3063 implementation can define a different state machine as long as its 3064 behavior is consistent with an implementation that implements 3065 these states. 3067 10.2.1. Send Stream States 3069 Figure 10 shows the states for the part of a stream that sends data 3070 to a peer. 3072 o 3073 | Application Open 3074 | Open Paired Stream (bidirectional) 3075 v 3076 +-------+ 3077 | Open | Send RST_STREAM 3078 | |-----------------------. 3079 +-------+ | 3080 | | 3081 | Send STREAM / | 3082 | STREAM_BLOCKED | 3083 v | 3084 +-------+ | 3085 | Send | Send RST_STREAM | 3086 | |---------------------->| 3087 +-------+ | 3088 | | 3089 | Send STREAM + FIN | 3090 v v 3091 +-------+ +-------+ 3092 | Data | Send RST_STREAM | Reset | 3093 | Sent +------------------>| Sent | 3094 +-------+ +-------+ 3095 | | 3096 | Recv All ACKs | Recv ACK 3097 v v 3098 +-------+ +-------+ 3099 | Data | | Reset | 3100 | Recvd | | Recvd | 3101 +-------+ +-------+ 3103 Figure 10: States for Send Streams 3105 The sending part of stream that the endpoint initiates (types 0 and 2 3106 for clients, 1 and 3 for servers) is opened by the application or 3107 application protocol. The "Open" state represents a newly created 3108 stream that is able to accept data from the application. Stream data 3109 might be buffered in this state in preparation for sending. 3111 The sending part of a bidirectional stream initiated by a peer (type 3112 0 for a server, type 1 for a client) enters the "Open" state if the 3113 receiving part enters the "Recv" state. 3115 Sending the first STREAM or STREAM_BLOCKED frame causes a send stream 3116 to enter the "Send" state. An implementation might choose to defer 3117 allocating a Stream ID to a send stream until it sends the first 3118 frame and enters this state, which can allow for better stream 3119 prioritization. 3121 In the "Send" state, an endpoint transmits - and retransmits as 3122 necessary - data in STREAM frames. The endpoint respects the flow 3123 control limits of its peer, accepting MAX_STREAM_DATA frames. An 3124 endpoint in the "Send" state generates STREAM_BLOCKED frames if it 3125 encounters flow control limits. 3127 After the application indicates that stream data is complete and a 3128 STREAM frame containing the FIN bit is sent, the send stream enters 3129 the "Data Sent" state. From this state, the endpoint only 3130 retransmits stream data as necessary. The endpoint no longer needs 3131 to track flow control limits or send STREAM_BLOCKED frames for a send 3132 stream in this state. The endpoint can ignore any MAX_STREAM_DATA 3133 frames it receives from its peer in this state; MAX_STREAM_DATA 3134 frames might be received until the peer receives the final stream 3135 offset. 3137 Once all stream data has been successfully acknowledged, the send 3138 stream enters the "Data Recvd" state, which is a terminal state. 3140 From any of the "Open", "Send", or "Data Sent" states, an application 3141 can signal that it wishes to abandon transmission of stream data. 3142 Similarly, the endpoint might receive a STOP_SENDING frame from its 3143 peer. In either case, the endpoint sends a RST_STREAM frame, which 3144 causes the stream to enter the "Reset Sent" state. 3146 An endpoint MAY send a RST_STREAM as the first frame on a send 3147 stream; this causes the send stream to open and then immediately 3148 transition to the "Reset Sent" state. 3150 Once a packet containing a RST_STREAM has been acknowledged, the send 3151 stream enters the "Reset Recvd" state, which is a terminal state. 3153 10.2.2. Receive Stream States 3155 Figure 11 shows the states for the part of a stream that receives 3156 data from a peer. The states for a receive stream mirror only some 3157 of the states of the send stream at the peer. A receive stream 3158 doesn't track states on the send stream that cannot be observed, such 3159 as the "Open" state; instead, receive streams track the delivery of 3160 data to the application or application protocol some of which cannot 3161 be observed by the sender. 3163 o 3164 | Recv STREAM / STREAM_BLOCKED / RST_STREAM 3165 | Open Paired Stream (bidirectional) 3166 | Recv MAX_STREAM_DATA 3167 v 3168 +-------+ 3169 | Recv | Recv RST_STREAM 3170 | |-----------------------. 3171 +-------+ | 3172 | | 3173 | Recv STREAM + FIN | 3174 v | 3175 +-------+ | 3176 | Size | Recv RST_STREAM | 3177 | Known +---------------------->| 3178 +-------+ | 3179 | | 3180 | Recv All Data | 3181 v v 3182 +-------+ +-------+ 3183 | Data | Recv RST_STREAM | Reset | 3184 | Recvd +<-- (optional) --->| Recvd | 3185 +-------+ +-------+ 3186 | | 3187 | App Read All Data | App Read RST 3188 v v 3189 +-------+ +-------+ 3190 | Data | | Reset | 3191 | Read | | Read | 3192 +-------+ +-------+ 3194 Figure 11: States for Receive Streams 3196 The receiving part of a stream initiated by a peer (types 1 and 3 for 3197 a client, or 0 and 2 for a server) are created when the first STREAM, 3198 STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only, 3199 see below) is received for that stream. The initial state for a 3200 receive stream is "Recv". Receiving a RST_STREAM frame causes the 3201 receive stream to immediately transition to the "Reset Recvd". 3203 The receive stream enters the "Recv" state when the sending part of a 3204 bidirectional stream initiated by the endpoint (type 0 for a client, 3205 type 1 for a server) enters the "Open" state. 3207 A bidirectional stream also opens when a MAX_STREAM_DATA frame is 3208 received. Receiving a MAX_STREAM_DATA frame implies that the remote 3209 peer has opened the stream and is providing flow control credit. A 3210 MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED 3211 frame if packets are lost or reordered. 3213 In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED 3214 frames. Incoming data is buffered and reassembled into the correct 3215 order for delivery to the application. As data is consumed by the 3216 application and buffer space becomes available, the endpoint sends 3217 MAX_STREAM_DATA frames to allow the peer to send more data. 3219 When a STREAM frame with a FIN bit is received, the final offset (see 3220 Section 11.3) is known. The receive stream enters the "Size Known" 3221 state. In this state, the endpoint no longer needs to send 3222 MAX_STREAM_DATA frames, it only receives any retransmissions of 3223 stream data. 3225 Once all data for the stream has been received, the receive stream 3226 enters the "Data Recvd" state. This might happen as a result of 3227 receiving the same STREAM frame that causes the transition to "Size 3228 Known". In this state, the endpoint has all stream data. Any STREAM 3229 or STREAM_BLOCKED frames it receives for the stream can be discarded. 3231 The "Data Recvd" state persists until stream data has been delivered 3232 to the application or application protocol. Once stream data has 3233 been delivered, the stream enters the "Data Read" state, which is a 3234 terminal state. 3236 Receiving a RST_STREAM frame in the "Recv" or "Size Known" states 3237 causes the stream to enter the "Reset Recvd" state. This might cause 3238 the delivery of stream data to the application to be interrupted. 3240 It is possible that all stream data is received when a RST_STREAM is 3241 received (that is, from the "Data Recvd" state). Similarly, it is 3242 possible for remaining stream data to arrive after receiving a 3243 RST_STREAM frame (the "Reset Recvd" state). An implementation is 3244 able to manage this situation as they choose. Sending RST_STREAM 3245 means that an endpoint cannot guarantee delivery of stream data; 3246 however there is no requirement that stream data not be delivered if 3247 a RST_STREAM is received. An implementation MAY interrupt delivery 3248 of stream data, discard any data that was not consumed, and signal 3249 the existence of the RST_STREAM immediately. Alternatively, the 3250 RST_STREAM signal might be suppressed or withheld if stream data is 3251 completely received. In the latter case, the receive stream 3252 effectively transitions to "Data Recvd" from "Reset Recvd". 3254 Once the application has been delivered the signal indicating that 3255 the receive stream was reset, the receive stream transitions to the 3256 "Reset Read" state, which is a terminal state. 3258 10.2.3. Permitted Frame Types 3260 The sender of a stream sends just three frame types that affect the 3261 state of a stream at either sender or receiver: STREAM 3262 (Section 8.17), STREAM_BLOCKED (Section 8.11), and RST_STREAM 3263 (Section 8.3). 3265 A sender MUST NOT send any of these frames from a terminal state 3266 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 3267 STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset 3268 Sent" state in addition to the terminal states. A receiver could 3269 receive any of these frames in any state, but only due to the 3270 possibility of delayed delivery of packets carrying them. 3272 The receiver of a stream sends MAX_STREAM_DATA (Section 8.7) and 3273 STOP_SENDING frames (Section 8.14). 3275 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 3276 receiver can send STOP_SENDING in any state where it has not received 3277 a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset 3278 Read". However there is little value in sending a STOP_SENDING frame 3279 after all stream data has been received in the "Data Recvd" state. A 3280 sender could receive these frames in any state as a result of delayed 3281 delivery of packets. 3283 10.2.4. Bidirectional Stream States 3285 A bidirectional stream is composed of a send stream and a receive 3286 stream. Implementations may represent states of the bidirectional 3287 stream as composites of send and receive stream states. The simplest 3288 model presents the stream as "open" when either send or receive 3289 stream is in a non-terminal state and "closed" when both send and 3290 receive streams are in a terminal state. 3292 Table 6 shows a more complex mapping of bidirectional stream states 3293 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 3294 shows that multiple states on send or receive streams are mapped to 3295 the same composite state. Note that this is just one possibility for 3296 such a mapping; this mapping requires that data is acknowledged 3297 before the transition to a "closed" or "half-closed" state. 3299 +-----------------------+---------------------+---------------------+ 3300 | Send Stream | Receive Stream | Composite State | 3301 +-----------------------+---------------------+---------------------+ 3302 | No Stream/Open | No Stream/Recv *1 | idle | 3303 | | | | 3304 | Open/Send/Data Sent | Recv/Size Known | open | 3305 | | | | 3306 | Open/Send/Data Sent | Data Recvd/Data | half-closed | 3307 | | Read | (remote) | 3308 | | | | 3309 | Open/Send/Data Sent | Reset Recvd/Reset | half-closed | 3310 | | Read | (remote) | 3311 | | | | 3312 | Data Recvd | Recv/Size Known | half-closed (local) | 3313 | | | | 3314 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 3315 | Recvd | | | 3316 | | | | 3317 | Data Recvd | Recv/Size Known | half-closed (local) | 3318 | | | | 3319 | Reset Sent/Reset | Data Recvd/Data | closed | 3320 | Recvd | Read | | 3321 | | | | 3322 | Reset Sent/Reset | Reset Recvd/Reset | closed | 3323 | Recvd | Read | | 3324 | | | | 3325 | Data Recvd | Data Recvd/Data | closed | 3326 | | Read | | 3327 | | | | 3328 | Data Recvd | Reset Recvd/Reset | closed | 3329 | | Read | | 3330 +-----------------------+---------------------+---------------------+ 3332 Table 6: Possible Mapping of Stream States to HTTP/2 3334 Note (*1): A stream is considered "idle" if it has not yet been 3335 created, or if the receive stream is in the "Recv" state without 3336 yet having received any frames. 3338 10.3. Solicited State Transitions 3340 If an endpoint is no longer interested in the data it is receiving on 3341 a stream, it MAY send a STOP_SENDING frame identifying that stream to 3342 prompt closure of the stream in the opposite direction. This 3343 typically indicates that the receiving application is no longer 3344 reading data it receives from the stream, but is not a guarantee that 3345 incoming data will be ignored. 3347 STREAM frames received after sending STOP_SENDING are still counted 3348 toward the connection and stream flow-control windows, even though 3349 these frames will be discarded upon receipt. This avoids potential 3350 ambiguity about which STREAM frames count toward flow control. 3352 A STOP_SENDING frame requests that the receiving endpoint send a 3353 RST_STREAM frame. An endpoint that receives a STOP_SENDING frame 3354 MUST send a RST_STREAM frame for that stream, and can use an error 3355 code of STOPPING. If the STOP_SENDING frame is received on a send 3356 stream that is already in the "Data Sent" state, a RST_STREAM frame 3357 MAY still be sent in order to cancel retransmission of previously- 3358 sent STREAM frames. 3360 STOP_SENDING SHOULD only be sent for a receive stream that has not 3361 been reset. STOP_SENDING is most useful for streams in the "Recv" or 3362 "Size Known" states. 3364 An endpoint is expected to send another STOP_SENDING frame if a 3365 packet containing a previous STOP_SENDING is lost. However, once 3366 either all stream data or a RST_STREAM frame has been received for 3367 the stream - that is, the stream is in any state other than "Recv" or 3368 "Size Known" - sending a STOP_SENDING frame is unnecessary. 3370 10.4. Stream Concurrency 3372 An endpoint limits the number of concurrently active incoming streams 3373 by adjusting the maximum stream ID. An initial value is set in the 3374 transport parameters (see Section 7.4.1) and is subsequently 3375 increased by MAX_STREAM_ID frames (see Section 8.8). 3377 The maximum stream ID is specific to each endpoint and applies only 3378 to the peer that receives the setting. That is, clients specify the 3379 maximum stream ID the server can initiate, and servers specify the 3380 maximum stream ID the client can initiate. Each endpoint may respond 3381 on streams initiated by the other peer, regardless of whether it is 3382 permitted to initiated new streams. 3384 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 3385 that receives a STREAM frame with an ID greater than the limit it has 3386 sent MUST treat this as a stream error of type STREAM_ID_ERROR 3387 (Section 12), unless this is a result of a change in the initial 3388 offsets (see Section 7.4.2). 3390 A receiver MUST NOT renege on an advertisement; that is, once a 3391 receiver advertises a stream ID via a MAX_STREAM_ID frame, it MUST 3392 NOT subsequently advertise a smaller maximum ID. A sender may 3393 receive MAX_STREAM_ID frames out of order; a sender MUST therefore 3394 ignore any MAX_STREAM_ID that does not increase the maximum. 3396 10.5. Sending and Receiving Data 3398 Once a stream is created, endpoints may use the stream to send and 3399 receive data. Each endpoint may send a series of STREAM frames 3400 encapsulating data on a stream until the stream is terminated in that 3401 direction. Streams are an ordered byte-stream abstraction, and they 3402 have no other structure within them. STREAM frame boundaries are not 3403 expected to be preserved in retransmissions from the sender or during 3404 delivery to the application at the receiver. 3406 When new data is to be sent on a stream, a sender MUST set the 3407 encapsulating STREAM frame's offset field to the stream offset of the 3408 first byte of this new data. The first byte of data that is sent on 3409 a stream has the stream offset 0. The largest offset delivered on a 3410 stream MUST be less than 2^62. A receiver MUST ensure that received 3411 stream data is delivered to the application as an ordered byte- 3412 stream. Data received out of order MUST be buffered for later 3413 delivery, as long as it is not in violation of the receiver's flow 3414 control limits. 3416 An endpoint MUST NOT send data on any stream without ensuring that it 3417 is within the data limits set by its peer. The cryptographic 3418 handshake stream, Stream 0, is exempt from the connection-level data 3419 limits established by MAX_DATA. Data on stream 0 other than the 3420 initial cryptographic handshake message is still subject to stream- 3421 level data limits and MAX_STREAM_DATA. This message is exempt from 3422 flow control because it needs to be sent in a single packet 3423 regardless of the server's flow control state. This rule applies 3424 even for 0-RTT handshakes where the remembered value of 3425 MAX_STREAM_DATA would not permit sending a full initial cryptographic 3426 handshake message. 3428 Flow control is described in detail in Section 11, and congestion 3429 control is described in the companion document [QUIC-RECOVERY]. 3431 10.6. Stream Prioritization 3433 Stream multiplexing has a significant effect on application 3434 performance if resources allocated to streams are correctly 3435 prioritized. Experience with other multiplexed protocols, such as 3436 HTTP/2 [HTTP2], shows that effective prioritization strategies have a 3437 significant positive impact on performance. 3439 QUIC does not provide frames for exchanging prioritization 3440 information. Instead it relies on receiving priority information 3441 from the application that uses QUIC. Protocols that use QUIC are 3442 able to define any prioritization scheme that suits their application 3443 semantics. A protocol might define explicit messages for signaling 3444 priority, such as those defined in HTTP/2; it could define rules that 3445 allow an endpoint to determine priority based on context; or it could 3446 leave the determination to the application. 3448 A QUIC implementation SHOULD provide ways in which an application can 3449 indicate the relative priority of streams. When deciding which 3450 streams to dedicate resources to, QUIC SHOULD use the information 3451 provided by the application. Failure to account for priority of 3452 streams can result in suboptimal performance. 3454 Stream priority is most relevant when deciding which stream data will 3455 be transmitted. Often, there will be limits on what can be 3456 transmitted as a result of connection flow control or the current 3457 congestion controller state. 3459 Giving preference to the transmission of its own management frames 3460 ensures that the protocol functions efficiently. That is, 3461 prioritizing frames other than STREAM frames ensures that loss 3462 recovery, congestion control, and flow control operate effectively. 3464 Stream 0 MUST be prioritized over other streams prior to the 3465 completion of the cryptographic handshake. This includes the 3466 retransmission of the second flight of client handshake messages, 3467 that is, the TLS Finished and any client authentication messages. 3469 STREAM frames that are determined to be lost SHOULD be retransmitted 3470 before sending new data, unless application priorities indicate 3471 otherwise. Retransmitting lost stream data can fill in gaps, which 3472 allows the peer to consume already received data and free up flow 3473 control window. 3475 11. Flow Control 3477 It is necessary to limit the amount of data that a sender may have 3478 outstanding at any time, so as to prevent a fast sender from 3479 overwhelming a slow receiver, or to prevent a malicious sender from 3480 consuming significant resources at a receiver. This section 3481 describes QUIC's flow-control mechanisms. 3483 QUIC employs a credit-based flow-control scheme similar to HTTP/2's 3484 flow control [HTTP2]. A receiver advertises the number of octets it 3485 is prepared to receive on a given stream and for the entire 3486 connection. This leads to two levels of flow control in QUIC: (i) 3487 Connection flow control, which prevents senders from exceeding a 3488 receiver's buffer capacity for the connection, and (ii) Stream flow 3489 control, which prevents a single stream from consuming the entire 3490 receive buffer for a connection. 3492 A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the 3493 sender to advertise additional credit. MAX_STREAM_DATA frames send 3494 the the maximum absolute byte offset of a stream, while MAX_DATA 3495 sends the maximum sum of the absolute byte offsets of all streams 3496 other than stream 0. 3498 A receiver MAY advertise a larger offset at any point by sending 3499 MAX_DATA or MAX_STREAM_DATA frames. A receiver MUST NOT renege on an 3500 advertisement; that is, once a receiver advertises an offset, it MUST 3501 NOT subsequently advertise a smaller offset. A sender could receive 3502 MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST 3503 therefore ignore any flow control offset that does not move the 3504 window forward. 3506 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 3507 (Section 12) if the peer violates the advertised connection or stream 3508 data limits. 3510 A sender SHOULD send BLOCKED or STREAM_BLOCKED frames to indicate it 3511 has data to write but is blocked by flow control limits. These 3512 frames are expected to be sent infrequently in common cases, but they 3513 are considered useful for debugging and monitoring purposes. 3515 A receiver advertises credit for a stream by sending a 3516 MAX_STREAM_DATA frame with the Stream ID set appropriately. A 3517 receiver could use the current offset of data consumed to determine 3518 the flow control offset to be advertised. A receiver MAY send 3519 MAX_STREAM_DATA frames in multiple packets in order to make sure that 3520 the sender receives an update before running out of flow control 3521 credit, even if one of the packets is lost. 3523 Connection flow control is a limit to the total bytes of stream data 3524 sent in STREAM frames on all streams. A receiver advertises credit 3525 for a connection by sending a MAX_DATA frame. A receiver maintains a 3526 cumulative sum of bytes received on all streams, which are used to 3527 check for flow control violations. A receiver might use a sum of 3528 bytes consumed on all contributing streams to determine the maximum 3529 data limit to be advertised. 3531 11.1. Edge Cases and Other Considerations 3533 There are some edge cases which must be considered when dealing with 3534 stream and connection level flow control. Given enough time, both 3535 endpoints must agree on flow control state. If one end believes it 3536 can send more than the other end is willing to receive, the 3537 connection will be torn down when too much data arrives. 3539 Conversely if a sender believes it is blocked, while endpoint B 3540 expects more data can be received, then the connection can be in a 3541 deadlock, with the sender waiting for a MAX_DATA or MAX_STREAM_DATA 3542 frame which will never come. 3544 On receipt of a RST_STREAM frame, an endpoint will tear down state 3545 for the matching stream and ignore further data arriving on that 3546 stream. This could result in the endpoints getting out of sync, 3547 since the RST_STREAM frame may have arrived out of order and there 3548 may be further bytes in flight. The data sender would have counted 3549 the data against its connection level flow control budget, but a 3550 receiver that has not received these bytes would not know to include 3551 them as well. The receiver must learn the number of bytes that were 3552 sent on the stream to make the same adjustment in its connection flow 3553 controller. 3555 To avoid this de-synchronization, a RST_STREAM sender MUST include 3556 the final byte offset sent on the stream in the RST_STREAM frame. On 3557 receiving a RST_STREAM frame, a receiver definitively knows how many 3558 bytes were sent on that stream before the RST_STREAM frame, and the 3559 receiver MUST use the final offset to account for all bytes sent on 3560 the stream in its connection level flow controller. 3562 11.1.1. Response to a RST_STREAM 3564 RST_STREAM terminates one direction of a stream abruptly. Whether 3565 any action or response can or should be taken on the data already 3566 received is an application-specific issue, but it will often be the 3567 case that upon receipt of a RST_STREAM an endpoint will choose to 3568 stop sending data in its own direction. If the sender of a 3569 RST_STREAM wishes to explicitly state that no future data will be 3570 processed, that endpoint MAY send a STOP_SENDING frame at the same 3571 time. 3573 11.1.2. Data Limit Increments 3575 This document leaves when and how many bytes to advertise in a 3576 MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few 3577 considerations. These frames contribute to connection overhead. 3578 Therefore frequently sending frames with small changes is 3579 undesirable. At the same time, infrequent updates require larger 3580 increments to limits if blocking is to be avoided. Thus, larger 3581 updates require a receiver to commit to larger resource commitments. 3582 Thus there is a tradeoff between resource commitment and overhead 3583 when determining how large a limit is advertised. 3585 A receiver MAY use an autotuning mechanism to tune the frequency and 3586 amount that it increases data limits based on a roundtrip time 3587 estimate and the rate at which the receiving application consumes 3588 data, similar to common TCP implementations. 3590 11.2. Stream Limit Increment 3592 As with flow control, this document leaves when and how many streams 3593 to make available to a peer via MAX_STREAM_ID to implementations, but 3594 offers a few considerations. MAX_STREAM_ID frames constitute minimal 3595 overhead, while withholding MAX_STREAM_ID frames can prevent the peer 3596 from using the available parallelism. 3598 Implementations will likely want to increase the maximum stream ID as 3599 peer-initiated streams close. A receiver MAY also advance the 3600 maximum stream ID based on current activity, system conditions, and 3601 other environmental factors. 3603 11.2.1. Blocking on Flow Control 3605 If a sender does not receive a MAX_DATA or MAX_STREAM_DATA frame when 3606 it has run out of flow control credit, the sender will be blocked and 3607 SHOULD send a BLOCKED or STREAM_BLOCKED frame. These frames are 3608 expected to be useful for debugging at the receiver; they do not 3609 require any other action. A receiver SHOULD NOT wait for a BLOCKED 3610 or STREAM_BLOCKED frame before sending MAX_DATA or MAX_STREAM_DATA, 3611 since doing so will mean that a sender is unable to send for an 3612 entire round trip. 3614 For smooth operation of the congestion controller, it is generally 3615 considered best to not let the sender go into quiescence if 3616 avoidable. To avoid blocking a sender, and to reasonably account for 3617 the possibiity of loss, a receiver should send a MAX_DATA or 3618 MAX_STREAM_DATA frame at least two roundtrips before it expects the 3619 sender to get blocked. 3621 A sender sends a single BLOCKED or STREAM_BLOCKED frame only once 3622 when it reaches a data limit. A sender SHOULD NOT send multiple 3623 BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the 3624 original frame is determined to be lost. Another BLOCKED or 3625 STREAM_BLOCKED frame can be sent after the data limit is increased. 3627 11.3. Stream Final Offset 3629 The final offset is the count of the number of octets that are 3630 transmitted on a stream. For a stream that is reset, the final 3631 offset is carried explicitly in a RST_STREAM frame. Otherwise, the 3632 final offset is the offset of the end of the data carried in a STREAM 3633 frame marked with a FIN flag, or 0 in the case of incoming 3634 unidirectional streams. 3636 An endpoint will know the final offset for a stream when the receive 3637 stream enters the "Size Known" or "Reset Recvd" state. 3639 An endpoint MUST NOT send data on a stream at or beyond the final 3640 offset. 3642 Once a final offset for a stream is known, it cannot change. If a 3643 RST_STREAM or STREAM frame causes the final offset to change for a 3644 stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error 3645 (see Section 12). A receiver SHOULD treat receipt of data at or 3646 beyond the final offset as a FINAL_OFFSET_ERROR error, even after a 3647 stream is closed. Generating these errors is not mandatory, but only 3648 because requiring that an endpoint generate these errors also means 3649 that the endpoint needs to maintain the final offset state for closed 3650 streams, which could mean a significant state commitment. 3652 12. Error Handling 3654 An endpoint that detects an error SHOULD signal the existence of that 3655 error to its peer. Errors can affect an entire connection (see 3656 Section 12.1), or a single stream (see Section 12.2). 3658 The most appropriate error code (Section 12.3) SHOULD be included in 3659 the frame that signals the error. Where this specification 3660 identifies error conditions, it also identifies the error code that 3661 is used. 3663 A stateless reset (Section 7.9.4) is not suitable for any error that 3664 can be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or 3665 RST_STREAM frame. A stateless reset MUST NOT be used by an endpoint 3666 that has the state necessary to send a frame on the connection. 3668 12.1. Connection Errors 3670 Errors that result in the connection being unusable, such as an 3671 obvious violation of protocol semantics or corruption of state that 3672 affects an entire connection, MUST be signaled using a 3673 CONNECTION_CLOSE or APPLICATION_CLOSE frame (Section 8.4, 3674 Section 8.5). An endpoint MAY close the connection in this manner 3675 even if the error only affects a single stream. 3677 Application protocols can signal application-specific protocol errors 3678 using the APPLICATION_CLOSE frame. Errors that are specific to the 3679 transport, including all those described in this document, are 3680 carried in a CONNECTION_CLOSE frame. Other than the type of error 3681 code they carry, these frames are identical in format and semantics. 3683 A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a 3684 packet that is lost. An endpoint SHOULD be prepared to retransmit a 3685 packet containing either frame type if it receives more packets on a 3686 terminated connection. Limiting the number of retransmissions and 3687 the time over which this final packet is sent limits the effort 3688 expended on terminated connections. 3690 An endpoint that chooses not to retransmit packets containing 3691 CONNECTION_CLOSE or APPLICATION_CLOSE risks a peer missing the first 3692 such packet. The only mechanism available to an endpoint that 3693 continues to receive data for a terminated connection is to use the 3694 stateless reset process (Section 7.9.4). 3696 An endpoint that receives an invalid CONNECTION_CLOSE or 3697 APPLICATION_CLOSE frame MUST NOT signal the existence of the error to 3698 its peer. 3700 12.2. Stream Errors 3702 If the error affects a single stream, but otherwise leaves the 3703 connection in a recoverable state, the endpoint can send a RST_STREAM 3704 frame (Section 8.3) with an appropriate error code to terminate just 3705 the affected stream. 3707 Stream 0 is critical to the functioning of the entire connection. If 3708 stream 0 is closed with either a RST_STREAM or STREAM frame bearing 3709 the FIN flag, an endpoint MUST generate a connection error of type 3710 PROTOCOL_VIOLATION. 3712 RST_STREAM MUST be instigated by the application and MUST carry an 3713 application error code. Resetting a stream without knowledge of the 3714 application protocol could cause the protocol to enter an 3715 unrecoverable state. Application protocols might require certain 3716 streams to be reliably delivered in order to guarantee consistent 3717 state between endpoints. 3719 12.3. Transport Error Codes 3721 QUIC error codes are 16-bit unsigned integers. 3723 This section lists the defined QUIC transport error codes that may be 3724 used in a CONNECTION_CLOSE frame. These errors apply to the entire 3725 connection. 3727 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 3728 signal that the connection is being closed abruptly in the absence 3729 of any error. 3731 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 3732 cannot continue with the connection. 3734 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 3735 permitted in its advertised data limits (see Section 11). 3737 STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream 3738 identifier that exceeded its advertised maximum stream ID. 3740 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 3741 that was not in a state that permitted that frame (see 3742 Section 10.2). 3744 FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame 3745 containing data that exceeded the previously established final 3746 offset. Or an endpoint received a RST_STREAM frame containing a 3747 final offset that was lower than the maximum offset of data that 3748 was already received. Or an endpoint received a RST_STREAM frame 3749 containing a different final offset to the one already 3750 established. 3752 FRAME_FORMAT_ERROR (0x7): An endpoint received a frame that was 3753 badly formatted. For instance, an empty STREAM frame that omitted 3754 the FIN flag, or an ACK frame that has more acknowledgment ranges 3755 than the remainder of the packet could carry. This is a generic 3756 error code; an endpoint SHOULD use the more specific frame format 3757 error codes (0x1XX) if possible. 3759 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 3760 parameters that were badly formatted, included an invalid value, 3761 was absent even though it is mandatory, was present though it is 3762 forbidden, or is otherwise in error. 3764 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 3765 parameters that contained version negotiation parameters that 3766 disagreed with the version negotiation that it performed. This 3767 error code indicates a potential version downgrade attack. 3769 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 3770 protocol compliance that was not covered by more specific error 3771 codes. 3773 UNSOLICITED_PONG (0xB): An endpoint received a PONG frame that did 3774 not correspond to any PING frame that it previously sent. 3776 FRAME_ERROR (0x1XX): An endpoint detected an error in a specific 3777 frame type. The frame type is included as the last octet of the 3778 error code. For example, an error in a MAX_STREAM_ID frame would 3779 be indicated with the code (0x106). 3781 See Section 14.2 for details of registering new error codes. 3783 12.4. Application Protocol Error Codes 3785 Application protocol error codes are 16-bit unsigned integers, but 3786 the management of application error codes are left to application 3787 protocols. Application protocol error codes are used for the 3788 RST_STREAM (Section 8.3) and APPLICATION_CLOSE (Section 8.5) frames. 3790 There is no restriction on the use of the 16-bit error code space for 3791 application protocols. However, QUIC reserves the error code with a 3792 value of 0 to mean STOPPING. The application error code of STOPPING 3793 (0) is used by the transport to cancel a stream in response to 3794 receipt of a STOP_SENDING frame. 3796 13. Security and Privacy Considerations 3798 13.1. Spoofed ACK Attack 3800 An attacker might be able to receive an address validation token 3801 (Section 7.6) from the server and then release the IP address it used 3802 to acquire that token. The attacker may, in the future, spoof this 3803 same address (which now presumably addresses a different endpoint), 3804 and initiate a 0-RTT connection with a server on the victim's behalf. 3805 The attacker can then spoof ACK frames to the server which cause the 3806 server to send excessive amounts of data toward the new owner of the 3807 IP address. 3809 There are two possible mitigations to this attack. The simplest one 3810 is that a server can unilaterally create a gap in packet-number 3811 space. In the non-attack scenario, the client will send an ACK frame 3812 with the larger value for largest acknowledged. In the attack 3813 scenario, the attacker could acknowledge a packet in the gap. If the 3814 server sees an acknowledgment for a packet that was never sent, the 3815 connection can be aborted. 3817 The second mitigation is that the server can require that 3818 acknowledgments for sent packets match the encryption level of the 3819 sent packet. This mitigation is useful if the connection has an 3820 ephemeral forward-secure key that is generated and used for every new 3821 connection. If a packet sent is protected with a forward-secure key, 3822 then any acknowledgments that are received for them MUST also be 3823 forward-secure protected. Since the attacker will not have the 3824 forward secure key, the attacker will not be able to generate 3825 forward-secure protected packets with ACK frames. 3827 13.2. Slowloris Attacks 3829 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 3830 connections to the target endpoint open and hold them open as long as 3831 possible. These attacks can be executed against a QUIC endpoint by 3832 generating the minimum amount of activity necessary to avoid being 3833 closed for inactivity. This might involve sending small amounts of 3834 data, gradually opening flow control windows in order to control the 3835 sender rate, or manufacturing ACK frames that simulate a high loss 3836 rate. 3838 QUIC deployments SHOULD provide mitigations for the Slowloris 3839 attacks, such as increasing the maximum number of clients the server 3840 will allow, limiting the number of connections a single IP address is 3841 allowed to make, imposing restrictions on the minimum transfer speed 3842 a connection is allowed to have, and restricting the length of time 3843 an endpoint is allowed to stay connected. 3845 13.3. Stream Fragmentation and Reassembly Attacks 3847 An adversarial endpoint might intentionally fragment the data on 3848 stream buffers in order to cause disproportionate memory commitment. 3849 An adversarial endpoint could open a stream and send some STREAM 3850 frames containing arbitrary fragments of the stream content. 3852 The attack is mitigated if flow control windows correspond to 3853 available memory. However, some receivers will over-commit memory 3854 and advertise flow control offsets in the aggregate that exceed 3855 actual available memory. The over-commitment strategy can lead to 3856 better performance when endpoints are well behaved, but renders 3857 endpoints vulnerable to the stream fragmentation attack. 3859 QUIC deployments SHOULD provide mitigations against the stream 3860 fragmentation attack. Mitigations could consist of avoiding over- 3861 committing memory, delaying reassembly of STREAM frames, implementing 3862 heuristics based on the age and duration of reassembly holes, or some 3863 combination. 3865 13.4. Stream Commitment Attack 3867 An adversarial endpoint can open lots of streams, exhausting state on 3868 an endpoint. The adversarial endpoint could repeat the process on a 3869 large number of connections, in a manner similar to SYN flooding 3870 attacks in TCP. 3872 Normally, clients will open streams sequentially, as explained in 3873 Section 10.1. However, when several streams are initiated at short 3874 intervals, transmission error may cause STREAM DATA frames opening 3875 streams to be received out of sequence. A receiver is obligated to 3876 open intervening streams if a higher-numbered stream ID is received. 3877 Thus, on a new connection, opening stream 2000001 opens 1 million 3878 streams, as required by the specification. 3880 The number of active streams is limited by the concurrent stream 3881 limit transport parameter, as explained in Section 10.4. If chosen 3882 judisciously, this limit mitigates the effect of the stream 3883 commitment attack. However, setting the limit too low could affect 3884 performance when applications expect to open large number of streams. 3886 14. IANA Considerations 3888 14.1. QUIC Transport Parameter Registry 3890 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 3891 under a "QUIC Protocol" heading. 3893 The "QUIC Transport Parameters" registry governs a 16-bit space. 3894 This space is split into two spaces that are governed by different 3895 policies. Values with the first byte in the range 0x00 to 0xfe (in 3896 hexadecimal) are assigned via the Specification Required policy 3897 [RFC8126]. Values with the first byte 0xff are reserved for Private 3898 Use [RFC8126]. 3900 Registrations MUST include the following fields: 3902 Value: The numeric value of the assignment (registrations will be 3903 between 0x0000 and 0xfeff). 3905 Parameter Name: A short mnemonic for the parameter. 3907 Specification: A reference to a publicly available specification for 3908 the value. 3910 The nominated expert(s) verify that a specification exists and is 3911 readily accessible. The expert(s) are encouraged to be biased 3912 towards approving registrations unless they are abusive, frivolous, 3913 or actively harmful (not merely aesthetically displeasing, or 3914 architecturally dubious). 3916 The initial contents of this registry are shown in Table 7. 3918 +--------+----------------------------+---------------+ 3919 | Value | Parameter Name | Specification | 3920 +--------+----------------------------+---------------+ 3921 | 0x0000 | initial_max_stream_data | Section 7.4.1 | 3922 | | | | 3923 | 0x0001 | initial_max_data | Section 7.4.1 | 3924 | | | | 3925 | 0x0002 | initial_max_stream_id_bidi | Section 7.4.1 | 3926 | | | | 3927 | 0x0003 | idle_timeout | Section 7.4.1 | 3928 | | | | 3929 | 0x0004 | omit_connection_id | Section 7.4.1 | 3930 | | | | 3931 | 0x0005 | max_packet_size | Section 7.4.1 | 3932 | | | | 3933 | 0x0006 | stateless_reset_token | Section 7.4.1 | 3934 | | | | 3935 | 0x0007 | ack_delay_exponent | Section 7.4.1 | 3936 | | | | 3937 | 0x0008 | initial_max_stream_id_uni | Section 7.4.1 | 3938 +--------+----------------------------+---------------+ 3940 Table 7: Initial QUIC Transport Parameters Entries 3942 14.2. QUIC Transport Error Codes Registry 3944 IANA [SHALL add/has added] a registry for "QUIC Transport Error 3945 Codes" under a "QUIC Protocol" heading. 3947 The "QUIC Transport Error Codes" registry governs a 16-bit space. 3948 This space is split into two spaces that are governed by different 3949 policies. Values with the first byte in the range 0x00 to 0xfe (in 3950 hexadecimal) are assigned via the Specification Required policy 3951 [RFC8126]. Values with the first byte 0xff are reserved for Private 3952 Use [RFC8126]. 3954 Registrations MUST include the following fields: 3956 Value: The numeric value of the assignment (registrations will be 3957 between 0x0000 and 0xfeff). 3959 Code: A short mnemonic for the parameter. 3961 Description: A brief description of the error code semantics, which 3962 MAY be a summary if a specification reference is provided. 3964 Specification: A reference to a publicly available specification for 3965 the value. 3967 The initial contents of this registry are shown in Table 8. Note 3968 that FRAME_ERROR takes the range from 0x100 to 0x1FF and private use 3969 occupies the range from 0xFE00 to 0xFFFF. 3971 +-----------+------------------------+---------------+--------------+ 3972 | Value | Error | Description | Specificatio | 3973 | | | | n | 3974 +-----------+------------------------+---------------+--------------+ 3975 | 0x0 | NO_ERROR | No error | Section 12.3 | 3976 | | | | | 3977 | 0x1 | INTERNAL_ERROR | Implementatio | Section 12.3 | 3978 | | | n error | | 3979 | | | | | 3980 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 12.3 | 3981 | | | error | | 3982 | | | | | 3983 | 0x4 | STREAM_ID_ERROR | Invalid | Section 12.3 | 3984 | | | stream ID | | 3985 | | | | | 3986 | 0x5 | STREAM_STATE_ERROR | Frame | Section 12.3 | 3987 | | | received in | | 3988 | | | invalid | | 3989 | | | stream state | | 3990 | | | | | 3991 | 0x6 | FINAL_OFFSET_ERROR | Change to | Section 12.3 | 3992 | | | final stream | | 3993 | | | offset | | 3994 | | | | | 3995 | 0x7 | FRAME_FORMAT_ERROR | Generic frame | Section 12.3 | 3996 | | | format error | | 3997 | | | | | 3998 | 0x8 | TRANSPORT_PARAMETER_ER | Error in | Section 12.3 | 3999 | | ROR | transport | | 4000 | | | parameters | | 4001 | | | | | 4002 | 0x9 | VERSION_NEGOTIATION_ER | Version | Section 12.3 | 4003 | | ROR | negotiation | | 4004 | | | failure | | 4005 | | | | | 4006 | 0xA | PROTOCOL_VIOLATION | Generic | Section 12.3 | 4007 | | | protocol | | 4008 | | | violation | | 4009 | | | | | 4010 | 0xB | UNSOLICITED_PONG | Unsolicited | Section 12.3 | 4011 | | | PONG frame | | 4012 | | | | | 4013 | 0x100-0x1 | FRAME_ERROR | Specific | Section 12.3 | 4014 | FF | | frame format | | 4015 | | | error | | 4016 +-----------+------------------------+---------------+--------------+ 4018 Table 8: Initial QUIC Transport Error Codes Entries 4020 15. References 4022 15.1. Normative References 4024 [I-D.ietf-tls-tls13] 4025 Rescorla, E., "The Transport Layer Security (TLS) Protocol 4026 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 4027 January 2018. 4029 [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 4030 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 4031 . 4033 [PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4034 DOI 10.17487/RFC1191, November 1990, 4035 . 4037 [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 4038 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 4039 DOI 10.17487/RFC8201, July 2017, 4040 . 4042 [QUIC-RECOVERY] 4043 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 4044 and Congestion Control", draft-ietf-quic-recovery-09 (work 4045 in progress), January 2018. 4047 [QUIC-TLS] 4048 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 4049 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 4050 tls-09 (work in progress), January 2018. 4052 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4053 DOI 10.17487/RFC1191, November 1990, 4054 . 4056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4057 Requirement Levels", BCP 14, RFC 2119, 4058 DOI 10.17487/RFC2119, March 1997, 4059 . 4061 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 4062 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 4063 2003, . 4065 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 4066 "Randomness Requirements for Security", BCP 106, RFC 4086, 4067 DOI 10.17487/RFC4086, June 2005, 4068 . 4070 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 4071 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 4072 . 4074 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4075 Writing an IANA Considerations Section in RFCs", BCP 26, 4076 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4077 . 4079 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4080 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4081 May 2017, . 4083 15.2. Informative References 4085 [EARLY-DESIGN] 4086 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 4087 December 2013, . 4089 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 4090 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 4091 DOI 10.17487/RFC7540, May 2015, 4092 . 4094 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4095 Hashing for Message Authentication", RFC 2104, 4096 DOI 10.17487/RFC2104, February 1997, 4097 . 4099 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 4100 RFC 2360, DOI 10.17487/RFC2360, June 1998, 4101 . 4103 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 4104 Translation (NAT) Behavioral Requirements for Unicast 4105 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 4106 2007, . 4108 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 4109 Key Derivation Function (HKDF)", RFC 5869, 4110 DOI 10.17487/RFC5869, May 2010, 4111 . 4113 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 4114 "TCP Extensions for Multipath Operation with Multiple 4115 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 4116 . 4118 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 4119 "Transport Layer Security (TLS) Application-Layer Protocol 4120 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 4121 July 2014, . 4123 [SLOWLORIS] 4124 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 4125 . 4128 [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer 4129 Communication Review Vol. 37, pp. 361, 4130 DOI 10.1145/1282427.1282421, October 2007. 4132 15.3. URIs 4134 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 4136 [2] https://github.com/quicwg 4138 [3] https://github.com/quicwg/base-drafts/labels/-transport 4140 [4] https://github.com/quicwg/base-drafts/wiki/QUIC-Versions 4142 Appendix A. Contributors 4144 The original authors of this specification were Ryan Hamilton, Jana 4145 Iyengar, Ian Swett, and Alyssa Wilk. 4147 The original design and rationale behind this protocol draw 4148 significantly from work by Jim Roskind [EARLY-DESIGN]. In 4149 alphabetical order, the contributors to the pre-IETF QUIC project at 4150 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 4151 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 4152 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 4153 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 4154 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 4156 Appendix B. Acknowledgments 4158 Special thanks are due to the following for helping shape pre-IETF 4159 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 4160 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 4162 This document has benefited immensely from various private 4163 discussions and public ones on the quic@ietf.org and proto- 4164 quic@chromium.org mailing lists. Our thanks to all. 4166 Appendix C. Change Log 4168 *RFC Editor's Note:* Please remove this section prior to 4169 publication of a final version of this document. 4171 Issue and pull request numbers are listed with a leading octothorp. 4173 C.1. Since draft-ietf-quic-transport-08 4175 o Clarified requirements for BLOCKED usage (#65, #924) 4177 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 4178 #928) 4180 o Cleartext integrity as version independent (#568) 4182 o GAP limitation in ACK Frame (#613) 4184 o Improved PMTUD description (#614, #1036) 4186 o Clarified stream state machine (#634, #662, #894) 4188 o Reserved versions don't need to be generated deterministically 4189 (#831, #931) 4191 o You don't always need the draining period (#871) 4193 o Stateless reset clarified as version-specific (#930, #986) 4195 o initial_max_stream_id_x transport parameters are optional (#970, 4196 #971) 4198 o Ack Delay assumes a default value during the handshake (#1007, 4199 #1009) 4201 o Removed transport parameters from NewSessionTicket (#1015) 4203 C.2. Since draft-ietf-quic-transport-07 4205 o The long header now has version before packet number (#926, #939) 4207 o Rename and consolidate packet types (#846, #822, #847) 4208 o Packet types are assigned new codepoints and the Connection ID 4209 Flag is inverted (#426, #956) 4211 o Removed type for Version Negotiation and use Version 0 (#963, 4212 #968) 4214 o Streams are split into unidirectional and bidirectional (#643, 4215 #656, #720, #872, #175, #885) 4217 * Stream limits now have separate uni- and bi-directinal 4218 transport parameters (#909, #958) 4220 * Stream limit transport parameters are now optional and default 4221 to 0 (#970, #971) 4223 o The stream state machine has been split into read and write (#634, 4224 #894) 4226 o Employ variable-length integer encodings throughout (#595) 4228 o Improvements to connection close 4230 * Added distinct closing and draining states (#899, #871) 4232 * Draining period can terminate early (#869, #870) 4234 * Clarifications about stateless reset (#889, #890) 4236 o Address validation for connection migration (#161, #732, #878) 4238 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 4240 o negotiated_version is sent in server transport parameters (#710, 4241 #959) 4243 o Increased the range over which packet numbers are randomized 4244 (#864, #850, #964) 4246 C.3. Since draft-ietf-quic-transport-06 4248 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 4250 o Split error code space between application and transport (#485) 4252 o Stateless reset token moved to end (#820) 4254 o 1-RTT-protected long header types removed (#848) 4255 o No acknowledgments during draining period (#852) 4257 o Remove "application close" as a separate close type (#854) 4259 o Remove timestamps from the ACK frame (#841) 4261 o Require transport parameters to only appear once (#792) 4263 C.4. Since draft-ietf-quic-transport-05 4265 o Stateless token is server-only (#726) 4267 o Refactor section on connection termination (#733, #748, #328, 4268 #177) 4270 o Limit size of Version Negotiation packet (#585) 4272 o Clarify when and what to ack (#736) 4274 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 4276 o Clarify Keep-alive requirements (#729) 4278 C.5. Since draft-ietf-quic-transport-04 4280 o Introduce STOP_SENDING frame, RST_STREAM only resets in one 4281 direction (#165) 4283 o Removed GOAWAY; application protocols are responsible for graceful 4284 shutdown (#696) 4286 o Reduced the number of error codes (#96, #177, #184, #211) 4288 o Version validation fields can't move or change (#121) 4290 o Removed versions from the transport parameters in a 4291 NewSessionTicket message (#547) 4293 o Clarify the meaning of "bytes in flight" (#550) 4295 o Public reset is now stateless reset and not visible to the path 4296 (#215) 4298 o Reordered bits and fields in STREAM frame (#620) 4300 o Clarifications to the stream state machine (#572, #571) 4301 o Increased the maximum length of the Largest Acknowledged field in 4302 ACK frames to 64 bits (#629) 4304 o truncate_connection_id is renamed to omit_connection_id (#659) 4306 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 4307 #328) 4309 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 4311 C.6. Since draft-ietf-quic-transport-03 4313 o Change STREAM and RST_STREAM layout 4315 o Add MAX_STREAM_ID settings 4317 C.7. Since draft-ietf-quic-transport-02 4319 o The size of the initial packet payload has a fixed minimum (#267, 4320 #472) 4322 o Define when Version Negotiation packets are ignored (#284, #294, 4323 #241, #143, #474) 4325 o The 64-bit FNV-1a algorithm is used for integrity protection of 4326 unprotected packets (#167, #480, #481, #517) 4328 o Rework initial packet types to change how the connection ID is 4329 chosen (#482, #442, #493) 4331 o No timestamps are forbidden in unprotected packets (#542, #429) 4333 o Cryptographic handshake is now on stream 0 (#456) 4335 o Remove congestion control exemption for cryptographic handshake 4336 (#248, #476) 4338 o Version 1 of QUIC uses TLS; a new version is needed to use a 4339 different handshake protocol (#516) 4341 o STREAM frames have a reduced number of offset lengths (#543, #430) 4343 o Split some frames into separate connection- and stream- level 4344 frames (#443) 4346 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 4348 * BLOCKED split to match WINDOW_UPDATE split (#454) 4349 * Define STREAM_ID_NEEDED frame (#455) 4351 o A NEW_CONNECTION_ID frame supports connection migration without 4352 linkability (#232, #491, #496) 4354 o Transport parameters for 0-RTT are retained from a previous 4355 connection (#405, #513, #512) 4357 * A client in 0-RTT no longer required to reset excess streams 4358 (#425, #479) 4360 o Expanded security considerations (#440, #444, #445, #448) 4362 C.8. Since draft-ietf-quic-transport-01 4364 o Defined short and long packet headers (#40, #148, #361) 4366 o Defined a versioning scheme and stable fields (#51, #361) 4368 o Define reserved version values for "greasing" negotiation (#112, 4369 #278) 4371 o The initial packet number is randomized (#35, #283) 4373 o Narrow the packet number encoding range requirement (#67, #286, 4374 #299, #323, #356) 4376 o Defined client address validation (#52, #118, #120, #275) 4378 o Define transport parameters as a TLS extension (#49, #122) 4380 o SCUP and COPT parameters are no longer valid (#116, #117) 4382 o Transport parameters for 0-RTT are either remembered from before, 4383 or assume default values (#126) 4385 o The server chooses connection IDs in its final flight (#119, #349, 4386 #361) 4388 o The server echoes the Connection ID and packet number fields when 4389 sending a Version Negotiation packet (#133, #295, #244) 4391 o Defined a minimum packet size for the initial handshake packet 4392 from the client (#69, #136, #139, #164) 4394 o Path MTU Discovery (#64, #106) 4395 o The initial handshake packet from the client needs to fit in a 4396 single packet (#338) 4398 o Forbid acknowledgment of packets containing only ACK and PADDING 4399 (#291) 4401 o Require that frames are processed when packets are acknowledged 4402 (#381, #341) 4404 o Removed the STOP_WAITING frame (#66) 4406 o Don't require retransmission of old timestamps for lost ACK frames 4407 (#308) 4409 o Clarified that frames are not retransmitted, but the information 4410 in them can be (#157, #298) 4412 o Error handling definitions (#335) 4414 o Split error codes into four sections (#74) 4416 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 4417 (#289) 4419 o Define packet protection rules (#336) 4421 o Require that stream be entirely delivered or reset, including 4422 acknowledgment of all STREAM frames or the RST_STREAM, before it 4423 closes (#381) 4425 o Remove stream reservation from state machine (#174, #280) 4427 o Only stream 1 does not contribute to connection-level flow control 4428 (#204) 4430 o Stream 1 counts towards the maximum concurrent stream limit (#201, 4431 #282) 4433 o Remove connection-level flow control exclusion for some streams 4434 (except 1) (#246) 4436 o RST_STREAM affects connection-level flow control (#162, #163) 4438 o Flow control accounting uses the maximum data offset on each 4439 stream, rather than bytes received (#378) 4441 o Moved length-determining fields to the start of STREAM and ACK 4442 (#168, #277) 4444 o Added the ability to pad between frames (#158, #276) 4446 o Remove error code and reason phrase from GOAWAY (#352, #355) 4448 o GOAWAY includes a final stream number for both directions (#347) 4450 o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a 4451 consistent offset (#249) 4453 o Defined priority as the responsibility of the application protocol 4454 (#104, #303) 4456 C.9. Since draft-ietf-quic-transport-00 4458 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 4460 o Defined versioning 4462 o Reworked description of packet and frame layout 4464 o Error code space is divided into regions for each component 4466 o Use big endian for all numeric values 4468 C.10. Since draft-hamilton-quic-transport-protocol-01 4470 o Adopted as base for draft-ietf-quic-tls 4472 o Updated authors/editors list 4474 o Added IANA Considerations section 4476 o Moved Contributors and Acknowledgments to appendices 4478 Authors' Addresses 4480 Jana Iyengar (editor) 4481 Google 4483 Email: jri@google.com 4485 Martin Thomson (editor) 4486 Mozilla 4488 Email: martin.thomson@gmail.com