idnits 2.17.1 draft-ietf-quic-transport-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2018) is 2127 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: '0' on line 1529 == Missing Reference: 'CH' is mentioned on line 1516, but not defined == Missing Reference: 'SH' is mentioned on line 1519, but not defined == Missing Reference: 'EE' is mentioned on line 1520, but not defined == Missing Reference: 'CERT' is mentioned on line 1520, but not defined == Missing Reference: 'CV' is mentioned on line 1520, but not defined == Missing Reference: 'FIN' is mentioned on line 1525, but not defined -- Looks like a reference, but probably isn't: '1' on line 1529 == Missing Reference: 'EOED' is mentioned on line 1524, but not defined -- Looks like a reference, but probably isn't: '2' on line 1528 -- Looks like a reference, but probably isn't: '16' on line 1583 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-13 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-13 -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-01 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Iyengar, Ed. 3 Internet-Draft Fastly 4 Intended status: Standards Track M. Thomson, Ed. 5 Expires: December 30, 2018 Mozilla 6 June 28, 2018 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-13 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 . 24 Working Group information can be found at ; source code and issues list for this draft can be found at 26 . 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 December 30, 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 . . . . . . . . . . . . . . . . . 6 64 2.1. Notational Conventions . . . . . . . . . . . . . . . . . 7 65 3. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Packet Types and Formats . . . . . . . . . . . . . . . . . . 8 67 4.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 11 69 4.3. Version Negotiation Packet . . . . . . . . . . . . . . . 12 70 4.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 14 71 4.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 14 72 4.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 17 73 4.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 18 74 4.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 18 75 4.6. Coalescing Packets . . . . . . . . . . . . . . . . . . . 19 76 4.7. Connection ID Encoding . . . . . . . . . . . . . . . . . 20 77 4.8. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 21 78 5. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 23 79 5.1. Extension Frames . . . . . . . . . . . . . . . . . . . . 26 80 6. Life of a Connection . . . . . . . . . . . . . . . . . . . . 26 81 6.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 27 82 6.2. Matching Packets to Connections . . . . . . . . . . . . . 28 83 6.2.1. Client Packet Handling . . . . . . . . . . . . . . . 28 84 6.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29 85 6.3. Version Negotiation . . . . . . . . . . . . . . . . . . . 29 86 6.3.1. Sending Version Negotiation Packets . . . . . . . . . 30 87 6.3.2. Handling Version Negotiation Packets . . . . . . . . 30 88 6.3.3. Using Reserved Versions . . . . . . . . . . . . . . . 31 89 6.4. Cryptographic and Transport Handshake . . . . . . . . . . 31 90 6.5. Example Handshake Flows . . . . . . . . . . . . . . . . . 32 91 6.6. Transport Parameters . . . . . . . . . . . . . . . . . . 34 92 6.6.1. Transport Parameter Definitions . . . . . . . . . . . 36 93 6.6.2. Values of Transport Parameters for 0-RTT . . . . . . 38 94 6.6.3. New Transport Parameters . . . . . . . . . . . . . . 38 95 6.6.4. Version Negotiation Validation . . . . . . . . . . . 39 96 6.7. Stateless Retries . . . . . . . . . . . . . . . . . . . . 40 97 6.8. Using Explicit Congestion Notification . . . . . . . . . 40 98 6.9. Proof of Source Address Ownership . . . . . . . . . . . . 42 99 6.9.1. Client Address Validation Procedure . . . . . . . . . 43 100 6.9.2. Address Validation for Future Connections . . . . . . 44 101 6.9.3. Address Validation Token Integrity . . . . . . . . . 44 102 6.10. Path Validation . . . . . . . . . . . . . . . . . . . . . 44 103 6.10.1. Initiation . . . . . . . . . . . . . . . . . . . . . 45 104 6.10.2. Response . . . . . . . . . . . . . . . . . . . . . . 45 105 6.10.3. Completion . . . . . . . . . . . . . . . . . . . . . 46 106 6.10.4. Abandonment . . . . . . . . . . . . . . . . . . . . 46 107 6.11. Connection Migration . . . . . . . . . . . . . . . . . . 47 108 6.11.1. Probing a New Path . . . . . . . . . . . . . . . . . 47 109 6.11.2. Initiating Connection Migration . . . . . . . . . . 48 110 6.11.3. Responding to Connection Migration . . . . . . . . . 48 111 6.11.4. Loss Detection and Congestion Control . . . . . . . 50 112 6.11.5. Privacy Implications of Connection Migration . . . . 51 113 6.12. Server's Preferred Address . . . . . . . . . . . . . . . 51 114 6.12.1. Communicating A Preferred Address . . . . . . . . . 52 115 6.12.2. Responding to Connection Migration . . . . . . . . . 52 116 6.12.3. Interaction of Client Migration and Preferred 117 Address . . . . . . . . . . . . . . . . . . . . . . 52 118 6.13. Connection Termination . . . . . . . . . . . . . . . . . 53 119 6.13.1. Closing and Draining Connection States . . . . . . . 53 120 6.13.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 54 121 6.13.3. Immediate Close . . . . . . . . . . . . . . . . . . 55 122 6.13.4. Stateless Reset . . . . . . . . . . . . . . . . . . 56 123 7. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 59 124 7.1. Variable-Length Integer Encoding . . . . . . . . . . . . 59 125 7.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 60 126 7.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 60 127 7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 61 128 7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 62 129 7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 62 130 7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 62 131 7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 63 132 7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 64 133 7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 65 134 7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 65 135 7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 66 136 7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 66 137 7.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 68 138 7.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 68 139 7.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 70 140 7.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 71 141 7.15.3. ACK Frames and Packet Protection . . . . . . . . . . 72 142 7.16. ACK_ECN Frame . . . . . . . . . . . . . . . . . . . . . . 72 143 7.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 73 144 7.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 74 145 7.19. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . . 74 146 7.20. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 74 147 7.21. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 76 148 8. Packetization and Reliability . . . . . . . . . . . . . . . . 77 149 8.1. Packet Processing and Acknowledgment . . . . . . . . . . 78 150 8.2. Retransmission of Information . . . . . . . . . . . . . . 78 151 8.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 80 152 8.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 80 153 8.4.1. IPv4 PMTU Discovery . . . . . . . . . . . . . . . . . 81 154 8.4.2. Special Considerations for Packetization Layer PMTU 155 Discovery . . . . . . . . . . . . . . . . . . . . . . 82 156 9. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 82 157 9.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 83 158 9.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 84 159 9.2.1. Send Stream States . . . . . . . . . . . . . . . . . 85 160 9.2.2. Receive Stream States . . . . . . . . . . . . . . . . 86 161 9.2.3. Permitted Frame Types . . . . . . . . . . . . . . . . 89 162 9.2.4. Bidirectional Stream States . . . . . . . . . . . . . 89 163 9.3. Solicited State Transitions . . . . . . . . . . . . . . . 90 164 9.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 91 165 9.5. Sending and Receiving Data . . . . . . . . . . . . . . . 92 166 9.6. Stream Prioritization . . . . . . . . . . . . . . . . . . 92 167 10. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 93 168 10.1. Edge Cases and Other Considerations . . . . . . . . . . 94 169 10.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 95 170 10.1.2. Data Limit Increments . . . . . . . . . . . . . . . 95 171 10.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 96 172 10.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 96 173 10.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 96 174 10.4. Flow Control for Crytographic Handshake . . . . . . . . 97 175 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 97 176 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 97 177 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 98 178 11.3. Transport Error Codes . . . . . . . . . . . . . . . . . 98 179 11.4. Application Protocol Error Codes . . . . . . . . . . . . 100 180 12. Security Considerations . . . . . . . . . . . . . . . . . . . 100 181 12.1. Handshake Denial of Service . . . . . . . . . . . . . . 100 182 12.2. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 101 183 12.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 102 184 12.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 102 185 12.5. Stream Fragmentation and Reassembly Attacks . . . . . . 102 186 12.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 103 187 12.7. Explicit Congestion Notification Attacks . . . . . . . . 103 188 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 189 13.1. QUIC Transport Parameter Registry . . . . . . . . . . . 104 190 13.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 105 191 13.3. QUIC Transport Error Codes Registry . . . . . . . . . . 106 192 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 193 14.1. Normative References . . . . . . . . . . . . . . . . . . 108 194 14.2. Informative References . . . . . . . . . . . . . . . . . 109 195 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 110 196 A.1. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 110 197 A.2. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 111 198 A.3. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 111 199 A.4. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 112 200 A.5. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 113 201 A.6. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 113 202 A.7. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 114 203 A.8. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 115 204 A.9. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 115 205 A.10. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 116 206 A.11. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 116 207 A.12. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 117 208 A.13. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 119 209 A.14. Since draft-hamilton-quic-transport-protocol-01 . . . . . 119 210 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 119 211 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 119 212 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 214 1. Introduction 216 QUIC is a multiplexed and secure transport protocol that runs on top 217 of UDP. QUIC aims to provide a flexible set of features that allow 218 it to be a general-purpose secure transport for multiple 219 applications. 221 o Version negotiation 223 o Low-latency connection establishment 225 o Authenticated and encrypted header and payload 227 o Stream multiplexing 229 o Stream and connection-level flow control 231 o Connection migration and resilience to NAT rebinding 233 QUIC implements techniques learned from experience with TCP, SCTP and 234 other transport protocols. QUIC uses UDP as substrate so as to not 235 require changes to legacy client operating systems and middleboxes to 236 be deployable. QUIC authenticates all of its headers and encrypts 237 most of the data it exchanges, including its signaling. This allows 238 the protocol to evolve without incurring a dependency on upgrades to 239 middleboxes. This document describes the core QUIC protocol, 240 including the conceptual design, wire format, and mechanisms of the 241 QUIC protocol for connection establishment, stream multiplexing, 242 stream and connection-level flow control, connection migration, and 243 data reliability. 245 Accompanying documents describe QUIC's loss detection and congestion 246 control [QUIC-RECOVERY], and the use of TLS 1.3 for key negotiation 247 [QUIC-TLS]. 249 QUIC version 1 conforms to the protocol invariants in 250 [QUIC-INVARIANTS]. 252 2. Conventions and Definitions 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in BCP 257 14 [RFC2119] [RFC8174] when, and only when, they appear in all 258 capitals, as shown here. 260 Definitions of terms that are used in this document: 262 Client: The endpoint initiating a QUIC connection. 264 Server: The endpoint accepting incoming QUIC connections. 266 Endpoint: The client or server end of a connection. 268 Stream: A logical, bi-directional channel of ordered bytes within a 269 QUIC connection. 271 Connection: A conversation between two QUIC endpoints with a single 272 encryption context that multiplexes streams within it. 274 Connection ID: An opaque identifier that is used to identify a QUIC 275 connection at an endpoint. Each endpoint sets a value that its 276 peer includes in packets. 278 QUIC packet: A well-formed UDP payload that can be parsed by a QUIC 279 receiver. 281 QUIC is a name, not an acronym. 283 2.1. Notational Conventions 285 Packet and frame diagrams use the format described in Section 3.1 of 286 [RFC2360], with the following additional conventions: 288 [x] Indicates that x is optional 290 x (A) Indicates that x is A bits long 292 x (A/B/C) ... Indicates that x is one of A, B, or C bits long 294 x (i) ... Indicates that x uses the variable-length encoding in 295 Section 7.1 297 x (*) ... Indicates that x is variable-length 299 3. Versions 301 QUIC versions are identified using a 32-bit unsigned number. 303 The version 0x00000000 is reserved to represent version negotiation. 304 This version of the specification is identified by the number 305 0x00000001. 307 Other versions of QUIC might have different properties to this 308 version. The properties of QUIC that are guaranteed to be consistent 309 across all versions of the protocol are described in 310 [QUIC-INVARIANTS]. 312 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 313 protocol, as described in [QUIC-TLS]. 315 Versions with the most significant 16 bits of the version number 316 cleared are reserved for use in future IETF consensus documents. 318 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 319 forcing version negotiation to be exercised. That is, any version 320 number where the low four bits of all octets is 1010 (in binary). A 321 client or server MAY advertise support for any of these reserved 322 versions. 324 Reserved version numbers will probably never represent a real 325 protocol; a client MAY use one of these version numbers with the 326 expectation that the server will initiate version negotiation; a 327 server MAY advertise support for one of these versions and can expect 328 that clients ignore the value. 330 [[RFC editor: please remove the remainder of this section before 331 publication.]] 333 The version number for the final version of this specification 334 (0x00000001), is reserved for the version of the protocol that is 335 published as an RFC. 337 Version numbers used to identify IETF drafts are created by adding 338 the draft number to 0xff000000. For example, draft-ietf-quic- 339 transport-13 would be identified as 0xff00000D. 341 Implementors are encouraged to register version numbers of QUIC that 342 they are using for private experimentation on the GitHub wiki at 343 . 345 4. Packet Types and Formats 347 We first describe QUIC's packet types and their formats, since some 348 are referenced in subsequent mechanisms. 350 All numeric values are encoded in network byte order (that is, big- 351 endian) and all field sizes are in bits. When discussing individual 352 bits of fields, the least significant bit is referred to as bit 0. 353 Hexadecimal notation is used for describing the value of fields. 355 Any QUIC packet has either a long or a short header, as indicated by 356 the Header Form bit. Long headers are expected to be used early in 357 the connection before version negotiation and establishment of 1-RTT 358 keys. Short headers are minimal version-specific headers, which are 359 used after version negotiation and 1-RTT keys are established. 361 4.1. Long Header 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+ 365 |1| Type (7) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Version (32) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |DCIL(4)|SCIL(4)| 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Destination Connection ID (0/32..144) ... 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Source Connection ID (0/32..144) ... 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Length (i) ... 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Packet Number (8/16/32) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Payload (*) ... 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 1: Long Header Format 384 Long headers are used for packets that are sent prior to the 385 completion of version negotiation and establishment of 1-RTT keys. 386 Once both conditions are met, a sender switches to sending packets 387 using the short header (Section 4.2). The long form allows for 388 special packets - such as the Version Negotiation packet - to be 389 represented in this uniform fixed-length packet format. A long 390 header contains the following fields: 392 Header Form: The most significant bit (0x80) of octet 0 (the first 393 octet) is set to 1 for long headers. 395 Long Packet Type: The remaining seven bits of octet 0 contain the 396 packet type. This field can indicate one of 128 packet types. 397 The types specified for this version are listed in Table 1. 399 Version: The QUIC Version is a 32-bit field that follows the Type. 400 This field indicates which version of QUIC is in use and 401 determines how the rest of the protocol fields are interpreted. 403 DCIL and SCIL: The octet following the version contains the lengths 404 of the two connection ID fields that follow it. These lengths are 405 encoded as two 4-bit unsigned integers. The Destination 406 Connection ID Length (DCIL) field occupies the 4 high bits of the 407 octet and the Source Connection ID Length (SCIL) field occupies 408 the 4 low bits of the octet. An encoded length of 0 indicates 409 that the connection ID is also 0 octets in length. Non-zero 410 encoded lengths are increased by 3 to get the full length of the 411 connection ID, producing a length between 4 and 18 octets 412 inclusive. For example, an octet with the value 0x50 describes an 413 8-octet Destination Connection ID and a zero-length Source 414 Connection ID. 416 Destination Connection ID: The Destination Connection ID field 417 follows the connection ID lengths and is either 0 octets in length 418 or between 4 and 18 octets. Section 4.7 describes the use of this 419 field in more detail. 421 Source Connection ID: The Source Connection ID field follows the 422 Destination Connection ID and is either 0 octets in length or 423 between 4 and 18 octets. Section 4.7 describes the use of this 424 field in more detail. 426 Length: The length of the remainder of the packet (that is, the 427 Packet Number and Payload fields) in octets, encoded as a 428 variable-length integer (Section 7.1). 430 Packet Number: The packet number field is 1, 2, or 4 octets long. 431 The packet number has confidentiality protection separate from 432 packet protection, as described in Section 5.6 of [QUIC-TLS]. The 433 length of the packet number field is encoded in the plaintext 434 packet number. See Section 4.8 for details. 436 Payload: The payload of the packet. 438 The following packet types are defined: 440 +------+-----------------+---------------+ 441 | Type | Name | Section | 442 +------+-----------------+---------------+ 443 | 0x7F | Initial | Section 4.4.1 | 444 | | | | 445 | 0x7E | Retry | Section 4.4.2 | 446 | | | | 447 | 0x7D | Handshake | Section 4.4.3 | 448 | | | | 449 | 0x7C | 0-RTT Protected | Section 4.5 | 450 +------+-----------------+---------------+ 452 Table 1: Long Header Packet Types 454 The header form, type, connection ID lengths octet, destination and 455 source connection IDs, and version fields of a long header packet are 456 version-independent. The packet number and values for packet types 457 defined in Table 1 are version-specific. See [QUIC-INVARIANTS] for 458 details on how packets from different versions of QUIC are 459 interpreted. 461 The interpretation of the fields and the payload are specific to a 462 version and packet type. Type-specific semantics for this version 463 are described in the following sections. 465 The end of the packet is determined by the Length field. The Length 466 field covers the both the Packet Number and Payload fields, both of 467 which are confidentiality protected and initially of unknown length. 468 The size of the Payload field is learned once the packet number 469 protection is removed. 471 Senders can sometimes coalesce multiple packets into one UDP 472 datagram. See Section 4.6 for more details. 474 4.2. Short Header 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+ 479 |0|K|1|1|0|R R R| 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Destination Connection ID (0..144) ... 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Packet Number (8/16/32) ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Protected Payload (*) ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 2: Short Header Format 490 The short header can be used after the version and 1-RTT keys are 491 negotiated. This header form has the following fields: 493 Header Form: The most significant bit (0x80) of octet 0 is set to 0 494 for the short header. 496 Key Phase Bit: The second bit (0x40) of octet 0 indicates the key 497 phase, which allows a recipient of a packet to identify the packet 498 protection keys that are used to protect the packet. See 499 [QUIC-TLS] for details. 501 [[Editor's Note: this section should be removed and the bit 502 definitions changed before this draft goes to the IESG.]] 504 Third Bit: The third bit (0x20) of octet 0 is set to 1. 506 [[Editor's Note: this section should be removed and the bit 507 definitions changed before this draft goes to the IESG.]] 509 Fourth Bit: The fourth bit (0x10) of octet 0 is set to 1. 511 [[Editor's Note: this section should be removed and the bit 512 definitions changed before this draft goes to the IESG.]] 514 Google QUIC Demultipexing Bit: The fifth bit (0x8) of octet 0 is set 515 to 0. This allows implementations of Google QUIC to distinguish 516 Google QUIC packets from short header packets sent by a client 517 because Google QUIC servers expect the connection ID to always be 518 present. The special interpretation of this bit SHOULD be removed 519 from this specification when Google QUIC has finished 520 transitioning to the new header format. 522 Reserved: The sixth, seventh, and eighth bits (0x7) of octet 0 are 523 reserved for experimentation. 525 Destination Connection ID: The Destination Connection ID is a 526 connection ID that is chosen by the intended recipient of the 527 packet. See Section 6.1 for more details. 529 Packet Number: The packet number field is 1, 2, or 4 octets long. 530 The packet number has confidentiality protection separate from 531 packet protection, as described in Section 5.6 of [QUIC-TLS]. The 532 length of the packet number field is encoded in the plaintext 533 packet number. See Section 4.8 for details. 535 Protected Payload: Packets with a short header always include a 536 1-RTT protected payload. 538 The header form and connection ID field of a short header packet are 539 version-independent. The remaining fields are specific to the 540 selected QUIC version. See [QUIC-INVARIANTS] for details on how 541 packets from different versions of QUIC are interpreted. 543 4.3. Version Negotiation Packet 545 A Version Negotiation packet is inherently not version-specific, and 546 does not use the long packet header (see Section 4.1. Upon receipt 547 by a client, it will appear to be a packet using the long header, but 548 will be identified as a Version Negotiation packet based on the 549 Version field having a value of 0. 551 The Version Negotiation packet is a response to a client packet that 552 contains a version that is not supported by the server, and is only 553 sent by servers. 555 The layout of a Version Negotiation packet is: 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+ 560 |1| Unused (7) | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Version (32) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 |DCIL(4)|SCIL(4)| 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Destination Connection ID (0/32..144) ... 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Source Connection ID (0/32..144) ... 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Supported Version 1 (32) ... 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | [Supported Version 2 (32)] ... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 ... 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | [Supported Version N (32)] ... 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 3: Version Negotiation Packet 581 The value in the Unused field is selected randomly by the server. 583 The Version field of a Version Negotiation packet MUST be set to 584 0x00000000. 586 The server MUST include the value from the Source Connection ID field 587 of the packet it receives in the Destination Connection ID field. 588 The value for Source Connection ID MUST be copied from the 589 Destination Connection ID of the received packet, which is initially 590 randomly selected by a client. Echoing both connection IDs gives 591 clients some assurance that the server received the packet and that 592 the Version Negotiation packet was not generated by an off-path 593 attacker. 595 The remainder of the Version Negotiation packet is a list of 32-bit 596 versions which the server supports. 598 A Version Negotiation packet cannot be explicitly acknowledged in an 599 ACK frame by a client. Receiving another Initial packet implicitly 600 acknowledges a Version Negotiation packet. 602 The Version Negotiation packet does not include the Packet Number and 603 Length fields present in other packets that use the long header form. 604 Consequently, a Version Negotiation packet consumes an entire UDP 605 datagram. 607 See Section 6.3 for a description of the version negotiation process. 609 4.4. Cryptographic Handshake Packets 611 Once version negotiation is complete, the cryptographic handshake is 612 used to agree on cryptographic keys. The cryptographic handshake is 613 carried in Initial (Section 4.4.1) and Handshake (Section 4.4.3) 614 packets. 616 All these packets use the long header and contain the current QUIC 617 version in the version field. 619 In order to prevent tampering by version-unaware middleboxes, Initial 620 packets are protected with connection- and version-specific keys 621 (Initial keys) as described in [QUIC-TLS]. This protection does not 622 provide confidentiality or integrity against on-path attackers, but 623 provides some level of protection against off-path attackers. 625 4.4.1. Initial Packet 627 The Initial packet uses long headers with a type value of 0x7F. It 628 carries the first CRYPTO frames sent by the client and server to 629 perform key exchange, and may carry ACKs in either direction. The 630 Initial packet is protected by Initial keys as described in 631 [QUIC-TLS]. 633 The Initial packet has two additional header fields that follow the 634 normal Long Header. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Token Length (i) ... 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Token (*) ... 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Token Length: A variable-length integer specifying the length of the 645 Token field, in bytes. It may be zero if no token is present. 646 Initial packets sent by the server MUST include a zero-length 647 token. 649 Token: An optional token blob previously received in either a Retry 650 packet or NEW_TOKEN frame. 652 The client and server use the Initial packet type for any packet that 653 contains an initial cryptographic handshake message. In addition to 654 the first packet(s). This includes all cases where a new packet 655 containing the initial cryptographic message needs to be created, 656 such as the packets sent after receiving a Version Negotiation 657 (Section 4.3) or Retry packet (Section 4.4.2). 659 A server sends its first Initial packet in response to a client 660 Initial. A server may send multiple Initial packets. The 661 cryptographic key exchange could require multiple round trips or 662 retransmissions of this data. 664 The payload of an Initial packet includes a CRYPTO frame (or frames) 665 containing a cryptographic handshake message, ACK frames, or both. 666 The first CRYPTO frame sent always begins at an offset of 0 (see 667 Section 6.4). The client's complete first message MUST fit in a 668 single packet (see Section 6.4). Note that if the server sends a 669 HelloRetryRequest, the client will send a second Initial packet with 670 a CRYPTO frame with an offset starting at the end of the CRYPTO 671 stream in the first Initial. 673 4.4.1.1. Connection IDs 675 When an Initial packet is sent by a client which has not previously 676 received a Retry packet from the server, it populates the Destination 677 Connection ID field with an unpredictable value. This MUST be at 678 least 8 octets in length. Until a packet is received from the 679 server, the client MUST use the same value unless it abandons the 680 connection attempt and starts a new one. The initial Destination 681 Connection ID is used to determine packet protection keys for Initial 682 packets. 684 The client populates the Source Connection ID field with a value of 685 its choosing and sets the SCIL field to match. 687 The Destination Connection ID field in the server's Initial packet 688 contains a connection ID that is chosen by the recipient of the 689 packet (i.e., the client); the Source Connection ID includes the 690 connection ID that the sender of the packet wishes to use (see 691 Section 6.1). The server MUST use consistent Source Connection IDs 692 during the handshake. 694 On first receiving an Initial or Retry packet from the server, the 695 client uses the Source Connection ID supplied by the server as the 696 Destination Connection ID for subsequent packets. Once a client has 697 received an Initial packet from the server, it MUST discard any 698 packet it receives with a different Source Connection ID. 700 4.4.1.2. Tokens 702 If the client has a suitable token available from a previous 703 connection, it SHOULD populate the Token field. 705 If the client received a Retry packet from the server and sends an 706 Initial packet in response, then it sets the Destination Connection 707 ID to the value from the Source Connection ID in the Retry packet. 708 Changing Destination Connection ID also results in a change to the 709 keys used to protect the Initial packet. It also sets the Token 710 field to the token provided in the Retry. The client MUST NOT change 711 the Source Connection ID because the server could include the 712 connection ID as part of its token validation logic. 714 When a server receives an Initial packet with an address validation 715 token, it SHOULD attempt to validate it. If the token is invalid 716 then the server SHOULD proceed as if the client did not have a 717 validated address, including potentially sending a Retry. If the 718 validation succeeds, the server SHOULD then allow the handshake to 719 proceed (see Section 6.7). 721 Note: The rationale for treating the client as unvalidated rather 722 than discarding the packet is that the client might have received 723 the token in a previous connection using the NEW_TOKEN frame, and 724 if the server has lost state, it might be unable to validate the 725 token at all, leading to connection failure if the packet is 726 discarded. 728 4.4.1.3. Starting Packet Numbers 730 The first Initial packet contains a packet number of 0. Each packet 731 sent after the Initial packet is associated with a packet number 732 space and its packet number increases monotonically in that space 733 (see Section 4.8). 735 4.4.1.4. Minimum Packet Size 737 The payload of a UDP datagram carrying the Initial packet MUST be 738 expanded to at least 1200 octets (see Section 8), by adding PADDING 739 frames to the Initial packet and/or by combining the Initial packet 740 with a 0-RTT packet (see Section 4.6). 742 4.4.2. Retry Packet 744 A Retry packet uses long headers with a type value of 0x7E. It 745 carries an address validation token created by the server. It is 746 used by a server that wishes to perform a stateless retry (see 747 Section 6.7). 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | ODCIL(8 | Original Destination Connection ID (*) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Retry Token (*) ... 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 A Retry packet is not encrypted at all. Instead, the payload of a 758 Retry packet contains two values in the clear. 760 ODCIL: The length of the Original Destination Connection ID. 762 Original Destination Connection ID: The Destination Connection ID 763 from the Initial packet that this Retry is in response to. The 764 length of this field is given in DCIL. 766 Retry Token: An opaque token that the server can use to validate the 767 client's address. 769 The server populates the Destination Connection ID with the 770 connection ID that the client included in the Source Connection ID of 771 the Initial packet. This might be a zero-length value. 773 The server includes a connection ID of its choice in the Source 774 Connection ID field. The client MUST use this connection ID in the 775 Destination Connection ID of subsequent packets that it sends. 777 The Packet Number field of a Retry packet MUST be set to 0. This 778 value is subsequently protected as normal. [[Editor's Note: This 779 isn't ideal, because it creates a "cheat" where the client assumes a 780 value. That's a problem, so I'm tempted to suggest that this include 781 any value less than 2^30 so that normal processing works - and can be 782 properly exercised.]] 784 A Retry packet is never explicitly acknowledged in an ACK frame by a 785 client. 787 A server MUST only send a Retry in response to a client Initial 788 packet. 790 If the Original Destination Connection ID field does not match the 791 Destination Connection ID from most recent the Initial packet it 792 sent, clients MUST discard the packet. This prevents an off-path 793 attacker from injecting a Retry packet with a bogus new Source 794 Connection ID. 796 Otherwise, the client SHOULD respond with a new Initial packet with 797 the Token field set to the token received in the Retry packet. 799 4.4.3. Handshake Packet 801 A Handshake packet uses long headers with a type value of 0x7D. It 802 is used to carry acknowledgments and cryptographic handshake messages 803 from the server and client. 805 A server sends its cryptographic handshake in one or more Handshake 806 packets in response to an Initial packet if it does not send a Retry 807 packet. Once a client has received a Handshake packet from a server, 808 it uses Handshake packets to send subsequent cryptographic handshake 809 messages and acknowledgments to the server. 811 The Destination Connection ID field in a Handshake packet contains a 812 connection ID that is chosen by the recipient of the packet; the 813 Source Connection ID includes the connection ID that the sender of 814 the packet wishes to use (see Section 4.7). 816 The first Handshake packet sent by a server contains a packet number 817 of 0. Handshake packets are their own packet number space. Packet 818 numbers are incremented normally for other Handshake packets. 820 Servers MUST NOT send more than three datagrams including Initial and 821 Handshake packets without receiving a packet from a verified source 822 address. Source addresses can be verified through an address 823 validation token (delivered via a Retry packet or a NEW_TOKEN frame) 824 or by receiving any message from the client encrypted using the 825 Handshake keys. 827 The payload of this packet contains CRYPTO frames and could contain 828 PADDING, or ACK frames. Handshake packets MAY contain 829 CONNECTION_CLOSE frames if the handshake is unsuccessful. 831 4.5. Protected Packets 833 All QUIC packets use packet protection. Packets that are protected 834 with the static handshake keys or the 0-RTT keys are sent with long 835 headers; all packets protected with 1-RTT keys are sent with short 836 headers. The different packet types explicitly indicate the 837 encryption level and therefore the keys that are used to remove 838 packet protection. 0-RTT and 1-RTT protected packets share a single 839 packet number space. 841 Packets protected with handshake keys only use packet protection to 842 ensure that the sender of the packet is on the network path. This 843 packet protection is not effective confidentiality protection; any 844 entity that receives the Initial packet from a client can recover the 845 keys necessary to remove packet protection or to generate packets 846 that will be successfully authenticated. 848 Packets protected with 0-RTT and 1-RTT keys are expected to have 849 confidentiality and data origin authentication; the cryptographic 850 handshake ensures that only the communicating endpoints receive the 851 corresponding keys. 853 Packets protected with 0-RTT keys use a type value of 0x7C. The 854 connection ID fields for a 0-RTT packet MUST match the values used in 855 the Initial packet (Section 4.4.1). 857 The client can send 0-RTT packets after receiving an Initial 858 Section 4.4.1 or Handshake (Section 4.4.3) packet, if that packet 859 does not complete the handshake. Even if the client receives a 860 different connection ID in the Handshake packet, it MUST continue to 861 use the same Destination Connection ID for 0-RTT packets, see 862 Section 4.7. 864 The version field for protected packets is the current QUIC version. 866 The packet number field contains a packet number, which has 867 additional confidentiality protection that is applied after packet 868 protection is applied (see [QUIC-TLS] for details). The underlying 869 packet number increases with each packet sent, see Section 4.8 for 870 details. 872 The payload is protected using authenticated encryption. [QUIC-TLS] 873 describes packet protection in detail. After decryption, the 874 plaintext consists of a sequence of frames, as described in 875 Section 5. 877 4.6. Coalescing Packets 879 A sender can coalesce multiple QUIC packets (typically a 880 Cryptographic Handshake packet and a Protected packet) into one UDP 881 datagram. This can reduce the number of UDP datagrams needed to send 882 application data during the handshake and immediately afterwards. It 883 is not necessary for senders to coalesce packets, though failing to 884 do so will require sending a significantly larger number of datagrams 885 during the handshake. Receivers MUST be able to process coalesced 886 packets. 888 Senders SHOULD coalesce packets in order of increasing encryption 889 levels (Initial, Handshake, 0-RTT, 1-RTT), as this makes it more 890 likely the receiver will be able to process all the packets in a 891 single pass. A packet with a short header does not include a length, 892 so it will always be the last packet included in a UDP datagram. 894 Senders MUST NOT coalesce QUIC packets with different Destination 895 Connection IDs into a single UDP datagram. Receivers SHOULD ignore 896 any subsequent packets with a different Destination Connection ID 897 than the first packet in the datagram. 899 Every QUIC packet that is coalesced into a single UDP datagram is 900 separate and complete. Though the values of some fields in the 901 packet header might be redundant, no fields are omitted. The 902 receiver of coalesced QUIC packets MUST individually process each 903 QUIC packet and separately acknowledge them, as if they were received 904 as the payload of different UDP datagrams. If one or more packets in 905 a datagram cannot be processed yet (because the keys are not yet 906 available) or processing fails (decryption failure, unknown type, 907 etc.), the receiver MUST still attempt to process the remaining 908 packets. The skipped packets MAY either be discarded or buffered for 909 later processing, just as if the packets were received out-of-order 910 in separate datagrams. 912 4.7. Connection ID Encoding 914 A connection ID is used to ensure consistent routing of packets, as 915 described in Section 6.1. The long header contains two connection 916 IDs: the Destination Connection ID is chosen by the recipient of the 917 packet and is used to provide consistent routing; the Source 918 Connection ID is used to set the Destination Connection ID used by 919 the peer. 921 During the handshake, packets with the long header are used to 922 establish the connection ID that each endpoint uses. Each endpoint 923 uses the Source Connection ID field to specify the connection ID that 924 is used in the Destination Connection ID field of packets being sent 925 to them. Upon receiving a packet, each endpoint sets the Destination 926 Connection ID it sends to match the value of the Source Connection ID 927 that they receive. 929 During the handshake, an endpoint might receive multiple packets with 930 the long header, and thus be given multiple opportunities to update 931 the Destination Connection ID it sends. A client MUST only change 932 the value it sends in the Destination Connection ID in response to 933 the first packet of each type it receives from the server (Retry or 934 Initial); a server MUST set its value based on the Initial packet. 935 Any additional changes are not permitted; if subsequent packets of 936 those types include a different Source Connection ID, they MUST be 937 discarded. This avoids problems that might arise from stateless 938 processing of multiple Initial packets producing different connection 939 IDs. 941 Short headers only include the Destination Connection ID and omit the 942 explicit length. The length of the Destination Connection ID field 943 is expected to be known to endpoints. 945 Endpoints using a connection-ID based load balancer could agree with 946 the load balancer on a fixed or minimum length and on an encoding for 947 connection IDs. This fixed portion could encode an explicit length, 948 which allows the entire connection ID to vary in length and still be 949 used by the load balancer. 951 The very first packet sent by a client includes a random value for 952 Destination Connection ID. The same value MUST be used for all 0-RTT 953 packets sent on that connection (Section 4.5). This randomized value 954 is used to determine the handshake packet protection keys (see 955 Section 5.3.2 of [QUIC-TLS]). 957 A Version Negotiation (Section 4.3) packet MUST use both connection 958 IDs selected by the client, swapped to ensure correct routing toward 959 the client. 961 The connection ID can change over the lifetime of a connection, 962 especially in response to connection migration (Section 6.11). 963 NEW_CONNECTION_ID frames (Section 7.13) are used to provide new 964 connection ID values. 966 4.8. Packet Numbers 968 The packet number is an integer in the range 0 to 2^62-1. The value 969 is used in determining the cryptographic nonce for packet encryption. 970 Each endpoint maintains a separate packet number for sending and 971 receiving. 973 Packet numbers are divided into 3 spaces in QUIC: 975 o Initial space: All Initial packets Section 4.4.1 are in this 976 space. 978 o Handshake space: All Handshake packets Section 4.4.3 are in this 979 space. 981 o Application data space: All 0-RTT and 1-RTT encrypted packets 982 Section 4.5 are in this space. 984 As described in [QUIC-TLS], each packet type uses different 985 encryption keys. 987 Conceptually, a packet number space is the encryption context in 988 which a packet can be processed and ACKed. Initial packets can only 989 be sent with Initial encryption keys and ACKed in packets which are 990 also Initial packets. Similarly, Handshake packets can only be sent 991 and acknowledged in Handshake packets. 993 This enforces cryptographic separation between the data sent in the 994 different packet sequence number spaces. Each packet number space 995 starts at packet number 0. Subsequent packets sent in the same 996 packet number space MUST increase the packet number by at least one. 998 0-RTT and 1-RTT data exist in the same packet number space to make 999 loss recovery algorithms easier to implement between the two packet 1000 types. 1002 A QUIC endpoint MUST NOT reuse a packet number within the same packet 1003 number space in one connection (that is, under the same cryptographic 1004 keys). If the packet number for sending reaches 2^62 - 1, the sender 1005 MUST close the connection without sending a CONNECTION_CLOSE frame or 1006 any further packets; an endpoint MAY send a Stateless Reset 1007 (Section 6.13.4) in response to further packets that it receives. 1009 In the QUIC long and short packet headers, the number of bits 1010 required to represent the packet number are reduced by including only 1011 a variable number of the least significant bits of the packet number. 1012 One or two of the most significant bits of the first octet determine 1013 how many bits of the packet number are provided, as shown in Table 2. 1015 +---------------------+----------------+--------------+ 1016 | First octet pattern | Encoded Length | Bits Present | 1017 +---------------------+----------------+--------------+ 1018 | 0b0xxxxxxx | 1 octet | 7 | 1019 | | | | 1020 | 0b10xxxxxx | 2 | 14 | 1021 | | | | 1022 | 0b11xxxxxx | 4 | 30 | 1023 +---------------------+----------------+--------------+ 1025 Table 2: Packet Number Encodings for Packet Headers 1027 Note that these encodings are similar to those in Section 7.1, but 1028 use different values. 1030 The encoded packet number is protected as described in Section 5.6 1031 [QUIC-TLS]. Protection of the packet number is removed prior to 1032 recovering the full packet number. The full packet number is 1033 reconstructed at the receiver based on the number of significant bits 1034 present, the content of those bits, and the largest packet number 1035 received on a successfully authenticated packet. Recovering the full 1036 packet number is necessary to successfully remove packet protection. 1038 Once packet number protection is removed, the packet number is 1039 decoded by finding the packet number value that is closest to the 1040 next expected packet. The next expected packet is the highest 1041 received packet number plus one. For example, if the highest 1042 successfully authenticated packet had a packet number of 0xaa82f30e, 1043 then a packet containing a 14-bit value of 0x9b3 will be decoded as 1044 0xaa8309b3. 1046 The sender MUST use a packet number size able to represent more than 1047 twice as large a range than the difference between the largest 1048 acknowledged packet and packet number being sent. A peer receiving 1049 the packet will then correctly decode the packet number, unless the 1050 packet is delayed in transit such that it arrives after many higher- 1051 numbered packets have been received. An endpoint SHOULD use a large 1052 enough packet number encoding to allow the packet number to be 1053 recovered even if the packet arrives after packets that are sent 1054 afterwards. 1056 As a result, the size of the packet number encoding is at least one 1057 more than the base 2 logarithm of the number of contiguous 1058 unacknowledged packet numbers, including the new packet. 1060 For example, if an endpoint has received an acknowledgment for packet 1061 0x6afa2f, sending a packet with a number of 0x6b2d79 requires a 1062 packet number encoding with 14 bits or more; whereas the 30-bit 1063 packet number encoding is needed to send a packet with a number of 1064 0x6bc107. 1066 A Version Negotiation packet (Section 4.3) does not include a packet 1067 number. The Retry packet (Section 4.4.2) has special rules for 1068 populating the packet number field. 1070 5. Frames and Frame Types 1072 The payload of all packets, after removing packet protection, 1073 consists of a sequence of frames, as shown in Figure 4. Version 1074 Negotiation and Stateless Reset do not contain frames. 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Frame 1 (*) ... 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Frame 2 (*) ... 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 ... 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Frame N (*) ... 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 Figure 4: Contents of Protected Payload 1090 Protected payloads MUST contain at least one frame, and MAY contain 1091 multiple frames and multiple frame types. 1093 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 1094 packet boundary. Each frame begins with a Frame Type, indicating its 1095 type, followed by additional type-dependent fields: 1097 0 1 2 3 1098 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Type (i) ... 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Type-Dependent Fields (*) ... 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 5: Generic Frame Layout 1107 The frame types defined in this specification are listed in Table 3. 1108 The Frame Type in STREAM frames is used to carry other frame-specific 1109 flags. For all other frames, the Frame Type field simply identifies 1110 the frame. These frames are explained in more detail as they are 1111 referenced later in the document. 1113 +-------------+-------------------+--------------+ 1114 | Type Value | Frame Type Name | Definition | 1115 +-------------+-------------------+--------------+ 1116 | 0x00 | PADDING | Section 7.2 | 1117 | | | | 1118 | 0x01 | RST_STREAM | Section 7.3 | 1119 | | | | 1120 | 0x02 | CONNECTION_CLOSE | Section 7.4 | 1121 | | | | 1122 | 0x03 | APPLICATION_CLOSE | Section 7.5 | 1123 | | | | 1124 | 0x04 | MAX_DATA | Section 7.6 | 1125 | | | | 1126 | 0x05 | MAX_STREAM_DATA | Section 7.7 | 1127 | | | | 1128 | 0x06 | MAX_STREAM_ID | Section 7.8 | 1129 | | | | 1130 | 0x07 | PING | Section 7.9 | 1131 | | | | 1132 | 0x08 | BLOCKED | Section 7.10 | 1133 | | | | 1134 | 0x09 | STREAM_BLOCKED | Section 7.11 | 1135 | | | | 1136 | 0x0a | STREAM_ID_BLOCKED | Section 7.12 | 1137 | | | | 1138 | 0x0b | NEW_CONNECTION_ID | Section 7.13 | 1139 | | | | 1140 | 0x0c | STOP_SENDING | Section 7.14 | 1141 | | | | 1142 | 0x0d | ACK | Section 7.15 | 1143 | | | | 1144 | 0x0e | PATH_CHALLENGE | Section 7.17 | 1145 | | | | 1146 | 0x0f | PATH_RESPONSE | Section 7.18 | 1147 | | | | 1148 | 0x10 - 0x17 | STREAM | Section 7.20 | 1149 | | | | 1150 | 0x18 | CRYPTO | Section 7.21 | 1151 | | | | 1152 | 0x19 | NEW_TOKEN | Section 7.19 | 1153 | | | | 1154 | 0x20 | ACK_ECN | Section 7.16 | 1155 +-------------+-------------------+--------------+ 1157 Table 3: Frame Types 1159 All QUIC frames are idempotent. That is, a valid frame does not 1160 cause undesirable side effects or errors when received more than 1161 once. 1163 The Frame Type field uses a variable length integer encoding (see 1164 Section 7.1) with one exception. To ensure simple and efficient 1165 implementations of frame parsing, a frame type MUST use the shortest 1166 possible encoding. Though a two-, four- or eight-octet encoding of 1167 the frame types defined in this document is possible, the Frame Type 1168 field for these frames are encoded on a single octet. For instance, 1169 though 0x4007 is a legitimate two-octet encoding for a variable- 1170 length integer with a value of 7, PING frames are always encoded as a 1171 single octet with the value 0x07. An endpoint MUST treat the receipt 1172 of a frame type that uses a longer encoding than necessary as a 1173 connection error of type PROTOCOL_VIOLATION. 1175 5.1. Extension Frames 1177 QUIC frames do not use a self-describing encoding. An endpoint 1178 therefore needs to understand the syntax of all frames before it can 1179 successfully process a packet. This allows for efficient encoding of 1180 frames, but it means that an endpoint cannot send a frame of a type 1181 that is unknown to its peer. 1183 An extension to QUIC that wishes to use a new type of frame MUST 1184 first ensure that a peer is able to understand the frame. An 1185 endpoint can use a transport parameter to signal its willingness to 1186 receive one or more extension frame types with the one transport 1187 parameter. 1189 An IANA registry is used to manage the assignment of frame types, see 1190 Section 13.2. 1192 6. Life of a Connection 1194 A QUIC connection is a single conversation between two QUIC 1195 endpoints. QUIC's connection establishment intertwines version 1196 negotiation with the cryptographic and transport handshakes to reduce 1197 connection establishment latency, as described in Section 6.4. Once 1198 established, a connection may migrate to a different IP or port at 1199 either endpoint, due to NAT rebinding or mobility, as described in 1200 Section 6.11. Finally a connection may be terminated by either 1201 endpoint, as described in Section 6.13. 1203 6.1. Connection ID 1205 Each connection is identified by a collection of identifiers assigned 1206 to it. A connection ID can be 0 octets in length (and thus unlikely 1207 to be unique), or between 4 and 18 octets (inclusive). Connection 1208 IDs are selected independently in each direction. 1210 The primary function of a connection ID is to ensure that changes in 1211 addressing at lower protocol layers (UDP, IP, and below) don't cause 1212 packets for a QUIC connection to be delivered to the wrong endpoint. 1213 Each endpoint selects connection IDs using an implementation-specific 1214 (and perhaps deployment-specific) method which will allow packets 1215 with that connection ID to be routed back to the endpoint and 1216 identified by the endpoint upon receipt. 1218 A zero-length connection ID MAY be used when the connection ID is not 1219 needed for routing and the address/port tuple of packets is 1220 sufficient to associate them to a connection. An endpoint whose peer 1221 has selected a zero-length connection ID MUST continue to use a zero- 1222 length connection ID for the lifetime of the connection and MUST NOT 1223 send packets from any other local address. 1225 When an endpoint has requested a non-zero-length connection ID, it 1226 will issue a series of connection IDs over the lifetime of a 1227 connection. The series of connection IDs issued by an endpoint is 1228 ordered, with the final connection ID selected during the handshake 1229 coming first. Additional connection IDs are provided using the 1230 NEW_CONNECTION_ID frame (Section 7.13), each with a specified 1231 sequence number. The series of connection IDs issued SHOULD be 1232 contiguous, but might not appear to be upon receipt due to reordering 1233 or loss. 1235 Each connection ID MUST be used on only one local address. When 1236 packets are sent for the first time on a new local address, a new 1237 connection ID MUST be used with a higher sequence number than any 1238 connection ID previously used on any local address. At any time, an 1239 endpoint MAY change to a new connection ID on a local address already 1240 in use. 1242 An endpoint MUST NOT send packets with a connection ID which has a 1243 lower sequence number than the highest sequence number of any 1244 connection ID ever sent or received on that local address. This 1245 ensures that when an endpoint migrates to a new path or changes 1246 connection ID on an existing path, the packets will use a new 1247 connection ID in both directions. 1249 Implementations SHOULD ensure that peers have a connection ID with a 1250 matching sequence number available when changing to a new connection 1251 ID. An implementation could do this by always supplying a 1252 corresponding connection ID to a peer for each connection ID received 1253 from that peer. 1255 While endpoints select connection IDs as appropriate for their 1256 implementation, the connection ID MUST NOT include the unprotected 1257 sequence number. Endpoints need to be able to recover the sequence 1258 number associated with each connection ID they generate without 1259 relying on information available to unaffiliate parties. A 1260 connection ID that encodes an unencrypted sequence number could be 1261 used to correlate connection IDs across network paths. 1263 6.2. Matching Packets to Connections 1265 Incoming packets are classified on receipt. Packets can either be 1266 associated with an existing connection, or - for servers - 1267 potentially create a new connection. 1269 Hosts try to associate a packet with an existing connection. If the 1270 packet has a Destination Connection ID corresponding to an existing 1271 connection, QUIC processes that packet accordingly. Note that more 1272 than one connection ID can be associated with a connection; see 1273 Section 6.1. 1275 If the Destination Connection ID is zero length and the packet 1276 matches the address/port tuple of a connection where the host did not 1277 require connection IDs, QUIC processes the packet as part of that 1278 connection. Endpoints MUST drop packets with zero-length Destination 1279 Connection ID fields if they do not correspond to a single 1280 connection. 1282 6.2.1. Client Packet Handling 1284 Valid packets sent to clients always include a Destination Connection 1285 ID that matches the value the client selects. Clients that choose to 1286 receive zero-length connection IDs can use the address/port tuple to 1287 identify a connection. Packets that don't match an existing 1288 connection MAY be discarded. 1290 Due to packet reordering or loss, clients might receive packets for a 1291 connection that are encrypted with a key it has not yet computed. 1292 Clients MAY drop these packets, or MAY buffer them in anticipation of 1293 later packets that allow it to compute the key. 1295 If a client receives a packet that has an unsupported version, it 1296 MUST discard that packet. 1298 6.2.2. Server Packet Handling 1300 If a server receives a packet that has an unsupported version and 1301 sufficient length to be an Initial packet for some version supported 1302 by the server, it SHOULD send a Version Negotiation packet as 1303 described in Section 6.3.1. Servers MAY rate control these packets 1304 to avoid storms of Version Negotiation packets. 1306 The first packet for an unsupported version can use different 1307 semantics and encodings for any version-specific field. In 1308 particular, different packet protection keys might be used for 1309 different versions. Servers that do not support a particular version 1310 are unlikely to be able to decrypt the content of the packet. 1311 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1312 unknown version, but instead send a Version Negotiation packet, 1313 provided that the packet is sufficiently long. 1315 Servers MUST drop other packets that contain unsupported versions. 1317 Packets with a supported version, or no version field, are matched to 1318 a connection as described in Section 6.2. If not matched, the server 1319 continues below. 1321 If the packet is an Initial packet fully conforming with the 1322 specification, the server proceeds with the handshake (Section 6.4). 1323 This commits the server to the version that the client selected. 1325 If a server isn't currently accepting any new connections, it SHOULD 1326 send a Handshake packet containing a CONNECTION_CLOSE frame with 1327 error code SERVER_BUSY. 1329 If the packet is a 0-RTT packet, the server MAY buffer a limited 1330 number of these packets in anticipation of a late-arriving Initial 1331 Packet. Clients are forbidden from sending Handshake packets prior 1332 to receiving a server response, so servers SHOULD ignore any such 1333 packets. 1335 Servers MUST drop incoming packets under all other circumstances. 1336 They SHOULD send a Stateless Reset (Section 6.13.4) if a connection 1337 ID is present in the header. 1339 6.3. Version Negotiation 1341 Version negotiation ensures that client and server agree to a QUIC 1342 version that is mutually supported. A server sends a Version 1343 Negotiation packet in response to each packet that might initiate a 1344 new connection, see Section 6.2 for details. 1346 The size of the first packet sent by a client will determine whether 1347 a server sends a Version Negotiation packet. Clients that support 1348 multiple QUIC versions SHOULD pad their Initial packets to reflect 1349 the largest minimum Initial packet size of all their versions. This 1350 ensures that the server responds if there are any mutually supported 1351 versions. 1353 6.3.1. Sending Version Negotiation Packets 1355 If the version selected by the client is not acceptable to the 1356 server, the server responds with a Version Negotiation packet (see 1357 Section 4.3). This includes a list of versions that the server will 1358 accept. 1360 This system allows a server to process packets with unsupported 1361 versions without retaining state. Though either the Initial packet 1362 or the Version Negotiation packet that is sent in response could be 1363 lost, the client will send new packets until it successfully receives 1364 a response or it abandons the connection attempt. 1366 6.3.2. Handling Version Negotiation Packets 1368 When the client receives a Version Negotiation packet, it first 1369 checks that the Destination and Source Connection ID fields match the 1370 Source and Destination Connection ID fields in a packet that the 1371 client sent. If this check fails, the packet MUST be discarded. 1373 Once the Version Negotiation packet is determined to be valid, the 1374 client then selects an acceptable protocol version from the list 1375 provided by the server. The client then attempts to create a 1376 connection using that version. Though the contents of the Initial 1377 packet the client sends might not change in response to version 1378 negotiation, a client MUST increase the packet number it uses on 1379 every packet it sends. Packets MUST continue to use long headers and 1380 MUST include the new negotiated protocol version. 1382 The client MUST use the long header format and include its selected 1383 version on all packets until it has 1-RTT keys and it has received a 1384 packet from the server which is not a Version Negotiation packet. 1386 A client MUST NOT change the version it uses unless it is in response 1387 to a Version Negotiation packet from the server. Once a client 1388 receives a packet from the server which is not a Version Negotiation 1389 packet, it MUST discard other Version Negotiation packets on the same 1390 connection. Similarly, a client MUST ignore a Version Negotiation 1391 packet if it has already received and acted on a Version Negotiation 1392 packet. 1394 A client MUST ignore a Version Negotiation packet that lists the 1395 client's chosen version. 1397 Version negotiation packets have no cryptographic protection. The 1398 result of the negotiation MUST be revalidated as part of the 1399 cryptographic handshake (see Section 6.6.4). 1401 6.3.3. Using Reserved Versions 1403 For a server to use a new version in the future, clients must 1404 correctly handle unsupported versions. To help ensure this, a server 1405 SHOULD include a reserved version (see Section 3) while generating a 1406 Version Negotiation packet. 1408 The design of version negotiation permits a server to avoid 1409 maintaining state for packets that it rejects in this fashion. The 1410 validation of version negotiation (see Section 6.6.4) only validates 1411 the result of version negotiation, which is the same no matter which 1412 reserved version was sent. A server MAY therefore send different 1413 reserved version numbers in the Version Negotiation Packet and in its 1414 transport parameters. 1416 A client MAY send a packet using a reserved version number. This can 1417 be used to solicit a list of supported versions from a server. 1419 6.4. Cryptographic and Transport Handshake 1421 QUIC relies on a combined cryptographic and transport handshake to 1422 minimize connection establishment latency. QUIC uses the CRYPTO 1423 frame Section 7.21 to transmit the cryptographic handshake. Version 1424 0x00000001 of QUIC uses TLS 1.3 as described in [QUIC-TLS]; a 1425 different QUIC version number could indicate that a different 1426 cryptographic handshake protocol is in use. 1428 QUIC provides reliable, ordered delivery of the cryptographic 1429 handshake data. QUIC packet protection ensures confidentiality and 1430 integrity protection that meets the requirements of the cryptographic 1431 handshake protocol: 1433 o authenticated key exchange, where 1435 * a server is always authenticated, 1437 * a client is optionally authenticated, 1439 * every connection produces distinct and unrelated keys, 1440 * keying material is usable for packet protection for both 0-RTT 1441 and 1-RTT packets, and 1443 * 1-RTT keys have forward secrecy 1445 o authenticated values for the transport parameters of the peer (see 1446 Section 6.6) 1448 o authenticated confirmation of version negotiation (see 1449 Section 6.6.4) 1451 o authenticated negotiation of an application protocol (TLS uses 1452 ALPN [RFC7301] for this purpose) 1454 o for the server, the ability to carry data that provides assurance 1455 that the client can receive packets that are addressed with the 1456 transport address that is claimed by the client (see Section 6.9) 1458 The initial CRYPTO frame MUST be sent in a single packet. Any second 1459 attempt that is triggered by address validation MUST also be sent 1460 within a single packet. This avoids having to reassemble a message 1461 from multiple packets. 1463 The first client packet of the cryptographic handshake protocol MUST 1464 fit within a 1232 octet QUIC packet payload. This includes overheads 1465 that reduce the space available to the cryptographic handshake 1466 protocol. 1468 The CRYPTO frame can be sent in different packet number spaces. 1469 CRYPTO frames in each packet number space carry a separate sequence 1470 of handshake data starting from an offset of 0. 1472 6.5. Example Handshake Flows 1474 Details of how TLS is integrated with QUIC are provided in 1475 [QUIC-TLS], but some examples are provided here. 1477 Figure 6 provides an overview of the 1-RTT handshake. Each line 1478 shows a QUIC packet with the packet type and packet number shown 1479 first, followed by the contents. So, for instance the first packet 1480 is of type Initial, with packet number 0, and contains a CRYPTO frame 1481 carrying the ClientHello. 1483 Note that multiple QUIC packets - even of different encryption levels 1484 - may be coalesced into a single UDP datagram (see Section 4.6, and 1485 so this handshake may consist of as few as 4 UDP datagrams, or any 1486 number more. For instance, the server's first flight contains 1487 packets from the Initial encryption level (obfuscation), the 1488 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1489 encryption level. 1491 Client Server 1493 Initial[0]: CRYPTO[CH] -> 1495 Initial[0]: CRYPTO[SH] ACK[0] 1496 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1497 <- 1-RTT[0]: STREAM[1, "..."] 1499 Initial[1]: ACK[0] 1500 Handshake[0]: CRYPTO[FIN], ACK[0] 1501 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1503 1-RTT[1]: STREAM[55, "..."], ACK[0] 1504 <- Handshake[1]: ACK[0] 1506 Figure 6: Example 1-RTT Handshake 1508 Figure 7 shows an example of a connection with a 0-RTT handshake and 1509 a single packet of 0-RTT data. Note that as described in 1510 Section 4.8, the server ACKs the 0-RTT data at the 1-RTT encryption 1511 level, and the client's sequence numbers at the 1-RTT encryption 1512 level continue to increment from its 0-RTT packets. 1514 Client Server 1516 Initial[0]: CRYPTO[CH] 1517 0-RTT[0]: STREAM[0, "..."] -> 1519 Initial[0]: CRYPTO[SH] ACK[0] 1520 Handshake[0] CRYPTO[EE, CERT, CV, FIN] 1521 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1523 Initial[1]: ACK[0] 1524 0-RTT[1]: CRYPTO[EOED] 1525 Handshake[0]: CRYPTO[FIN], ACK[0] 1526 1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1528 1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1529 <- Handshake[1]: ACK[0] 1531 Figure 7: Example 1-RTT Handshake 1533 6.6. Transport Parameters 1535 During connection establishment, both endpoints make authenticated 1536 declarations of their transport parameters. These declarations are 1537 made unilaterally by each endpoint. Endpoints are required to comply 1538 with the restrictions implied by these parameters; the description of 1539 each parameter includes rules for its handling. 1541 The format of the transport parameters is the TransportParameters 1542 struct from Figure 8. This is described using the presentation 1543 language from Section 3 of [I-D.ietf-tls-tls13]. 1545 uint32 QuicVersion; 1547 enum { 1548 initial_max_stream_data(0), 1549 initial_max_data(1), 1550 initial_max_bidi_streams(2), 1551 idle_timeout(3), 1552 preferred_address(4), 1553 max_packet_size(5), 1554 stateless_reset_token(6), 1555 ack_delay_exponent(7), 1556 initial_max_uni_streams(8), 1557 disable_migration(9), 1558 (65535) 1559 } TransportParameterId; 1561 struct { 1562 TransportParameterId parameter; 1563 opaque value<0..2^16-1>; 1564 } TransportParameter; 1566 struct { 1567 select (Handshake.msg_type) { 1568 case client_hello: 1569 QuicVersion initial_version; 1571 case encrypted_extensions: 1572 QuicVersion negotiated_version; 1573 QuicVersion supported_versions<4..2^8-4>; 1574 }; 1575 TransportParameter parameters<22..2^16-1>; 1576 } TransportParameters; 1578 struct { 1579 enum { IPv4(4), IPv6(6), (15) } ipVersion; 1580 opaque ipAddress<4..2^8-1>; 1581 uint16 port; 1582 opaque connectionId<0..18>; 1583 opaque statelessResetToken[16]; 1584 } PreferredAddress; 1586 Figure 8: Definition of TransportParameters 1588 The "extension_data" field of the quic_transport_parameters extension 1589 defined in [QUIC-TLS] contains a TransportParameters value. TLS 1590 encoding rules are therefore used to encode the transport parameters. 1592 QUIC encodes transport parameters into a sequence of octets, which 1593 are then included in the cryptographic handshake. Once the handshake 1594 completes, the transport parameters declared by the peer are 1595 available. Each endpoint validates the value provided by its peer. 1596 In particular, version negotiation MUST be validated (see 1597 Section 6.6.4) before the connection establishment is considered 1598 properly complete. 1600 Definitions for each of the defined transport parameters are included 1601 in Section 6.6.1. Any given parameter MUST appear at most once in a 1602 given transport parameters extension. An endpoint MUST treat receipt 1603 of duplicate transport parameters as a connection error of type 1604 TRANSPORT_PARAMETER_ERROR. 1606 6.6.1. Transport Parameter Definitions 1608 An endpoint MUST include the following parameters in its encoded 1609 TransportParameters: 1611 initial_max_stream_data (0x0000): The initial stream maximum data 1612 parameter contains the initial value for the maximum data that can 1613 be sent on any newly created stream. This parameter is encoded as 1614 an unsigned 32-bit integer in units of octets. This is equivalent 1615 to an implicit MAX_STREAM_DATA frame (Section 7.7) being sent on 1616 all streams immediately after opening. 1618 initial_max_data (0x0001): The initial maximum data parameter 1619 contains the initial value for the maximum amount of data that can 1620 be sent on the connection. This parameter is encoded as an 1621 unsigned 32-bit integer in units of octets. This is equivalent to 1622 sending a MAX_DATA (Section 7.6) for the connection immediately 1623 after completing the handshake. 1625 idle_timeout (0x0003): The idle timeout is a value in seconds that 1626 is encoded as an unsigned 16-bit integer. The maximum value is 1627 600 seconds (10 minutes). 1629 An endpoint MAY use the following transport parameters: 1631 initial_max_bidi_streams (0x0002): The initial maximum bidirectional 1632 streams parameter contains the initial maximum number of 1633 application-owned bidirectional streams the peer may initiate, 1634 encoded as an unsigned 16-bit integer. If this parameter is 1635 absent or zero, application-owned bidirectional streams cannot be 1636 created until a MAX_STREAM_ID frame is sent. Setting this 1637 parameter is equivalent to sending a MAX_STREAM_ID (Section 7.8) 1638 immediately after completing the handshake containing the 1639 corresponding Stream ID. For example, a value of 0x05 would be 1640 equivalent to receiving a MAX_STREAM_ID containing 16 when 1641 received by a client or 17 when received by a server. 1643 initial_max_uni_streams (0x0008): The initial maximum unidirectional 1644 streams parameter contains the initial maximum number of 1645 application-owned unidirectional streams the peer may initiate, 1646 encoded as an unsigned 16-bit integer. If this parameter is 1647 absent or zero, unidirectional streams cannot be created until a 1648 MAX_STREAM_ID frame is sent. Setting this parameter is equivalent 1649 to sending a MAX_STREAM_ID (Section 7.8) immediately after 1650 completing the handshake containing the corresponding Stream ID. 1651 For example, a value of 0x05 would be equivalent to receiving a 1652 MAX_STREAM_ID containing 18 when received by a client or 19 when 1653 received by a server. 1655 max_packet_size (0x0005): The maximum packet size parameter places a 1656 limit on the size of packets that the endpoint is willing to 1657 receive, encoded as an unsigned 16-bit integer. This indicates 1658 that packets larger than this limit will be dropped. The default 1659 for this parameter is the maximum permitted UDP payload of 65527. 1660 Values below 1200 are invalid. This limit only applies to 1661 protected packets (Section 4.5). 1663 ack_delay_exponent (0x0007): An 8-bit unsigned integer value 1664 indicating an exponent used to decode the ACK Delay field in the 1665 ACK frame, see Section 7.15. If this value is absent, a default 1666 value of 3 is assumed (indicating a multiplier of 8). The default 1667 value is also used for ACK frames that are sent in Initial and 1668 Handshake packets. Values above 20 are invalid. 1670 disable_migration (0x0009): The endpoint does not support connection 1671 migration (Section 6.11). Peers MUST NOT send any packets, 1672 including probing packets (Section 6.11.1), from a local address 1673 other than that used to perform the handshake. This parameter is 1674 a zero-length value. 1676 A server MAY include the following transport parameters: 1678 stateless_reset_token (0x0006): The Stateless Reset Token is used in 1679 verifying a stateless reset, see Section 6.13.4. This parameter 1680 is a sequence of 16 octets. 1682 preferred_address (0x0004): The server's Preferred Address is used 1683 to effect a change in server address at the end of the handshake, 1684 as described in Section 6.12. 1686 A client MUST NOT include a stateless reset token or a preferred 1687 address. A server MUST treat receipt of either transport parameter 1688 as a connection error of type TRANSPORT_PARAMETER_ERROR. 1690 6.6.2. Values of Transport Parameters for 0-RTT 1692 A client that attempts to send 0-RTT data MUST remember the transport 1693 parameters used by the server. The transport parameters that the 1694 server advertises during connection establishment apply to all 1695 connections that are resumed using the keying material established 1696 during that handshake. Remembered transport parameters apply to the 1697 new connection until the handshake completes and new transport 1698 parameters from the server can be provided. 1700 A server can remember the transport parameters that it advertised, or 1701 store an integrity-protected copy of the values in the ticket and 1702 recover the information when accepting 0-RTT data. A server uses the 1703 transport parameters in determining whether to accept 0-RTT data. 1705 A server MAY accept 0-RTT and subsequently provide different values 1706 for transport parameters for use in the new connection. If 0-RTT 1707 data is accepted by the server, the server MUST NOT reduce any limits 1708 or alter any values that might be violated by the client with its 1709 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1710 set values for initial_max_data or initial_max_stream_data that are 1711 smaller than the remembered value of those parameters. Similarly, a 1712 server MUST NOT reduce the value of initial_max_bidi_streams or 1713 initial_max_uni_streams. 1715 Omitting or setting a zero value for certain transport parameters can 1716 result in 0-RTT data being enabled, but not usable. The following 1717 transport parameters SHOULD be set to non-zero values for 0-RTT: 1718 initial_max_bidi_streams, initial_max_uni_streams, initial_max_data, 1719 initial_max_stream_data. 1721 The value of the server's previous preferred_address MUST NOT be used 1722 when establishing a new connection; rather, the client should wait to 1723 observe the server's new preferred_address value in the handshake. 1725 A server MUST reject 0-RTT data or even abort a handshake if the 1726 implied values for transport parameters cannot be supported. 1728 6.6.3. New Transport Parameters 1730 New transport parameters can be used to negotiate new protocol 1731 behavior. An endpoint MUST ignore transport parameters that it does 1732 not support. Absence of a transport parameter therefore disables any 1733 optional protocol feature that is negotiated using the parameter. 1735 New transport parameters can be registered according to the rules in 1736 Section 13.1. 1738 6.6.4. Version Negotiation Validation 1740 Though the cryptographic handshake has integrity protection, two 1741 forms of QUIC version downgrade are possible. In the first, an 1742 attacker replaces the QUIC version in the Initial packet. In the 1743 second, a fake Version Negotiation packet is sent by an attacker. To 1744 protect against these attacks, the transport parameters include three 1745 fields that encode version information. These parameters are used to 1746 retroactively authenticate the choice of version (see Section 6.3). 1748 The cryptographic handshake provides integrity protection for the 1749 negotiated version as part of the transport parameters (see 1750 Section 6.6). As a result, attacks on version negotiation by an 1751 attacker can be detected. 1753 The client includes the initial_version field in its transport 1754 parameters. The initial_version is the version that the client 1755 initially attempted to use. If the server did not send a Version 1756 Negotiation packet Section 4.3, this will be identical to the 1757 negotiated_version field in the server transport parameters. 1759 A server that processes all packets in a stateful fashion can 1760 remember how version negotiation was performed and validate the 1761 initial_version value. 1763 A server that does not maintain state for every packet it receives 1764 (i.e., a stateless server) uses a different process. If the 1765 initial_version matches the version of QUIC that is in use, a 1766 stateless server can accept the value. 1768 If the initial_version is different from the version of QUIC that is 1769 in use, a stateless server MUST check that it would have sent a 1770 Version Negotiation packet if it had received a packet with the 1771 indicated initial_version. If a server would have accepted the 1772 version included in the initial_version and the value differs from 1773 the QUIC version that is in use, the server MUST terminate the 1774 connection with a VERSION_NEGOTIATION_ERROR error. 1776 The server includes both the version of QUIC that is in use and a 1777 list of the QUIC versions that the server supports. 1779 The negotiated_version field is the version that is in use. This 1780 MUST be set by the server to the value that is on the Initial packet 1781 that it accepts (not an Initial packet that triggers a Retry or 1782 Version Negotiation packet). A client that receives a 1783 negotiated_version that does not match the version of QUIC that is in 1784 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 1785 error code. 1787 The server includes a list of versions that it would send in any 1788 version negotiation packet (Section 4.3) in the supported_versions 1789 field. The server populates this field even if it did not send a 1790 version negotiation packet. 1792 The client validates that the negotiated_version is included in the 1793 supported_versions list and - if version negotiation was performed - 1794 that it would have selected the negotiated version. A client MUST 1795 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 1796 if the current QUIC version is not listed in the supported_versions 1797 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 1798 code if version negotiation occurred but it would have selected a 1799 different version based on the value of the supported_versions list. 1801 When an endpoint accepts multiple QUIC versions, it can potentially 1802 interpret transport parameters as they are defined by any of the QUIC 1803 versions it supports. The version field in the QUIC packet header is 1804 authenticated using transport parameters. The position and the 1805 format of the version fields in transport parameters MUST either be 1806 identical across different QUIC versions, or be unambiguously 1807 different to ensure no confusion about their interpretation. One way 1808 that a new format could be introduced is to define a TLS extension 1809 with a different codepoint. 1811 6.7. Stateless Retries 1813 A server can process an initial cryptographic handshake messages from 1814 a client without committing any state. This allows a server to 1815 perform address validation (Section 6.9), or to defer connection 1816 establishment costs. 1818 A server that generates a response to an Initial packet without 1819 retaining connection state MUST use the Retry packet (Section 4.4.2). 1820 This packet causes a client to restart the connection attempt and 1821 includes the token in the new Initial packet (Section 4.4.1) to prove 1822 source address ownership. 1824 6.8. Using Explicit Congestion Notification 1826 QUIC endpoints use Explicit Congestion Notification (ECN) [RFC3168] 1827 to detect and respond to network congestion. ECN allows a network 1828 node to indicate congestion in the network by setting a codepoint in 1829 the IP header of a packet instead of dropping it. Endpoints react to 1830 congestion by reducing their sending rate in response, as described 1831 in [QUIC-RECOVERY]. 1833 To use ECN, QUIC endpoints first determine whether a path and peer 1834 support ECN marking. Verifying the path occurs at the beginning of a 1835 connection and when the connection migrates to a new path (see 1836 Section 6.11). 1838 Each endpoint independently verifies and enables ECN for the path 1839 from it to the peer. 1841 To verify that both a path and the peer support ECN, an endpoint MUST 1842 set one of the ECN Capable Transport (ECT) codepoints - ECT(0) or 1843 ECT(1) - in the IP header [RFC8311] of all outgoing packets. 1845 If an ECT codepoint set in the IP header is not corrupted by a 1846 network device, then a received packet contains either the codepoint 1847 sent by the peer or the Congestion Experienced (CE) codepoint set by 1848 a network device that is experiencing congestion. 1850 On receiving a packet with an ECT or CE codepoint, an endpoint that 1851 supports ECN increases the corresponding ECT(0), ECT(1), or CE count, 1852 and includes these counters in subsequent (see Section 8.1) ACK_ECN 1853 frames (see Section 7.16). 1855 A packet detected by a receiver as a duplicate does not affect the 1856 receiver's local ECN codepoint counts to mitigate security concerns 1857 (Section 12.7). 1859 If an endpoint receives a packet without an ECT or CE codepoint, it 1860 responds per Section 8.1 with an ACK frame. 1862 If an endpoint does not support ECN or does not have access to 1863 received ECN codepoints, it acknowledges received packets per 1864 Section 8.1 with an ACK frame. 1866 If a packet sent with an ECT codepoint is newly acknowledged by the 1867 peer in an ACK frame, the endpoint stops setting ECT codepoints in 1868 subsequent packets, with the expectation that either the network or 1869 the peer no longer supports ECN. 1871 To protect the connection from arbitrary corruption of ECN codepoints 1872 by the network, an endpoint verifies the following when an ACK_ECN 1873 frame is received: 1875 o The total increase in ECT(0), ECT(1), and CE counters reported in 1876 the ACK_ECN frame MUST be equal to the total number of packets 1877 newly acknowledged in this ACK_ECN frame. 1879 o The increase in ECT(0) and ECT(1) counters MUST be no greater than 1880 the number of packets newly acknowledged that were sent with the 1881 corresponding codepoint. 1883 Upon successful verification, an endpoint continues to set ECT 1884 codepoints in subsequent packets with the expectation that the path 1885 is ECN-capable. 1887 If verification fails, then the endpoint ceases setting ECT 1888 codepoints in subsequent packets with the expectation that either the 1889 network or the peer does not support ECN. 1891 If an endpoint sets ECT codepoints on outgoing packets and encounters 1892 a retransmission timeout due to the absence of acknowledgments from 1893 the peer (see [QUIC-RECOVERY]), the endpoint MAY cease setting ECT 1894 codepoints in subsequent packets. Doing so allows the connection to 1895 traverse network elements that drop packets carrying ECT or CE 1896 codepoints in the IP header. 1898 6.9. Proof of Source Address Ownership 1900 Transport protocols commonly spend a round trip checking that a 1901 client owns the transport address (IP and port) that it claims. 1902 Verifying that a client can receive packets sent to its claimed 1903 transport address protects against spoofing of this information by 1904 malicious clients. 1906 This technique is used primarily to avoid QUIC from being used for 1907 traffic amplification attack. In such an attack, a packet is sent to 1908 a server with spoofed source address information that identifies a 1909 victim. If a server generates more or larger packets in response to 1910 that packet, the attacker can use the server to send more data toward 1911 the victim than it would be able to send on its own. 1913 Several methods are used in QUIC to mitigate this attack. Firstly, 1914 the initial handshake packet is padded to at least 1200 octets. This 1915 allows a server to send a similar amount of data without risking 1916 causing an amplification attack toward an unproven remote address. 1918 A server eventually confirms that a client has received its messages 1919 when the first Handshake-level message is received. This might be 1920 insufficient, either because the server wishes to avoid the 1921 computational cost of completing the handshake, or it might be that 1922 the size of the packets that are sent during the handshake is too 1923 large. This is especially important for 0-RTT, where the server 1924 might wish to provide application data traffic - such as a response 1925 to a request - in response to the data carried in the early data from 1926 the client. 1928 To send additional data prior to completing the cryptographic 1929 handshake, the server then needs to validate that the client owns the 1930 address that it claims. 1932 Source address validation is therefore performed by the core 1933 transport protocol during the establishment of a connection. 1935 A different type of source address validation is performed after a 1936 connection migration, see Section 6.10. 1938 6.9.1. Client Address Validation Procedure 1940 QUIC uses token-based address validation. Any time the server wishes 1941 to validate a client address, it provides the client with a token. 1942 As long as the token's authenticity can be checked (see 1943 Section 6.9.3) and the client is able to return that token, it proves 1944 to the server that it received the token. 1946 Upon receiving the client's Initial packet, the server can request 1947 address validation by sending a Retry packet containing a token. 1948 This token is repeated in the client's next Initial packet. Because 1949 the token is consumed by the server that generates it, there is no 1950 need for a single well-defined format. A token could include 1951 information about the claimed client address (IP and port), a 1952 timestamp, and any other supplementary information the server will 1953 need to validate the token in the future. 1955 The Retry packet is sent to the client and a legitimate client will 1956 respond with an Initial packet containing the token from the Retry 1957 packet when it continues the handshake. In response to receiving the 1958 token, a server can either abort the connection or permit it to 1959 proceed. 1961 A connection MAY be accepted without address validation - or with 1962 only limited validation - but a server SHOULD limit the data it sends 1963 toward an unvalidated address. Successful completion of the 1964 cryptographic handshake implicitly provides proof that the client has 1965 received packets from the server. 1967 The client should allow for additional Retry packets being sent in 1968 response to Initial packets sent containing a token. There are 1969 several situations in which the server might not be able to use the 1970 previously generated token to validate the client's address and must 1971 send a new Retry. A reasonable limit to the number of tries the 1972 client allows for, before giving up, is 3. That is, the client MUST 1973 echo the address validation token from a new Retry packet up to 3 1974 times. After that, it MAY give up on the connection attempt. 1976 6.9.2. Address Validation for Future Connections 1978 A server MAY provide clients with an address validation token during 1979 one connection that can be used on a subsequent connection. Address 1980 validation is especially important with 0-RTT because a server 1981 potentially sends a significant amount of data to a client in 1982 response to 0-RTT data. 1984 The server uses the NEW_TOKEN frame Section 7.19 to provide the 1985 client with an address validation token that can be used to validate 1986 future connections. The client may then use this token to validate 1987 future connections by including it in the Initial packet's header. 1988 The client MUST NOT use the token provided in a Retry for future 1989 connections. 1991 Unlike the token that is created for a Retry packet, there might be 1992 some time between when the token is created and when the token is 1993 subsequently used. Thus, a resumption token SHOULD include an 1994 expiration time. The server MAY include either an explicit 1995 expiration time or an issued timestamp and dynamically calculate the 1996 expiration time. It is also unlikely that the client port number is 1997 the same on two different connections; validating the port is 1998 therefore unlikely to be successful. 2000 6.9.3. Address Validation Token Integrity 2002 An address validation token MUST be difficult to guess. Including a 2003 large enough random value in the token would be sufficient, but this 2004 depends on the server remembering the value it sends to clients. 2006 A token-based scheme allows the server to offload any state 2007 associated with validation to the client. For this design to work, 2008 the token MUST be covered by integrity protection against 2009 modification or falsification by clients. Without integrity 2010 protection, malicious clients could generate or guess values for 2011 tokens that would be accepted by the server. Only the server 2012 requires access to the integrity protection key for tokens. 2014 6.10. Path Validation 2016 Path validation is used by an endpoint to verify reachability of a 2017 peer over a specific path. That is, it tests reachability between a 2018 specific local address and a specific peer address, where an address 2019 is the two-tuple of IP address and port. Path validation tests that 2020 packets can be both sent to and received from a peer. 2022 Path validation is used during connection migration (see Section 6.11 2023 and Section 6.12) by the migrating endpoint to verify reachability of 2024 a peer from a new local address. Path validation is also used by the 2025 peer to verify that the migrating endpoint is able to receive packets 2026 sent to the its new address. That is, that the packets received from 2027 the migrating endpoint do not carry a spoofed source address. 2029 Path validation can be used at any time by either endpoint. For 2030 instance, an endpoint might check that a peer is still in possession 2031 of its address after a period of quiescence. 2033 Path validation is not designed as a NAT traversal mechanism. Though 2034 the mechanism described here might be effective for the creation of 2035 NAT bindings that support NAT traversal, the expectation is that one 2036 or other peer is able to receive packets without first having sent a 2037 packet on that path. Effective NAT traversal needs additional 2038 synchronization mechanisms that are not provided here. 2040 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 2041 are used for path validation with other frames. For instance, an 2042 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 2043 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 2044 PATH_CHALLENGE. 2046 6.10.1. Initiation 2048 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 2049 containing a random payload on the path to be validated. 2051 An endpoint MAY send additional PATH_CHALLENGE frames to handle 2052 packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more 2053 frequently than it would an Initial packet, ensuring that connection 2054 migration is no more load on a new path than establishing a new 2055 connection. 2057 The endpoint MUST use fresh random data in every PATH_CHALLENGE frame 2058 so that it can associate the peer's response with the causative 2059 PATH_CHALLENGE. 2061 6.10.2. Response 2063 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 2064 immediately by echoing the data contained in the PATH_CHALLENGE frame 2065 in a PATH_RESPONSE frame, with the following stipulation. Since a 2066 PATH_CHALLENGE might be sent from a spoofed address, an endpoint MAY 2067 limit the rate at which it sends PATH_RESPONSE frames and MAY 2068 silently discard PATH_CHALLENGE frames that would cause it to respond 2069 at a higher rate. 2071 To ensure that packets can be both sent to and received from the 2072 peer, the PATH_RESPONSE MUST be sent on the same path as the 2073 triggering PATH_CHALLENGE: from the same local address on which the 2074 PATH_CHALLENGE was received, to the same remote address from which 2075 the PATH_CHALLENGE was received. 2077 6.10.3. Completion 2079 A new address is considered valid when a PATH_RESPONSE frame is 2080 received containing data that was sent in a previous PATH_CHALLENGE. 2081 Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE 2082 frame is not adequate validation, since the acknowledgment can be 2083 spoofed by a malicious peer. 2085 For path validation to be successful, a PATH_RESPONSE frame MUST be 2086 received from the same remote address to which the corresponding 2087 PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a 2088 different remote address than the one to which the PATH_CHALLENGE was 2089 sent, path validation is considered to have failed, even if the data 2090 matches that sent in the PATH_CHALLENGE. 2092 Additionally, the PATH_RESPONSE frame MUST be received on the same 2093 local address from which the corresponding PATH_CHALLENGE was sent. 2094 If a PATH_RESPONSE frame is received on a different local address 2095 than the one from which the PATH_CHALLENGE was sent, path validation 2096 is considered to have failed, even if the data matches that sent in 2097 the PATH_CHALLENGE. Thus, the endpoint considers the path to be 2098 valid when a PATH_RESPONSE frame is received on the same path with 2099 the same payload as the PATH_CHALLENGE frame. 2101 6.10.4. Abandonment 2103 An endpoint SHOULD abandon path validation after sending some number 2104 of PATH_CHALLENGE frames or after some time has passed. When setting 2105 this timer, implementations are cautioned that the new path could 2106 have a longer round-trip time than the original. 2108 Note that the endpoint might receive packets containing other frames 2109 on the new path, but a PATH_RESPONSE frame with appropriate data is 2110 required for path validation to succeed. 2112 If path validation fails, the path is deemed unusable. This does not 2113 necessarily imply a failure of the connection - endpoints can 2114 continue sending packets over other paths as appropriate. If no 2115 paths are available, an endpoint can wait for a new path to become 2116 available or close the connection. 2118 A path validation might be abandoned for other reasons besides 2119 failure. Primarily, this happens if a connection migration to a new 2120 path is initiated while a path validation on the old path is in 2121 progress. 2123 6.11. Connection Migration 2125 QUIC allows connections to survive changes to endpoint addresses 2126 (that is, IP address and/or port), such as those caused by a endpoint 2127 migrating to a new network. This section describes the process by 2128 which an endpoint migrates to a new address. 2130 An endpoint MUST NOT initiate connection migration before the 2131 handshake is finished and the endpoint has 1-RTT keys. An endpoint 2132 also MUST NOT initiate connection migration if the peer sent the 2133 "disable_migration" transport parameter during the handshake. An 2134 endpoint which has sent this transport parameter, but detects that a 2135 peer has nonetheless migrated to a different network MAY treat this 2136 as a connection error of type INVALID_MIGRATION. However, note that 2137 not all changes of peer address are intentional migrations. The peer 2138 could experience an unintended change of address due to NAT 2139 rebinding; endpoints SHOULD perform path validation (Section 6.10) if 2140 the rebinding does not cause the connection to fail. 2142 This document limits migration of connections to new client 2143 addresses, except as described in Section 6.12. Clients are 2144 responsible for initiating all migrations. Servers do not send non- 2145 probing packets (see Section 6.11.1) toward a client address until it 2146 sees a non-probing packet from that address. If a client receives 2147 packets from an unknown server address, the client MAY discard these 2148 packets. 2150 6.11.1. Probing a New Path 2152 An endpoint MAY probe for peer reachability from a new local address 2153 using path validation Section 6.10 prior to migrating the connection 2154 to the new local address. Failure of path validation simply means 2155 that the new path is not usable for this connection. Failure to 2156 validate a path does not cause the connection to end unless there are 2157 no valid alternative paths available. 2159 An endpoint uses a new connection ID for probes sent from a new local 2160 address, see Section 6.11.5 for further discussion. 2162 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2163 is probing for reachability on a path. An endpoint sends a 2164 PATH_RESPONSE in response as per Section 6.10. 2166 PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are "probing 2167 frames", and all other frames are "non-probing frames". A packet 2168 containing only probing frames is a "probing packet", and a packet 2169 containing any other frame is a "non-probing packet". 2171 6.11.2. Initiating Connection Migration 2173 A endpoint can migrate a connection to a new local address by sending 2174 packets containing frames other than probing frames from that 2175 address. 2177 Each endpoint validates its peer's address during connection 2178 establishment. Therefore, a migrating endpoint can send to its peer 2179 knowing that the peer is willing to receive at the peer's current 2180 address. Thus an endpoint can migrate to a new local address without 2181 first validating the peer's address. 2183 When migrating, the new path might not support the endpoint's current 2184 sending rate. Therefore, the endpoint resets its congestion 2185 controller, as described in Section 6.11.4. 2187 The new path might not have the same ECN capability. Therefore, the 2188 endpoint verifies ECN capability as described in Section 6.8. 2190 Receiving acknowledgments for data sent on the new path serves as 2191 proof of the peer's reachability from the new address. Note that 2192 since acknowledgments may be received on any path, return 2193 reachability on the new path is not established. To establish return 2194 reachability on the new path, an endpoint MAY concurrently initiate 2195 path validation Section 6.10 on the new path. 2197 6.11.3. Responding to Connection Migration 2199 Receiving a packet from a new peer address containing a non-probing 2200 frame indicates that the peer has migrated to that address. 2202 In response to such a packet, an endpoint MUST start sending 2203 subsequent packets to the new peer address and MUST initiate path 2204 validation (Section 6.10) to verify the peer's ownership of the 2205 unvalidated address. 2207 An endpoint MAY send data to an unvalidated peer address, but it MUST 2208 protect against potential attacks as described in Section 6.11.3.1 2209 and Section 6.11.3.2. An endpoint MAY skip validation of a peer 2210 address if that address has been seen recently. 2212 An endpoint only changes the address that it sends packets to in 2213 response to the highest-numbered non-probing packet. This ensures 2214 that an endpoint does not send packets to an old peer address in the 2215 case that it receives reordered packets. 2217 After changing the address to which it sends non-probing packets, an 2218 endpoint could abandon any path validation for other addresses. 2220 Receiving a packet from a new peer address might be the result of a 2221 NAT rebinding at the peer. 2223 After verifying a new client address, the server SHOULD send new 2224 address validation tokens (Section 6.9) to the client. 2226 6.11.3.1. Handling Address Spoofing by a Peer 2228 It is possible that a peer is spoofing its source address to cause an 2229 endpoint to send excessive amounts of data to an unwilling host. If 2230 the endpoint sends significantly more data than the spoofing peer, 2231 connection migration might be used to amplify the volume of data that 2232 an attacker can generate toward a victim. 2234 As described in Section 6.11.3, an endpoint is required to validate a 2235 peer's new address to confirm the peer's possession of the new 2236 address. Until a peer's address is deemed valid, an endpoint MUST 2237 limit the rate at which it sends data to this address. The endpoint 2238 MUST NOT send more than a minimum congestion window's worth of data 2239 per estimated round-trip time (kMinimumWindow, as defined in 2240 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2241 being used for a denial of service attack against an unsuspecting 2242 victim. Note that since the endpoint will not have any round-trip 2243 time measurements to this address, the estimate SHOULD be the default 2244 initial value (see [QUIC-RECOVERY]). 2246 If an endpoint skips validation of a peer address as described in 2247 Section 6.11.3, it does not need to limit its sending rate. 2249 6.11.3.2. Handling Address Spoofing by an On-path Attacker 2251 An on-path attacker could cause a spurious connection migration by 2252 copying and forwarding a packet with a spoofed address such that it 2253 arrives before the original packet. The packet with the spoofed 2254 address will be seen to come from a migrating connection, and the 2255 original packet will be seen as a duplicate and dropped. After a 2256 spurious migration, validation of the source address will fail 2257 because the entity at the source address does not have the necessary 2258 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2259 that is sent to it even if it wanted to. 2261 To protect the connection from failing due to such a spurious 2262 migration, an endpoint MUST revert to using the last validated peer 2263 address when validation of a new peer address fails. 2265 If an endpoint has no state about the last validated peer address, it 2266 MUST close the connection silently by discarding all connection 2267 state. This results in new packets on the connection being handled 2268 generically. For instance, an endpoint MAY send a stateless reset in 2269 response to any further incoming packets. 2271 Note that receipt of packets with higher packet numbers from the 2272 legitimate peer address will trigger another connection migration. 2273 This will cause the validation of the address of the spurious 2274 migration to be abandoned. 2276 6.11.4. Loss Detection and Congestion Control 2278 The capacity available on the new path might not be the same as the 2279 old path. Packets sent on the old path SHOULD NOT contribute to 2280 congestion control or RTT estimation for the new path. 2282 On confirming a peer's ownership of its new address, an endpoint 2283 SHOULD immediately reset the congestion controller and round-trip 2284 time estimator for the new path. 2286 An endpoint MUST NOT return to the send rate used for the previous 2287 path unless it is reasonably sure that the previous send rate is 2288 valid for the new path. For instance, a change in the client's port 2289 number is likely indicative of a rebinding in a middlebox and not a 2290 complete change in path. This determination likely depends on 2291 heuristics, which could be imperfect; if the new path capacity is 2292 significantly reduced, ultimately this relies on the congestion 2293 controller responding to congestion signals and reducing send rates 2294 appropriately. 2296 There may be apparent reordering at the receiver when an endpoint 2297 sends data and probes from/to multiple addresses during the migration 2298 period, since the two resulting paths may have different round-trip 2299 times. A receiver of packets on multiple paths will still send ACK 2300 frames covering all received packets. 2302 While multiple paths might be used during connection migration, a 2303 single congestion control context and a single loss recovery context 2304 (as described in [QUIC-RECOVERY]) may be adequate. A sender can make 2305 exceptions for probe packets so that their loss detection is 2306 independent and does not unduly cause the congestion controller to 2307 reduce its sending rate. An endpoint might arm a separate alarm when 2308 a PATH_CHALLENGE is sent, which is disarmed when the corresponding 2309 PATH_RESPONSE is received. If the alarm fires before the 2310 PATH_RESPONSE is received, the endpoint might send a new 2311 PATH_CHALLENGE, and restart the alarm for a longer period of time. 2313 6.11.5. Privacy Implications of Connection Migration 2315 Using a stable connection ID on multiple network paths allows a 2316 passive observer to correlate activity between those paths. An 2317 endpoint that moves between networks might not wish to have their 2318 activity correlated by any entity other than their peer, so different 2319 connection IDs are used when sending from different local addresses, 2320 as discussed in Section 6.1. 2322 This eliminates the use of the connection ID for linking activity 2323 from the same connection on different networks. Protection of packet 2324 numbers ensures that packet numbers cannot be used to correlate 2325 activity. This does not prevent other properties of packets, such as 2326 timing and size, from being used to correlate activity. 2328 Clients MAY move to a new connection ID at any time based on 2329 implementation-specific concerns. For example, after a period of 2330 network inactivity NAT rebinding might occur when the client begins 2331 sending data again. 2333 A client might wish to reduce linkability by employing a new 2334 connection ID and source UDP port when sending traffic after a period 2335 of inactivity. Changing the UDP port from which it sends packets at 2336 the same time might cause the packet to appear as a connection 2337 migration. This ensures that the mechanisms that support migration 2338 are exercised even for clients that don't experience NAT rebindings 2339 or genuine migrations. Changing port number can cause a peer to 2340 reset its congestion state (see Section 6.11.4), so the port SHOULD 2341 only be changed infrequently. 2343 6.12. Server's Preferred Address 2345 QUIC allows servers to accept connections on one IP address and 2346 attempt to transfer these connections to a more preferred address 2347 shortly after the handshake. This is particularly useful when 2348 clients initially connect to an address shared by multiple servers 2349 but would prefer to use a unicast address to ensure connection 2350 stability. This section describes the protocol for migrating a 2351 connection to a preferred server address. 2353 Migrating a connection to a new server address mid-connection is left 2354 for future work. If a client receives packets from a new server 2355 address not indicated by the preferred_address transport parameter, 2356 the client SHOULD discard these packets. 2358 6.12.1. Communicating A Preferred Address 2360 A server conveys a preferred address by including the 2361 preferred_address transport parameter in the TLS handshake. 2363 Once the handshake is finished, the client SHOULD initiate path 2364 validation (see Section 6.10) of the server's preferred address using 2365 the connection ID provided in the preferred_address transport 2366 parameter. 2368 If path validation succeeds, the client SHOULD immediately begin 2369 sending all future packets to the new server address using the new 2370 connection ID and discontinue use of the old server address. If path 2371 validation fails, the client MUST continue sending all future packets 2372 to the server's original IP address. 2374 6.12.2. Responding to Connection Migration 2376 A server might receive a packet addressed to its preferred IP address 2377 at any time after the handshake is completed. If this packet 2378 contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE 2379 frame as per Section 6.10, but the server MUST continue sending all 2380 other packets from its original IP address. 2382 The server SHOULD also initiate path validation of the client using 2383 its preferred address and the address from which it received the 2384 client probe. This helps to guard against spurious migration 2385 initiated by an attacker. 2387 Once the server has completed its path validation and has received a 2388 non-probing packet with a new largest packet number on its preferred 2389 address, the server begins sending to the client exclusively from its 2390 preferred IP address. It SHOULD drop packets for this connection 2391 received on the old IP address, but MAY continue to process delayed 2392 packets. 2394 6.12.3. Interaction of Client Migration and Preferred Address 2396 A client might need to perform a connection migration before it has 2397 migrated to the server's preferred address. In this case, the client 2398 SHOULD perform path validation to both the original and preferred 2399 server address from the client's new address concurrently. 2401 If path validation of the server's preferred address succeeds, the 2402 client MUST abandon validation of the original address and migrate to 2403 using the server's preferred address. If path validation of the 2404 server's preferred address fails, but validation of the server's 2405 original address succeeds, the client MAY migrate to using the 2406 original address from the client's new address. 2408 If the connection to the server's preferred address is not from the 2409 same client address, the server MUST protect against potential 2410 attacks as described in Section 6.11.3.1 and Section 6.11.3.2. In 2411 addition to intentional simultaneous migration, this might also occur 2412 because the client's access network used a different NAT binding for 2413 the server's preferred address. 2415 Servers SHOULD initiate path validation to the client's new address 2416 upon receiving a probe packet from a different address. Servers MUST 2417 NOT send more than a minimum congestion window's worth of non-probing 2418 packets to the new address before path validation is complete. 2420 6.13. Connection Termination 2422 Connections should remain open until they become idle for a pre- 2423 negotiated period of time. A QUIC connection, once established, can 2424 be terminated in one of three ways: 2426 o idle timeout (Section 6.13.2) 2428 o immediate close (Section 6.13.3) 2430 o stateless reset (Section 6.13.4) 2432 6.13.1. Closing and Draining Connection States 2434 The closing and draining connection states exist to ensure that 2435 connections close cleanly and that delayed or reordered packets are 2436 properly discarded. These states SHOULD persist for three times the 2437 current Retransmission Timeout (RTO) interval as defined in 2438 [QUIC-RECOVERY]. 2440 An endpoint enters a closing period after initiating an immediate 2441 close (Section 6.13.3). While closing, an endpoint MUST NOT send 2442 packets unless they contain a CONNECTION_CLOSE or APPLICATION_CLOSE 2443 frame (see Section 6.13.3 for details). 2445 In the closing state, only a packet containing a closing frame can be 2446 sent. An endpoint retains only enough information to generate a 2447 packet containing a closing frame and to identify packets as 2448 belonging to the connection. The connection ID and QUIC version is 2449 sufficient information to identify packets for a closing connection; 2450 an endpoint can discard all other connection state. An endpoint MAY 2451 retain packet protection keys for incoming packets to allow it to 2452 read and process a closing frame. 2454 The draining state is entered once an endpoint receives a signal that 2455 its peer is closing or draining. While otherwise identical to the 2456 closing state, an endpoint in the draining state MUST NOT send any 2457 packets. Retaining packet protection keys is unnecessary once a 2458 connection is in the draining state. 2460 An endpoint MAY transition from the closing period to the draining 2461 period if it can confirm that its peer is also closing or draining. 2462 Receiving a closing frame is sufficient confirmation, as is receiving 2463 a stateless reset. The draining period SHOULD end when the closing 2464 period would have ended. In other words, the endpoint can use the 2465 same end time, but cease retransmission of the closing packet. 2467 Disposing of connection state prior to the end of the closing or 2468 draining period could cause delayed or reordered packets to be 2469 handled poorly. Endpoints that have some alternative means to ensure 2470 that late-arriving packets on the connection do not create QUIC 2471 state, such as those that are able to close the UDP socket, MAY use 2472 an abbreviated draining period which can allow for faster resource 2473 recovery. Servers that retain an open socket for accepting new 2474 connections SHOULD NOT exit the closing or draining period early. 2476 Once the closing or draining period has ended, an endpoint SHOULD 2477 discard all connection state. This results in new packets on the 2478 connection being handled generically. For instance, an endpoint MAY 2479 send a stateless reset in response to any further incoming packets. 2481 The draining and closing periods do not apply when a stateless reset 2482 (Section 6.13.4) is sent. 2484 An endpoint is not expected to handle key updates when it is closing 2485 or draining. A key update might prevent the endpoint from moving 2486 from the closing state to draining, but it otherwise has no impact. 2488 An endpoint could receive packets from a new source address, 2489 indicating a client connection migration (Section 6.11), while in the 2490 closing period. An endpoint in the closing state MUST strictly limit 2491 the number of packets it sends to this new address until the address 2492 is validated (see Section 6.10). A server in the closing state MAY 2493 instead choose to discard packets received from a new source address. 2495 6.13.2. Idle Timeout 2497 A connection that remains idle for longer than the idle timeout (see 2498 Section 6.6.1) is closed. A connection enters the draining state 2499 when the idle timeout expires. 2501 The time at which an idle timeout takes effect won't be perfectly 2502 synchronized on both endpoints. An endpoint that sends packets near 2503 the end of an idle period could have those packets discarded if its 2504 peer enters the draining state before the packet is received. 2506 6.13.3. Immediate Close 2508 An endpoint sends a closing frame (CONNECTION_CLOSE or 2509 APPLICATION_CLOSE) to terminate the connection immediately. Any 2510 closing frame causes all streams to immediately become closed; open 2511 streams can be assumed to be implicitly reset. 2513 After sending a closing frame, endpoints immediately enter the 2514 closing state. During the closing period, an endpoint that sends a 2515 closing frame SHOULD respond to any packet that it receives with 2516 another packet containing a closing frame. To minimize the state 2517 that an endpoint maintains for a closing connection, endpoints MAY 2518 send the exact same packet. However, endpoints SHOULD limit the 2519 number of packets they generate containing a closing frame. For 2520 instance, an endpoint could progressively increase the number of 2521 packets that it receives before sending additional packets or 2522 increase the time between packets. 2524 Note: Allowing retransmission of a packet contradicts other advice 2525 in this document that recommends the creation of new packet 2526 numbers for every packet. Sending new packet numbers is primarily 2527 of advantage to loss recovery and congestion control, which are 2528 not expected to be relevant for a closed connection. 2529 Retransmitting the final packet requires less state. 2531 After receiving a closing frame, endpoints enter the draining state. 2532 An endpoint that receives a closing frame MAY send a single packet 2533 containing a closing frame before entering the draining state, using 2534 a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An 2535 endpoint MUST NOT send further packets, which could result in a 2536 constant exchange of closing frames until the closing period on 2537 either peer ended. 2539 An immediate close can be used after an application protocol has 2540 arranged to close a connection. This might be after the application 2541 protocols negotiates a graceful shutdown. The application protocol 2542 exchanges whatever messages that are needed to cause both endpoints 2543 to agree to close the connection, after which the application 2544 requests that the connection be closed. The application protocol can 2545 use an APPLICATION_CLOSE message with an appropriate error code to 2546 signal closure. 2548 6.13.4. Stateless Reset 2550 A stateless reset is provided as an option of last resort for an 2551 endpoint that does not have access to the state of a connection. A 2552 crash or outage might result in peers continuing to send data to an 2553 endpoint that is unable to properly continue the connection. An 2554 endpoint that wishes to communicate a fatal connection error MUST use 2555 a closing frame if it has sufficient state to do so. 2557 To support this process, a token is sent by endpoints. The token is 2558 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2559 servers can specify the stateless_reset_token transport parameter 2560 during the handshake (clients cannot because their transport 2561 parameters don't have confidentiality protection). This value is 2562 protected by encryption, so only client and server know this value. 2564 An endpoint that receives packets that it cannot process sends a 2565 packet in the following layout: 2567 0 1 2 3 2568 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 2569 +-+-+-+-+-+-+-+-+ 2570 |0|K|1|1|0|0|0|0| 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | Random Octets (160..) ... 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 | | 2575 + + 2576 | | 2577 + Stateless Reset Token (128) + 2578 | | 2579 + + 2580 | | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 This design ensures that a stateless reset packet is - to the extent 2584 possible - indistinguishable from a regular packet with a short 2585 header. 2587 The message consists of a header octet, followed by random octets of 2588 arbitrary length, followed by a Stateless Reset Token. 2590 A stateless reset will be interpreted by a recipient as a packet with 2591 a short header. For the packet to appear as valid, the Random Octets 2592 field needs to include at least 20 octets of random or unpredictable 2593 values. This is intended to allow for a destination connection ID of 2594 the maximum length permitted, a packet number, and minimal payload. 2595 The Stateless Reset Token corresponds to the minimum expansion of the 2596 packet protection AEAD. More random octets might be necessary if the 2597 endpoint could have negotiated a packet protection scheme with a 2598 larger minimum AEAD expansion. 2600 An endpoint SHOULD NOT send a stateless reset that is significantly 2601 larger than the packet it receives. Endpoints MUST discard packets 2602 that are too small to be valid QUIC packets. With the set of AEAD 2603 functions defined in [QUIC-TLS], packets less than 19 octets long are 2604 never valid. 2606 An endpoint cannot determine the Source Connection ID from a packet 2607 with a short header, therefore it cannot set the Destination 2608 Connection ID in the stateless reset packet. The destination 2609 connection ID will therefore differ from the value used in previous 2610 packets. A random Destination Connection ID makes the connection ID 2611 appear to be the result of moving to a new connection ID that was 2612 provided using a NEW_CONNECTION_ID frame (Section 7.13). 2614 Using a randomized connection ID results in two problems: 2616 o The packet might not reach the peer. If the Destination 2617 Connection ID is critical for routing toward the peer, then this 2618 packet could be incorrectly routed. This causes the stateless 2619 reset to be ineffective in causing errors to be quickly detected 2620 and recovered. In this case, endpoints will need to rely on other 2621 methods - such as timers - to detect that the connection has 2622 failed. 2624 o The randomly generated connection ID can be used by entities other 2625 than the peer to identify this as a potential stateless reset. An 2626 endpoint that occasionally uses different connection IDs might 2627 introduce some uncertainty about this. 2629 Finally, the last 16 octets of the packet are set to the value of the 2630 Stateless Reset Token. 2632 A stateless reset is not appropriate for signaling error conditions. 2633 An endpoint that wishes to communicate a fatal connection error MUST 2634 use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has 2635 sufficient state to do so. 2637 This stateless reset design is specific to QUIC version 1. An 2638 endpoint that supports multiple versions of QUIC needs to generate a 2639 stateless reset that will be accepted by peers that support any 2640 version that the endpoint might support (or might have supported 2641 prior to losing state). Designers of new versions of QUIC need to be 2642 aware of this and either reuse this design, or use a portion of the 2643 packet other than the last 16 octets for carrying data. 2645 6.13.4.1. Detecting a Stateless Reset 2647 An endpoint detects a potential stateless reset when a packet with a 2648 short header either cannot be decrypted or is marked as a duplicate 2649 packet. The endpoint then compares the last 16 octets of the packet 2650 with the Stateless Reset Token provided by its peer, either in a 2651 NEW_CONNECTION_ID frame or the server's transport parameters. If 2652 these values are identical, the endpoint MUST enter the draining 2653 period and not send any further packets on this connection. If the 2654 comparison fails, the packet can be discarded. 2656 6.13.4.2. Calculating a Stateless Reset Token 2658 The stateless reset token MUST be difficult to guess. In order to 2659 create a Stateless Reset Token, an endpoint could randomly generate 2660 [RFC4086] a secret for every connection that it creates. However, 2661 this presents a coordination problem when there are multiple 2662 instances in a cluster or a storage problem for a endpoint that might 2663 lose state. Stateless reset specifically exists to handle the case 2664 where state is lost, so this approach is suboptimal. 2666 A single static key can be used across all connections to the same 2667 endpoint by generating the proof using a second iteration of a 2668 preimage-resistant function that takes three inputs: the static key, 2669 the connection ID chosen by the endpoint (see Section 6.1), and an 2670 instance identifier. An endpoint could use HMAC [RFC2104] (for 2671 example, HMAC(static_key, instance_id || connection_id)) or HKDF 2672 [RFC5869] (for example, using the static key as input keying 2673 material, with instance and connection identifiers as salt). The 2674 output of this function is truncated to 16 octets to produce the 2675 Stateless Reset Token for that connection. 2677 An endpoint that loses state can use the same method to generate a 2678 valid Stateless Reset Token. The connection ID comes from the packet 2679 that the endpoint receives. An instance that receives a packet for 2680 another instance might be able to recover the instance identifier 2681 using the connection ID. Alternatively, the instance identifier 2682 might be omitted from the calculation of the Stateless Reset Token so 2683 that all instances are equally able to generate a stateless reset. 2685 This design relies on the peer always sending a connection ID in its 2686 packets so that the endpoint can use the connection ID from a packet 2687 to reset the connection. An endpoint that uses this design cannot 2688 allow its peers to send packets with a zero-length destination 2689 connection ID. 2691 Revealing the Stateless Reset Token allows any entity to terminate 2692 the connection, so a value can only be used once. This method for 2693 choosing the Stateless Reset Token means that the combination of 2694 instance, connection ID, and static key cannot occur for another 2695 connection. A connection ID from a connection that is reset by 2696 revealing the Stateless Reset Token cannot be reused for new 2697 connections at the same instance without first changing to use a 2698 different static key or instance identifier. 2700 Note that Stateless Reset messages do not have any cryptographic 2701 protection. 2703 7. Frame Types and Formats 2705 As described in Section 5, packets contain one or more frames. This 2706 section describes the format and semantics of the core QUIC frame 2707 types. 2709 7.1. Variable-Length Integer Encoding 2711 QUIC frames commonly use a variable-length encoding for non-negative 2712 integer values. This encoding ensures that smaller integer values 2713 need fewer octets to encode. 2715 The QUIC variable-length integer encoding reserves the two most 2716 significant bits of the first octet to encode the base 2 logarithm of 2717 the integer encoding length in octets. The integer value is encoded 2718 on the remaining bits, in network byte order. 2720 This means that integers are encoded on 1, 2, 4, or 8 octets and can 2721 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 2722 the encoding properties. 2724 +------+--------+-------------+-----------------------+ 2725 | 2Bit | Length | Usable Bits | Range | 2726 +------+--------+-------------+-----------------------+ 2727 | 00 | 1 | 6 | 0-63 | 2728 | | | | | 2729 | 01 | 2 | 14 | 0-16383 | 2730 | | | | | 2731 | 10 | 4 | 30 | 0-1073741823 | 2732 | | | | | 2733 | 11 | 8 | 62 | 0-4611686018427387903 | 2734 +------+--------+-------------+-----------------------+ 2736 Table 4: Summary of Integer Encodings 2738 For example, the eight octet sequence c2 19 7c 5e ff 14 e8 8c (in 2739 hexadecimal) decodes to the decimal value 151288809941952652; the 2740 four octet sequence 9d 7f 3e 7d decodes to 494878333; the two octet 2741 sequence 7b bd decodes to 15293; and the single octet 25 decodes to 2742 37 (as does the two octet sequence 40 25). 2744 Error codes (Section 11.3) are described using integers, but do not 2745 use this encoding. 2747 7.2. PADDING Frame 2749 The PADDING frame (type=0x00) has no semantic value. PADDING frames 2750 can be used to increase the size of a packet. Padding can be used to 2751 increase an initial client packet to the minimum required size, or to 2752 provide protection against traffic analysis for protected packets. 2754 A PADDING frame has no content. That is, a PADDING frame consists of 2755 the single octet that identifies the frame as a PADDING frame. 2757 7.3. RST_STREAM Frame 2759 An endpoint may use a RST_STREAM frame (type=0x01) to abruptly 2760 terminate a stream. 2762 After sending a RST_STREAM, an endpoint ceases transmission and 2763 retransmission of STREAM frames on the identified stream. A receiver 2764 of RST_STREAM can discard any data that it already received on that 2765 stream. 2767 An endpoint that receives a RST_STREAM frame for a send-only stream 2768 MUST terminate the connection with error PROTOCOL_VIOLATION. 2770 The RST_STREAM frame is as follows: 2772 0 1 2 3 2773 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 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | Stream ID (i) ... 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | Application Error Code (16) | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Final Offset (i) ... 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 The fields are: 2784 Stream ID: A variable-length integer encoding of the Stream ID of 2785 the stream being terminated. 2787 Application Protocol Error Code: A 16-bit application protocol error 2788 code (see Section 11.4) which indicates why the stream is being 2789 closed. 2791 Final Offset: A variable-length integer indicating the absolute byte 2792 offset of the end of data written on this stream by the RST_STREAM 2793 sender. 2795 7.4. CONNECTION_CLOSE frame 2797 An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its 2798 peer that the connection is being closed. CONNECTION_CLOSE is used 2799 to signal errors at the QUIC layer, or the absence of errors (with 2800 the NO_ERROR code). 2802 If there are open streams that haven't been explicitly closed, they 2803 are implicitly closed when the connection is closed. 2805 The CONNECTION_CLOSE frame is as follows: 2807 0 1 2 3 2808 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 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | Error Code (16) | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | Frame Type (i) ... 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | Reason Phrase Length (i) ... 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 | Reason Phrase (*) ... 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 The fields of a CONNECTION_CLOSE frame are as follows: 2821 Error Code: A 16-bit error code which indicates the reason for 2822 closing this connection. CONNECTION_CLOSE uses codes from the 2823 space defined in Section 11.3 (APPLICATION_CLOSE uses codes from 2824 the application protocol error code space, see Section 11.4). 2826 Frame Type: The type of frame that triggered the error. A value of 2827 0 (equivalent to the mention of the PADDING frame) is used when 2828 the frame type is unknown. 2830 Reason Phrase Length: A variable-length integer specifying the 2831 length of the reason phrase in bytes. Note that a 2832 CONNECTION_CLOSE frame cannot be split between packets, so in 2833 practice any limits on packet size will also limit the space 2834 available for a reason phrase. 2836 Reason Phrase: A human-readable explanation for why the connection 2837 was closed. This can be zero length if the sender chooses to not 2838 give details beyond the Error Code. This SHOULD be a UTF-8 2839 encoded string [RFC3629]. 2841 7.5. APPLICATION_CLOSE frame 2843 An APPLICATION_CLOSE frame (type=0x03) uses the same format as the 2844 CONNECTION_CLOSE frame (Section 7.4), except that it uses error codes 2845 from the application protocol error code space (Section 11.4) instead 2846 of the transport error code space. 2848 Other than the error code space, the format and semantics of the 2849 APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame. 2851 7.6. MAX_DATA Frame 2853 The MAX_DATA frame (type=0x04) is used in flow control to inform the 2854 peer of the maximum amount of data that can be sent on the connection 2855 as a whole. 2857 The frame is as follows: 2859 0 1 2 3 2860 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 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | Maximum Data (i) ... 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 The fields in the MAX_DATA frame are as follows: 2867 Maximum Data: A variable-length integer indicating the maximum 2868 amount of data that can be sent on the entire connection, in units 2869 of octets. 2871 All data sent in STREAM frames counts toward this limit. The sum of 2872 the largest received offsets on all streams - including streams in 2873 terminal states - MUST NOT exceed the value advertised by a receiver. 2874 An endpoint MUST terminate a connection with a 2875 QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more 2876 data than the maximum data value that it has sent, unless this is a 2877 result of a change in the initial limits (see Section 6.6.2). 2879 7.7. MAX_STREAM_DATA Frame 2881 The MAX_STREAM_DATA frame (type=0x05) is used in flow control to 2882 inform a peer of the maximum amount of data that can be sent on a 2883 stream. 2885 An endpoint that receives a MAX_STREAM_DATA frame for a receive-only 2886 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 2888 An endpoint that receives a MAX_STREAM_DATA frame for a send-only 2889 stream it has not opened MUST terminate the connection with error 2890 PROTOCOL_VIOLATION. 2892 Note that an endpoint may legally receive a MAX_STREAM_DATA frame on 2893 a bidirectional stream it has not opened. 2895 The frame is as follows: 2897 0 1 2 3 2898 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 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 | Stream ID (i) ... 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | Maximum Stream Data (i) ... 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 The fields in the MAX_STREAM_DATA frame are as follows: 2907 Stream ID: The stream ID of the stream that is affected encoded as a 2908 variable-length integer. 2910 Maximum Stream Data: A variable-length integer indicating the 2911 maximum amount of data that can be sent on the identified stream, 2912 in units of octets. 2914 When counting data toward this limit, an endpoint accounts for the 2915 largest received offset of data that is sent or received on the 2916 stream. Loss or reordering can mean that the largest received offset 2917 on a stream can be greater than the total size of data received on 2918 that stream. Receiving STREAM frames might not increase the largest 2919 received offset. 2921 The data sent on a stream MUST NOT exceed the largest maximum stream 2922 data value advertised by the receiver. An endpoint MUST terminate a 2923 connection with a FLOW_CONTROL_ERROR error if it receives more data 2924 than the largest maximum stream data that it has sent for the 2925 affected stream, unless this is a result of a change in the initial 2926 limits (see Section 6.6.2). 2928 7.8. MAX_STREAM_ID Frame 2930 The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum 2931 stream ID that they are permitted to open. 2933 The frame is as follows: 2935 0 1 2 3 2936 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 2937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 | Maximum Stream ID (i) ... 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 The fields in the MAX_STREAM_ID frame are as follows: 2943 Maximum Stream ID: ID of the maximum unidirectional or bidirectional 2944 peer-initiated stream ID for the connection encoded as a variable- 2945 length integer. The limit applies to unidirectional steams if the 2946 second least signification bit of the stream ID is 1, and applies 2947 to bidirectional streams if it is 0. 2949 Loss or reordering can mean that a MAX_STREAM_ID frame can be 2950 received which states a lower stream limit than the client has 2951 previously received. MAX_STREAM_ID frames which do not increase the 2952 maximum stream ID MUST be ignored. 2954 A peer MUST NOT initiate a stream with a higher stream ID than the 2955 greatest maximum stream ID it has received. An endpoint MUST 2956 terminate a connection with a STREAM_ID_ERROR error if a peer 2957 initiates a stream with a higher stream ID than it has sent, unless 2958 this is a result of a change in the initial limits (see 2959 Section 6.6.2). 2961 7.9. PING Frame 2963 Endpoints can use PING frames (type=0x07) to verify that their peers 2964 are still alive or to check reachability to the peer. The PING frame 2965 contains no additional fields. 2967 The receiver of a PING frame simply needs to acknowledge the packet 2968 containing this frame. 2970 The PING frame can be used to keep a connection alive when an 2971 application or application protocol wishes to prevent the connection 2972 from timing out. An application protocol SHOULD provide guidance 2973 about the conditions under which generating a PING is recommended. 2974 This guidance SHOULD indicate whether it is the client or the server 2975 that is expected to send the PING. Having both endpoints send PING 2976 frames without coordination can produce an excessive number of 2977 packets and poor performance. 2979 A connection will time out if no packets are sent or received for a 2980 period longer than the time specified in the idle_timeout transport 2981 parameter (see Section 6.13). However, state in middleboxes might 2982 time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 2983 minute timeout interval, experience shows that sending packets every 2984 15 to 30 seconds is necessary to prevent the majority of middleboxes 2985 from losing state for UDP flows. 2987 7.10. BLOCKED Frame 2989 A sender SHOULD send a BLOCKED frame (type=0x08) when it wishes to 2990 send data, but is unable to due to connection-level flow control (see 2991 Section 10.2.1). BLOCKED frames can be used as input to tuning of 2992 flow control algorithms (see Section 10.1.2). 2994 The BLOCKED frame is as follows: 2996 0 1 2 3 2997 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 2998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2999 | Offset (i) ... 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 The BLOCKED frame contains a single field. 3004 Offset: A variable-length integer indicating the connection-level 3005 offset at which the blocking occurred. 3007 7.11. STREAM_BLOCKED Frame 3009 A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it 3010 wishes to send data, but is unable to due to stream-level flow 3011 control. This frame is analogous to BLOCKED (Section 7.10). 3013 An endpoint that receives a STREAM_BLOCKED frame for a send-only 3014 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 3016 The STREAM_BLOCKED frame is as follows: 3018 0 1 2 3 3019 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 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3021 | Stream ID (i) ... 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3023 | Offset (i) ... 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 The STREAM_BLOCKED frame contains two fields: 3028 Stream ID: A variable-length integer indicating the stream which is 3029 flow control blocked. 3031 Offset: A variable-length integer indicating the offset of the 3032 stream at which the blocking occurred. 3034 7.12. STREAM_ID_BLOCKED Frame 3036 A sender MAY send a STREAM_ID_BLOCKED frame (type=0x0a) when it 3037 wishes to open a stream, but is unable to due to the maximum stream 3038 ID limit set by its peer (see Section 7.8). This does not open the 3039 stream, but informs the peer that a new stream was needed, but the 3040 stream limit prevented the creation of the stream. 3042 The STREAM_ID_BLOCKED frame is as follows: 3044 0 1 2 3 3045 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 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3047 | Stream ID (i) ... 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3050 The STREAM_ID_BLOCKED frame contains a single field. 3052 Stream ID: A variable-length integer indicating the highest stream 3053 ID that the sender was permitted to open. 3055 7.13. NEW_CONNECTION_ID Frame 3057 An endpoint sends a NEW_CONNECTION_ID frame (type=0x0b) to provide 3058 its peer with alternative connection IDs that can be used to break 3059 linkability when migrating connections (see Section 6.11.5). 3061 The NEW_CONNECTION_ID is as follows: 3063 0 1 2 3 3064 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 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 | Sequence (i) ... 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 | Length (8) | Connection ID (32..144) ... 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 | | 3071 + + 3072 | | 3073 + Stateless Reset Token (128) + 3074 | | 3075 + + 3076 | | 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 The fields are: 3081 Sequence: A variable-length integer. This value starts at 0 and 3082 increases by 1 for each connection ID that is provided by the 3083 server. The connection ID that is assigned during the handshake 3084 is assumed to have a sequence of -1. That is, the value selected 3085 during the handshake comes immediately before the first value that 3086 a server can send. 3088 Length: An 8-bit unsigned integer containing the length of the 3089 connection ID. Values less than 4 and greater than 18 are invalid 3090 and MUST be treated as a connection error of type 3091 PROTOCOL_VIOLATION. 3093 Connection ID: A connection ID of the specified length. 3095 Stateless Reset Token: A 128-bit value that will be used to for a 3096 stateless reset when the associated connection ID is used (see 3097 Section 6.13.4). 3099 An endpoint MUST NOT send this frame if it currently requires that 3100 its peer send packets with a zero-length Destination Connection ID. 3101 Changing the length of a connection ID to or from zero-length makes 3102 it difficult to identify when the value of the connection ID changed. 3103 An endpoint that is sending packets with a zero-length Destination 3104 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 3105 connection error of type PROTOCOL_VIOLATION. 3107 7.14. STOP_SENDING Frame 3109 An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate 3110 that incoming data is being discarded on receipt at application 3111 request. This signals a peer to abruptly terminate transmission on a 3112 stream. 3114 Receipt of a STOP_SENDING frame is only valid for a send stream that 3115 exists and is not in the "Ready" state (see Section 9.2.1). 3116 Receiving a STOP_SENDING frame for a send stream that is "Ready" or 3117 non-existent MUST be treated as a connection error of type 3118 PROTOCOL_VIOLATION. An endpoint that receives a STOP_SENDING frame 3119 for a receive-only stream MUST terminate the connection with error 3120 PROTOCOL_VIOLATION. 3122 The STOP_SENDING frame is as follows: 3124 0 1 2 3 3125 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 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | Stream ID (i) ... 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3129 | Application Error Code (16) | 3130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 The fields are: 3134 Stream ID: A variable-length integer carrying the Stream ID of the 3135 stream being ignored. 3137 Application Error Code: A 16-bit, application-specified reason the 3138 sender is ignoring the stream (see Section 11.4). 3140 7.15. ACK Frame 3142 Receivers send ACK frames (type=0x0d) to inform senders which packets 3143 they have received and processed. The ACK frame contains any number 3144 of ACK blocks. ACK blocks are ranges of acknowledged packets. 3146 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 3147 remains acknowledged, even if it does not appear in a future ACK 3148 frame. This is unlike TCP SACKs ([RFC2018]). 3150 It is expected that a sender will reuse the same packet number across 3151 different packet number spaces. ACK frames only acknowledge the 3152 packet numbers that were transmitted by the sender in the same packet 3153 number space of the packet that the ACK was received in. 3155 A client MUST NOT acknowledge Retry packets. Retry packets include 3156 the packet number from the Initial packet it responds to. Version 3157 Negotiation packets cannot be acknowledged because they do not 3158 contain a packet number. Rather than relying on ACK frames, these 3159 packets are implicitly acknowledged by the next Initial packet sent 3160 by the client. 3162 An ACK frame is shown below. 3164 0 1 2 3 3165 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 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 | Largest Acknowledged (i) ... 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 | ACK Delay (i) ... 3170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 | ACK Block Count (i) ... 3172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 | ACK Blocks (*) ... 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3176 Figure 9: ACK Frame Format 3178 The fields in the ACK frame are as follows: 3180 Largest Acknowledged: A variable-length integer representing the 3181 largest packet number the peer is acknowledging; this is usually 3182 the largest packet number that the peer has received prior to 3183 generating the ACK frame. Unlike the packet number in the QUIC 3184 long or short header, the value in an ACK frame is not truncated. 3186 ACK Delay: A variable-length integer including the time in 3187 microseconds that the largest acknowledged packet, as indicated in 3188 the Largest Acknowledged field, was received by this peer to when 3189 this ACK was sent. The value of the ACK Delay field is scaled by 3190 multiplying the encoded value by the 2 to the power of the value 3191 of the "ack_delay_exponent" transport parameter set by the sender 3192 of the ACK frame. The "ack_delay_exponent" defaults to 3, or a 3193 multiplier of 8 (see Section 6.6.1). Scaling in this fashion 3194 allows for a larger range of values with a shorter encoding at the 3195 cost of lower resolution. 3197 ACK Block Count: The number of Additional ACK Block (and Gap) fields 3198 after the First ACK Block. 3200 ACK Blocks: Contains one or more blocks of packet numbers which have 3201 been successfully received, see Section 7.15.1. 3203 7.15.1. ACK Block Section 3205 The ACK Block Section consists of alternating Gap and ACK Block 3206 fields in descending packet number order. A First Ack Block field is 3207 followed by a variable number of alternating Gap and Additional ACK 3208 Blocks. The number of Gap and Additional ACK Block fields is 3209 determined by the ACK Block Count field. 3211 Gap and ACK Block fields use a relative integer encoding for 3212 efficiency. Though each encoded value is positive, the values are 3213 subtracted, so that each ACK Block describes progressively lower- 3214 numbered packets. As long as contiguous ranges of packets are small, 3215 the variable-length integer encoding ensures that each range can be 3216 expressed in a small number of octets. 3218 0 1 2 3 3219 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 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 | First ACK Block (i) ... 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 | Gap (i) ... 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 | Additional ACK Block (i) ... 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | Gap (i) ... 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Additional ACK Block (i) ... 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 ... 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | Gap (i) ... 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | Additional ACK Block (i) ... 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 Figure 10: ACK Block Section 3240 Each ACK Block acknowledges a contiguous range of packets by 3241 indicating the number of acknowledged packets that precede the 3242 largest packet number in that block. A value of zero indicates that 3243 only the largest packet number is acknowledged. Larger ACK Block 3244 values indicate a larger range, with corresponding lower values for 3245 the smallest packet number in the range. Thus, given a largest 3246 packet number for the ACK, the smallest value is determined by the 3247 formula: 3249 smallest = largest - ack_block 3251 The range of packets that are acknowledged by the ACK block include 3252 the range from the smallest packet number to the largest, inclusive. 3254 The largest value for the First ACK Block is determined by the 3255 Largest Acknowledged field; the largest for Additional ACK Blocks is 3256 determined by cumulatively subtracting the size of all preceding ACK 3257 Blocks and Gaps. 3259 Each Gap indicates a range of packets that are not being 3260 acknowledged. The number of packets in the gap is one higher than 3261 the encoded value of the Gap Field. 3263 The value of the Gap field establishes the largest packet number 3264 value for the ACK block that follows the gap using the following 3265 formula: 3267 largest = previous_smallest - gap - 2 3269 If the calculated value for largest or smallest packet number for any 3270 ACK Block is negative, an endpoint MUST generate a connection error 3271 of type FRAME_ENCODING_ERROR indicating an error in an ACK frame. 3273 The fields in the ACK Block Section are: 3275 First ACK Block: A variable-length integer indicating the number of 3276 contiguous packets preceding the Largest Acknowledged that are 3277 being acknowledged. 3279 Gap (repeated): A variable-length integer indicating the number of 3280 contiguous unacknowledged packets preceding the packet number one 3281 lower than the smallest in the preceding ACK Block. 3283 ACK Block (repeated): A variable-length integer indicating the 3284 number of contiguous acknowledged packets preceding the largest 3285 packet number, as determined by the preceding Gap. 3287 7.15.2. Sending ACK Frames 3289 Implementations MUST NOT generate packets that only contain ACK 3290 frames in response to packets which only contain ACK frames. 3291 However, they MUST acknowledge packets containing only ACK frames 3292 when sending ACK frames in response to other packets. 3293 Implementations MUST NOT send more than one packet containing only 3294 ACK frames per received packet that contains frames other than ACK 3295 frames. Packets containing non-ACK frames MUST be acknowledged 3296 immediately or when a delayed ack timer expires. 3298 To limit ACK blocks to those that have not yet been received by the 3299 sender, the receiver SHOULD track which ACK frames have been 3300 acknowledged by its peer. Once an ACK frame has been acknowledged, 3301 the packets it acknowledges SHOULD NOT be acknowledged again. 3303 Because ACK frames are not sent in response to ACK-only packets, a 3304 receiver that is only sending ACK frames will only receive 3305 acknowledgements for its packets if the sender includes them in 3306 packets with non-ACK frames. A sender SHOULD bundle ACK frames with 3307 other frames when possible. 3309 Endpoints can only acknowledge packets sent in a particular packet 3310 number space by sending ACK frames in packets from the same packet 3311 number space. 3313 To limit receiver state or the size of ACK frames, a receiver MAY 3314 limit the number of ACK blocks it sends. A receiver can do this even 3315 without receiving acknowledgment of its ACK frames, with the 3316 knowledge this could cause the sender to unnecessarily retransmit 3317 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 3318 lost after sufficiently newer packets are acknowledged. Therefore, 3319 the receiver SHOULD repeatedly acknowledge newly received packets in 3320 preference to packets received in the past. 3322 7.15.3. ACK Frames and Packet Protection 3324 ACK frames MUST only be carried in a packet that has the same packet 3325 number space as the packet being ACKed (see Section 4.5). For 3326 instance, packets that are protected with 1-RTT keys MUST be 3327 acknowledged in packets that are also protected with 1-RTT keys. 3329 Packets that a client sends with 0-RTT packet protection MUST be 3330 acknowledged by the server in packets protected by 1-RTT keys. This 3331 can mean that the client is unable to use these acknowledgments if 3332 the server cryptographic handshake messages are delayed or lost. 3333 Note that the same limitation applies to other data sent by the 3334 server protected by the 1-RTT keys. 3336 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3337 frames with a reduced delay; see Section 3.5.1 of [QUIC-RECOVERY]. 3339 7.16. ACK_ECN Frame 3341 The ACK_ECN frame (type=0x20) is used by an endpoint that supports 3342 ECN to acknowledge packets received with ECN codepoints of ECT(0), 3343 ECT(1), or CE in the packet's IP header. 3345 0 1 2 3 3346 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 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 | Largest Acknowledged (i) ... 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 | ACK Delay (i) ... 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3352 | ECT(0) Count (i) ... 3353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 | ECT(1) Count (i) ... 3355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3356 | ECN-CE Count (i) ... 3357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 | ACK Block Count (i) ... 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 | ACK Blocks (*) ... 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 Figure 11: ACK_ECN Frame Format 3365 An ACK_ECN frame contains all the elements of the ACK frame 3366 (Section 7.15) with the addition of three counts following the ACK 3367 Delay field. 3369 ECT(0) Count: A variable-length integer representing the total 3370 number packets received with the ECT(0) codepoint. 3372 ECT(1) Count: A variable-length integer representing the total 3373 number packets received with the ECT(1) codepoint. 3375 CE Count: A variable-length integer representing the total number 3376 packets received with the CE codepoint. 3378 7.17. PATH_CHALLENGE Frame 3380 Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check 3381 reachability to the peer and for path validation during connection 3382 establishment and connection migration. 3384 PATH_CHALLENGE frames contain an 8-byte payload. 3386 0 1 2 3 3387 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 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | | 3390 + Data (8) + 3391 | | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 Data: This 8-byte field contains arbitrary data. 3395 A PATH_CHALLENGE frame containing 8 octets that are hard to guess is 3396 sufficient to ensure that it is easier to receive the packet than it 3397 is to guess the value correctly. 3399 The recipient of this frame MUST generate a PATH_RESPONSE frame 3400 (Section 7.18) containing the same Data. 3402 7.18. PATH_RESPONSE Frame 3404 The PATH_RESPONSE frame (type=0x0f) is sent in response to a 3405 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 3406 frame (Section 7.17). 3408 If the content of a PATH_RESPONSE frame does not match the content of 3409 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 3410 MAY generate a connection error of type UNSOLICITED_PATH_RESPONSE. 3412 7.19. NEW_TOKEN frame 3414 A server sends a NEW_TOKEN frame (type=0x19) to provide the client a 3415 token to send in a the header of an Initial packet for a future 3416 connection. 3418 The NEW_TOKEN frame is as follows: 3420 0 1 2 3 3421 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 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3423 | Token Length (i) ... 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 | Token (*) ... 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3428 The fields of a NEW_TOKEN frame are as follows: 3430 Token Length: A variable-length integer specifying the length of the 3431 token in bytes. 3433 Token: An opaque blob that the client may use with a future Initial 3434 packet. 3436 7.20. STREAM Frames 3438 STREAM frames implicitly create a stream and carry stream data. The 3439 STREAM frame takes the form 0b00010XXX (or the set of values from 3440 0x10 to 0x17). The value of the three low-order bits of the frame 3441 type determine the fields that are present in the frame. 3443 o The OFF bit (0x04) in the frame type is set to indicate that there 3444 is an Offset field present. When set to 1, the Offset field is 3445 present; when set to 0, the Offset field is absent and the Stream 3446 Data starts at an offset of 0 (that is, the frame contains the 3447 first octets of the stream, or the end of a stream that includes 3448 no data). 3450 o The LEN bit (0x02) in the frame type is set to indicate that there 3451 is a Length field present. If this bit is set to 0, the Length 3452 field is absent and the Stream Data field extends to the end of 3453 the packet. If this bit is set to 1, the Length field is present. 3455 o The FIN bit (0x01) of the frame type is set only on frames that 3456 contain the final offset of the stream. Setting this bit 3457 indicates that the frame marks the end of the stream. 3459 An endpoint that receives a STREAM frame for a send-only stream MUST 3460 terminate the connection with error PROTOCOL_VIOLATION. 3462 A STREAM frame is shown below. 3464 0 1 2 3 3465 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 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3467 | Stream ID (i) ... 3468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3469 | [Offset (i)] ... 3470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3471 | [Length (i)] ... 3472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3473 | Stream Data (*) ... 3474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 Figure 12: STREAM Frame Format 3478 The STREAM frame contains the following fields: 3480 Stream ID: A variable-length integer indicating the stream ID of the 3481 stream (see Section 9.1). 3483 Offset: A variable-length integer specifying the byte offset in the 3484 stream for the data in this STREAM frame. This field is present 3485 when the OFF bit is set to 1. When the Offset field is absent, 3486 the offset is 0. 3488 Length: A variable-length integer specifying the length of the 3489 Stream Data field in this STREAM frame. This field is present 3490 when the LEN bit is set to 1. When the LEN bit is set to 0, the 3491 Stream Data field consumes all the remaining octets in the packet. 3493 Stream Data: The bytes from the designated stream to be delivered. 3495 When a Stream Data field has a length of 0, the offset in the STREAM 3496 frame is the offset of the next byte that would be sent. 3498 The first byte in the stream has an offset of 0. The largest offset 3499 delivered on a stream - the sum of the re-constructed offset and data 3500 length - MUST be less than 2^62. 3502 Stream multiplexing is achieved by interleaving STREAM frames from 3503 multiple streams into one or more QUIC packets. A single QUIC packet 3504 can include multiple STREAM frames from one or more streams. 3506 Implementation note: One of the benefits of QUIC is avoidance of 3507 head-of-line blocking across multiple streams. When a packet loss 3508 occurs, only streams with data in that packet are blocked waiting for 3509 a retransmission to be received, while other streams can continue 3510 making progress. Note that when data from multiple streams is 3511 bundled into a single QUIC packet, loss of that packet blocks all 3512 those streams from making progress. An implementation is therefore 3513 advised to bundle as few streams as necessary in outgoing packets 3514 without losing transmission efficiency to underfilled packets. 3516 7.21. CRYPTO Frame 3518 The CRYPTO frame (type=0x18) is used to transmit cryptographic 3519 handshake messages. It can be sent in all packet types. The CRYPTO 3520 frame offers the cryptographic protocol an in-order stream of bytes. 3521 CRYPTO frames are functionally identical to STREAM frames, except 3522 that they do not bear a stream identifier; they are not flow 3523 controlled; and they do not carry markers for optional offset, 3524 optional length, and the end of the stream. 3526 A CRYPTO frame is shown below. 3528 0 1 2 3 3529 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 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 | Offset (i) ... 3532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3533 | Length (i) ... 3534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3535 | Crypto Data (*) ... 3536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3538 Figure 13: CRYPTO Frame Format 3540 The CRYPTO frame contains the following fields: 3542 Offset: A variable-length integer specifying the byte offset in the 3543 stream for the data in this CRYPTO frame. 3545 Length: A variable-length integer specifying the length of the 3546 Crypto Data field in this CRYPTO frame. 3548 Crypto Data: The cryptographic message data. 3550 There is a separate flow of cryptographic handshake data in each 3551 encryption level, each of which starts at an offset of 0. This 3552 implies that each encryption level is treated as a separate CRYPTO 3553 stream of data. 3555 Unlike STREAM frames, which include a Stream ID indicating to which 3556 stream the data belongs, the CRYPTO frame carries data for a single 3557 stream per encryption level. The stream does not have an explicit 3558 end, so CRYPTO frames do not have a FIN bit. 3560 8. Packetization and Reliability 3562 A sender bundles one or more frames in a QUIC packet (see Section 5). 3564 A sender SHOULD minimize per-packet bandwidth and computational costs 3565 by bundling as many frames as possible within a QUIC packet. A 3566 sender MAY wait for a short period of time to bundle multiple frames 3567 before sending a packet that is not maximally packed, to avoid 3568 sending out large numbers of small packets. An implementation may 3569 use knowledge about application sending behavior or heuristics to 3570 determine whether and for how long to wait. This waiting period is 3571 an implementation decision, and an implementation should be careful 3572 to delay conservatively, since any delay is likely to increase 3573 application-visible latency. 3575 8.1. Packet Processing and Acknowledgment 3577 A packet MUST NOT be acknowledged until packet protection has been 3578 successfully removed and all frames contained in the packet have been 3579 processed. Any stream state transitions triggered by the frame MUST 3580 have occurred. For STREAM frames, this means the data has been 3581 enqueued in preparation to be received by the application protocol, 3582 but it does not require that data is delivered and consumed. 3584 Once the packet has been fully processed, a receiver acknowledges 3585 receipt by sending one or more ACK frames containing the packet 3586 number of the received packet. To avoid creating an indefinite 3587 feedback loop, an endpoint MUST NOT send an ACK frame in response to 3588 a packet containing only ACK or PADDING frames, even if there are 3589 packet gaps which precede the received packet. The endpoint MUST 3590 acknowledge packets containing only ACK or PADDING frames in the next 3591 ACK frame that it sends. 3593 Strategies and implications of the frequency of generating 3594 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 3596 8.2. Retransmission of Information 3598 QUIC packets that are determined to be lost are not retransmitted 3599 whole. The same applies to the frames that are contained within lost 3600 packets. Instead, the information that might be carried in frames is 3601 sent again in new frames as needed. 3603 New frames and packets are used to carry information that is 3604 determined to have been lost. In general, information is sent again 3605 when a packet containing that information is determined to be lost 3606 and sending ceases when a packet containing that information is 3607 acknowledged. 3609 o Data sent in CRYPTO frames are retransmitted according to the 3610 rules in [QUIC-RECOVERY], until either all data has been 3611 acknowledged or the crypto state machine implicitly knows that the 3612 peer received the data. 3614 o Application data sent in STREAM frames is retransmitted in new 3615 STREAM frames unless the endpoint has sent a RST_STREAM for that 3616 stream. Once an endpoint sends a RST_STREAM frame, no further 3617 STREAM frames are needed. 3619 o The most recent set of acknowledgments are sent in ACK frames. An 3620 ACK frame SHOULD contain all unacknowledged acknowledgments, as 3621 described in Section 7.15.2. 3623 o Cancellation of stream transmission, as carried in a RST_STREAM 3624 frame, is sent until acknowledged or until all stream data is 3625 acknowledged by the peer (that is, either the "Reset Recvd" or 3626 "Data Recvd" state is reached on the send stream). The content of 3627 a RST_STREAM frame MUST NOT change when it is sent again. 3629 o Similarly, a request to cancel stream transmission, as encoded in 3630 a STOP_SENDING frame, is sent until the receive stream enters 3631 either a "Data Recvd" or "Reset Recvd" state, see Section 9.3. 3633 o Connection close signals, including those that use 3634 CONNECTION_CLOSE and APPLICATION_CLOSE frames, are not sent again 3635 when packet loss is detected, but as described in Section 6.13. 3637 o The current connection maximum data is sent in MAX_DATA frames. 3638 An updated value is sent in a MAX_DATA frame if the packet 3639 containing the most recently sent MAX_DATA frame is declared lost, 3640 or when the endpoint decides to update the limit. Care is 3641 necessary to avoid sending this frame too often as the limit can 3642 increase frequently and cause an unnecessarily large number of 3643 MAX_DATA frames to be sent. 3645 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3646 frames. Like MAX_DATA, an updated value is sent when the packet 3647 containing the most recent MAX_STREAM_DATA frame for a stream is 3648 lost or when the limit is updated, with care taken to prevent the 3649 frame from being sent too often. An endpoint SHOULD stop sending 3650 MAX_STREAM_DATA frames when the receive stream enters a "Size 3651 Known" state. 3653 o The maximum stream ID for a stream of a given type is sent in 3654 MAX_STREAM_ID frames. Like MAX_DATA, an updated value is sent 3655 when a packet containing the most recent MAX_STREAM_ID for a 3656 stream type frame is declared lost or when the limit is updated, 3657 with care taken to prevent the frame from being sent too often. 3659 o Blocked signals are carried in BLOCKED, STREAM_BLOCKED, and 3660 STREAM_ID_BLOCKED frames. BLOCKED streams have connection scope, 3661 STREAM_BLOCKED frames have stream scope, and STREAM_ID_BLOCKED 3662 frames are scoped to a specific stream type. New frames are sent 3663 if packets containing the most recent frame for a scope is lost, 3664 but only while the endpoint is blocked on the corresponding limit. 3665 These frames always include the limit that is causing blocking at 3666 the time that they are transmitted. 3668 o A liveness or path validation check using PATH_CHALLENGE frames is 3669 sent periodically until a matching PATH_RESPONSE frame is received 3670 or until there is no remaining need for liveness or path 3671 validation checking. PATH_CHALLENGE frames include a different 3672 payload each time they are sent. 3674 o Responses to path validation using PATH_RESPONSE frames are sent 3675 just once. A new PATH_CHALLENGE frame will be sent if another 3676 PATH_RESPONSE frame is needed. 3678 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3679 retransmitted if the packet containing them is lost. 3681 o PADDING frames contain no information, so lost PADDING frames do 3682 not require repair. 3684 Upon detecting losses, a sender MUST take appropriate congestion 3685 control action. The details of loss detection and congestion control 3686 are described in [QUIC-RECOVERY]. 3688 8.3. Packet Size 3690 The QUIC packet size includes the QUIC header and integrity check, 3691 but not the UDP or IP header. 3693 Clients MUST pad any Initial packet it sends to have a QUIC packet 3694 size of at least 1200 octets. Sending an Initial packet of this size 3695 ensures that the network path supports a reasonably sized packet, and 3696 helps reduce the amplitude of amplification attacks caused by server 3697 responses toward an unverified client address. 3699 An Initial packet MAY exceed 1200 octets if the client knows that the 3700 Path Maximum Transmission Unit (PMTU) supports the size that it 3701 chooses. 3703 A server MAY send a CONNECTION_CLOSE frame with error code 3704 PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200 3705 octets. It MUST NOT send any other frame type in response, or 3706 otherwise behave as if any part of the offending packet was processed 3707 as valid. 3709 8.4. Path Maximum Transmission Unit 3711 The Path Maximum Transmission Unit (PMTU) is the maximum size of the 3712 entire IP header, UDP header, and UDP payload. The UDP payload 3713 includes the QUIC packet header, protected payload, and any 3714 authentication fields. 3716 All QUIC packets SHOULD be sized to fit within the estimated PMTU to 3717 avoid IP fragmentation or packet drops. To optimize bandwidth 3718 efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery 3719 ([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) 3720 for detecting the PMTU, setting the PMTU appropriately, and storing 3721 the result of previous PMTU determinations. 3723 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3724 packets larger than 1280 octets. Assuming the minimum IP header 3725 size, this results in a QUIC packet size of 1232 octets for IPv6 and 3726 1252 octets for IPv4. Some QUIC implementations MAY wish to be more 3727 conservative in computing allowed QUIC packet size given unknown 3728 tunneling overheads or IP header options. 3730 QUIC endpoints that implement any kind of PMTU discovery SHOULD 3731 maintain an estimate for each combination of local and remote IP 3732 addresses. Each pairing of local and remote addresses could have a 3733 different maximum MTU in the path. 3735 QUIC depends on the network path supporting a MTU of at least 1280 3736 octets. This is the IPv6 minimum MTU and therefore also supported by 3737 most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below 3738 this number, even if it receives signals that indicate a smaller 3739 limit might exist. 3741 If a QUIC endpoint determines that the PMTU between any pair of local 3742 and remote IP addresses has fallen below 1280 octets, it MUST 3743 immediately cease sending QUIC packets on the affected path. This 3744 could result in termination of the connection if an alternative path 3745 cannot be found. 3747 8.4.1. IPv4 PMTU Discovery 3749 Traditional ICMP-based path MTU discovery in IPv4 [PMTUDv4] is 3750 potentially vulnerable to off-path attacks that successfully guess 3751 the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient 3752 value. TCP connections mitigate this risk by using the (at minimum) 3753 8 bytes of transport header echoed in the ICMP message to validate 3754 the TCP sequence number as valid for the current connection. 3755 However, as QUIC operates over UDP, in IPv4 the echoed information 3756 could consist only of the IP and UDP headers, which usually has 3757 insufficient entropy to mitigate off-path attacks. 3759 As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps 3760 to mitigate this risk. For instance, an application could: 3762 o Set the IPv4 Don't Fragment (DF) bit on a small proportion of 3763 packets, so that most invalid ICMP messages arrive when there are 3764 no DF packets outstanding, and can therefore be identified as 3765 spurious. 3767 o Store additional information from the IP or UDP headers from DF 3768 packets (for example, the IP ID or UDP checksum) to further 3769 authenticate incoming Datagram Too Big messages. 3771 o Any reduction in PMTU due to a report contained in an ICMP packet 3772 is provisional until QUIC's loss detection algorithm determines 3773 that the packet is actually lost. 3775 8.4.2. Special Considerations for Packetization Layer PMTU Discovery 3777 The PADDING frame provides a useful option for PMTU probe packets. 3778 PADDING frames generate acknowledgements, but they need not be 3779 delivered reliably. As a result, the loss of PADDING frames in probe 3780 packets does not require delay-inducing retransmission. However, 3781 PADDING frames do consume congestion window, which may delay the 3782 transmission of subsequent application data. 3784 When implementing the algorithm in Section 7.2 of [PLPMTUD], the 3785 initial value of search_low SHOULD be consistent with the IPv6 3786 minimum packet size. Paths that do not support this size cannot 3787 deliver Initial packets, and therefore are not QUIC-compliant. 3789 Section 7.3 of [PLPMTUD] discusses tradeoffs between small and large 3790 increases in the size of probe packets. As QUIC probe packets need 3791 not contain application data, aggressive increases in probe size 3792 carry fewer consequences. 3794 9. Streams: QUIC's Data Structuring Abstraction 3796 Streams in QUIC provide a lightweight, ordered byte-stream 3797 abstraction. 3799 There are two basic types of stream in QUIC. Unidirectional streams 3800 carry data in one direction only; bidirectional streams allow for 3801 data to be sent in both directions. Different stream identifiers are 3802 used to distinguish between unidirectional and bidirectional streams, 3803 as well as to create a separation between streams that are initiated 3804 by the client and server (see Section 9.1). 3806 Either type of stream can be created by either endpoint, can 3807 concurrently send data interleaved with other streams, and can be 3808 cancelled. 3810 Stream offsets allow for the octets on a stream to be placed in 3811 order. An endpoint MUST be capable of delivering data received on a 3812 stream in order. Implementations MAY choose to offer the ability to 3813 deliver data out of order. There is no means of ensuring ordering 3814 between octets on different streams. 3816 The creation and destruction of streams are expected to have minimal 3817 bandwidth and computational cost. A single STREAM frame may create, 3818 carry data for, and terminate a stream, or a stream may last the 3819 entire duration of a connection. 3821 Streams are individually flow controlled, allowing an endpoint to 3822 limit memory commitment and to apply back pressure. The creation of 3823 streams is also flow controlled, with each peer declaring the maximum 3824 stream ID it is willing to accept at a given time. 3826 An alternative view of QUIC streams is as an elastic "message" 3827 abstraction, similar to the way ephemeral streams are used in SST 3828 [SST], which may be a more appealing description for some 3829 applications. 3831 9.1. Stream Identifiers 3833 Streams are identified by an unsigned 62-bit integer, referred to as 3834 the Stream ID. The least significant two bits of the Stream ID are 3835 used to identify the type of stream (unidirectional or bidirectional) 3836 and the initiator of the stream. 3838 The least significant bit (0x1) of the Stream ID identifies the 3839 initiator of the stream. Clients initiate even-numbered streams 3840 (those with the least significant bit set to 0); servers initiate 3841 odd-numbered streams (with the bit set to 1). Separation of the 3842 stream identifiers ensures that client and server are able to open 3843 streams without the latency imposed by negotiating for an identifier. 3845 If an endpoint receives a frame for a stream that it expects to 3846 initiate (i.e., odd-numbered for the client or even-numbered for the 3847 server), but which it has not yet opened, it MUST close the 3848 connection with error code STREAM_STATE_ERROR. 3850 The second least significant bit (0x2) of the Stream ID 3851 differentiates between unidirectional streams and bidirectional 3852 streams. Unidirectional streams always have this bit set to 1 and 3853 bidirectional streams have this bit set to 0. 3855 The two type bits from a Stream ID therefore identify streams as 3856 summarized in Table 5. 3858 +----------+----------------------------------+ 3859 | Low Bits | Stream Type | 3860 +----------+----------------------------------+ 3861 | 0x0 | Client-Initiated, Bidirectional | 3862 | | | 3863 | 0x1 | Server-Initiated, Bidirectional | 3864 | | | 3865 | 0x2 | Client-Initiated, Unidirectional | 3866 | | | 3867 | 0x3 | Server-Initiated, Unidirectional | 3868 +----------+----------------------------------+ 3870 Table 5: Stream ID Types 3872 The first bi-directional stream opened by the client is stream 0. 3874 A QUIC endpoint MUST NOT reuse a Stream ID. Streams can be used in 3875 any order. Streams that are used out of order result in opening all 3876 lower-numbered streams of the same type in the same direction. 3878 Stream IDs are encoded as a variable-length integer (see 3879 Section 7.1). 3881 9.2. Stream States 3883 This section describes the two types of QUIC stream in terms of the 3884 states of their send or receive components. Two state machines are 3885 described: one for streams on which an endpoint transmits data 3886 (Section 9.2.1); another for streams from which an endpoint receives 3887 data (Section 9.2.2). 3889 Unidirectional streams use the applicable state machine directly. 3890 Bidirectional streams use both state machines. For the most part, 3891 the use of these state machines is the same whether the stream is 3892 unidirectional or bidirectional. The conditions for opening a stream 3893 are slightly more complex for a bidirectional stream because the 3894 opening of either send or receive sides causes the stream to open in 3895 both directions. 3897 An endpoint can open streams up to its maximum stream limit in any 3898 order, however endpoints SHOULD open the send side of streams for 3899 each type in order. 3901 Note: These states are largely informative. This document uses 3902 stream states to describe rules for when and how different types 3903 of frames can be sent and the reactions that are expected when 3904 different types of frames are received. Though these state 3905 machines are intended to be useful in implementing QUIC, these 3906 states aren't intended to constrain implementations. An 3907 implementation can define a different state machine as long as its 3908 behavior is consistent with an implementation that implements 3909 these states. 3911 9.2.1. Send Stream States 3913 Figure 14 shows the states for the part of a stream that sends data 3914 to a peer. 3916 o 3917 | Create Stream (Sending) 3918 | Create Bidirectional Stream (Receiving) 3919 v 3920 +-------+ 3921 | Ready | Send RST_STREAM 3922 | |-----------------------. 3923 +-------+ | 3924 | | 3925 | Send STREAM / | 3926 | STREAM_BLOCKED | 3927 v | 3928 +-------+ | 3929 | Send | Send RST_STREAM | 3930 | |---------------------->| 3931 +-------+ | 3932 | | 3933 | Send STREAM + FIN | 3934 v v 3935 +-------+ +-------+ 3936 | Data | Send RST_STREAM | Reset | 3937 | Sent +------------------>| Sent | 3938 +-------+ +-------+ 3939 | | 3940 | Recv All ACKs | Recv ACK 3941 v v 3942 +-------+ +-------+ 3943 | Data | | Reset | 3944 | Recvd | | Recvd | 3945 +-------+ +-------+ 3947 Figure 14: States for Send Streams 3949 The sending part of stream that the endpoint initiates (types 0 and 2 3950 for clients, 1 and 3 for servers) is opened by the application or 3951 application protocol. The "Ready" state represents a newly created 3952 stream that is able to accept data from the application. Stream data 3953 might be buffered in this state in preparation for sending. 3955 The sending part of a bidirectional stream initiated by a peer (type 3956 0 for a server, type 1 for a client) enters the "Ready" state if the 3957 receiving part enters the "Recv" state. 3959 Sending the first STREAM or STREAM_BLOCKED frame causes a send stream 3960 to enter the "Send" state. An implementation might choose to defer 3961 allocating a Stream ID to a send stream until it sends the first 3962 frame and enters this state, which can allow for better stream 3963 prioritization. 3965 In the "Send" state, an endpoint transmits - and retransmits as 3966 necessary - data in STREAM frames. The endpoint respects the flow 3967 control limits of its peer, accepting MAX_STREAM_DATA frames. An 3968 endpoint in the "Send" state generates STREAM_BLOCKED frames if it 3969 encounters flow control limits. 3971 After the application indicates that stream data is complete and a 3972 STREAM frame containing the FIN bit is sent, the send stream enters 3973 the "Data Sent" state. From this state, the endpoint only 3974 retransmits stream data as necessary. The endpoint no longer needs 3975 to track flow control limits or send STREAM_BLOCKED frames for a send 3976 stream in this state. The endpoint can ignore any MAX_STREAM_DATA 3977 frames it receives from its peer in this state; MAX_STREAM_DATA 3978 frames might be received until the peer receives the final stream 3979 offset. 3981 Once all stream data has been successfully acknowledged, the send 3982 stream enters the "Data Recvd" state, which is a terminal state. 3984 From any of the "Ready", "Send", or "Data Sent" states, an 3985 application can signal that it wishes to abandon transmission of 3986 stream data. Similarly, the endpoint might receive a STOP_SENDING 3987 frame from its peer. In either case, the endpoint sends a RST_STREAM 3988 frame, which causes the stream to enter the "Reset Sent" state. 3990 An endpoint MAY send a RST_STREAM as the first frame on a send 3991 stream; this causes the send stream to open and then immediately 3992 transition to the "Reset Sent" state. 3994 Once a packet containing a RST_STREAM has been acknowledged, the send 3995 stream enters the "Reset Recvd" state, which is a terminal state. 3997 9.2.2. Receive Stream States 3999 Figure 15 shows the states for the part of a stream that receives 4000 data from a peer. The states for a receive stream mirror only some 4001 of the states of the send stream at the peer. A receive stream 4002 doesn't track states on the send stream that cannot be observed, such 4003 as the "Ready" state; instead, receive streams track the delivery of 4004 data to the application or application protocol some of which cannot 4005 be observed by the sender. 4007 o 4008 | Recv STREAM / STREAM_BLOCKED / RST_STREAM 4009 | Create Bidirectional Stream (Sending) 4010 | Recv MAX_STREAM_DATA 4011 v 4012 +-------+ 4013 | Recv | Recv RST_STREAM 4014 | |-----------------------. 4015 +-------+ | 4016 | | 4017 | Recv STREAM + FIN | 4018 v | 4019 +-------+ | 4020 | Size | Recv RST_STREAM | 4021 | Known +---------------------->| 4022 +-------+ | 4023 | | 4024 | Recv All Data | 4025 v v 4026 +-------+ +-------+ 4027 | Data | Recv RST_STREAM | Reset | 4028 | Recvd +<-- (optional) --->| Recvd | 4029 +-------+ +-------+ 4030 | | 4031 | App Read All Data | App Read RST 4032 v v 4033 +-------+ +-------+ 4034 | Data | | Reset | 4035 | Read | | Read | 4036 +-------+ +-------+ 4038 Figure 15: States for Receive Streams 4040 The receiving part of a stream initiated by a peer (types 1 and 3 for 4041 a client, or 0 and 2 for a server) are created when the first STREAM, 4042 STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only, 4043 see below) is received for that stream. The initial state for a 4044 receive stream is "Recv". Receiving a RST_STREAM frame causes the 4045 receive stream to immediately transition to the "Reset Recvd". 4047 The receive stream enters the "Recv" state when the sending part of a 4048 bidirectional stream initiated by the endpoint (type 0 for a client, 4049 type 1 for a server) enters the "Ready" state. 4051 A bidirectional stream also opens when a MAX_STREAM_DATA frame is 4052 received. Receiving a MAX_STREAM_DATA frame implies that the remote 4053 peer has opened the stream and is providing flow control credit. A 4054 MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED 4055 frame if packets are lost or reordered. 4057 In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED 4058 frames. Incoming data is buffered and can be reassembled into the 4059 correct order for delivery to the application. As data is consumed 4060 by the application and buffer space becomes available, the endpoint 4061 sends MAX_STREAM_DATA frames to allow the peer to send more data. 4063 When a STREAM frame with a FIN bit is received, the final offset (see 4064 Section 10.3) is known. The receive stream enters the "Size Known" 4065 state. In this state, the endpoint no longer needs to send 4066 MAX_STREAM_DATA frames, it only receives any retransmissions of 4067 stream data. 4069 Once all data for the stream has been received, the receive stream 4070 enters the "Data Recvd" state. This might happen as a result of 4071 receiving the same STREAM frame that causes the transition to "Size 4072 Known". In this state, the endpoint has all stream data. Any STREAM 4073 or STREAM_BLOCKED frames it receives for the stream can be discarded. 4075 The "Data Recvd" state persists until stream data has been delivered 4076 to the application or application protocol. Once stream data has 4077 been delivered, the stream enters the "Data Read" state, which is a 4078 terminal state. 4080 Receiving a RST_STREAM frame in the "Recv" or "Size Known" states 4081 causes the stream to enter the "Reset Recvd" state. This might cause 4082 the delivery of stream data to the application to be interrupted. 4084 It is possible that all stream data is received when a RST_STREAM is 4085 received (that is, from the "Data Recvd" state). Similarly, it is 4086 possible for remaining stream data to arrive after receiving a 4087 RST_STREAM frame (the "Reset Recvd" state). An implementation is 4088 able to manage this situation as they choose. Sending RST_STREAM 4089 means that an endpoint cannot guarantee delivery of stream data; 4090 however there is no requirement that stream data not be delivered if 4091 a RST_STREAM is received. An implementation MAY interrupt delivery 4092 of stream data, discard any data that was not consumed, and signal 4093 the existence of the RST_STREAM immediately. Alternatively, the 4094 RST_STREAM signal might be suppressed or withheld if stream data is 4095 completely received. In the latter case, the receive stream 4096 effectively transitions to "Data Recvd" from "Reset Recvd". 4098 Once the application has been delivered the signal indicating that 4099 the receive stream was reset, the receive stream transitions to the 4100 "Reset Read" state, which is a terminal state. 4102 9.2.3. Permitted Frame Types 4104 The sender of a stream sends just three frame types that affect the 4105 state of a stream at either sender or receiver: STREAM 4106 (Section 7.20), STREAM_BLOCKED (Section 7.11), and RST_STREAM 4107 (Section 7.3). 4109 A sender MUST NOT send any of these frames from a terminal state 4110 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 4111 STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset 4112 Sent" state in addition to the terminal states. A receiver could 4113 receive any of these frames in any state, but only due to the 4114 possibility of delayed delivery of packets carrying them. 4116 The receiver of a stream sends MAX_STREAM_DATA (Section 7.7) and 4117 STOP_SENDING frames (Section 7.14). 4119 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 4120 receiver can send STOP_SENDING in any state where it has not received 4121 a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset 4122 Read". However there is little value in sending a STOP_SENDING frame 4123 after all stream data has been received in the "Data Recvd" state. A 4124 sender could receive these frames in any state as a result of delayed 4125 delivery of packets. 4127 9.2.4. Bidirectional Stream States 4129 A bidirectional stream is composed of a send stream and a receive 4130 stream. Implementations may represent states of the bidirectional 4131 stream as composites of send and receive stream states. The simplest 4132 model presents the stream as "open" when either send or receive 4133 stream is in a non-terminal state and "closed" when both send and 4134 receive streams are in a terminal state. 4136 Table 6 shows a more complex mapping of bidirectional stream states 4137 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 4138 shows that multiple states on send or receive streams are mapped to 4139 the same composite state. Note that this is just one possibility for 4140 such a mapping; this mapping requires that data is acknowledged 4141 before the transition to a "closed" or "half-closed" state. 4143 +-----------------------+---------------------+---------------------+ 4144 | Send Stream | Receive Stream | Composite State | 4145 +-----------------------+---------------------+---------------------+ 4146 | No Stream/Ready | No Stream/Recv *1 | idle | 4147 | | | | 4148 | Ready/Send/Data Sent | Recv/Size Known | open | 4149 | | | | 4150 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 4151 | | Read | (remote) | 4152 | | | | 4153 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 4154 | | Read | (remote) | 4155 | | | | 4156 | Data Recvd | Recv/Size Known | half-closed (local) | 4157 | | | | 4158 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 4159 | Recvd | | | 4160 | | | | 4161 | Data Recvd | Recv/Size Known | half-closed (local) | 4162 | | | | 4163 | Reset Sent/Reset | Data Recvd/Data | closed | 4164 | Recvd | Read | | 4165 | | | | 4166 | Reset Sent/Reset | Reset Recvd/Reset | closed | 4167 | Recvd | Read | | 4168 | | | | 4169 | Data Recvd | Data Recvd/Data | closed | 4170 | | Read | | 4171 | | | | 4172 | Data Recvd | Reset Recvd/Reset | closed | 4173 | | Read | | 4174 +-----------------------+---------------------+---------------------+ 4176 Table 6: Possible Mapping of Stream States to HTTP/2 4178 Note (*1): A stream is considered "idle" if it has not yet been 4179 created, or if the receive stream is in the "Recv" state without 4180 yet having received any frames. 4182 9.3. Solicited State Transitions 4184 If an endpoint is no longer interested in the data it is receiving on 4185 a stream, it MAY send a STOP_SENDING frame identifying that stream to 4186 prompt closure of the stream in the opposite direction. This 4187 typically indicates that the receiving application is no longer 4188 reading data it receives from the stream, but is not a guarantee that 4189 incoming data will be ignored. 4191 STREAM frames received after sending STOP_SENDING are still counted 4192 toward the connection and stream flow-control windows, even though 4193 these frames will be discarded upon receipt. This avoids potential 4194 ambiguity about which STREAM frames count toward flow control. 4196 A STOP_SENDING frame requests that the receiving endpoint send a 4197 RST_STREAM frame. An endpoint that receives a STOP_SENDING frame 4198 MUST send a RST_STREAM frame for that stream, and can use an error 4199 code of STOPPING. If the STOP_SENDING frame is received on a send 4200 stream that is already in the "Data Sent" state, a RST_STREAM frame 4201 MAY still be sent in order to cancel retransmission of previously- 4202 sent STREAM frames. 4204 STOP_SENDING SHOULD only be sent for a receive stream that has not 4205 been reset. STOP_SENDING is most useful for streams in the "Recv" or 4206 "Size Known" states. 4208 An endpoint is expected to send another STOP_SENDING frame if a 4209 packet containing a previous STOP_SENDING is lost. However, once 4210 either all stream data or a RST_STREAM frame has been received for 4211 the stream - that is, the stream is in any state other than "Recv" or 4212 "Size Known" - sending a STOP_SENDING frame is unnecessary. 4214 9.4. Stream Concurrency 4216 An endpoint limits the number of concurrently active incoming streams 4217 by adjusting the maximum stream ID. An initial value is set in the 4218 transport parameters (see Section 6.6.1) and is subsequently 4219 increased by MAX_STREAM_ID frames (see Section 7.8). 4221 The maximum stream ID is specific to each endpoint and applies only 4222 to the peer that receives the setting. That is, clients specify the 4223 maximum stream ID the server can initiate, and servers specify the 4224 maximum stream ID the client can initiate. Each endpoint may respond 4225 on streams initiated by the other peer, regardless of whether it is 4226 permitted to initiated new streams. 4228 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 4229 that receives a STREAM frame with an ID greater than the limit it has 4230 sent MUST treat this as a stream error of type STREAM_ID_ERROR 4231 (Section 11), unless this is a result of a change in the initial 4232 offsets (see Section 6.6.2). 4234 A receiver MUST NOT renege on an advertisement; that is, once a 4235 receiver advertises a stream ID via a MAX_STREAM_ID frame, it MUST 4236 NOT subsequently advertise a smaller maximum ID. A sender may 4237 receive MAX_STREAM_ID frames out of order; a sender MUST therefore 4238 ignore any MAX_STREAM_ID that does not increase the maximum. 4240 9.5. Sending and Receiving Data 4242 Once a stream is created, endpoints may use the stream to send and 4243 receive data. Each endpoint may send a series of STREAM frames 4244 encapsulating data on a stream until the stream is terminated in that 4245 direction. Streams are an ordered byte-stream abstraction, and they 4246 have no other structure within them. STREAM frame boundaries are not 4247 expected to be preserved in retransmissions from the sender or during 4248 delivery to the application at the receiver. 4250 When new data is to be sent on a stream, a sender MUST set the 4251 encapsulating STREAM frame's offset field to the stream offset of the 4252 first byte of this new data. The first octet of data on a stream has 4253 an offset of 0. An endpoint is expected to send every stream octet. 4254 The largest offset delivered on a stream MUST be less than 2^62. 4256 QUIC makes no specific allowances for partial reliability or delivery 4257 of stream data out of order. Endpoints MUST be able to deliver 4258 stream data to an application as an ordered byte-stream. Delivering 4259 an ordered byte-stream requires that an endpoint buffer any data that 4260 is received out of order, up to the advertised flow control limit. 4262 An endpoint could receive the same octets multiple times; octets that 4263 have already been received can be discarded. The value for a given 4264 octet MUST NOT change if it is sent multiple times; an endpoint MAY 4265 treat receipt of a changed octet as a connection error of type 4266 PROTOCOL_VIOLATION. 4268 An endpoint MUST NOT send data on any stream without ensuring that it 4269 is within the data limits set by its peer. 4271 Flow control is described in detail in Section 10, and congestion 4272 control is described in the companion document [QUIC-RECOVERY]. 4274 9.6. Stream Prioritization 4276 Stream multiplexing has a significant effect on application 4277 performance if resources allocated to streams are correctly 4278 prioritized. Experience with other multiplexed protocols, such as 4279 HTTP/2 [HTTP2], shows that effective prioritization strategies have a 4280 significant positive impact on performance. 4282 QUIC does not provide frames for exchanging prioritization 4283 information. Instead it relies on receiving priority information 4284 from the application that uses QUIC. Protocols that use QUIC are 4285 able to define any prioritization scheme that suits their application 4286 semantics. A protocol might define explicit messages for signaling 4287 priority, such as those defined in HTTP/2; it could define rules that 4288 allow an endpoint to determine priority based on context; or it could 4289 leave the determination to the application. 4291 A QUIC implementation SHOULD provide ways in which an application can 4292 indicate the relative priority of streams. When deciding which 4293 streams to dedicate resources to, QUIC SHOULD use the information 4294 provided by the application. Failure to account for priority of 4295 streams can result in suboptimal performance. 4297 Stream priority is most relevant when deciding which stream data will 4298 be transmitted. Often, there will be limits on what can be 4299 transmitted as a result of connection flow control or the current 4300 congestion controller state. 4302 Giving preference to the transmission of its own management frames 4303 ensures that the protocol functions efficiently. That is, 4304 prioritizing frames other than STREAM frames ensures that loss 4305 recovery, congestion control, and flow control operate effectively. 4307 CRYPTO frames SHOULD be prioritized over other streams prior to the 4308 completion of the cryptographic handshake. This includes the 4309 retransmission of the second flight of client handshake messages, 4310 that is, the TLS Finished and any client authentication messages. 4312 STREAM data in frames determined to be lost SHOULD be retransmitted 4313 before sending new data, unless application priorities indicate 4314 otherwise. Retransmitting lost stream data can fill in gaps, which 4315 allows the peer to consume already received data and free up flow 4316 control window. 4318 10. Flow Control 4320 It is necessary to limit the amount of data that a sender may have 4321 outstanding at any time, so as to prevent a fast sender from 4322 overwhelming a slow receiver, or to prevent a malicious sender from 4323 consuming significant resources at a receiver. This section 4324 describes QUIC's flow-control mechanisms. 4326 QUIC employs a credit-based flow-control scheme similar to HTTP/2's 4327 flow control [HTTP2]. A receiver advertises the number of octets it 4328 is prepared to receive on a given stream and for the entire 4329 connection. This leads to two levels of flow control in QUIC: (i) 4330 Connection flow control, which prevents senders from exceeding a 4331 receiver's buffer capacity for the connection, and (ii) Stream flow 4332 control, which prevents a single stream from consuming the entire 4333 receive buffer for a connection. 4335 A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the 4336 sender to advertise additional credit. MAX_STREAM_DATA frames send 4337 the maximum absolute byte offset of a stream, while MAX_DATA sends 4338 the maximum of the sum of the absolute byte offsets of all streams. 4340 A receiver MAY advertise a larger offset at any point by sending 4341 MAX_DATA or MAX_STREAM_DATA frames. A receiver MUST NOT renege on an 4342 advertisement; that is, once a receiver advertises an offset, it MUST 4343 NOT subsequently advertise a smaller offset. A sender could receive 4344 MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST 4345 therefore ignore any flow control offset that does not move the 4346 window forward. 4348 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 4349 (Section 11) if the peer violates the advertised connection or stream 4350 data limits. 4352 A sender SHOULD send BLOCKED or STREAM_BLOCKED frames to indicate it 4353 has data to write but is blocked by flow control limits. These 4354 frames are expected to be sent infrequently in common cases, but they 4355 are considered useful for debugging and monitoring purposes. 4357 A receiver advertises credit for a stream by sending a 4358 MAX_STREAM_DATA frame with the Stream ID set appropriately. A 4359 receiver could use the current offset of data consumed to determine 4360 the flow control offset to be advertised. A receiver MAY send 4361 MAX_STREAM_DATA frames in multiple packets in order to make sure that 4362 the sender receives an update before running out of flow control 4363 credit, even if one of the packets is lost. 4365 Connection flow control is a limit to the total bytes of stream data 4366 sent in STREAM frames on all streams. A receiver advertises credit 4367 for a connection by sending a MAX_DATA frame. A receiver maintains a 4368 cumulative sum of bytes received on all contributing streams, which 4369 are used to check for flow control violations. A receiver might use 4370 a sum of bytes consumed on all contributing streams to determine the 4371 maximum data limit to be advertised. 4373 10.1. Edge Cases and Other Considerations 4375 There are some edge cases which must be considered when dealing with 4376 stream and connection level flow control. Given enough time, both 4377 endpoints must agree on flow control state. If one end believes it 4378 can send more than the other end is willing to receive, the 4379 connection will be torn down when too much data arrives. 4381 Conversely if a sender believes it is blocked, while endpoint B 4382 expects more data can be received, then the connection can be in a 4383 deadlock, with the sender waiting for a MAX_DATA or MAX_STREAM_DATA 4384 frame which will never come. 4386 On receipt of a RST_STREAM frame, an endpoint will tear down state 4387 for the matching stream and ignore further data arriving on that 4388 stream. This could result in the endpoints getting out of sync, 4389 since the RST_STREAM frame may have arrived out of order and there 4390 may be further bytes in flight. The data sender would have counted 4391 the data against its connection level flow control budget, but a 4392 receiver that has not received these bytes would not know to include 4393 them as well. The receiver must learn the number of bytes that were 4394 sent on the stream to make the same adjustment in its connection flow 4395 controller. 4397 To avoid this de-synchronization, a RST_STREAM sender MUST include 4398 the final byte offset sent on the stream in the RST_STREAM frame. On 4399 receiving a RST_STREAM frame, a receiver definitively knows how many 4400 bytes were sent on that stream before the RST_STREAM frame, and the 4401 receiver MUST use the final offset to account for all bytes sent on 4402 the stream in its connection level flow controller. 4404 10.1.1. Response to a RST_STREAM 4406 RST_STREAM terminates one direction of a stream abruptly. Whether 4407 any action or response can or should be taken on the data already 4408 received is an application-specific issue, but it will often be the 4409 case that upon receipt of a RST_STREAM an endpoint will choose to 4410 stop sending data in its own direction. If the sender of a 4411 RST_STREAM wishes to explicitly state that no future data will be 4412 processed, that endpoint MAY send a STOP_SENDING frame at the same 4413 time. 4415 10.1.2. Data Limit Increments 4417 This document leaves when and how many bytes to advertise in a 4418 MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few 4419 considerations. These frames contribute to connection overhead. 4420 Therefore frequently sending frames with small changes is 4421 undesirable. At the same time, infrequent updates require larger 4422 increments to limits if blocking is to be avoided. Thus, larger 4423 updates require a receiver to commit to larger resource commitments. 4424 Thus there is a tradeoff between resource commitment and overhead 4425 when determining how large a limit is advertised. 4427 A receiver MAY use an autotuning mechanism to tune the frequency and 4428 amount that it increases data limits based on a round-trip time 4429 estimate and the rate at which the receiving application consumes 4430 data, similar to common TCP implementations. 4432 10.2. Stream Limit Increment 4434 As with flow control, this document leaves when and how many streams 4435 to make available to a peer via MAX_STREAM_ID to implementations, but 4436 offers a few considerations. MAX_STREAM_ID frames constitute minimal 4437 overhead, while withholding MAX_STREAM_ID frames can prevent the peer 4438 from using the available parallelism. 4440 Implementations will likely want to increase the maximum stream ID as 4441 peer-initiated streams close. A receiver MAY also advance the 4442 maximum stream ID based on current activity, system conditions, and 4443 other environmental factors. 4445 10.2.1. Blocking on Flow Control 4447 If a sender does not receive a MAX_DATA or MAX_STREAM_DATA frame when 4448 it has run out of flow control credit, the sender will be blocked and 4449 SHOULD send a BLOCKED or STREAM_BLOCKED frame. These frames are 4450 expected to be useful for debugging at the receiver; they do not 4451 require any other action. A receiver SHOULD NOT wait for a BLOCKED 4452 or STREAM_BLOCKED frame before sending MAX_DATA or MAX_STREAM_DATA, 4453 since doing so will mean that a sender is unable to send for an 4454 entire round trip. 4456 For smooth operation of the congestion controller, it is generally 4457 considered best to not let the sender go into quiescence if 4458 avoidable. To avoid blocking a sender, and to reasonably account for 4459 the possibiity of loss, a receiver should send a MAX_DATA or 4460 MAX_STREAM_DATA frame at least two round trips before it expects the 4461 sender to get blocked. 4463 A sender sends a single BLOCKED or STREAM_BLOCKED frame only once 4464 when it reaches a data limit. A sender SHOULD NOT send multiple 4465 BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the 4466 original frame is determined to be lost. Another BLOCKED or 4467 STREAM_BLOCKED frame can be sent after the data limit is increased. 4469 10.3. Stream Final Offset 4471 The final offset is the count of the number of octets that are 4472 transmitted on a stream. For a stream that is reset, the final 4473 offset is carried explicitly in a RST_STREAM frame. Otherwise, the 4474 final offset is the offset of the end of the data carried in a STREAM 4475 frame marked with a FIN flag, or 0 in the case of incoming 4476 unidirectional streams. 4478 An endpoint will know the final offset for a stream when the receive 4479 stream enters the "Size Known" or "Reset Recvd" state. 4481 An endpoint MUST NOT send data on a stream at or beyond the final 4482 offset. 4484 Once a final offset for a stream is known, it cannot change. If a 4485 RST_STREAM or STREAM frame causes the final offset to change for a 4486 stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error 4487 (see Section 11). A receiver SHOULD treat receipt of data at or 4488 beyond the final offset as a FINAL_OFFSET_ERROR error, even after a 4489 stream is closed. Generating these errors is not mandatory, but only 4490 because requiring that an endpoint generate these errors also means 4491 that the endpoint needs to maintain the final offset state for closed 4492 streams, which could mean a significant state commitment. 4494 10.4. Flow Control for Crytographic Handshake 4496 Data sent in CRYPTO frames is not flow controlled in the same way as 4497 STREAM frames. QUIC relies on the cryptographic protocol 4498 implementation to avoid excessive buffering of data, see [QUIC-TLS]. 4499 The implementation SHOULD provide an interface to QUIC to tell it 4500 about its buffering limits so that there is not excessive buffering 4501 at multiple layers. 4503 11. Error Handling 4505 An endpoint that detects an error SHOULD signal the existence of that 4506 error to its peer. Both transport-level and application-level errors 4507 can affect an entire connection (see Section 11.1), while only 4508 application-level errors can be isolated to a single stream (see 4509 Section 11.2). 4511 The most appropriate error code (Section 11.3) SHOULD be included in 4512 the frame that signals the error. Where this specification 4513 identifies error conditions, it also identifies the error code that 4514 is used. 4516 A stateless reset (Section 6.13.4) is not suitable for any error that 4517 can be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or 4518 RST_STREAM frame. A stateless reset MUST NOT be used by an endpoint 4519 that has the state necessary to send a frame on the connection. 4521 11.1. Connection Errors 4523 Errors that result in the connection being unusable, such as an 4524 obvious violation of protocol semantics or corruption of state that 4525 affects an entire connection, MUST be signaled using a 4526 CONNECTION_CLOSE or APPLICATION_CLOSE frame (Section 7.4, 4527 Section 7.5). An endpoint MAY close the connection in this manner 4528 even if the error only affects a single stream. 4530 Application protocols can signal application-specific protocol errors 4531 using the APPLICATION_CLOSE frame. Errors that are specific to the 4532 transport, including all those described in this document, are 4533 carried in a CONNECTION_CLOSE frame. Other than the type of error 4534 code they carry, these frames are identical in format and semantics. 4536 A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a 4537 packet that is lost. An endpoint SHOULD be prepared to retransmit a 4538 packet containing either frame type if it receives more packets on a 4539 terminated connection. Limiting the number of retransmissions and 4540 the time over which this final packet is sent limits the effort 4541 expended on terminated connections. 4543 An endpoint that chooses not to retransmit packets containing 4544 CONNECTION_CLOSE or APPLICATION_CLOSE risks a peer missing the first 4545 such packet. The only mechanism available to an endpoint that 4546 continues to receive data for a terminated connection is to use the 4547 stateless reset process (Section 6.13.4). 4549 An endpoint that receives an invalid CONNECTION_CLOSE or 4550 APPLICATION_CLOSE frame MUST NOT signal the existence of the error to 4551 its peer. 4553 11.2. Stream Errors 4555 If an application-level error affects a single stream, but otherwise 4556 leaves the connection in a recoverable state, the endpoint can send a 4557 RST_STREAM frame (Section 7.3) with an appropriate error code to 4558 terminate just the affected stream. 4560 Other than STOPPING (Section 9.3), RST_STREAM MUST be instigated by 4561 the application and MUST carry an application error code. Resetting 4562 a stream without knowledge of the application protocol could cause 4563 the protocol to enter an unrecoverable state. Application protocols 4564 might require certain streams to be reliably delivered in order to 4565 guarantee consistent state between endpoints. 4567 11.3. Transport Error Codes 4569 QUIC error codes are 16-bit unsigned integers. 4571 This section lists the defined QUIC transport error codes that may be 4572 used in a CONNECTION_CLOSE frame. These errors apply to the entire 4573 connection. 4575 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 4576 signal that the connection is being closed abruptly in the absence 4577 of any error. 4579 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 4580 cannot continue with the connection. 4582 SERVER_BUSY (0x2): The server is currently busy and does not accept 4583 any new connections. 4585 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 4586 permitted in its advertised data limits (see Section 10). 4588 STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream 4589 identifier that exceeded its advertised maximum stream ID. 4591 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 4592 that was not in a state that permitted that frame (see 4593 Section 9.2). 4595 FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame 4596 containing data that exceeded the previously established final 4597 offset. Or an endpoint received a RST_STREAM frame containing a 4598 final offset that was lower than the maximum offset of data that 4599 was already received. Or an endpoint received a RST_STREAM frame 4600 containing a different final offset to the one already 4601 established. 4603 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 4604 badly formatted. For instance, an empty STREAM frame that omitted 4605 the FIN flag, or an ACK frame that has more acknowledgment ranges 4606 than the remainder of the packet could carry. 4608 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 4609 parameters that were badly formatted, included an invalid value, 4610 was absent even though it is mandatory, was present though it is 4611 forbidden, or is otherwise in error. 4613 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 4614 parameters that contained version negotiation parameters that 4615 disagreed with the version negotiation that it performed. This 4616 error code indicates a potential version downgrade attack. 4618 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 4619 protocol compliance that was not covered by more specific error 4620 codes. 4622 UNSOLICITED_PATH_RESPONSE (0xB): An endpoint received a 4623 PATH_RESPONSE frame that did not correspond to any PATH_CHALLENGE 4624 frame that it previously sent. 4626 INVALID_MIGRATION (0xC): A peer has migrated to a different network 4627 when the endpoint had disabled migration. 4629 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 4630 of 256 values is reserved for carrying error codes specific to the 4631 cryptographic handshake that is used. Codes for errors occuring 4632 when TLS is used for the crypto handshake are defined in 4633 Section 11 of [QUIC-TLS]. 4635 See Section 13.3 for details of registering new error codes. 4637 11.4. Application Protocol Error Codes 4639 Application protocol error codes are 16-bit unsigned integers, but 4640 the management of application error codes are left to application 4641 protocols. Application protocol error codes are used for the 4642 RST_STREAM (Section 7.3) and APPLICATION_CLOSE (Section 7.5) frames. 4644 There is no restriction on the use of the 16-bit error code space for 4645 application protocols. However, QUIC reserves the error code with a 4646 value of 0 to mean STOPPING. The application error code of STOPPING 4647 (0) is used by the transport to cancel a stream in response to 4648 receipt of a STOP_SENDING frame. 4650 12. Security Considerations 4652 12.1. Handshake Denial of Service 4654 As an encrypted and authenticated transport QUIC provides a range of 4655 protections against denial of service. Once the cryptographic 4656 handshake is complete, QUIC endpoints discard most packets that are 4657 not authenticated, greatly limiting the ability of an attacker to 4658 interfere with existing connections. 4660 Once a connection is established QUIC endpoints might accept some 4661 unauthenticated ICMP packets (see Section 8.4.1), but the use of 4662 these packets is extremely limited. The only other type of packet 4663 that an endpoint might accept is a stateless reset (Section 6.13.4) 4664 which relies on the token being kept secret until it is used. 4666 During the creation of a connection, QUIC only provides protection 4667 against attack from off the network path. All QUIC packets contain 4668 proof that the recipient saw a preceding packet from its peer. 4670 The first mechanism used is the source and destination connection 4671 IDs, which are required to match those set by a peer. Except for an 4672 Initial and stateless reset packets, an endpoint only accepts packets 4673 that include a destination connection that matches a connection ID 4674 the endpoint previously chose. This is the only protection offered 4675 for Version Negotiation packets. 4677 The destination connection ID in an Initial packet is selected by a 4678 client to be unpredictable, which serves an additional purpose. The 4679 packets that carry the cryptographic handshake are protected with a 4680 key that is derived from this connection ID and salt specific to the 4681 QUIC version. This allows endpoints to use the same process for 4682 authenticating packets that they receive as they use after the 4683 cryptographic handshake completes. Packets that cannot be 4684 authenticated are discarded. Protecting packets in this fashion 4685 provides a strong assurance that the sender of the packet saw the 4686 Initial packet and understood it. 4688 These protections are not intended to be effective against an 4689 attacker that is able to receive QUIC packets prior to the connection 4690 being established. Such an attacker can potentially send packets 4691 that will be accepted by QUIC endpoints. This version of QUIC 4692 attempts to detect this sort of attack, but it expects that endpoints 4693 will fail to establish a connection rather than recovering. For the 4694 most part, the cryptographic handshake protocol [QUIC-TLS] is 4695 responsible for detecting tampering during the handshake, though 4696 additional validation is required for version negotiation (see 4697 Section 6.6.4). 4699 Endpoints are permitted to use other methods to detect and attempt to 4700 recover from interference with the handshake. Invalid packets may be 4701 identified and discarded using other methods, but no specific method 4702 is mandated in this document. 4704 12.2. Spoofed ACK Attack 4706 An attacker might be able to receive an address validation token 4707 (Section 6.9) from the server and then release the IP address it used 4708 to acquire that token. The attacker may, in the future, spoof this 4709 same address (which now presumably addresses a different endpoint), 4710 and initiate a 0-RTT connection with a server on the victim's behalf. 4711 The attacker can then spoof ACK frames to the server which cause the 4712 server to send excessive amounts of data toward the new owner of the 4713 IP address. 4715 There are two possible mitigations to this attack. The simplest one 4716 is that a server can unilaterally create a gap in packet-number 4717 space. In the non-attack scenario, the client will send an ACK frame 4718 with the larger value for largest acknowledged. In the attack 4719 scenario, the attacker could acknowledge a packet in the gap. If the 4720 server sees an acknowledgment for a packet that was never sent, the 4721 connection can be aborted. 4723 The second mitigation is that the server can require that 4724 acknowledgments for sent packets match the encryption level of the 4725 sent packet. This mitigation is useful if the connection has an 4726 ephemeral forward-secure key that is generated and used for every new 4727 connection. If a packet sent is protected with a forward-secure key, 4728 then any acknowledgments that are received for them MUST also be 4729 forward-secure protected. Since the attacker will not have the 4730 forward secure key, the attacker will not be able to generate 4731 forward-secure protected packets with ACK frames. 4733 12.3. Optimistic ACK Attack 4735 An endpoint that acknowledges packets it has not received might cause 4736 a congestion controller to permit sending at rates beyond what the 4737 network supports. An endpoint MAY skip packet numbers when sending 4738 packets to detect this behavior. An endpoint can then immediately 4739 close the connection with a connection error of type 4740 PROTOCOL_VIOLATION (see Section 6.13.3). 4742 12.4. Slowloris Attacks 4744 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 4745 connections to the target endpoint open and hold them open as long as 4746 possible. These attacks can be executed against a QUIC endpoint by 4747 generating the minimum amount of activity necessary to avoid being 4748 closed for inactivity. This might involve sending small amounts of 4749 data, gradually opening flow control windows in order to control the 4750 sender rate, or manufacturing ACK frames that simulate a high loss 4751 rate. 4753 QUIC deployments SHOULD provide mitigations for the Slowloris 4754 attacks, such as increasing the maximum number of clients the server 4755 will allow, limiting the number of connections a single IP address is 4756 allowed to make, imposing restrictions on the minimum transfer speed 4757 a connection is allowed to have, and restricting the length of time 4758 an endpoint is allowed to stay connected. 4760 12.5. Stream Fragmentation and Reassembly Attacks 4762 An adversarial endpoint might intentionally fragment the data on 4763 stream buffers in order to cause disproportionate memory commitment. 4764 An adversarial endpoint could open a stream and send some STREAM 4765 frames containing arbitrary fragments of the stream content. 4767 The attack is mitigated if flow control windows correspond to 4768 available memory. However, some receivers will over-commit memory 4769 and advertise flow control offsets in the aggregate that exceed 4770 actual available memory. The over-commitment strategy can lead to 4771 better performance when endpoints are well behaved, but renders 4772 endpoints vulnerable to the stream fragmentation attack. 4774 QUIC deployments SHOULD provide mitigations against the stream 4775 fragmentation attack. Mitigations could consist of avoiding over- 4776 committing memory, delaying reassembly of STREAM frames, implementing 4777 heuristics based on the age and duration of reassembly holes, or some 4778 combination. 4780 12.6. Stream Commitment Attack 4782 An adversarial endpoint can open lots of streams, exhausting state on 4783 an endpoint. The adversarial endpoint could repeat the process on a 4784 large number of connections, in a manner similar to SYN flooding 4785 attacks in TCP. 4787 Normally, clients will open streams sequentially, as explained in 4788 Section 9.1. However, when several streams are initiated at short 4789 intervals, transmission error may cause STREAM DATA frames opening 4790 streams to be received out of sequence. A receiver is obligated to 4791 open intervening streams if a higher-numbered stream ID is received. 4792 Thus, on a new connection, opening stream 2000001 opens 1 million 4793 streams, as required by the specification. 4795 The number of active streams is limited by the concurrent stream 4796 limit transport parameter, as explained in Section 9.4. If chosen 4797 judisciously, this limit mitigates the effect of the stream 4798 commitment attack. However, setting the limit too low could affect 4799 performance when applications expect to open large number of streams. 4801 12.7. Explicit Congestion Notification Attacks 4803 An on-path attacker could manipulate the value of ECN codepoints in 4804 the IP header to influence the sender's rate. [RFC3168] discusses 4805 manipulations and their effects in more detail. 4807 An on-the-side attacker can duplicate and send packets with modified 4808 ECN codepoints to affect the sender's rate. If duplicate packets are 4809 discarded by a receiver, an off-path attacker will need to race the 4810 duplicate packet against the original to be successful in this 4811 attack. Therefore, QUIC receivers ignore ECN codepoints set in 4812 duplicate packets (see Section 6.8). 4814 13. IANA Considerations 4815 13.1. QUIC Transport Parameter Registry 4817 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 4818 under a "QUIC Protocol" heading. 4820 The "QUIC Transport Parameters" registry governs a 16-bit space. 4821 This space is split into two spaces that are governed by different 4822 policies. Values with the first byte in the range 0x00 to 0xfe (in 4823 hexadecimal) are assigned via the Specification Required policy 4824 [RFC8126]. Values with the first byte 0xff are reserved for Private 4825 Use [RFC8126]. 4827 Registrations MUST include the following fields: 4829 Value: The numeric value of the assignment (registrations will be 4830 between 0x0000 and 0xfeff). 4832 Parameter Name: A short mnemonic for the parameter. 4834 Specification: A reference to a publicly available specification for 4835 the value. 4837 The nominated expert(s) verify that a specification exists and is 4838 readily accessible. Expert(s) are encouraged to be biased towards 4839 approving registrations unless they are abusive, frivolous, or 4840 actively harmful (not merely aesthetically displeasing, or 4841 architecturally dubious). 4843 The initial contents of this registry are shown in Table 7. 4845 +--------+--------------------------+---------------+ 4846 | Value | Parameter Name | Specification | 4847 +--------+--------------------------+---------------+ 4848 | 0x0000 | initial_max_stream_data | Section 6.6.1 | 4849 | | | | 4850 | 0x0001 | initial_max_data | Section 6.6.1 | 4851 | | | | 4852 | 0x0002 | initial_max_bidi_streams | Section 6.6.1 | 4853 | | | | 4854 | 0x0003 | idle_timeout | Section 6.6.1 | 4855 | | | | 4856 | 0x0004 | preferred_address | Section 6.6.1 | 4857 | | | | 4858 | 0x0005 | max_packet_size | Section 6.6.1 | 4859 | | | | 4860 | 0x0006 | stateless_reset_token | Section 6.6.1 | 4861 | | | | 4862 | 0x0007 | ack_delay_exponent | Section 6.6.1 | 4863 | | | | 4864 | 0x0008 | initial_max_uni_streams | Section 6.6.1 | 4865 +--------+--------------------------+---------------+ 4867 Table 7: Initial QUIC Transport Parameters Entries 4869 13.2. QUIC Frame Type Registry 4871 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 4872 "QUIC Protocol" heading. 4874 The "QUIC Frame Types" registry governs a 62-bit space. This space 4875 is split into three spaces that are governed by different policies. 4876 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 4877 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 4878 to 0x3fff operate on the Specification Required policy [RFC8126]. 4879 All other values are assigned to Private Use [RFC8126]. 4881 Registrations MUST include the following fields: 4883 Value: The numeric value of the assignment (registrations will be 4884 between 0x00 and 0x3fff). A range of values MAY be assigned. 4886 Frame Name: A short mnemonic for the frame type. 4888 Specification: A reference to a publicly available specification for 4889 the value. 4891 The nominated expert(s) verify that a specification exists and is 4892 readily accessible. Specifications for new registrations need to 4893 describe the means by which an endpoint might determine that it can 4894 send the identified type of frame. An accompanying transport 4895 parameter registration (see Section 13.1) is expected for most 4896 registrations. The specification needs to describe the format and 4897 assigned semantics of any fields in the frame. 4899 Expert(s) are encouraged to be biased towards approving registrations 4900 unless they are abusive, frivolous, or actively harmful (not merely 4901 aesthetically displeasing, or architecturally dubious). 4903 The initial contents of this registry are tabulated in Table 3. 4905 13.3. QUIC Transport Error Codes Registry 4907 IANA [SHALL add/has added] a registry for "QUIC Transport Error 4908 Codes" under a "QUIC Protocol" heading. 4910 The "QUIC Transport Error Codes" registry governs a 16-bit space. 4911 This space is split into two spaces that are governed by different 4912 policies. Values with the first byte in the range 0x00 to 0xfe (in 4913 hexadecimal) are assigned via the Specification Required policy 4914 [RFC8126]. Values with the first byte 0xff are reserved for Private 4915 Use [RFC8126]. 4917 Registrations MUST include the following fields: 4919 Value: The numeric value of the assignment (registrations will be 4920 between 0x0000 and 0xfeff). 4922 Code: A short mnemonic for the parameter. 4924 Description: A brief description of the error code semantics, which 4925 MAY be a summary if a specification reference is provided. 4927 Specification: A reference to a publicly available specification for 4928 the value. 4930 The initial contents of this registry are shown in Table 8. Values 4931 from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. 4933 +------+---------------------------+----------------+---------------+ 4934 | Valu | Error | Description | Specification | 4935 | e | | | | 4936 +------+---------------------------+----------------+---------------+ 4937 | 0x0 | NO_ERROR | No error | Section 11.3 | 4938 | | | | | 4939 | 0x1 | INTERNAL_ERROR | Implementation | Section 11.3 | 4940 | | | error | | 4941 | | | | | 4942 | 0x2 | SERVER_BUSY | Server | Section 11.3 | 4943 | | | currently busy | | 4944 | | | | | 4945 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 11.3 | 4946 | | | error | | 4947 | | | | | 4948 | 0x4 | STREAM_ID_ERROR | Invalid stream | Section 11.3 | 4949 | | | ID | | 4950 | | | | | 4951 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 11.3 | 4952 | | | in invalid | | 4953 | | | stream state | | 4954 | | | | | 4955 | 0x6 | FINAL_OFFSET_ERROR | Change to | Section 11.3 | 4956 | | | final stream | | 4957 | | | offset | | 4958 | | | | | 4959 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 11.3 | 4960 | | | error | | 4961 | | | | | 4962 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 11.3 | 4963 | | | transport | | 4964 | | | parameters | | 4965 | | | | | 4966 | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 11.3 | 4967 | | | negotiation | | 4968 | | | failure | | 4969 | | | | | 4970 | 0xA | PROTOCOL_VIOLATION | Generic | Section 11.3 | 4971 | | | protocol | | 4972 | | | violation | | 4973 | | | | | 4974 | 0xB | UNSOLICITED_PATH_RESPONSE | Unsolicited | Section 11.3 | 4975 | | | PATH_RESPONSE | | 4976 | | | frame | | 4977 | | | | | 4978 | 0xC | INVALID_MIGRATION | Violated | Section 11.3 | 4979 | | | disabled | | 4980 | | | migration | | 4981 +------+---------------------------+----------------+---------------+ 4983 Table 8: Initial QUIC Transport Error Codes Entries 4985 14. References 4987 14.1. Normative References 4989 [I-D.ietf-tls-tls13] 4990 Rescorla, E., "The Transport Layer Security (TLS) Protocol 4991 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 4992 July 2017. 4994 [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 4995 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 4996 . 4998 [PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4999 DOI 10.17487/RFC1191, November 1990, 5000 . 5002 [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5003 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5004 DOI 10.17487/RFC8201, July 2017, 5005 . 5007 [QUIC-RECOVERY] 5008 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5009 and Congestion Control", draft-ietf-quic-recovery-13 (work 5010 in progress), June 2018. 5012 [QUIC-TLS] 5013 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5014 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5015 tls-13 (work in progress), June 2018. 5017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5018 Requirement Levels", BCP 14, RFC 2119, 5019 DOI 10.17487/RFC2119, March 1997, 5020 . 5022 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5023 of Explicit Congestion Notification (ECN) to IP", 5024 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5025 . 5027 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 5028 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 5029 2003, . 5031 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5032 "Randomness Requirements for Security", BCP 106, RFC 4086, 5033 DOI 10.17487/RFC4086, June 2005, 5034 . 5036 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5037 Writing an IANA Considerations Section in RFCs", BCP 26, 5038 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5039 . 5041 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5042 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5043 May 2017, . 5045 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 5046 Notification (ECN) Experimentation", RFC 8311, 5047 DOI 10.17487/RFC8311, January 2018, 5048 . 5050 14.2. Informative References 5052 [EARLY-DESIGN] 5053 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 5054 December 2013, . 5056 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 5057 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 5058 DOI 10.17487/RFC7540, May 2015, 5059 . 5061 [QUIC-INVARIANTS] 5062 Thomson, M., "Version-Independent Properties of QUIC", 5063 draft-ietf-quic-invariants-01 (work in progress), June 5064 2018. 5066 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 5067 Selective Acknowledgment Options", RFC 2018, 5068 DOI 10.17487/RFC2018, October 1996, 5069 . 5071 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5072 Hashing for Message Authentication", RFC 2104, 5073 DOI 10.17487/RFC2104, February 1997, 5074 . 5076 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 5077 RFC 2360, DOI 10.17487/RFC2360, June 1998, 5078 . 5080 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 5081 Translation (NAT) Behavioral Requirements for Unicast 5082 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 5083 2007, . 5085 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5086 Key Derivation Function (HKDF)", RFC 5869, 5087 DOI 10.17487/RFC5869, May 2010, 5088 . 5090 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5091 "Transport Layer Security (TLS) Application-Layer Protocol 5092 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5093 July 2014, . 5095 [SLOWLORIS] 5096 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 5097 . 5100 [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer 5101 Communication Review Vol. 37, pp. 361, 5102 DOI 10.1145/1282427.1282421, October 2007. 5104 Appendix A. Change Log 5106 *RFC Editor's Note:* Please remove this section prior to 5107 publication of a final version of this document. 5109 Issue and pull request numbers are listed with a leading octothorp. 5111 A.1. Since draft-ietf-quic-transport-12 5113 o Changes to integration of the TLS handshake (#829, #1018, #1094, 5114 #1165, #1190, #1233, #1242, #1252, #1450) 5116 * The cryptographic handshake uses CRYPTO frames, not stream 0 5118 * QUIC packet protection is used in place of TLS record 5119 protection 5121 * Separate QUIC packet number spaces are used for the handshake 5123 * Changed Retry to be independent of the cryptographic handshake 5125 * Added NEW_TOKEN frame and Token fields to Initial packet 5126 * Limit the use of HelloRetryRequest to address TLS needs (like 5127 key shares) 5129 o Enable server to transition connections to a preferred address 5130 (#560, #1251, #1373) 5132 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 5133 (#804, #805, #1372) 5135 o Changed rules and recommendations for use of new connection IDs 5136 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 5138 o Added a transport parameter to disable intentional connection 5139 migration (#1271, #1447) 5141 o Packets from different connection ID can't be coalesced (#1287, 5142 #1423) 5144 o Fixed sampling method for packet number encryption; the length 5145 field in long headers includes the packet number field in addition 5146 to the packet payload (#1387, #1389) 5148 o Stateless Reset is now symmetric and subject to size constraints 5149 (#466, #1346) 5151 o Added frame type extension mechanism (#58, #1473) 5153 A.2. Since draft-ietf-quic-transport-11 5155 o Enable server to transition connections to a preferred address 5156 (#560, #1251) 5158 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 5159 #990, #734, #1317, #1267, #1079) 5161 o Packet numbers use a variable-length encoding (#989, #1334) 5163 o STREAM frames can now be empty (#1350) 5165 A.3. Since draft-ietf-quic-transport-10 5167 o Swap payload length and packed number fields in long header 5168 (#1294) 5170 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 5171 (#1274) 5173 o Spin bit reserved (#1283) 5174 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 5176 o A more complete connection migration (#1249) 5178 o Refine opportunistic ACK defense text (#305, #1030, #1185) 5180 o A Stateless Reset Token isn't mandatory (#818, #1191) 5182 o Removed implicit stream opening (#896, #1193) 5184 o An empty STREAM frame can be used to open a stream without sending 5185 data (#901, #1194) 5187 o Define stream counts in transport parameters rather than a maximum 5188 stream ID (#1023, #1065) 5190 o STOP_SENDING is now prohibited before streams are used (#1050) 5192 o Recommend including ACK in Retry packets and allow PADDING (#1067, 5193 #882) 5195 o Endpoints now become closing after an idle timeout (#1178, #1179) 5197 o Remove implication that Version Negotiation is sent when a packet 5198 of the wrong version is received (#1197) 5200 A.4. Since draft-ietf-quic-transport-09 5202 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 5203 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 5204 (#1091, #725, #1086) 5206 o A server can now only send 3 packets without validating the client 5207 address (#38, #1090) 5209 o Delivery order of stream data is no longer strongly specified 5210 (#252, #1070) 5212 o Rework of packet handling and version negotiation (#1038) 5214 o Stream 0 is now exempt from flow control until the handshake 5215 completes (#1074, #725, #825, #1082) 5217 o Improved retransmission rules for all frame types: information is 5218 retransmitted, not packets or frames (#463, #765, #1095, #1053) 5220 o Added an error code for server busy signals (#1137) 5221 o Endpoints now set the connection ID that their peer uses. 5222 Connection IDs are variable length. Removed the 5223 omit_connection_id transport parameter and the corresponding short 5224 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 5226 A.5. Since draft-ietf-quic-transport-08 5228 o Clarified requirements for BLOCKED usage (#65, #924) 5230 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 5231 #928) 5233 o GAP limitation in ACK Frame (#613) 5235 o Improved PMTUD description (#614, #1036) 5237 o Clarified stream state machine (#634, #662, #743, #894) 5239 o Reserved versions don't need to be generated deterministically 5240 (#831, #931) 5242 o You don't always need the draining period (#871) 5244 o Stateless reset clarified as version-specific (#930, #986) 5246 o initial_max_stream_id_x transport parameters are optional (#970, 5247 #971) 5249 o Ack Delay assumes a default value during the handshake (#1007, 5250 #1009) 5252 o Removed transport parameters from NewSessionTicket (#1015) 5254 A.6. Since draft-ietf-quic-transport-07 5256 o The long header now has version before packet number (#926, #939) 5258 o Rename and consolidate packet types (#846, #822, #847) 5260 o Packet types are assigned new codepoints and the Connection ID 5261 Flag is inverted (#426, #956) 5263 o Removed type for Version Negotiation and use Version 0 (#963, 5264 #968) 5266 o Streams are split into unidirectional and bidirectional (#643, 5267 #656, #720, #872, #175, #885) 5268 * Stream limits now have separate uni- and bi-directinal 5269 transport parameters (#909, #958) 5271 * Stream limit transport parameters are now optional and default 5272 to 0 (#970, #971) 5274 o The stream state machine has been split into read and write (#634, 5275 #894) 5277 o Employ variable-length integer encodings throughout (#595) 5279 o Improvements to connection close 5281 * Added distinct closing and draining states (#899, #871) 5283 * Draining period can terminate early (#869, #870) 5285 * Clarifications about stateless reset (#889, #890) 5287 o Address validation for connection migration (#161, #732, #878) 5289 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 5291 o negotiated_version is sent in server transport parameters (#710, 5292 #959) 5294 o Increased the range over which packet numbers are randomized 5295 (#864, #850, #964) 5297 A.7. Since draft-ietf-quic-transport-06 5299 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 5301 o Split error code space between application and transport (#485) 5303 o Stateless reset token moved to end (#820) 5305 o 1-RTT-protected long header types removed (#848) 5307 o No acknowledgments during draining period (#852) 5309 o Remove "application close" as a separate close type (#854) 5311 o Remove timestamps from the ACK frame (#841) 5313 o Require transport parameters to only appear once (#792) 5315 A.8. Since draft-ietf-quic-transport-05 5317 o Stateless token is server-only (#726) 5319 o Refactor section on connection termination (#733, #748, #328, 5320 #177) 5322 o Limit size of Version Negotiation packet (#585) 5324 o Clarify when and what to ack (#736) 5326 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 5328 o Clarify Keep-alive requirements (#729) 5330 A.9. Since draft-ietf-quic-transport-04 5332 o Introduce STOP_SENDING frame, RST_STREAM only resets in one 5333 direction (#165) 5335 o Removed GOAWAY; application protocols are responsible for graceful 5336 shutdown (#696) 5338 o Reduced the number of error codes (#96, #177, #184, #211) 5340 o Version validation fields can't move or change (#121) 5342 o Removed versions from the transport parameters in a 5343 NewSessionTicket message (#547) 5345 o Clarify the meaning of "bytes in flight" (#550) 5347 o Public reset is now stateless reset and not visible to the path 5348 (#215) 5350 o Reordered bits and fields in STREAM frame (#620) 5352 o Clarifications to the stream state machine (#572, #571) 5354 o Increased the maximum length of the Largest Acknowledged field in 5355 ACK frames to 64 bits (#629) 5357 o truncate_connection_id is renamed to omit_connection_id (#659) 5359 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 5360 #328) 5362 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 5364 A.10. Since draft-ietf-quic-transport-03 5366 o Change STREAM and RST_STREAM layout 5368 o Add MAX_STREAM_ID settings 5370 A.11. Since draft-ietf-quic-transport-02 5372 o The size of the initial packet payload has a fixed minimum (#267, 5373 #472) 5375 o Define when Version Negotiation packets are ignored (#284, #294, 5376 #241, #143, #474) 5378 o The 64-bit FNV-1a algorithm is used for integrity protection of 5379 unprotected packets (#167, #480, #481, #517) 5381 o Rework initial packet types to change how the connection ID is 5382 chosen (#482, #442, #493) 5384 o No timestamps are forbidden in unprotected packets (#542, #429) 5386 o Cryptographic handshake is now on stream 0 (#456) 5388 o Remove congestion control exemption for cryptographic handshake 5389 (#248, #476) 5391 o Version 1 of QUIC uses TLS; a new version is needed to use a 5392 different handshake protocol (#516) 5394 o STREAM frames have a reduced number of offset lengths (#543, #430) 5396 o Split some frames into separate connection- and stream- level 5397 frames (#443) 5399 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 5401 * BLOCKED split to match WINDOW_UPDATE split (#454) 5403 * Define STREAM_ID_NEEDED frame (#455) 5405 o A NEW_CONNECTION_ID frame supports connection migration without 5406 linkability (#232, #491, #496) 5408 o Transport parameters for 0-RTT are retained from a previous 5409 connection (#405, #513, #512) 5410 * A client in 0-RTT no longer required to reset excess streams 5411 (#425, #479) 5413 o Expanded security considerations (#440, #444, #445, #448) 5415 A.12. Since draft-ietf-quic-transport-01 5417 o Defined short and long packet headers (#40, #148, #361) 5419 o Defined a versioning scheme and stable fields (#51, #361) 5421 o Define reserved version values for "greasing" negotiation (#112, 5422 #278) 5424 o The initial packet number is randomized (#35, #283) 5426 o Narrow the packet number encoding range requirement (#67, #286, 5427 #299, #323, #356) 5429 o Defined client address validation (#52, #118, #120, #275) 5431 o Define transport parameters as a TLS extension (#49, #122) 5433 o SCUP and COPT parameters are no longer valid (#116, #117) 5435 o Transport parameters for 0-RTT are either remembered from before, 5436 or assume default values (#126) 5438 o The server chooses connection IDs in its final flight (#119, #349, 5439 #361) 5441 o The server echoes the Connection ID and packet number fields when 5442 sending a Version Negotiation packet (#133, #295, #244) 5444 o Defined a minimum packet size for the initial handshake packet 5445 from the client (#69, #136, #139, #164) 5447 o Path MTU Discovery (#64, #106) 5449 o The initial handshake packet from the client needs to fit in a 5450 single packet (#338) 5452 o Forbid acknowledgment of packets containing only ACK and PADDING 5453 (#291) 5455 o Require that frames are processed when packets are acknowledged 5456 (#381, #341) 5458 o Removed the STOP_WAITING frame (#66) 5460 o Don't require retransmission of old timestamps for lost ACK frames 5461 (#308) 5463 o Clarified that frames are not retransmitted, but the information 5464 in them can be (#157, #298) 5466 o Error handling definitions (#335) 5468 o Split error codes into four sections (#74) 5470 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 5471 (#289) 5473 o Define packet protection rules (#336) 5475 o Require that stream be entirely delivered or reset, including 5476 acknowledgment of all STREAM frames or the RST_STREAM, before it 5477 closes (#381) 5479 o Remove stream reservation from state machine (#174, #280) 5481 o Only stream 1 does not contribute to connection-level flow control 5482 (#204) 5484 o Stream 1 counts towards the maximum concurrent stream limit (#201, 5485 #282) 5487 o Remove connection-level flow control exclusion for some streams 5488 (except 1) (#246) 5490 o RST_STREAM affects connection-level flow control (#162, #163) 5492 o Flow control accounting uses the maximum data offset on each 5493 stream, rather than bytes received (#378) 5495 o Moved length-determining fields to the start of STREAM and ACK 5496 (#168, #277) 5498 o Added the ability to pad between frames (#158, #276) 5500 o Remove error code and reason phrase from GOAWAY (#352, #355) 5502 o GOAWAY includes a final stream number for both directions (#347) 5504 o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a 5505 consistent offset (#249) 5507 o Defined priority as the responsibility of the application protocol 5508 (#104, #303) 5510 A.13. Since draft-ietf-quic-transport-00 5512 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 5514 o Defined versioning 5516 o Reworked description of packet and frame layout 5518 o Error code space is divided into regions for each component 5520 o Use big endian for all numeric values 5522 A.14. Since draft-hamilton-quic-transport-protocol-01 5524 o Adopted as base for draft-ietf-quic-tls 5526 o Updated authors/editors list 5528 o Added IANA Considerations section 5530 o Moved Contributors and Acknowledgments to appendices 5532 Acknowledgments 5534 Special thanks are due to the following for helping shape pre-IETF 5535 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 5536 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 5538 This document has benefited immensely from various private 5539 discussions and public ones on the quic@ietf.org and proto- 5540 quic@chromium.org mailing lists. Our thanks to all. 5542 Contributors 5544 The original authors of this specification were Ryan Hamilton, Jana 5545 Iyengar, Ian Swett, and Alyssa Wilk. 5547 The original design and rationale behind this protocol draw 5548 significantly from work by Jim Roskind [EARLY-DESIGN]. In 5549 alphabetical order, the contributors to the pre-IETF QUIC project at 5550 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 5551 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 5552 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 5553 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 5554 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 5556 Authors' Addresses 5558 Jana Iyengar (editor) 5559 Fastly 5561 Email: jri.ietf@gmail.com 5563 Martin Thomson (editor) 5564 Mozilla 5566 Email: martin.thomson@gmail.com