idnits 2.17.1 draft-ietf-quic-transport-15.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The server includes a connection ID of its choice in the Source Connection ID field. This value MUST not be equal to the Destination Connection ID field of the packet sent by the client. The client MUST use this connection ID in the Destination Connection ID of subsequent packets that it sends. -- The document date (October 03, 2018) is 2031 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 1738 == Missing Reference: 'CH' is mentioned on line 1725, but not defined == Missing Reference: 'SH' is mentioned on line 1728, but not defined == Missing Reference: 'EE' is mentioned on line 1729, but not defined == Missing Reference: 'CERT' is mentioned on line 1729, but not defined == Missing Reference: 'CV' is mentioned on line 1729, but not defined == Missing Reference: 'FIN' is mentioned on line 1734, but not defined -- Looks like a reference, but probably isn't: '1' on line 1738 == Missing Reference: 'EOED' is mentioned on line 1733, but not defined -- Looks like a reference, but probably isn't: '2' on line 1737 -- Looks like a reference, but probably isn't: '16' on line 1796 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-15 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-15 -- 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-03 -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 8 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: April 6, 2019 Mozilla 6 October 03, 2018 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-15 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 April 6, 2019. 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. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5. Cryptographic Handshake Packets . . . . . . . . . . . . . 16 72 4.6. Initial Packet . . . . . . . . . . . . . . . . . . . . . 17 73 4.6.1. Connection IDs . . . . . . . . . . . . . . . . . . . 18 74 4.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 19 75 4.6.3. Starting Packet Numbers . . . . . . . . . . . . . . . 20 76 4.6.4. 0-RTT Packet Numbers . . . . . . . . . . . . . . . . 20 77 4.6.5. Minimum Packet Size . . . . . . . . . . . . . . . . . 21 78 4.7. Handshake Packet . . . . . . . . . . . . . . . . . . . . 21 79 4.8. Protected Packets . . . . . . . . . . . . . . . . . . . . 22 80 4.9. Coalescing Packets . . . . . . . . . . . . . . . . . . . 22 81 4.10. Connection ID Encoding . . . . . . . . . . . . . . . . . 23 82 4.11. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 24 83 5. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 27 84 5.1. Extension Frames . . . . . . . . . . . . . . . . . . . . 30 85 6. Life of a Connection . . . . . . . . . . . . . . . . . . . . 30 86 6.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 31 87 6.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 31 88 6.1.2. Consuming and Retiring Connection IDs . . . . . . . . 32 89 6.2. Matching Packets to Connections . . . . . . . . . . . . . 32 90 6.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33 91 6.2.2. Server Packet Handling . . . . . . . . . . . . . . . 33 92 6.3. Version Negotiation . . . . . . . . . . . . . . . . . . . 34 93 6.3.1. Sending Version Negotiation Packets . . . . . . . . . 34 94 6.3.2. Handling Version Negotiation Packets . . . . . . . . 35 95 6.3.3. Using Reserved Versions . . . . . . . . . . . . . . . 35 96 6.4. Cryptographic and Transport Handshake . . . . . . . . . . 36 97 6.5. Example Handshake Flows . . . . . . . . . . . . . . . . . 37 98 6.6. Transport Parameters . . . . . . . . . . . . . . . . . . 38 99 6.6.1. Transport Parameter Definitions . . . . . . . . . . . 41 100 6.6.2. Values of Transport Parameters for 0-RTT . . . . . . 43 101 6.6.3. New Transport Parameters . . . . . . . . . . . . . . 44 102 6.6.4. Version Negotiation Validation . . . . . . . . . . . 45 103 6.7. Stateless Retries . . . . . . . . . . . . . . . . . . . . 46 104 6.8. Using Explicit Congestion Notification . . . . . . . . . 46 105 6.9. Proof of Source Address Ownership . . . . . . . . . . . . 48 106 6.9.1. Client Address Validation Procedure . . . . . . . . . 49 107 6.9.2. Address Validation for Future Connections . . . . . . 50 108 6.9.3. Address Validation Token Integrity . . . . . . . . . 50 109 6.10. Path Validation . . . . . . . . . . . . . . . . . . . . . 51 110 6.10.1. Initiation . . . . . . . . . . . . . . . . . . . . . 51 111 6.10.2. Response . . . . . . . . . . . . . . . . . . . . . . 52 112 6.10.3. Completion . . . . . . . . . . . . . . . . . . . . . 52 113 6.10.4. Abandonment . . . . . . . . . . . . . . . . . . . . 53 114 6.11. Connection Migration . . . . . . . . . . . . . . . . . . 53 115 6.11.1. Probing a New Path . . . . . . . . . . . . . . . . . 54 116 6.11.2. Initiating Connection Migration . . . . . . . . . . 54 117 6.11.3. Responding to Connection Migration . . . . . . . . . 55 118 6.11.4. Loss Detection and Congestion Control . . . . . . . 56 119 6.11.5. Privacy Implications of Connection Migration . . . . 57 120 6.12. Server's Preferred Address . . . . . . . . . . . . . . . 58 121 6.12.1. Communicating A Preferred Address . . . . . . . . . 59 122 6.12.2. Responding to Connection Migration . . . . . . . . . 59 123 6.12.3. Interaction of Client Migration and Preferred 124 Address . . . . . . . . . . . . . . . . . . . . . . 59 125 6.13. Connection Termination . . . . . . . . . . . . . . . . . 60 126 6.13.1. Closing and Draining Connection States . . . . . . . 60 127 6.13.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 61 128 6.13.3. Immediate Close . . . . . . . . . . . . . . . . . . 62 129 6.13.4. Stateless Reset . . . . . . . . . . . . . . . . . . 63 130 7. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 67 131 7.1. Variable-Length Integer Encoding . . . . . . . . . . . . 67 132 7.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 68 133 7.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 68 134 7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 69 135 7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 70 136 7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 71 137 7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 72 138 7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 73 139 7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 73 140 7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 74 141 7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 74 142 7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 75 143 7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 75 144 7.14. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 77 145 7.15. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 77 146 7.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 78 147 7.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 79 148 7.16.2. ECN section . . . . . . . . . . . . . . . . . . . . 81 149 7.16.3. Sending ACK Frames . . . . . . . . . . . . . . . . . 82 150 7.16.4. ACK Frames and Packet Protection . . . . . . . . . . 83 151 7.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 83 152 7.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 84 153 7.19. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . . 84 154 7.20. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 84 155 7.21. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 86 156 8. Packetization and Reliability . . . . . . . . . . . . . . . . 87 157 8.1. Packet Processing and Acknowledgment . . . . . . . . . . 87 158 8.2. Retransmission of Information . . . . . . . . . . . . . . 88 159 8.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 90 160 8.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 90 161 8.4.1. IPv4 PMTU Discovery . . . . . . . . . . . . . . . . . 91 162 8.4.2. Special Considerations for Packetization Layer PMTU 163 Discovery . . . . . . . . . . . . . . . . . . . . . . 92 164 9. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 92 165 9.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 93 166 9.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 94 167 9.2.1. Send Stream States . . . . . . . . . . . . . . . . . 95 168 9.2.2. Receive Stream States . . . . . . . . . . . . . . . . 97 169 9.2.3. Permitted Frame Types . . . . . . . . . . . . . . . . 99 170 9.2.4. Bidirectional Stream States . . . . . . . . . . . . . 99 171 9.3. Solicited State Transitions . . . . . . . . . . . . . . . 101 172 9.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 101 173 9.5. Sending and Receiving Data . . . . . . . . . . . . . . . 102 174 9.6. Stream Prioritization . . . . . . . . . . . . . . . . . . 102 175 10. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 103 176 10.1. Edge Cases and Other Considerations . . . . . . . . . . 105 177 10.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 105 178 10.1.2. Data Limit Increments . . . . . . . . . . . . . . . 105 179 10.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 106 180 10.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 106 181 10.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 107 182 10.4. Flow Control for Cryptographic Handshake . . . . . . . . 107 183 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 107 184 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 108 185 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 108 186 11.3. Transport Error Codes . . . . . . . . . . . . . . . . . 109 187 11.4. Application Protocol Error Codes . . . . . . . . . . . . 110 188 12. Security Considerations . . . . . . . . . . . . . . . . . . . 110 189 12.1. Handshake Denial of Service . . . . . . . . . . . . . . 110 190 12.2. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 111 191 12.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 112 192 12.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 112 193 12.5. Stream Fragmentation and Reassembly Attacks . . . . . . 113 194 12.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 113 195 12.7. Explicit Congestion Notification Attacks . . . . . . . . 114 196 12.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 114 197 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114 198 13.1. QUIC Transport Parameter Registry . . . . . . . . . . . 114 199 13.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 116 200 13.3. QUIC Transport Error Codes Registry . . . . . . . . . . 117 201 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 202 14.1. Normative References . . . . . . . . . . . . . . . . . . 120 203 14.2. Informative References . . . . . . . . . . . . . . . . . 121 204 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 122 205 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 123 206 B.1. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 123 207 B.2. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 124 208 B.3. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 124 209 B.4. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 125 210 B.5. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 126 211 B.6. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 126 212 B.7. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 127 213 B.8. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 127 214 B.9. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 128 215 B.10. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 129 216 B.11. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 129 217 B.12. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 130 218 B.13. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 130 219 B.14. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 131 220 B.15. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 133 221 B.16. Since draft-hamilton-quic-transport-protocol-01 . . . . . 133 222 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 133 223 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 134 224 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 134 226 1. Introduction 228 QUIC is a multiplexed and secure transport protocol that runs on top 229 of UDP. QUIC aims to provide a flexible set of features that allow 230 it to be a general-purpose secure transport for multiple 231 applications. 233 o Version negotiation 235 o Low-latency connection establishment 236 o Authenticated and encrypted header and payload 238 o Stream multiplexing 240 o Stream and connection-level flow control 242 o Connection migration and resilience to NAT rebinding 244 QUIC uses UDP as a substrate to avoid requiring changes in legacy 245 client operating systems and middleboxes. QUIC authenticates all of 246 its headers and encrypts most of the data it exchanges, including its 247 signaling. This allows the protocol to evolve without incurring a 248 dependency on upgrades to middleboxes. 250 This document describes the core QUIC protocol, including the 251 conceptual design, wire format, and mechanisms of the QUIC protocol 252 for connection establishment, stream multiplexing, stream and 253 connection-level flow control, connection migration, and data 254 reliability. 256 Accompanying documents describe QUIC's loss detection and congestion 257 control [QUIC-RECOVERY], and the use of TLS 1.3 for key negotiation 258 [QUIC-TLS]. 260 QUIC version 1 conforms to the protocol invariants in 261 [QUIC-INVARIANTS]. 263 2. Conventions and Definitions 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 267 "OPTIONAL" in this document are to be interpreted as described in BCP 268 14 [RFC2119] [RFC8174] when, and only when, they appear in all 269 capitals, as shown here. 271 Definitions of terms that are used in this document: 273 Client: The endpoint initiating a QUIC connection. 275 Server: The endpoint accepting incoming QUIC connections. 277 Endpoint: The client or server end of a connection. 279 Stream: A logical, bi-directional channel of ordered bytes within a 280 QUIC connection. 282 Connection: A conversation between two QUIC endpoints with a single 283 encryption context that multiplexes streams within it. 285 Connection ID: An opaque identifier that is used to identify a QUIC 286 connection at an endpoint. Each endpoint sets a value that its 287 peer includes in packets. 289 QUIC packet: The smallest unit of data that can be exchanged by QUIC 290 endpoints. 292 QUIC is a name, not an acronym. 294 2.1. Notational Conventions 296 Packet and frame diagrams use the format described in Section 3.1 of 297 [RFC2360], with the following additional conventions: 299 [x] Indicates that x is optional 301 x (A) Indicates that x is A bits long 303 x (A/B/C) ... Indicates that x is one of A, B, or C bits long 305 x (i) ... Indicates that x uses the variable-length encoding in 306 Section 7.1 308 x (*) ... Indicates that x is variable-length 310 3. Versions 312 QUIC versions are identified using a 32-bit unsigned number. 314 The version 0x00000000 is reserved to represent version negotiation. 315 This version of the specification is identified by the number 316 0x00000001. 318 Other versions of QUIC might have different properties to this 319 version. The properties of QUIC that are guaranteed to be consistent 320 across all versions of the protocol are described in 321 [QUIC-INVARIANTS]. 323 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 324 protocol, as described in [QUIC-TLS]. 326 Versions with the most significant 16 bits of the version number 327 cleared are reserved for use in future IETF consensus documents. 329 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 330 forcing version negotiation to be exercised. That is, any version 331 number where the low four bits of all octets is 1010 (in binary). A 332 client or server MAY advertise support for any of these reserved 333 versions. 335 Reserved version numbers will probably never represent a real 336 protocol; a client MAY use one of these version numbers with the 337 expectation that the server will initiate version negotiation; a 338 server MAY advertise support for one of these versions and can expect 339 that clients ignore the value. 341 [[RFC editor: please remove the remainder of this section before 342 publication.]] 344 The version number for the final version of this specification 345 (0x00000001), is reserved for the version of the protocol that is 346 published as an RFC. 348 Version numbers used to identify IETF drafts are created by adding 349 the draft number to 0xff000000. For example, draft-ietf-quic- 350 transport-13 would be identified as 0xff00000D. 352 Implementors are encouraged to register version numbers of QUIC that 353 they are using for private experimentation on the GitHub wiki at 354 . 356 4. Packet Types and Formats 358 We first describe QUIC's packet types and their formats, since some 359 are referenced in subsequent mechanisms. 361 All numeric values are encoded in network byte order (that is, big- 362 endian) and all field sizes are in bits. When discussing individual 363 bits of fields, the least significant bit is referred to as bit 0. 364 Hexadecimal notation is used for describing the value of fields. 366 Any QUIC packet has either a long or a short header, as indicated by 367 the Header Form bit. Long headers are expected to be used early in 368 the connection before version negotiation and establishment of 1-RTT 369 keys. Short headers are minimal version-specific headers, which are 370 used after version negotiation and 1-RTT keys are established. 372 4.1. Long Header 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+ 376 |1| Type (7) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Version (32) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |DCIL(4)|SCIL(4)| 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Destination Connection ID (0/32..144) ... 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Source Connection ID (0/32..144) ... 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Length (i) ... 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Packet Number (8/16/32) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Payload (*) ... 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 1: Long Header Packet Format 395 Long headers are used for packets that are sent prior to the 396 completion of version negotiation and establishment of 1-RTT keys. 397 Once both conditions are met, a sender switches to sending packets 398 using the short header (Section 4.2). The long form allows for 399 special packets - such as the Version Negotiation packet - to be 400 represented in this uniform fixed-length packet format. Packets that 401 use the long header contain the following fields: 403 Header Form: The most significant bit (0x80) of octet 0 (the first 404 octet) is set to 1 for long headers. 406 Long Packet Type: The remaining seven bits of octet 0 contain the 407 packet type. This field can indicate one of 128 packet types. 408 The types specified for this version are listed in Table 1. 410 Version: The QUIC Version is a 32-bit field that follows the Type. 411 This field indicates which version of QUIC is in use and 412 determines how the rest of the protocol fields are interpreted. 414 DCIL and SCIL: The octet following the version contains the lengths 415 of the two connection ID fields that follow it. These lengths are 416 encoded as two 4-bit unsigned integers. The Destination 417 Connection ID Length (DCIL) field occupies the 4 high bits of the 418 octet and the Source Connection ID Length (SCIL) field occupies 419 the 4 low bits of the octet. An encoded length of 0 indicates 420 that the connection ID is also 0 octets in length. Non-zero 421 encoded lengths are increased by 3 to get the full length of the 422 connection ID, producing a length between 4 and 18 octets 423 inclusive. For example, an octet with the value 0x50 describes an 424 8-octet Destination Connection ID and a zero-length Source 425 Connection ID. 427 Destination Connection ID: The Destination Connection ID field 428 follows the connection ID lengths and is either 0 octets in length 429 or between 4 and 18 octets. Section 4.10 describes the use of 430 this field in more detail. 432 Source Connection ID: The Source Connection ID field follows the 433 Destination Connection ID and is either 0 octets in length or 434 between 4 and 18 octets. Section 4.10 describes the use of this 435 field in more detail. 437 Length: The length of the remainder of the packet (that is, the 438 Packet Number and Payload fields) in octets, encoded as a 439 variable-length integer (Section 7.1). 441 Packet Number: The packet number field is 1, 2, or 4 octets long. 442 The packet number has confidentiality protection separate from 443 packet protection, as described in Section 5.3 of [QUIC-TLS]. The 444 length of the packet number field is encoded in the plaintext 445 packet number. See Section 4.11 for details. 447 Payload: The payload of the packet. 449 The following packet types are defined: 451 +------+-----------------+-------------+ 452 | Type | Name | Section | 453 +------+-----------------+-------------+ 454 | 0x7F | Initial | Section 4.6 | 455 | | | | 456 | 0x7E | Retry | Section 4.4 | 457 | | | | 458 | 0x7D | Handshake | Section 4.7 | 459 | | | | 460 | 0x7C | 0-RTT Protected | Section 4.8 | 461 +------+-----------------+-------------+ 463 Table 1: Long Header Packet Types 465 The header form, type, connection ID lengths octet, destination and 466 source connection IDs, and version fields of a long header packet are 467 version-independent. The packet number and values for packet types 468 defined in Table 1 are version-specific. See [QUIC-INVARIANTS] for 469 details on how packets from different versions of QUIC are 470 interpreted. 472 The interpretation of the fields and the payload are specific to a 473 version and packet type. Type-specific semantics for this version 474 are described in the following sections. 476 The end of the packet is determined by the Length field. The Length 477 field covers both the Packet Number and Payload fields, both of which 478 are confidentiality protected and initially of unknown length. The 479 size of the Payload field is learned once the packet number 480 protection is removed. 482 Senders can sometimes coalesce multiple packets into one UDP 483 datagram. See Section 4.9 for more details. 485 4.2. Short Header 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+ 490 |0|K|1|1|0|R R R| 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Destination Connection ID (0..144) ... 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Packet Number (8/16/32) ... 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Protected Payload (*) ... 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Figure 2: Short Header Packet Format 501 The short header can be used after the version and 1-RTT keys are 502 negotiated. Packets that use the short header contain the following 503 fields: 505 Header Form: The most significant bit (0x80) of octet 0 is set to 0 506 for the short header. 508 Key Phase Bit: The second bit (0x40) of octet 0 indicates the key 509 phase, which allows a recipient of a packet to identify the packet 510 protection keys that are used to protect the packet. See 511 [QUIC-TLS] for details. 513 [[Editor's Note: this section should be removed and the bit 514 definitions changed before this draft goes to the IESG.]] 516 Third Bit: The third bit (0x20) of octet 0 is set to 1. 518 [[Editor's Note: this section should be removed and the bit 519 definitions changed before this draft goes to the IESG.]] 521 Fourth Bit: The fourth bit (0x10) of octet 0 is set to 1. 523 [[Editor's Note: this section should be removed and the bit 524 definitions changed before this draft goes to the IESG.]] 526 Google QUIC Demultiplexing Bit: The fifth bit (0x8) of octet 0 is 527 set to 0. This allows implementations of Google QUIC to 528 distinguish Google QUIC packets from short header packets sent by 529 a client because Google QUIC servers expect the connection ID to 530 always be present. The special interpretation of this bit SHOULD 531 be removed from this specification when Google QUIC has finished 532 transitioning to the new header format. 534 Reserved: The sixth, seventh, and eighth bits (0x7) of octet 0 are 535 reserved for experimentation. Endpoints MUST ignore these bits on 536 packets they receive unless they are participating in an 537 experiment that uses these bits. An endpoint not actively using 538 these bits SHOULD set the value randomly on packets they send to 539 protect against unwanted inference about particular values. 541 Destination Connection ID: The Destination Connection ID is a 542 connection ID that is chosen by the intended recipient of the 543 packet. See Section 6.1 for more details. 545 Packet Number: The packet number field is 1, 2, or 4 octets long. 546 The packet number has confidentiality protection separate from 547 packet protection, as described in Section 5.3 of [QUIC-TLS]. The 548 length of the packet number field is encoded in the plaintext 549 packet number. See Section 4.11 for details. 551 Protected Payload: Packets with a short header always include a 552 1-RTT protected payload. 554 The header form and connection ID field of a short header packet are 555 version-independent. The remaining fields are specific to the 556 selected QUIC version. See [QUIC-INVARIANTS] for details on how 557 packets from different versions of QUIC are interpreted. 559 4.3. Version Negotiation Packet 561 A Version Negotiation packet is inherently not version-specific, and 562 does not use the long packet header (see Section 4.1. Upon receipt 563 by a client, it will appear to be a packet using the long header, but 564 will be identified as a Version Negotiation packet based on the 565 Version field having a value of 0. 567 The Version Negotiation packet is a response to a client packet that 568 contains a version that is not supported by the server, and is only 569 sent by servers. 571 The layout of a Version Negotiation packet is: 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+ 576 |1| Unused (7) | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Version (32) | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |DCIL(4)|SCIL(4)| 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Destination Connection ID (0/32..144) ... 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Source Connection ID (0/32..144) ... 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Supported Version 1 (32) ... 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | [Supported Version 2 (32)] ... 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 ... 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | [Supported Version N (32)] ... 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 3: Version Negotiation Packet 597 The value in the Unused field is selected randomly by the server. 599 The Version field of a Version Negotiation packet MUST be set to 600 0x00000000. 602 The server MUST include the value from the Source Connection ID field 603 of the packet it receives in the Destination Connection ID field. 604 The value for Source Connection ID MUST be copied from the 605 Destination Connection ID of the received packet, which is initially 606 randomly selected by a client. Echoing both connection IDs gives 607 clients some assurance that the server received the packet and that 608 the Version Negotiation packet was not generated by an off-path 609 attacker. 611 The remainder of the Version Negotiation packet is a list of 32-bit 612 versions which the server supports. 614 A Version Negotiation packet cannot be explicitly acknowledged in an 615 ACK frame by a client. Receiving another Initial packet implicitly 616 acknowledges a Version Negotiation packet. 618 The Version Negotiation packet does not include the Packet Number and 619 Length fields present in other packets that use the long header form. 620 Consequently, a Version Negotiation packet consumes an entire UDP 621 datagram. 623 See Section 6.3 for a description of the version negotiation process. 625 4.4. Retry Packet 627 A Retry packet uses a long packet header with a type value of 0x7E. 628 It carries an address validation token created by the server. It is 629 used by a server that wishes to perform a stateless retry (see 630 Section 6.7). 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+ 635 |1| 0x7e | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Version (32) | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |DCIL(4)|SCIL(4)| 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Destination Connection ID (0/32..144) ... 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Source Connection ID (0/32..144) ... 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | ODCIL(8) | Original Destination Connection ID (*) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Retry Token (*) ... 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Figure 4: Retry Packet 652 A Retry packet (shown in Figure 4) only uses the invariant portion of 653 the long packet header [QUIC-INVARIANTS]; that is, the fields up to 654 and including the Destination and Source Connection ID fields. A 655 Retry packet does not contain any protected fields. Like Version 656 Negotiation, a Retry packet contains the long header including the 657 connection IDs, but omits the Length, Packet Number, and Payload 658 fields. These are replaced with: 660 ODCIL: The length of the Original Destination Connection ID field. 661 The length is encoded in the least significant 4 bits of the 662 octet, using the same encoding as the DCIL and SCIL fields. The 663 most significant 4 bits of this octet are reserved. Unless a use 664 for these bits has been negotiated, endpoints SHOULD send 665 randomized values and MUST ignore any value that it receives. 667 Original Destination Connection ID: The Original Destination 668 Connection ID contains the value of the Destination Connection ID 669 from the Initial packet that this Retry is in response to. The 670 length of this field is given in ODCIL. 672 Retry Token: An opaque token that the server can use to validate the 673 client's address. 675 The server populates the Destination Connection ID with the 676 connection ID that the client included in the Source Connection ID of 677 the Initial packet. 679 The server includes a connection ID of its choice in the Source 680 Connection ID field. This value MUST not be equal to the Destination 681 Connection ID field of the packet sent by the client. The client 682 MUST use this connection ID in the Destination Connection ID of 683 subsequent packets that it sends. 685 A server MAY send Retry packets in response to Initial and 0-RTT 686 packets. A server can either discard or buffer 0-RTT packets that it 687 receives. A server can send multiple Retry packets as it receives 688 Initial or 0-RTT packets. 690 A client MUST accept and process at most one Retry packet for each 691 connection attempt. After the client has received and processed an 692 Initial or Retry packet from the server, it MUST discard any 693 subsequent Retry packets that it receives. 695 Clients MUST discard Retry packets that contain an Original 696 Destination Connection ID field that does not match the Destination 697 Connection ID from its Initial packet. This prevents an off-path 698 attacker from injecting a Retry packet. 700 The client responds to a Retry packet with an Initial packet that 701 includes the provided Retry Token to continue connection 702 establishment. 704 A client sets the Destination Connection ID field of this Initial 705 packet to the value from the Source Connection ID in the Retry 706 packet. Changing Destination Connection ID also results in a change 707 to the keys used to protect the Initial packet. It also sets the 708 Token field to the token provided in the Retry. The client MUST NOT 709 change the Source Connection ID because the server could include the 710 connection ID as part of its token validation logic (see 711 Section 4.6.2). 713 All subsequent Initial packets from the client MUST use the 714 connection ID and token values from the Retry packet. Aside from 715 this, the Initial packet sent by the client is subject to the same 716 restrictions as the first Initial packet. A client can either reuse 717 the cryptographic handshake message or construct a new one at its 718 discretion. 720 A client MAY attempt 0-RTT after receiving a Retry packet by sending 721 0-RTT packets to the connection ID provided by the server. A client 722 that sends additional 0-RTT packets without constructing a new 723 cryptographic handshake message MUST NOT reset the packet number to 0 724 after a Retry packet, see Section 4.6.4. 726 A server acknowledges the use of a Retry packet for a connection 727 using the original_connection_id transport parameter (see 728 Section 6.6.1). If the server sends a Retry packet, it MUST include 729 the value of the Original Destination Connection ID field of the 730 Retry packet (that is, the Destination Connection ID field from the 731 client's first Initial packet) in the transport parameter. 733 If the client received and processed a Retry packet, it validates 734 that the original_connection_id transport parameter is present and 735 correct; otherwise, it validates that the transport parameter is 736 absent. A client MUST treat a failed validation as a connection 737 error of type TRANSPORT_PARAMETER_ERROR. 739 A Retry packet does not include a packet number and cannot be 740 explicitly acknowledged by a client. 742 4.5. Cryptographic Handshake Packets 744 Once version negotiation is complete, the cryptographic handshake is 745 used to agree on cryptographic keys. The cryptographic handshake is 746 carried in Initial (Section 4.6) and Handshake (Section 4.7) packets. 748 All these packets use the long header and contain the current QUIC 749 version in the version field. 751 In order to prevent tampering by version-unaware middleboxes, Initial 752 packets are protected with connection- and version-specific keys 753 (Initial keys) as described in [QUIC-TLS]. This protection does not 754 provide confidentiality or integrity against on-path attackers, but 755 provides some level of protection against off-path attackers. 757 4.6. Initial Packet 759 The Initial packet uses long headers with a type value of 0x7F. It 760 carries the first CRYPTO frames sent by the client and server to 761 perform key exchange, and carries ACKs in either direction. The 762 Initial packet is protected by Initial keys as described in 763 [QUIC-TLS]. 765 The Initial packet (shown in Figure 5) has two additional header 766 fields that are added to the Long Header before the Length field. 768 +-+-+-+-+-+-+-+-+ 769 |1| 0x7f | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Version (32) | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 |DCIL(4)|SCIL(4)| 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Destination Connection ID (0/32..144) ... 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Source Connection ID (0/32..144) ... 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Token Length (i) ... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Token (*) ... 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Length (i) ... 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Packet Number (8/16/32) | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Payload (*) ... 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Figure 5: Initial Packet 792 These fields include the token that was previously provided in a 793 Retry packet or NEW_TOKEN frame: 795 Token Length: A variable-length integer specifying the length of the 796 Token field, in bytes. This value is zero if no token is present. 797 Initial packets sent by the server MUST set the Token Length field 798 to zero; clients that receive an Initial packet with a non-zero 799 Token Length field MUST either discard the packet or generate a 800 connection error of type PROTOCOL_VIOLATION. 802 Token: The value of the token. 804 The client and server use the Initial packet type for any packet that 805 contains an initial cryptographic handshake message. This includes 806 all cases where a new packet containing the initial cryptographic 807 message needs to be created, such as the packets sent after receiving 808 a Version Negotiation (Section 4.3) or Retry packet (Section 4.4). 810 A server sends its first Initial packet in response to a client 811 Initial. A server may send multiple Initial packets. The 812 cryptographic key exchange could require multiple round trips or 813 retransmissions of this data. 815 The payload of an Initial packet includes a CRYPTO frame (or frames) 816 containing a cryptographic handshake message, ACK frames, or both. 817 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 818 that receives an Initial packet containing other frames can either 819 discard the packet as spurious or treat it as a connection error. 821 The first packet sent by a client always includes a CRYPTO frame that 822 contains the entirety of the first cryptographic handshake message. 823 This packet, and the cryptographic handshake message, MUST fit in a 824 single UDP datagram (see Section 6.4). The first CRYPTO frame sent 825 always begins at an offset of 0 (see Section 6.4). 827 Note that if the server sends a HelloRetryRequest, the client will 828 send a second Initial packet. This Initial packet will continue the 829 cryptographic handshake and will contain a CRYPTO frame with an 830 offset matching the size of the CRYPTO frame sent in the first 831 Initial packet. Cryptographic handshake messages subsequent to the 832 first do not need to fit within a single UDP datagram. 834 4.6.1. Connection IDs 836 When an Initial packet is sent by a client which has not previously 837 received a Retry packet from the server, it populates the Destination 838 Connection ID field with an unpredictable value. This MUST be at 839 least 8 octets in length. Until a packet is received from the 840 server, the client MUST use the same value unless it abandons the 841 connection attempt and starts a new one. The initial Destination 842 Connection ID is used to determine packet protection keys for Initial 843 packets. 845 The client populates the Source Connection ID field with a value of 846 its choosing and sets the SCIL field to match. 848 The Destination Connection ID field in the server's Initial packet 849 contains a connection ID that is chosen by the recipient of the 850 packet (i.e., the client); the Source Connection ID includes the 851 connection ID that the sender of the packet wishes to use (see 852 Section 6.1). The server MUST use consistent Source Connection IDs 853 during the handshake. 855 On first receiving an Initial or Retry packet from the server, the 856 client uses the Source Connection ID supplied by the server as the 857 Destination Connection ID for subsequent packets. That means that a 858 client might change the Destination Connection ID twice during 859 connection establishment. Once a client has received an Initial 860 packet from the server, it MUST discard any packet it receives with a 861 different Source Connection ID. 863 4.6.2. Tokens 865 If the client has a token received in a NEW_TOKEN frame on a previous 866 connection to what it believes to be the same server, it can include 867 that value in the Token field of its Initial packet. 869 A token allows a server to correlate activity between connections. 870 Specifically, the connection where the token was issued, and any 871 connection where it is used. Clients that want to break continuity 872 of identity with a server MAY discard tokens provided using the 873 NEW_TOKEN frame. Tokens obtained in Retry packets MUST NOT be 874 discarded. 876 A client SHOULD NOT reuse a token. Reusing a token allows 877 connections to be linked by entities on the network path (see 878 Section 6.11.5). A client MUST NOT reuse a token if it believes that 879 its point of network attachment has changed since the token was last 880 used; that is, if there is a change in its local IP address or 881 network interface. A client needs to start the connection process 882 over if it migrates prior to completing the handshake. 884 When a server receives an Initial packet with an address validation 885 token, it SHOULD attempt to validate it. If the token is invalid 886 then the server SHOULD proceed as if the client did not have a 887 validated address, including potentially sending a Retry. If the 888 validation succeeds, the server SHOULD then allow the handshake to 889 proceed (see Section 6.7). 891 Note: The rationale for treating the client as unvalidated rather 892 than discarding the packet is that the client might have received 893 the token in a previous connection using the NEW_TOKEN frame, and 894 if the server has lost state, it might be unable to validate the 895 token at all, leading to connection failure if the packet is 896 discarded. A server MAY encode tokens provided with NEW_TOKEN 897 frames and Retry packets differently, and validate the latter more 898 strictly. 900 In a stateless design, a server can use encrypted and authenticated 901 tokens to pass information to clients that the server can later 902 recover and use to validate a client address. Tokens are not 903 integrated into the cryptographic handshake and so they are not 904 authenticated. For instance, a client might be able to reuse a 905 token. To avoid attacks that exploit this property, a server can 906 limit its use of tokens to only the information needed validate 907 client addresses. 909 4.6.3. Starting Packet Numbers 911 The first Initial packet sent by either endpoint contains a packet 912 number of 0. The packet number MUST increase monotonically 913 thereafter. Initial packets are in a different packet number space 914 to other packets (see Section 4.11). 916 4.6.4. 0-RTT Packet Numbers 918 Packet numbers for 0-RTT protected packets use the same space as 919 1-RTT protected packets. 921 After a client receives a Retry or Version Negotiation packet, 0-RTT 922 packets are likely to have been lost or discarded by the server. A 923 client MAY attempt to resend data in 0-RTT packets after it sends a 924 new Initial packet. 926 A client MUST NOT reset the packet number it uses for 0-RTT packets. 927 The keys used to protect 0-RTT packets will not change as a result of 928 responding to a Retry or Version Negotiation packet unless the client 929 also regenerates the cryptographic handshake message. Sending 930 packets with the same packet number in that case is likely to 931 compromise the packet protection for all 0-RTT packets because the 932 same key and nonce could be used to protect different content. 934 Receiving a Retry or Version Negotiation packet, especially a Retry 935 that changes the connection ID used for subsequent packets, indicates 936 a strong possibility that 0-RTT packets could be lost. A client only 937 receives acknowledgments for its 0-RTT packets once the handshake is 938 complete. Consequently, a server might expect 0-RTT packets to start 939 with a packet number of 0. Therefore, in determining the length of 940 the packet number encoding for 0-RTT packets, a client MUST assume 941 that all packets up to the current packet number are in flight, 942 starting from a packet number of 0. Thus, 0-RTT packets could need 943 to use a longer packet number encoding. 945 A client SHOULD instead generate a fresh cryptographic handshake 946 message and start packet numbers from 0. This ensures that new 0-RTT 947 packets will not use the same keys, avoiding any risk of key and 948 nonce reuse; this also prevents 0-RTT packets from previous handshake 949 attempts from being accepted as part of the connection. 951 4.6.5. Minimum Packet Size 953 The payload of a UDP datagram carrying the Initial packet MUST be 954 expanded to at least 1200 octets (see Section 8), by adding PADDING 955 frames to the Initial packet and/or by combining the Initial packet 956 with a 0-RTT packet (see Section 4.9). 958 4.7. Handshake Packet 960 A Handshake packet uses long headers with a type value of 0x7D. It 961 is used to carry acknowledgments and cryptographic handshake messages 962 from the server and client. 964 A server sends its cryptographic handshake in one or more Handshake 965 packets in response to an Initial packet if it does not send a Retry 966 packet. Once a client has received a Handshake packet from a server, 967 it uses Handshake packets to send subsequent cryptographic handshake 968 messages and acknowledgments to the server. 970 The Destination Connection ID field in a Handshake packet contains a 971 connection ID that is chosen by the recipient of the packet; the 972 Source Connection ID includes the connection ID that the sender of 973 the packet wishes to use (see Section 4.10). 975 The first Handshake packet sent by a server contains a packet number 976 of 0. Handshake packets are their own packet number space. Packet 977 numbers are incremented normally for other Handshake packets. 979 Servers MUST NOT send more than three times as many bytes as the 980 number of bytes received prior to verifying the client's address. 981 Source addresses can be verified through an address validation token 982 (delivered via a Retry packet or a NEW_TOKEN frame) or by processing 983 any message from the client encrypted using the Handshake keys. This 984 limit exists to mitigate amplification attacks. 986 In order to prevent this limit causing a handshake deadlock, the 987 client SHOULD always send a packet upon a handshake timeout, as 988 described in [QUIC-RECOVERY]. If the client has no data to 989 retransmit and does not have Handshake keys, it SHOULD send an 990 Initial packet in a UDP datagram of at least 1200 octets. If the 991 client has Handshake keys, it SHOULD send a Handshake packet. 993 The payload of this packet contains CRYPTO frames and could contain 994 PADDING, or ACK frames. Handshake packets MAY contain 995 CONNECTION_CLOSE or APPLICATION_CLOSE frames. Endpoints MUST treat 996 receipt of Handshake packets with other frames as a connection error. 998 4.8. Protected Packets 1000 All QUIC packets use packet protection. Packets that are protected 1001 with the static handshake keys or the 0-RTT keys are sent with long 1002 headers; all packets protected with 1-RTT keys are sent with short 1003 headers. The different packet types explicitly indicate the 1004 encryption level and therefore the keys that are used to remove 1005 packet protection. 0-RTT and 1-RTT protected packets share a single 1006 packet number space. 1008 Packets protected with handshake keys only use packet protection to 1009 ensure that the sender of the packet is on the network path. This 1010 packet protection is not effective confidentiality protection; any 1011 entity that receives the Initial packet from a client can recover the 1012 keys necessary to remove packet protection or to generate packets 1013 that will be successfully authenticated. 1015 Packets protected with 0-RTT and 1-RTT keys are expected to have 1016 confidentiality and data origin authentication; the cryptographic 1017 handshake ensures that only the communicating endpoints receive the 1018 corresponding keys. 1020 Packets protected with 0-RTT keys use a type value of 0x7C. The 1021 connection ID fields for a 0-RTT packet MUST match the values used in 1022 the Initial packet (Section 4.6). 1024 The version field for protected packets is the current QUIC version. 1026 The packet number field contains a packet number, which has 1027 additional confidentiality protection that is applied after packet 1028 protection is applied (see [QUIC-TLS] for details). The underlying 1029 packet number increases with each packet sent, see Section 4.11 for 1030 details. 1032 The payload is protected using authenticated encryption. [QUIC-TLS] 1033 describes packet protection in detail. After decryption, the 1034 plaintext consists of a sequence of frames, as described in 1035 Section 5. 1037 4.9. Coalescing Packets 1039 A sender can coalesce multiple QUIC packets (typically a 1040 Cryptographic Handshake packet and a Protected packet) into one UDP 1041 datagram. This can reduce the number of UDP datagrams needed to send 1042 application data during the handshake and immediately afterwards. It 1043 is not necessary for senders to coalesce packets, though failing to 1044 do so will require sending a significantly larger number of datagrams 1045 during the handshake. Receivers MUST be able to process coalesced 1046 packets. 1048 Coalescing packets in order of increasing encryption levels (Initial, 1049 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 1050 able to process all the packets in a single pass. A packet with a 1051 short header does not include a length, so it will always be the last 1052 packet included in a UDP datagram. 1054 Senders MUST NOT coalesce QUIC packets with different Destination 1055 Connection IDs into a single UDP datagram. Receivers SHOULD ignore 1056 any subsequent packets with a different Destination Connection ID 1057 than the first packet in the datagram. 1059 Every QUIC packet that is coalesced into a single UDP datagram is 1060 separate and complete. Though the values of some fields in the 1061 packet header might be redundant, no fields are omitted. The 1062 receiver of coalesced QUIC packets MUST individually process each 1063 QUIC packet and separately acknowledge them, as if they were received 1064 as the payload of different UDP datagrams. If one or more packets in 1065 a datagram cannot be processed yet (because the keys are not yet 1066 available) or processing fails (decryption failure, unknown type, 1067 etc.), the receiver MUST still attempt to process the remaining 1068 packets. The skipped packets MAY either be discarded or buffered for 1069 later processing, just as if the packets were received out-of-order 1070 in separate datagrams. 1072 Retry (Section 4.4) and Version Negotiation (Section 4.3) packets 1073 cannot be coalesced. 1075 4.10. Connection ID Encoding 1077 A connection ID is used to ensure consistent routing of packets, as 1078 described in Section 6.1. The long header contains two connection 1079 IDs: the Destination Connection ID is chosen by the recipient of the 1080 packet and is used to provide consistent routing; the Source 1081 Connection ID is used to set the Destination Connection ID used by 1082 the peer. 1084 During the handshake, packets with the long header are used to 1085 establish the connection ID that each endpoint uses. Each endpoint 1086 uses the Source Connection ID field to specify the connection ID that 1087 is used in the Destination Connection ID field of packets being sent 1088 to them. Upon receiving a packet, each endpoint sets the Destination 1089 Connection ID it sends to match the value of the Source Connection ID 1090 that they receive. 1092 During the handshake, a client can receive both a Retry and an 1093 Initial packet, and thus be given two opportunities to update the 1094 Destination Connection ID it sends. A client MUST only change the 1095 value it sends in the Destination Connection ID in response to the 1096 first packet of each type it receives from the server (Retry or 1097 Initial); a server MUST set its value based on the Initial packet. 1098 Any additional changes are not permitted; if subsequent packets of 1099 those types include a different Source Connection ID, they MUST be 1100 discarded. This avoids problems that might arise from stateless 1101 processing of multiple Initial packets producing different connection 1102 IDs. 1104 Short headers only include the Destination Connection ID and omit the 1105 explicit length. The length of the Destination Connection ID field 1106 is expected to be known to endpoints. 1108 Endpoints using a connection-ID based load balancer could agree with 1109 the load balancer on a fixed or minimum length and on an encoding for 1110 connection IDs. This fixed portion could encode an explicit length, 1111 which allows the entire connection ID to vary in length and still be 1112 used by the load balancer. 1114 The very first packet sent by a client includes a random value for 1115 Destination Connection ID. The same value MUST be used for all 0-RTT 1116 packets sent on that connection (Section 4.8). This randomized value 1117 is used to determine the packet protection keys for Initial packets 1118 (see Section 5.2 of [QUIC-TLS]). 1120 A Version Negotiation (Section 4.3) packet MUST use both connection 1121 IDs selected by the client, swapped to ensure correct routing toward 1122 the client. 1124 The connection ID can change over the lifetime of a connection, 1125 especially in response to connection migration (Section 6.11). 1126 NEW_CONNECTION_ID frames (Section 7.13) are used to provide new 1127 connection ID values. 1129 4.11. Packet Numbers 1131 The packet number is an integer in the range 0 to 2^62-1. The value 1132 is used in determining the cryptographic nonce for packet protection. 1133 Each endpoint maintains a separate packet number for sending and 1134 receiving. 1136 Packet numbers are divided into 3 spaces in QUIC: 1138 o Initial space: All Initial packets Section 4.6 are in this space. 1140 o Handshake space: All Handshake packets Section 4.7 are in this 1141 space. 1143 o Application data space: All 0-RTT and 1-RTT encrypted packets 1144 Section 4.8 are in this space. 1146 As described in [QUIC-TLS], each packet type uses different 1147 protection keys. 1149 Conceptually, a packet number space is the context in which a packet 1150 can be processed and acknowledged. Initial packets can only be sent 1151 with Initial packet protection keys and acknowledged in packets which 1152 are also Initial packets. Similarly, Handshake packets are sent at 1153 the Handshake encryption level and can only be acknowledged in 1154 Handshake packets. 1156 This enforces cryptographic separation between the data sent in the 1157 different packet sequence number spaces. Each packet number space 1158 starts at packet number 0. Subsequent packets sent in the same 1159 packet number space MUST increase the packet number by at least one. 1161 0-RTT and 1-RTT data exist in the same packet number space to make 1162 loss recovery algorithms easier to implement between the two packet 1163 types. 1165 A QUIC endpoint MUST NOT reuse a packet number within the same packet 1166 number space in one connection (that is, under the same cryptographic 1167 keys). If the packet number for sending reaches 2^62 - 1, the sender 1168 MUST close the connection without sending a CONNECTION_CLOSE frame or 1169 any further packets; an endpoint MAY send a Stateless Reset 1170 (Section 6.13.4) in response to further packets that it receives. 1172 In the QUIC long and short packet headers, the number of bits 1173 required to represent the packet number is reduced by including only 1174 a variable number of the least significant bits of the packet number. 1175 One or two of the most significant bits of the first octet determine 1176 how many bits of the packet number are provided, as shown in Table 2. 1178 +---------------------+----------------+--------------+ 1179 | First octet pattern | Encoded Length | Bits Present | 1180 +---------------------+----------------+--------------+ 1181 | 0b0xxxxxxx | 1 octet | 7 | 1182 | | | | 1183 | 0b10xxxxxx | 2 | 14 | 1184 | | | | 1185 | 0b11xxxxxx | 4 | 30 | 1186 +---------------------+----------------+--------------+ 1188 Table 2: Packet Number Encodings for Packet Headers 1190 Note that these encodings are similar to those in Section 7.1, but 1191 use different values. 1193 The encoded packet number is protected as described in Section 5.3 1194 [QUIC-TLS]. Protection of the packet number is removed prior to 1195 recovering the full packet number. The full packet number is 1196 reconstructed at the receiver based on the number of significant bits 1197 present, the value of those bits, and the largest packet number 1198 received on a successfully authenticated packet. Recovering the full 1199 packet number is necessary to successfully remove packet protection. 1201 Once packet number protection is removed, the packet number is 1202 decoded by finding the packet number value that is closest to the 1203 next expected packet. The next expected packet is the highest 1204 received packet number plus one. For example, if the highest 1205 successfully authenticated packet had a packet number of 0xaa82f30e, 1206 then a packet containing a 14-bit value of 0x9b3 will be decoded as 1207 0xaa8309b3. Example pseudo-code for packet number decoding can be 1208 found in Appendix A. 1210 The sender MUST use a packet number size able to represent more than 1211 twice as large a range than the difference between the largest 1212 acknowledged packet and packet number being sent. A peer receiving 1213 the packet will then correctly decode the packet number, unless the 1214 packet is delayed in transit such that it arrives after many higher- 1215 numbered packets have been received. An endpoint SHOULD use a large 1216 enough packet number encoding to allow the packet number to be 1217 recovered even if the packet arrives after packets that are sent 1218 afterwards. 1220 As a result, the size of the packet number encoding is at least one 1221 more than the base 2 logarithm of the number of contiguous 1222 unacknowledged packet numbers, including the new packet. 1224 For example, if an endpoint has received an acknowledgment for packet 1225 0x6afa2f, sending a packet with a number of 0x6b2d79 requires a 1226 packet number encoding with 14 bits or more; whereas the 30-bit 1227 packet number encoding is needed to send a packet with a number of 1228 0x6bc107. 1230 A receiver MUST discard a newly unprotected packet unless it is 1231 certain that it has not processed another packet with the same packet 1232 number from the same packet number space. Duplicate suppression MUST 1233 happen after removing packet protection for the reasons described in 1234 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 1235 suppression can be found in Section 3.4.3 of [RFC2406]. 1237 A Version Negotiation packet (Section 4.3) does not include a packet 1238 number. The Retry packet (Section 4.4) has special rules for 1239 populating the packet number field. 1241 5. Frames and Frame Types 1243 The payload of all packets, after removing packet protection, 1244 consists of a sequence of frames, as shown in Figure 6. Version 1245 Negotiation and Stateless Reset do not contain frames. 1247 0 1 2 3 1248 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 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Frame 1 (*) ... 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Frame 2 (*) ... 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 ... 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Frame N (*) ... 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Figure 6: QUIC Payload 1261 QUIC payloads MUST contain at least one frame, and MAY contain 1262 multiple frames and multiple frame types. 1264 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 1265 packet boundary. Each frame begins with a Frame Type, indicating its 1266 type, followed by additional type-dependent fields: 1268 0 1 2 3 1269 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 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Frame Type (i) ... 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Type-Dependent Fields (*) ... 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 Figure 7: Generic Frame Layout 1278 The frame types defined in this specification are listed in Table 3. 1279 The Frame Type in STREAM frames is used to carry other frame-specific 1280 flags. For all other frames, the Frame Type field simply identifies 1281 the frame. These frames are explained in more detail as they are 1282 referenced later in the document. 1284 +-------------+----------------------+--------------+ 1285 | Type Value | Frame Type Name | Definition | 1286 +-------------+----------------------+--------------+ 1287 | 0x00 | PADDING | Section 7.2 | 1288 | | | | 1289 | 0x01 | RST_STREAM | Section 7.3 | 1290 | | | | 1291 | 0x02 | CONNECTION_CLOSE | Section 7.4 | 1292 | | | | 1293 | 0x03 | APPLICATION_CLOSE | Section 7.5 | 1294 | | | | 1295 | 0x04 | MAX_DATA | Section 7.6 | 1296 | | | | 1297 | 0x05 | MAX_STREAM_DATA | Section 7.7 | 1298 | | | | 1299 | 0x06 | MAX_STREAM_ID | Section 7.8 | 1300 | | | | 1301 | 0x07 | PING | Section 7.9 | 1302 | | | | 1303 | 0x08 | BLOCKED | Section 7.10 | 1304 | | | | 1305 | 0x09 | STREAM_BLOCKED | Section 7.11 | 1306 | | | | 1307 | 0x0a | STREAM_ID_BLOCKED | Section 7.12 | 1308 | | | | 1309 | 0x0b | NEW_CONNECTION_ID | Section 7.13 | 1310 | | | | 1311 | 0x0c | STOP_SENDING | Section 7.15 | 1312 | | | | 1313 | 0x0d | RETIRE_CONNECTION_ID | Section 7.14 | 1314 | | | | 1315 | 0x0e | PATH_CHALLENGE | Section 7.17 | 1316 | | | | 1317 | 0x0f | PATH_RESPONSE | Section 7.18 | 1318 | | | | 1319 | 0x10 - 0x17 | STREAM | Section 7.20 | 1320 | | | | 1321 | 0x18 | CRYPTO | Section 7.21 | 1322 | | | | 1323 | 0x19 | NEW_TOKEN | Section 7.19 | 1324 | | | | 1325 | 0x1a - 0x1b | ACK | Section 7.16 | 1326 +-------------+----------------------+--------------+ 1328 Table 3: Frame Types 1330 All QUIC frames are idempotent. That is, a valid frame does not 1331 cause undesirable side effects or errors when received more than 1332 once. 1334 The Frame Type field uses a variable length integer encoding (see 1335 Section 7.1) with one exception. To ensure simple and efficient 1336 implementations of frame parsing, a frame type MUST use the shortest 1337 possible encoding. Though a two-, four- or eight-octet encoding of 1338 the frame types defined in this document is possible, the Frame Type 1339 field for these frames is encoded on a single octet. For instance, 1340 though 0x4007 is a legitimate two-octet encoding for a variable- 1341 length integer with a value of 7, PING frames are always encoded as a 1342 single octet with the value 0x07. An endpoint MUST treat the receipt 1343 of a frame type that uses a longer encoding than necessary as a 1344 connection error of type PROTOCOL_VIOLATION. 1346 5.1. Extension Frames 1348 QUIC frames do not use a self-describing encoding. An endpoint 1349 therefore needs to understand the syntax of all frames before it can 1350 successfully process a packet. This allows for efficient encoding of 1351 frames, but it means that an endpoint cannot send a frame of a type 1352 that is unknown to its peer. 1354 An extension to QUIC that wishes to use a new type of frame MUST 1355 first ensure that a peer is able to understand the frame. An 1356 endpoint can use a transport parameter to signal its willingness to 1357 receive one or more extension frame types with the one transport 1358 parameter. 1360 Extension frames MUST be congestion controlled and MUST cause an ACK 1361 frame to be sent. The exception is extension frames that replace or 1362 supplement the ACK frame. Extension frames are not included in flow 1363 control unless specified in the extension. 1365 An IANA registry is used to manage the assignment of frame types, see 1366 Section 13.2. 1368 6. Life of a Connection 1370 A QUIC connection is a single conversation between two QUIC 1371 endpoints. QUIC's connection establishment intertwines version 1372 negotiation with the cryptographic and transport handshakes to reduce 1373 connection establishment latency, as described in Section 6.4. Once 1374 established, a connection may migrate to a different IP or port at 1375 either endpoint, due to NAT rebinding or mobility, as described in 1376 Section 6.11. Finally, a connection may be terminated by either 1377 endpoint, as described in Section 6.13. 1379 6.1. Connection ID 1381 Each connection possesses a set of identifiers, any of which could be 1382 used to distinguish it from other connections. Connection IDs are 1383 selected independently in each direction. Each Connection ID has an 1384 associated sequence number to assist in deduplicating messages. 1386 The primary function of a connection ID is to ensure that changes in 1387 addressing at lower protocol layers (UDP, IP, and below) don't cause 1388 packets for a QUIC connection to be delivered to the wrong endpoint. 1389 Each endpoint selects connection IDs using an implementation-specific 1390 (and perhaps deployment-specific) method which will allow packets 1391 with that connection ID to be routed back to the endpoint and 1392 identified by the endpoint upon receipt. 1394 Connection IDs MUST NOT contain any information that can be used to 1395 correlate them with other connection IDs for the same connection. As 1396 a trivial example, this means the same connection ID MUST NOT be 1397 issued more than once on the same connection. 1399 A zero-length connection ID MAY be used when the connection ID is not 1400 needed for routing and the address/port tuple of packets is 1401 sufficient to identify a connection. An endpoint whose peer has 1402 selected a zero-length connection ID MUST continue to use a zero- 1403 length connection ID for the lifetime of the connection and MUST NOT 1404 send packets from any other local address. 1406 When an endpoint has requested a non-zero-length connection ID, it 1407 needs to ensure that the peer has a supply of connection IDs from 1408 which to choose for packets sent to the endpoint. These connection 1409 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1410 (Section 7.13). 1412 6.1.1. Issuing Connection IDs 1414 The initial connection ID issued by an endpoint is the Source 1415 Connection ID during the handshake. The sequence number of the 1416 initial connection ID is 0. If the preferred_address transport 1417 parameter is sent, the sequence number of the supplied connection ID 1418 is 1. Subsequent connection IDs are communicated to the peer using 1419 NEW_CONNECTION_ID frames (Section 7.13), and the sequence number on 1420 each newly-issued connection ID MUST increase by 1. The connection 1421 ID randomly selected by the client in the Initial packet and any 1422 connection ID provided by a Reset packet are not assigned sequence 1423 numbers unless a server opts to retain them as its initial connection 1424 ID. 1426 When an endpoint issues a connection ID, it MUST accept packets that 1427 carry this connection ID for the duration of the connection or until 1428 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1429 frame (Section 7.14). 1431 An endpoint SHOULD ensure that its peer has a sufficient number of 1432 available and unused connection IDs. While each endpoint 1433 independently chooses how many connection IDs to issue, endpoints 1434 SHOULD provide and maintain at least eight connection IDs. The 1435 endpoint can do this by always supplying a new connection ID when a 1436 connection ID is retired by its peer or when the endpoint receives a 1437 packet with a previously unused connection ID. Endpoints that 1438 initiate migration and require non-zero-length connection IDs SHOULD 1439 provide their peers with new connection IDs before migration, or risk 1440 the peer closing the connection. 1442 6.1.2. Consuming and Retiring Connection IDs 1444 An endpoint can change the connection ID it uses for a peer to 1445 another available one at any time during the connection. An endpoint 1446 consumes connection IDs in response to a migrating peer, see 1447 Section 6.11.5 for more. 1449 An endpoint maintains a set of connection IDs received from its peer, 1450 any of which it can use when sending packets. When the endpoint 1451 wishes to remove a connection ID from use, it sends a 1452 RETIRE_CONNECTION_ID frame to its peer, indicating that the peer 1453 might bring a new connection ID into circulation using the 1454 NEW_CONNECTION_ID frame. 1456 An endpoint that retires a connection ID can retain knowledge of that 1457 connection ID for a period of time after sending the 1458 RETIRE_CONNECTION_ID frame, or until that frame is acknowledged. 1460 As discussed in Section 6.11.5, each connection ID MUST be used on 1461 packets sent from only one local address. An endpoint that migrates 1462 away from a local address SHOULD retire all connection IDs used on 1463 that address once it no longer plans to use that address. 1465 6.2. Matching Packets to Connections 1467 Incoming packets are classified on receipt. Packets can either be 1468 associated with an existing connection, or - for servers - 1469 potentially create a new connection. 1471 Hosts try to associate a packet with an existing connection. If the 1472 packet has a Destination Connection ID corresponding to an existing 1473 connection, QUIC processes that packet accordingly. Note that more 1474 than one connection ID can be associated with a connection; see 1475 Section 6.1. 1477 If the Destination Connection ID is zero length and the packet 1478 matches the address/port tuple of a connection where the host did not 1479 require connection IDs, QUIC processes the packet as part of that 1480 connection. Endpoints MUST drop packets with zero-length Destination 1481 Connection ID fields if they do not correspond to a single 1482 connection. 1484 Endpoints SHOULD send a Stateless Reset (Section 6.13.4) for any 1485 packets that cannot be attributed to an existing connection. 1487 6.2.1. Client Packet Handling 1489 Valid packets sent to clients always include a Destination Connection 1490 ID that matches the value the client selects. Clients that choose to 1491 receive zero-length connection IDs can use the address/port tuple to 1492 identify a connection. Packets that don't match an existing 1493 connection are discarded. 1495 Due to packet reordering or loss, clients might receive packets for a 1496 connection that are encrypted with a key it has not yet computed. 1497 Clients MAY drop these packets, or MAY buffer them in anticipation of 1498 later packets that allow it to compute the key. 1500 If a client receives a packet that has an unsupported version, it 1501 MUST discard that packet. 1503 6.2.2. Server Packet Handling 1505 If a server receives a packet that has an unsupported version, but 1506 the packet is sufficiently large to initiate a new connection for any 1507 version supported by the server, it SHOULD send a Version Negotiation 1508 packet as described in Section 6.3.1. Servers MAY rate control these 1509 packets to avoid storms of Version Negotiation packets. 1511 The first packet for an unsupported version can use different 1512 semantics and encodings for any version-specific field. In 1513 particular, different packet protection keys might be used for 1514 different versions. Servers that do not support a particular version 1515 are unlikely to be able to decrypt the payload of the packet. 1516 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1517 unknown version, but instead send a Version Negotiation packet, 1518 provided that the packet is sufficiently long. 1520 Servers MUST drop other packets that contain unsupported versions. 1522 Packets with a supported version, or no version field, are matched to 1523 a connection as described in Section 6.2. If not matched, the server 1524 continues below. 1526 If the packet is an Initial packet fully conforming with the 1527 specification, the server proceeds with the handshake (Section 6.4). 1528 This commits the server to the version that the client selected. 1530 If a server isn't currently accepting any new connections, it SHOULD 1531 send an Initial packet containing a CONNECTION_CLOSE frame with error 1532 code SERVER_BUSY. 1534 If the packet is a 0-RTT packet, the server MAY buffer a limited 1535 number of these packets in anticipation of a late-arriving Initial 1536 Packet. Clients are forbidden from sending Handshake packets prior 1537 to receiving a server response, so servers SHOULD ignore any such 1538 packets. 1540 Servers MUST drop incoming packets under all other circumstances. 1542 6.3. Version Negotiation 1544 Version negotiation ensures that client and server agree to a QUIC 1545 version that is mutually supported. A server sends a Version 1546 Negotiation packet in response to each packet that might initiate a 1547 new connection, see Section 6.2 for details. 1549 The size of the first packet sent by a client will determine whether 1550 a server sends a Version Negotiation packet. Clients that support 1551 multiple QUIC versions SHOULD pad the first packet they send to the 1552 largest of the minimum packet sizes across all versions they support. 1553 This ensures that the server responds if there is a mutually 1554 supported version. 1556 6.3.1. Sending Version Negotiation Packets 1558 If the version selected by the client is not acceptable to the 1559 server, the server responds with a Version Negotiation packet (see 1560 Section 4.3). This includes a list of versions that the server will 1561 accept. 1563 This system allows a server to process packets with unsupported 1564 versions without retaining state. Though either the Initial packet 1565 or the Version Negotiation packet that is sent in response could be 1566 lost, the client will send new packets until it successfully receives 1567 a response or it abandons the connection attempt. 1569 6.3.2. Handling Version Negotiation Packets 1571 When the client receives a Version Negotiation packet, it first 1572 checks that the Destination and Source Connection ID fields match the 1573 Source and Destination Connection ID fields in a packet that the 1574 client sent. If this check fails, the packet MUST be discarded. 1576 Once the Version Negotiation packet is determined to be valid, the 1577 client then selects an acceptable protocol version from the list 1578 provided by the server. The client then attempts to create a 1579 connection using that version. Though the content of the Initial 1580 packet the client sends might not change in response to version 1581 negotiation, a client MUST increase the packet number it uses on 1582 every packet it sends. Packets MUST continue to use long headers and 1583 MUST include the new negotiated protocol version. 1585 The client MUST use the long header format and include its selected 1586 version on all packets until it has 1-RTT keys and it has received a 1587 packet from the server which is not a Version Negotiation packet. 1589 A client MUST NOT change the version it uses unless it is in response 1590 to a Version Negotiation packet from the server. Once a client 1591 receives a packet from the server which is not a Version Negotiation 1592 packet, it MUST discard other Version Negotiation packets on the same 1593 connection. Similarly, a client MUST ignore a Version Negotiation 1594 packet if it has already received and acted on a Version Negotiation 1595 packet. 1597 A client MUST ignore a Version Negotiation packet that lists the 1598 client's chosen version. 1600 A client MAY attempt 0-RTT after receiving a Version Negotiation 1601 packet. A client that sends additional 0-RTT packets MUST NOT reset 1602 the packet number to 0 as a result, see Section 4.6.4. 1604 Version negotiation packets have no cryptographic protection. The 1605 result of the negotiation MUST be revalidated as part of the 1606 cryptographic handshake (see Section 6.6.4). 1608 6.3.3. Using Reserved Versions 1610 For a server to use a new version in the future, clients must 1611 correctly handle unsupported versions. To help ensure this, a server 1612 SHOULD include a reserved version (see Section 3) while generating a 1613 Version Negotiation packet. 1615 The design of version negotiation permits a server to avoid 1616 maintaining state for packets that it rejects in this fashion. The 1617 validation of version negotiation (see Section 6.6.4) only validates 1618 the result of version negotiation, which is the same no matter which 1619 reserved version was sent. A server MAY therefore send different 1620 reserved version numbers in the Version Negotiation Packet and in its 1621 transport parameters. 1623 A client MAY send a packet using a reserved version number. This can 1624 be used to solicit a list of supported versions from a server. 1626 6.4. Cryptographic and Transport Handshake 1628 QUIC relies on a combined cryptographic and transport handshake to 1629 minimize connection establishment latency. QUIC uses the CRYPTO 1630 frame Section 7.21 to transmit the cryptographic handshake. Version 1631 0x00000001 of QUIC uses TLS 1.3 as described in [QUIC-TLS]; a 1632 different QUIC version number could indicate that a different 1633 cryptographic handshake protocol is in use. 1635 QUIC provides reliable, ordered delivery of the cryptographic 1636 handshake data. QUIC packet protection ensures confidentiality and 1637 integrity protection that meets the requirements of the cryptographic 1638 handshake protocol: 1640 o authenticated key exchange, where 1642 * a server is always authenticated, 1644 * a client is optionally authenticated, 1646 * every connection produces distinct and unrelated keys, 1648 * keying material is usable for packet protection for both 0-RTT 1649 and 1-RTT packets, and 1651 * 1-RTT keys have forward secrecy 1653 o authenticated values for the transport parameters of the peer (see 1654 Section 6.6) 1656 o authenticated confirmation of version negotiation (see 1657 Section 6.6.4) 1659 o authenticated negotiation of an application protocol (TLS uses 1660 ALPN [RFC7301] for this purpose) 1662 o for the server, the ability to carry data that provides assurance 1663 that the client can receive packets that are addressed with the 1664 transport address that is claimed by the client (see Section 6.9) 1666 The first CRYPTO frame MUST be sent in a single packet. Any second 1667 attempt that is triggered by address validation MUST also be sent 1668 within a single packet. This avoids having to reassemble a message 1669 from multiple packets. 1671 The first client packet of the cryptographic handshake protocol MUST 1672 fit within a 1232 octet QUIC packet payload. This includes overheads 1673 that reduce the space available to the cryptographic handshake 1674 protocol. 1676 The CRYPTO frame can be sent in different packet number spaces. 1677 CRYPTO frames in each packet number space carry a separate sequence 1678 of handshake data starting from an offset of 0. 1680 6.5. Example Handshake Flows 1682 Details of how TLS is integrated with QUIC are provided in 1683 [QUIC-TLS], but some examples are provided here. 1685 Figure 8 provides an overview of the 1-RTT handshake. Each line 1686 shows a QUIC packet with the packet type and packet number shown 1687 first, followed by the frames that are typically contained in those 1688 packets. So, for instance the first packet is of type Initial, with 1689 packet number 0, and contains a CRYPTO frame carrying the 1690 ClientHello. 1692 Note that multiple QUIC packets - even of different encryption levels 1693 - may be coalesced into a single UDP datagram (see Section 4.9), and 1694 so this handshake may consist of as few as 4 UDP datagrams, or any 1695 number more. For instance, the server's first flight contains 1696 packets from the Initial encryption level (obfuscation), the 1697 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1698 encryption level. 1700 Client Server 1702 Initial[0]: CRYPTO[CH] -> 1704 Initial[0]: CRYPTO[SH] ACK[0] 1705 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1706 <- 1-RTT[0]: STREAM[1, "..."] 1708 Initial[1]: ACK[0] 1709 Handshake[0]: CRYPTO[FIN], ACK[0] 1710 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1712 1-RTT[1]: STREAM[55, "..."], ACK[0] 1713 <- Handshake[1]: ACK[0] 1715 Figure 8: Example 1-RTT Handshake 1717 Figure 9 shows an example of a connection with a 0-RTT handshake and 1718 a single packet of 0-RTT data. Note that as described in 1719 Section 4.11, the server ACKs the 0-RTT data at the 1-RTT encryption 1720 level, and the client's sequence numbers at the 1-RTT encryption 1721 level continue to increment from its 0-RTT packets. 1723 Client Server 1725 Initial[0]: CRYPTO[CH] 1726 0-RTT[0]: STREAM[0, "..."] -> 1728 Initial[0]: CRYPTO[SH] ACK[0] 1729 Handshake[0] CRYPTO[EE, CERT, CV, FIN] 1730 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1732 Initial[1]: ACK[0] 1733 0-RTT[1]: CRYPTO[EOED] 1734 Handshake[0]: CRYPTO[FIN], ACK[0] 1735 1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1737 1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1738 <- Handshake[1]: ACK[0] 1740 Figure 9: Example 0-RTT Handshake 1742 6.6. Transport Parameters 1744 During connection establishment, both endpoints make authenticated 1745 declarations of their transport parameters. These declarations are 1746 made unilaterally by each endpoint. Endpoints are required to comply 1747 with the restrictions implied by these parameters; the description of 1748 each parameter includes rules for its handling. 1750 The format of the transport parameters is the TransportParameters 1751 struct from Figure 10. This is described using the presentation 1752 language from Section 3 of [TLS13]. 1754 uint32 QuicVersion; 1756 enum { 1757 initial_max_stream_data_bidi_local(0), 1758 initial_max_data(1), 1759 initial_max_bidi_streams(2), 1760 idle_timeout(3), 1761 preferred_address(4), 1762 max_packet_size(5), 1763 stateless_reset_token(6), 1764 ack_delay_exponent(7), 1765 initial_max_uni_streams(8), 1766 disable_migration(9), 1767 initial_max_stream_data_bidi_remote(10), 1768 initial_max_stream_data_uni(11), 1769 max_ack_delay(12), 1770 original_connection_id(13), 1771 (65535) 1772 } TransportParameterId; 1774 struct { 1775 TransportParameterId parameter; 1776 opaque value<0..2^16-1>; 1777 } TransportParameter; 1779 struct { 1780 select (Handshake.msg_type) { 1781 case client_hello: 1782 QuicVersion initial_version; 1784 case encrypted_extensions: 1785 QuicVersion negotiated_version; 1786 QuicVersion supported_versions<4..2^8-4>; 1787 }; 1788 TransportParameter parameters<22..2^16-1>; 1789 } TransportParameters; 1791 struct { 1792 enum { IPv4(4), IPv6(6), (15) } ipVersion; 1793 opaque ipAddress<4..2^8-1>; 1794 uint16 port; 1795 opaque connectionId<0..18>; 1796 opaque statelessResetToken[16]; 1797 } PreferredAddress; 1799 Figure 10: Definition of TransportParameters 1801 The "extension_data" field of the quic_transport_parameters extension 1802 defined in [QUIC-TLS] contains a TransportParameters value. TLS 1803 encoding rules are therefore used to encode the transport parameters. 1805 QUIC encodes transport parameters into a sequence of octets, which 1806 are then included in the cryptographic handshake. Once the handshake 1807 completes, the transport parameters declared by the peer are 1808 available. Each endpoint validates the value provided by its peer. 1809 In particular, version negotiation MUST be validated (see 1810 Section 6.6.4) before the connection establishment is considered 1811 properly complete. 1813 Definitions for each of the defined transport parameters are included 1814 in Section 6.6.1. Any given parameter MUST appear at most once in a 1815 given transport parameters extension. An endpoint MUST treat receipt 1816 of duplicate transport parameters as a connection error of type 1817 TRANSPORT_PARAMETER_ERROR. 1819 6.6.1. Transport Parameter Definitions 1821 An endpoint MAY use the following transport parameters: 1823 initial_max_data (0x0001): The initial maximum data parameter 1824 contains the initial value for the maximum amount of data that can 1825 be sent on the connection. This parameter is encoded as an 1826 unsigned 32-bit integer in units of octets. This is equivalent to 1827 sending a MAX_DATA (Section 7.6) for the connection immediately 1828 after completing the handshake. If the transport parameter is 1829 absent, the connection starts with a flow control limit of 0. 1831 initial_max_bidi_streams (0x0002): The initial maximum bidirectional 1832 streams parameter contains the initial maximum number of 1833 bidirectional streams the peer may initiate, encoded as an 1834 unsigned 16-bit integer. If this parameter is absent or zero, 1835 bidirectional streams cannot be created until a MAX_STREAM_ID 1836 frame is sent. Setting this parameter is equivalent to sending a 1837 MAX_STREAM_ID (Section 7.8) immediately after completing the 1838 handshake containing the corresponding Stream ID. For example, a 1839 value of 0x05 would be equivalent to receiving a MAX_STREAM_ID 1840 containing 16 when received by a client or 17 when received by a 1841 server. 1843 initial_max_uni_streams (0x0008): The initial maximum unidirectional 1844 streams parameter contains the initial maximum number of 1845 unidirectional streams the peer may initiate, encoded as an 1846 unsigned 16-bit integer. If this parameter is absent or zero, 1847 unidirectional streams cannot be created until a MAX_STREAM_ID 1848 frame is sent. Setting this parameter is equivalent to sending a 1849 MAX_STREAM_ID (Section 7.8) immediately after completing the 1850 handshake containing the corresponding Stream ID. For example, a 1851 value of 0x05 would be equivalent to receiving a MAX_STREAM_ID 1852 containing 18 when received by a client or 19 when received by a 1853 server. 1855 idle_timeout (0x0003): The idle timeout is a value in seconds that 1856 is encoded as an unsigned 16-bit integer. If this parameter is 1857 absent or zero then the idle timeout is disabled. 1859 max_packet_size (0x0005): The maximum packet size parameter places a 1860 limit on the size of packets that the endpoint is willing to 1861 receive, encoded as an unsigned 16-bit integer. This indicates 1862 that packets larger than this limit will be dropped. The default 1863 for this parameter is the maximum permitted UDP payload of 65527. 1864 Values below 1200 are invalid. This limit only applies to 1865 protected packets (Section 4.8). 1867 ack_delay_exponent (0x0007): An 8-bit unsigned integer value 1868 indicating an exponent used to decode the ACK Delay field in the 1869 ACK frame, see Section 7.16. If this value is absent, a default 1870 value of 3 is assumed (indicating a multiplier of 8). The default 1871 value is also used for ACK frames that are sent in Initial and 1872 Handshake packets. Values above 20 are invalid. 1874 disable_migration (0x0009): The endpoint does not support connection 1875 migration (Section 6.11). Peers MUST NOT send any packets, 1876 including probing packets (Section 6.11.1), from a local address 1877 other than that used to perform the handshake. This parameter is 1878 a zero-length value. 1880 max_ack_delay (0x000c): An 8 bit unsigned integer value indicating 1881 the maximum amount of time in milliseconds by which it will delay 1882 sending of acknowledgments. If this value is absent, a default of 1883 25 milliseconds is assumed. 1885 Either peer MAY advertise an initial value for the flow control on 1886 each type of stream on which they might receive data. Each of the 1887 following transport parameters is encoded as an unsigned 32-bit 1888 integer in units of octets: 1890 initial_max_stream_data_bidi_local (0x0000): The initial stream 1891 maximum data for bidirectional, locally-initiated streams 1892 parameter contains the initial flow control limit for newly 1893 created bidirectional streams opened by the endpoint that sets the 1894 transport parameter. In client transport parameters, this applies 1895 to streams with an identifier ending in 0x0; in server transport 1896 parameters, this applies to streams ending in 0x1. 1898 initial_max_stream_data_bidi_remote (0x000a): The initial stream 1899 maximum data for bidirectional, peer-initiated streams parameter 1900 contains the initial flow control limit for newly created 1901 bidirectional streams opened by the endpoint that receives the 1902 transport parameter. In client transport parameters, this applies 1903 to streams with an identifier ending in 0x1; in server transport 1904 parameters, this applies to streams ending in 0x0. 1906 initial_max_stream_data_uni (0x000b): The initial stream maximum 1907 data for unidirectional streams parameter contains the initial 1908 flow control limit for newly created unidirectional streams opened 1909 by the endpoint that receives the transport parameter. In client 1910 transport parameters, this applies to streams with an identifier 1911 ending in 0x3; in server transport parameters, this applies to 1912 streams ending in 0x2. 1914 If present, transport parameters that set initial stream flow control 1915 limits are equivalent to sending a MAX_STREAM_DATA frame 1916 (Section 7.7) on every stream of the corresponding type immediately 1917 after opening. If the transport parameter is absent, streams of that 1918 type start with a flow control limit of 0. 1920 A server MUST include the original_connection_id transport parameter 1921 if it sent a Retry packet: 1923 original_connection_id (0x000d): The value of the Destination 1924 Connection ID field from the first Initial packet sent by the 1925 client. This transport parameter is only sent by the server. 1927 A server MAY include the following transport parameters: 1929 stateless_reset_token (0x0006): The Stateless Reset Token is used in 1930 verifying a stateless reset, see Section 6.13.4. This parameter 1931 is a sequence of 16 octets. 1933 preferred_address (0x0004): The server's Preferred Address is used 1934 to effect a change in server address at the end of the handshake, 1935 as described in Section 6.12. 1937 A client MUST NOT include a stateless reset token or a preferred 1938 address. A server MUST treat receipt of either transport parameter 1939 as a connection error of type TRANSPORT_PARAMETER_ERROR. 1941 6.6.2. Values of Transport Parameters for 0-RTT 1943 A client that attempts to send 0-RTT data MUST remember the transport 1944 parameters used by the server. The transport parameters that the 1945 server advertises during connection establishment apply to all 1946 connections that are resumed using the keying material established 1947 during that handshake. Remembered transport parameters apply to the 1948 new connection until the handshake completes and new transport 1949 parameters from the server can be provided. 1951 A server can remember the transport parameters that it advertised, or 1952 store an integrity-protected copy of the values in the ticket and 1953 recover the information when accepting 0-RTT data. A server uses the 1954 transport parameters in determining whether to accept 0-RTT data. 1956 A server MAY accept 0-RTT and subsequently provide different values 1957 for transport parameters for use in the new connection. If 0-RTT 1958 data is accepted by the server, the server MUST NOT reduce any limits 1959 or alter any values that might be violated by the client with its 1960 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1961 set values for initial_max_data, initial_max_stream_data_bidi_local, 1962 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni 1963 that are smaller than the remembered value of those parameters. 1964 Similarly, a server MUST NOT reduce the value of 1965 initial_max_bidi_streams or initial_max_uni_streams. 1967 Omitting or setting a zero value for certain transport parameters can 1968 result in 0-RTT data being enabled, but not usable. The applicable 1969 subset of transport parameters that permit sending of application 1970 data SHOULD be set to non-zero values for 0-RTT. This includes 1971 initial_max_data and either initial_max_bidi_streams and 1972 initial_max_stream_data_bidi_remote, or initial_max_uni_streams and 1973 initial_max_stream_data_uni. 1975 The value of the server's previous preferred_address MUST NOT be used 1976 when establishing a new connection; rather, the client should wait to 1977 observe the server's new preferred_address value in the handshake. 1979 A server MUST reject 0-RTT data or even abort a handshake if the 1980 implied values for transport parameters cannot be supported. 1982 6.6.3. New Transport Parameters 1984 New transport parameters can be used to negotiate new protocol 1985 behavior. An endpoint MUST ignore transport parameters that it does 1986 not support. Absence of a transport parameter therefore disables any 1987 optional protocol feature that is negotiated using the parameter. 1989 New transport parameters can be registered according to the rules in 1990 Section 13.1. 1992 6.6.4. Version Negotiation Validation 1994 Though the cryptographic handshake has integrity protection, two 1995 forms of QUIC version downgrade are possible. In the first, an 1996 attacker replaces the QUIC version in the Initial packet. In the 1997 second, a fake Version Negotiation packet is sent by an attacker. To 1998 protect against these attacks, the transport parameters include three 1999 fields that encode version information. These parameters are used to 2000 retroactively authenticate the choice of version (see Section 6.3). 2002 The cryptographic handshake provides integrity protection for the 2003 negotiated version as part of the transport parameters (see 2004 Section 6.6). As a result, attacks on version negotiation by an 2005 attacker can be detected. 2007 The client includes the initial_version field in its transport 2008 parameters. The initial_version is the version that the client 2009 initially attempted to use. If the server did not send a Version 2010 Negotiation packet Section 4.3, this will be identical to the 2011 negotiated_version field in the server transport parameters. 2013 A server that processes all packets in a stateful fashion can 2014 remember how version negotiation was performed and validate the 2015 initial_version value. 2017 A server that does not maintain state for every packet it receives 2018 (i.e., a stateless server) uses a different process. If the 2019 initial_version matches the version of QUIC that is in use, a 2020 stateless server can accept the value. 2022 If the initial_version is different from the version of QUIC that is 2023 in use, a stateless server MUST check that it would have sent a 2024 Version Negotiation packet if it had received a packet with the 2025 indicated initial_version. If a server would have accepted the 2026 version included in the initial_version and the value differs from 2027 the QUIC version that is in use, the server MUST terminate the 2028 connection with a VERSION_NEGOTIATION_ERROR error. 2030 The server includes both the version of QUIC that is in use and a 2031 list of the QUIC versions that the server supports. 2033 The negotiated_version field is the version that is in use. This 2034 MUST be set by the server to the value that is on the Initial packet 2035 that it accepts (not an Initial packet that triggers a Retry or 2036 Version Negotiation packet). A client that receives a 2037 negotiated_version that does not match the version of QUIC that is in 2038 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 2039 error code. 2041 The server includes a list of versions that it would send in any 2042 version negotiation packet (Section 4.3) in the supported_versions 2043 field. The server populates this field even if it did not send a 2044 version negotiation packet. 2046 The client validates that the negotiated_version is included in the 2047 supported_versions list and - if version negotiation was performed - 2048 that it would have selected the negotiated version. A client MUST 2049 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 2050 if the current QUIC version is not listed in the supported_versions 2051 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 2052 code if version negotiation occurred but it would have selected a 2053 different version based on the value of the supported_versions list. 2055 When an endpoint accepts multiple QUIC versions, it can potentially 2056 interpret transport parameters as they are defined by any of the QUIC 2057 versions it supports. The version field in the QUIC packet header is 2058 authenticated using transport parameters. The position and the 2059 format of the version fields in transport parameters MUST either be 2060 identical across different QUIC versions, or be unambiguously 2061 different to ensure no confusion about their interpretation. One way 2062 that a new format could be introduced is to define a TLS extension 2063 with a different codepoint. 2065 6.7. Stateless Retries 2067 A server can process an Initial packet from a client without 2068 committing any state. This allows a server to perform address 2069 validation (Section 6.9), or to defer connection establishment costs. 2071 A server that generates a response to an Initial packet without 2072 retaining connection state MUST use the Retry packet (Section 4.4). 2073 This packet causes a client to restart the connection attempt and 2074 includes the token in the new Initial packet (Section 4.6) to prove 2075 source address ownership. 2077 6.8. Using Explicit Congestion Notification 2079 QUIC endpoints use Explicit Congestion Notification (ECN) [RFC3168] 2080 to detect and respond to network congestion. ECN allows a network 2081 node to indicate congestion in the network by setting a codepoint in 2082 the IP header of a packet instead of dropping it. Endpoints react to 2083 congestion by reducing their sending rate in response, as described 2084 in [QUIC-RECOVERY]. 2086 To use ECN, QUIC endpoints first determine whether a path supports 2087 ECN marking and the peer is able to access the ECN codepoint in the 2088 IP header. A network path does not support ECN if ECN marked packets 2089 get dropped or ECN markings are rewritten on the path. An endpoint 2090 verifies the path, both during connection establishment and when 2091 migrating to a new path (see Section 6.11). 2093 Each endpoint independently verifies and enables use of ECN by 2094 setting the IP header ECN codepoint to ECN Capable Transport (ECT) 2095 for the path from it to the other peer. Even if ECN is not used on 2096 the path to the peer, the endpoint MUST provide feedback about ECN 2097 markings received (if accessible). 2099 To verify both that a path supports ECN and the peer can provide ECN 2100 feedback, an endpoint MUST set the ECT(0) codepoint in the IP header 2101 of all outgoing packets [RFC8311]. 2103 If an ECT codepoint set in the IP header is not corrupted by a 2104 network device, then a received packet contains either the codepoint 2105 sent by the peer or the Congestion Experienced (CE) codepoint set by 2106 a network device that is experiencing congestion. 2108 On receiving a packet with an ECT or CE codepoint, an endpoint that 2109 can access the IP ECN codepoints increases the corresponding ECT(0), 2110 ECT(1), or CE count, and includes these counters in subsequent (see 2111 Section 8.1) ACK frames (see Section 7.16). 2113 A packet detected by a receiver as a duplicate does not affect the 2114 receiver's local ECN codepoint counts; see (Section 12.7) for 2115 relevant security concerns. 2117 If an endpoint receives a packet without an ECT or CE codepoint, it 2118 responds per Section 8.1 with an ACK frame. 2120 If an endpoint does not have access to received ECN codepoints, it 2121 acknowledges received packets per Section 8.1 with an ACK frame. 2123 If a packet sent with an ECT codepoint is newly acknowledged by the 2124 peer in an ACK frame, the endpoint stops setting ECT codepoints in 2125 subsequent packets, with the expectation that either the network or 2126 the peer no longer supports ECN. 2128 To protect the connection from arbitrary corruption of ECN codepoints 2129 by the network, an endpoint verifies the following when an ACK frame 2130 is received: 2132 o The increase in ECT(0) and ECT(1) counters MUST be at least the 2133 number of packets newly acknowledged that were sent with the 2134 corresponding codepoint. 2136 o The total increase in ECT(0), ECT(1), and CE counters reported in 2137 the ACK frame MUST be at least the total number of packets newly 2138 acknowledged in this ACK frame. 2140 An endpoint could miss acknowledgements for a packet when ACK frames 2141 are lost. It is therefore possible for the total increase in ECT(0), 2142 ECT(1), and CE counters to be greater than the number of packets 2143 acknowledged in an ACK frame. When this happens, the local reference 2144 counts MUST be increased to match the counters in the ACK frame. 2146 Upon successful verification, an endpoint continues to set ECT 2147 codepoints in subsequent packets with the expectation that the path 2148 is ECN-capable. 2150 If verification fails, then the endpoint ceases setting ECT 2151 codepoints in subsequent packets with the expectation that either the 2152 network or the peer does not support ECN. 2154 If an endpoint sets ECT codepoints on outgoing packets and encounters 2155 a retransmission timeout due to the absence of acknowledgments from 2156 the peer (see [QUIC-RECOVERY]), or if an endpoint has reason to 2157 believe that a network element might be corrupting ECN codepoints, 2158 the endpoint MAY cease setting ECT codepoints in subsequent packets. 2159 Doing so allows the connection to traverse network elements that drop 2160 or corrupt ECN codepoints in the IP header. 2162 6.9. Proof of Source Address Ownership 2164 Transport protocols commonly spend a round trip checking that a 2165 client owns the transport address (IP and port) that it claims. 2166 Verifying that a client can receive packets sent to its claimed 2167 transport address protects against spoofing of this information by 2168 malicious clients. 2170 This technique is used primarily to avoid QUIC from being used for 2171 traffic amplification attack. In such an attack, a packet is sent to 2172 a server with spoofed source address information that identifies a 2173 victim. If a server generates more or larger packets in response to 2174 that packet, the attacker can use the server to send more data toward 2175 the victim than it would be able to send on its own. 2177 Several methods are used in QUIC to mitigate this attack. Firstly, 2178 the initial handshake packet is sent in a UDP datagram that contains 2179 at least 1200 octets of UDP payload. This allows a server to send a 2180 similar amount of data without risking causing an amplification 2181 attack toward an unproven remote address. 2183 A server eventually confirms that a client has received its messages 2184 when the first Handshake-level message is received. This might be 2185 insufficient, either because the server wishes to avoid the 2186 computational cost of completing the handshake, or it might be that 2187 the size of the packets that are sent during the handshake is too 2188 large. This is especially important for 0-RTT, where the server 2189 might wish to provide application data traffic - such as a response 2190 to a request - in response to the data carried in the early data from 2191 the client. 2193 To send additional data prior to completing the cryptographic 2194 handshake, the server then needs to validate that the client owns the 2195 address that it claims. 2197 Source address validation is therefore performed by the core 2198 transport protocol during the establishment of a connection. 2200 A different type of source address validation is performed after a 2201 connection migration, see Section 6.10. 2203 6.9.1. Client Address Validation Procedure 2205 QUIC uses token-based address validation. Any time the server wishes 2206 to validate a client address, it provides the client with a token. 2207 As long as the token's authenticity can be checked (see 2208 Section 6.9.3) and the client is able to return that token, it proves 2209 to the server that it received the token. 2211 Upon receiving the client's Initial packet, the server can request 2212 address validation by sending a Retry packet containing a token. 2213 This token is repeated in the client's next Initial packet. Because 2214 the token is consumed by the server that generates it, there is no 2215 need for a single well-defined format. A token could include 2216 information about the claimed client address (IP and port), a 2217 timestamp, and any other supplementary information the server will 2218 need to validate the token in the future. 2220 The Retry packet is sent to the client and a legitimate client will 2221 respond with an Initial packet containing the token from the Retry 2222 packet when it continues the handshake. In response to receiving the 2223 token, a server can either abort the connection or permit it to 2224 proceed. 2226 A connection MAY be accepted without address validation - or with 2227 only limited validation - but a server SHOULD limit the data it sends 2228 toward an unvalidated address. Successful completion of the 2229 cryptographic handshake implicitly provides proof that the client has 2230 received packets from the server. 2232 The client should allow for additional Retry packets being sent in 2233 response to Initial packets sent containing a token. There are 2234 several situations in which the server might not be able to use the 2235 previously generated token to validate the client's address and must 2236 send a new Retry. A reasonable limit to the number of tries the 2237 client allows for, before giving up, is 3. That is, the client MUST 2238 echo the address validation token from a new Retry packet up to 3 2239 times. After that, it MAY give up on the connection attempt. 2241 6.9.2. Address Validation for Future Connections 2243 A server MAY provide clients with an address validation token during 2244 one connection that can be used on a subsequent connection. Address 2245 validation is especially important with 0-RTT because a server 2246 potentially sends a significant amount of data to a client in 2247 response to 0-RTT data. 2249 The server uses the NEW_TOKEN frame Section 7.19 to provide the 2250 client with an address validation token that can be used to validate 2251 future connections. The client may then use this token to validate 2252 future connections by including it in the Initial packet's header. 2253 The client MUST NOT use the token provided in a Retry for future 2254 connections. 2256 Unlike the token that is created for a Retry packet, there might be 2257 some time between when the token is created and when the token is 2258 subsequently used. Thus, a resumption token SHOULD include an 2259 expiration time. The server MAY include either an explicit 2260 expiration time or an issued timestamp and dynamically calculate the 2261 expiration time. It is also unlikely that the client port number is 2262 the same on two different connections; validating the port is 2263 therefore unlikely to be successful. 2265 6.9.3. Address Validation Token Integrity 2267 An address validation token MUST be difficult to guess. Including a 2268 large enough random value in the token would be sufficient, but this 2269 depends on the server remembering the value it sends to clients. 2271 A token-based scheme allows the server to offload any state 2272 associated with validation to the client. For this design to work, 2273 the token MUST be covered by integrity protection against 2274 modification or falsification by clients. Without integrity 2275 protection, malicious clients could generate or guess values for 2276 tokens that would be accepted by the server. Only the server 2277 requires access to the integrity protection key for tokens. 2279 6.10. Path Validation 2281 Path validation is used by an endpoint to verify reachability of a 2282 peer over a specific path. That is, it tests reachability between a 2283 specific local address and a specific peer address, where an address 2284 is the two-tuple of IP address and port. Path validation tests that 2285 packets can be both sent to and received from a peer. 2287 Path validation is used during connection migration (see Section 6.11 2288 and Section 6.12) by the migrating endpoint to verify reachability of 2289 a peer from a new local address. Path validation is also used by the 2290 peer to verify that the migrating endpoint is able to receive packets 2291 sent to the its new address. That is, that the packets received from 2292 the migrating endpoint do not carry a spoofed source address. 2294 Path validation can be used at any time by either endpoint. For 2295 instance, an endpoint might check that a peer is still in possession 2296 of its address after a period of quiescence. 2298 Path validation is not designed as a NAT traversal mechanism. Though 2299 the mechanism described here might be effective for the creation of 2300 NAT bindings that support NAT traversal, the expectation is that one 2301 or other peer is able to receive packets without first having sent a 2302 packet on that path. Effective NAT traversal needs additional 2303 synchronization mechanisms that are not provided here. 2305 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 2306 are used for path validation with other frames. For instance, an 2307 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 2308 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 2309 PATH_CHALLENGE. 2311 When probing a new path, an endpoint might want to ensure that its 2312 peer has an unused connection ID available for responses. The 2313 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 2314 same packet. This ensures that an unused connection ID will be 2315 available to the peer when sending a response. 2317 6.10.1. Initiation 2319 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 2320 containing a random payload on the path to be validated. 2322 An endpoint MAY send additional PATH_CHALLENGE frames to handle 2323 packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more 2324 frequently than it would an Initial packet, ensuring that connection 2325 migration is no more load on a new path than establishing a new 2326 connection. 2328 The endpoint MUST use fresh random data in every PATH_CHALLENGE frame 2329 so that it can associate the peer's response with the causative 2330 PATH_CHALLENGE. 2332 6.10.2. Response 2334 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 2335 immediately by echoing the data contained in the PATH_CHALLENGE frame 2336 in a PATH_RESPONSE frame, with the following stipulation. Since a 2337 PATH_CHALLENGE might be sent from a spoofed address, an endpoint MAY 2338 limit the rate at which it sends PATH_RESPONSE frames and MAY 2339 silently discard PATH_CHALLENGE frames that would cause it to respond 2340 at a higher rate. 2342 To ensure that packets can be both sent to and received from the 2343 peer, the PATH_RESPONSE MUST be sent on the same path as the 2344 triggering PATH_CHALLENGE: from the same local address on which the 2345 PATH_CHALLENGE was received, to the same remote address from which 2346 the PATH_CHALLENGE was received. 2348 6.10.3. Completion 2350 A new address is considered valid when a PATH_RESPONSE frame is 2351 received containing data that was sent in a previous PATH_CHALLENGE. 2352 Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE 2353 frame is not adequate validation, since the acknowledgment can be 2354 spoofed by a malicious peer. 2356 For path validation to be successful, a PATH_RESPONSE frame MUST be 2357 received from the same remote address to which the corresponding 2358 PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a 2359 different remote address than the one to which the PATH_CHALLENGE was 2360 sent, path validation is considered to have failed, even if the data 2361 matches that sent in the PATH_CHALLENGE. 2363 Additionally, the PATH_RESPONSE frame MUST be received on the same 2364 local address from which the corresponding PATH_CHALLENGE was sent. 2365 If a PATH_RESPONSE frame is received on a different local address 2366 than the one from which the PATH_CHALLENGE was sent, path validation 2367 is considered to have failed, even if the data matches that sent in 2368 the PATH_CHALLENGE. Thus, the endpoint considers the path to be 2369 valid when a PATH_RESPONSE frame is received on the same path with 2370 the same payload as the PATH_CHALLENGE frame. 2372 6.10.4. Abandonment 2374 An endpoint SHOULD abandon path validation after sending some number 2375 of PATH_CHALLENGE frames or after some time has passed. When setting 2376 this timer, implementations are cautioned that the new path could 2377 have a longer round-trip time than the original. 2379 Note that the endpoint might receive packets containing other frames 2380 on the new path, but a PATH_RESPONSE frame with appropriate data is 2381 required for path validation to succeed. 2383 If path validation fails, the path is deemed unusable. This does not 2384 necessarily imply a failure of the connection - endpoints can 2385 continue sending packets over other paths as appropriate. If no 2386 paths are available, an endpoint can wait for a new path to become 2387 available or close the connection. 2389 A path validation might be abandoned for other reasons besides 2390 failure. Primarily, this happens if a connection migration to a new 2391 path is initiated while a path validation on the old path is in 2392 progress. 2394 6.11. Connection Migration 2396 QUIC allows connections to survive changes to endpoint addresses 2397 (that is, IP address and/or port), such as those caused by an 2398 endpoint migrating to a new network. This section describes the 2399 process by which an endpoint migrates to a new address. 2401 An endpoint MUST NOT initiate connection migration before the 2402 handshake is finished and the endpoint has 1-RTT keys. The design of 2403 QUIC relies on endpoints retaining a stable address for the duration 2404 of the handshake. 2406 An endpoint also MUST NOT initiate connection migration if the peer 2407 sent the "disable_migration" transport parameter during the 2408 handshake. An endpoint which has sent this transport parameter, but 2409 detects that a peer has nonetheless migrated to a different network 2410 MAY treat this as a connection error of type INVALID_MIGRATION. 2412 Not all changes of peer address are intentional migrations. The peer 2413 could experience NAT rebinding: a change of address due to a 2414 middlebox, usually a NAT, allocating a new outgoing port or even a 2415 new outgoing IP address for a flow. Endpoints SHOULD perform path 2416 validation (Section 6.10) if a NAT rebinding does not cause the 2417 connection to fail. 2419 This document limits migration of connections to new client 2420 addresses, except as described in Section 6.12. Clients are 2421 responsible for initiating all migrations. Servers do not send non- 2422 probing packets (see Section 6.11.1) toward a client address until 2423 they see a non-probing packet from that address. If a client 2424 receives packets from an unknown server address, the client MAY 2425 discard these packets. 2427 6.11.1. Probing a New Path 2429 An endpoint MAY probe for peer reachability from a new local address 2430 using path validation Section 6.10 prior to migrating the connection 2431 to the new local address. Failure of path validation simply means 2432 that the new path is not usable for this connection. Failure to 2433 validate a path does not cause the connection to end unless there are 2434 no valid alternative paths available. 2436 An endpoint uses a new connection ID for probes sent from a new local 2437 address, see Section 6.11.5 for further discussion. An endpoint that 2438 uses a new local address needs to ensure that at least one new 2439 connection ID is available at the peer. That can be achieved by 2440 including a NEW_CONNECTION_ID frame in the probe. 2442 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2443 is probing for reachability on a path. An endpoint sends a 2444 PATH_RESPONSE in response as per Section 6.10. 2446 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2447 are "probing frames", and all other frames are "non-probing frames". 2448 A packet containing only probing frames is a "probing packet", and a 2449 packet containing any other frame is a "non-probing packet". 2451 6.11.2. Initiating Connection Migration 2453 An endpoint can migrate a connection to a new local address by 2454 sending packets containing frames other than probing frames from that 2455 address. 2457 Each endpoint validates its peer's address during connection 2458 establishment. Therefore, a migrating endpoint can send to its peer 2459 knowing that the peer is willing to receive at the peer's current 2460 address. Thus an endpoint can migrate to a new local address without 2461 first validating the peer's address. 2463 When migrating, the new path might not support the endpoint's current 2464 sending rate. Therefore, the endpoint resets its congestion 2465 controller, as described in Section 6.11.4. 2467 The new path might not have the same ECN capability. Therefore, the 2468 endpoint verifies ECN capability as described in Section 6.8. 2470 Receiving acknowledgments for data sent on the new path serves as 2471 proof of the peer's reachability from the new address. Note that 2472 since acknowledgments may be received on any path, return 2473 reachability on the new path is not established. To establish return 2474 reachability on the new path, an endpoint MAY concurrently initiate 2475 path validation Section 6.10 on the new path. 2477 6.11.3. Responding to Connection Migration 2479 Receiving a packet from a new peer address containing a non-probing 2480 frame indicates that the peer has migrated to that address. 2482 In response to such a packet, an endpoint MUST start sending 2483 subsequent packets to the new peer address and MUST initiate path 2484 validation (Section 6.10) to verify the peer's ownership of the 2485 unvalidated address. 2487 An endpoint MAY send data to an unvalidated peer address, but it MUST 2488 protect against potential attacks as described in Section 6.11.3.1 2489 and Section 6.11.3.2. An endpoint MAY skip validation of a peer 2490 address if that address has been seen recently. 2492 An endpoint only changes the address that it sends packets to in 2493 response to the highest-numbered non-probing packet. This ensures 2494 that an endpoint does not send packets to an old peer address in the 2495 case that it receives reordered packets. 2497 After changing the address to which it sends non-probing packets, an 2498 endpoint could abandon any path validation for other addresses. 2500 Receiving a packet from a new peer address might be the result of a 2501 NAT rebinding at the peer. 2503 After verifying a new client address, the server SHOULD send new 2504 address validation tokens (Section 6.9) to the client. 2506 6.11.3.1. Handling Address Spoofing by a Peer 2508 It is possible that a peer is spoofing its source address to cause an 2509 endpoint to send excessive amounts of data to an unwilling host. If 2510 the endpoint sends significantly more data than the spoofing peer, 2511 connection migration might be used to amplify the volume of data that 2512 an attacker can generate toward a victim. 2514 As described in Section 6.11.3, an endpoint is required to validate a 2515 peer's new address to confirm the peer's possession of the new 2516 address. Until a peer's address is deemed valid, an endpoint MUST 2517 limit the rate at which it sends data to this address. The endpoint 2518 MUST NOT send more than a minimum congestion window's worth of data 2519 per estimated round-trip time (kMinimumWindow, as defined in 2520 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2521 being used for a denial of service attack against an unsuspecting 2522 victim. Note that since the endpoint will not have any round-trip 2523 time measurements to this address, the estimate SHOULD be the default 2524 initial value (see [QUIC-RECOVERY]). 2526 If an endpoint skips validation of a peer address as described in 2527 Section 6.11.3, it does not need to limit its sending rate. 2529 6.11.3.2. Handling Address Spoofing by an On-path Attacker 2531 An on-path attacker could cause a spurious connection migration by 2532 copying and forwarding a packet with a spoofed address such that it 2533 arrives before the original packet. The packet with the spoofed 2534 address will be seen to come from a migrating connection, and the 2535 original packet will be seen as a duplicate and dropped. After a 2536 spurious migration, validation of the source address will fail 2537 because the entity at the source address does not have the necessary 2538 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2539 that is sent to it even if it wanted to. 2541 To protect the connection from failing due to such a spurious 2542 migration, an endpoint MUST revert to using the last validated peer 2543 address when validation of a new peer address fails. 2545 If an endpoint has no state about the last validated peer address, it 2546 MUST close the connection silently by discarding all connection 2547 state. This results in new packets on the connection being handled 2548 generically. For instance, an endpoint MAY send a stateless reset in 2549 response to any further incoming packets. 2551 Note that receipt of packets with higher packet numbers from the 2552 legitimate peer address will trigger another connection migration. 2553 This will cause the validation of the address of the spurious 2554 migration to be abandoned. 2556 6.11.4. Loss Detection and Congestion Control 2558 The capacity available on the new path might not be the same as the 2559 old path. Packets sent on the old path SHOULD NOT contribute to 2560 congestion control or RTT estimation for the new path. 2562 On confirming a peer's ownership of its new address, an endpoint 2563 SHOULD immediately reset the congestion controller and round-trip 2564 time estimator for the new path. 2566 An endpoint MUST NOT return to the send rate used for the previous 2567 path unless it is reasonably sure that the previous send rate is 2568 valid for the new path. For instance, a change in the client's port 2569 number is likely indicative of a rebinding in a middlebox and not a 2570 complete change in path. This determination likely depends on 2571 heuristics, which could be imperfect; if the new path capacity is 2572 significantly reduced, ultimately this relies on the congestion 2573 controller responding to congestion signals and reducing send rates 2574 appropriately. 2576 There may be apparent reordering at the receiver when an endpoint 2577 sends data and probes from/to multiple addresses during the migration 2578 period, since the two resulting paths may have different round-trip 2579 times. A receiver of packets on multiple paths will still send ACK 2580 frames covering all received packets. 2582 While multiple paths might be used during connection migration, a 2583 single congestion control context and a single loss recovery context 2584 (as described in [QUIC-RECOVERY]) may be adequate. A sender can make 2585 exceptions for probe packets so that their loss detection is 2586 independent and does not unduly cause the congestion controller to 2587 reduce its sending rate. An endpoint might set a separate timer when 2588 a PATH_CHALLENGE is sent, which is cancelled when the corresponding 2589 PATH_RESPONSE is received. If the timer fires before the 2590 PATH_RESPONSE is received, the endpoint might send a new 2591 PATH_CHALLENGE, and restart the timer for a longer period of time. 2593 6.11.5. Privacy Implications of Connection Migration 2595 Using a stable connection ID on multiple network paths allows a 2596 passive observer to correlate activity between those paths. An 2597 endpoint that moves between networks might not wish to have their 2598 activity correlated by any entity other than their peer, so different 2599 connection IDs are used when sending from different local addresses, 2600 as discussed in Section 6.1. For this to be effective endpoints need 2601 to ensure that connections IDs they provide cannot be linked by any 2602 other entity. 2604 This eliminates the use of the connection ID for linking activity 2605 from the same connection on different networks. Protection of packet 2606 numbers ensures that packet numbers cannot be used to correlate 2607 activity. This does not prevent other properties of packets, such as 2608 timing and size, from being used to correlate activity. 2610 Clients MAY move to a new connection ID at any time based on 2611 implementation-specific concerns. For example, after a period of 2612 network inactivity NAT rebinding might occur when the client begins 2613 sending data again. 2615 A client might wish to reduce linkability by employing a new 2616 connection ID and source UDP port when sending traffic after a period 2617 of inactivity. Changing the UDP port from which it sends packets at 2618 the same time might cause the packet to appear as a connection 2619 migration. This ensures that the mechanisms that support migration 2620 are exercised even for clients that don't experience NAT rebindings 2621 or genuine migrations. Changing port number can cause a peer to 2622 reset its congestion state (see Section 6.11.4), so the port SHOULD 2623 only be changed infrequently. 2625 Endpoints that use connection IDs with length greater than zero could 2626 have their activity correlated if their peers keep using the same 2627 destination connection ID after migration. Endpoints that receive 2628 packets with a previously unused Destination Connection ID SHOULD 2629 change to sending packets with a connection ID that has not been used 2630 on any other network path. The goal here is to ensure that packets 2631 sent on different paths cannot be correlated. To fulfill this 2632 privacy requirement, endpoints that initiate migration and use 2633 connection IDs with length greater than zero SHOULD provide their 2634 peers with new connection IDs before migration. 2636 Caution: If both endpoints change connection ID in response to 2637 seeing a change in connection ID from their peer, then this can 2638 trigger an infinite sequence of changes. 2640 6.12. Server's Preferred Address 2642 QUIC allows servers to accept connections on one IP address and 2643 attempt to transfer these connections to a more preferred address 2644 shortly after the handshake. This is particularly useful when 2645 clients initially connect to an address shared by multiple servers 2646 but would prefer to use a unicast address to ensure connection 2647 stability. This section describes the protocol for migrating a 2648 connection to a preferred server address. 2650 Migrating a connection to a new server address mid-connection is left 2651 for future work. If a client receives packets from a new server 2652 address not indicated by the preferred_address transport parameter, 2653 the client SHOULD discard these packets. 2655 6.12.1. Communicating A Preferred Address 2657 A server conveys a preferred address by including the 2658 preferred_address transport parameter in the TLS handshake. 2660 Once the handshake is finished, the client SHOULD initiate path 2661 validation (see Section 6.10) of the server's preferred address using 2662 the connection ID provided in the preferred_address transport 2663 parameter. 2665 If path validation succeeds, the client SHOULD immediately begin 2666 sending all future packets to the new server address using the new 2667 connection ID and discontinue use of the old server address. If path 2668 validation fails, the client MUST continue sending all future packets 2669 to the server's original IP address. 2671 6.12.2. Responding to Connection Migration 2673 A server might receive a packet addressed to its preferred IP address 2674 at any time after the handshake is completed. If this packet 2675 contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE 2676 frame as per Section 6.10, but the server MUST continue sending all 2677 other packets from its original IP address. 2679 The server SHOULD also initiate path validation of the client using 2680 its preferred address and the address from which it received the 2681 client probe. This helps to guard against spurious migration 2682 initiated by an attacker. 2684 Once the server has completed its path validation and has received a 2685 non-probing packet with a new largest packet number on its preferred 2686 address, the server begins sending to the client exclusively from its 2687 preferred IP address. It SHOULD drop packets for this connection 2688 received on the old IP address, but MAY continue to process delayed 2689 packets. 2691 6.12.3. Interaction of Client Migration and Preferred Address 2693 A client might need to perform a connection migration before it has 2694 migrated to the server's preferred address. In this case, the client 2695 SHOULD perform path validation to both the original and preferred 2696 server address from the client's new address concurrently. 2698 If path validation of the server's preferred address succeeds, the 2699 client MUST abandon validation of the original address and migrate to 2700 using the server's preferred address. If path validation of the 2701 server's preferred address fails, but validation of the server's 2702 original address succeeds, the client MAY migrate to using the 2703 original address from the client's new address. 2705 If the connection to the server's preferred address is not from the 2706 same client address, the server MUST protect against potential 2707 attacks as described in Section 6.11.3.1 and Section 6.11.3.2. In 2708 addition to intentional simultaneous migration, this might also occur 2709 because the client's access network used a different NAT binding for 2710 the server's preferred address. 2712 Servers SHOULD initiate path validation to the client's new address 2713 upon receiving a probe packet from a different address. Servers MUST 2714 NOT send more than a minimum congestion window's worth of non-probing 2715 packets to the new address before path validation is complete. 2717 6.13. Connection Termination 2719 Connections should remain open until they become idle for a pre- 2720 negotiated period of time. A QUIC connection, once established, can 2721 be terminated in one of three ways: 2723 o idle timeout (Section 6.13.2) 2725 o immediate close (Section 6.13.3) 2727 o stateless reset (Section 6.13.4) 2729 6.13.1. Closing and Draining Connection States 2731 The closing and draining connection states exist to ensure that 2732 connections close cleanly and that delayed or reordered packets are 2733 properly discarded. These states SHOULD persist for three times the 2734 current Retransmission Timeout (RTO) interval as defined in 2735 [QUIC-RECOVERY]. 2737 An endpoint enters a closing period after initiating an immediate 2738 close (Section 6.13.3). While closing, an endpoint MUST NOT send 2739 packets unless they contain a CONNECTION_CLOSE or APPLICATION_CLOSE 2740 frame (see Section 6.13.3 for details). 2742 In the closing state, only a packet containing a closing frame can be 2743 sent. An endpoint retains only enough information to generate a 2744 packet containing a closing frame and to identify packets as 2745 belonging to the connection. The connection ID and QUIC version is 2746 sufficient information to identify packets for a closing connection; 2747 an endpoint can discard all other connection state. An endpoint MAY 2748 retain packet protection keys for incoming packets to allow it to 2749 read and process a closing frame. 2751 The draining state is entered once an endpoint receives a signal that 2752 its peer is closing or draining. While otherwise identical to the 2753 closing state, an endpoint in the draining state MUST NOT send any 2754 packets. Retaining packet protection keys is unnecessary once a 2755 connection is in the draining state. 2757 An endpoint MAY transition from the closing period to the draining 2758 period if it can confirm that its peer is also closing or draining. 2759 Receiving a closing frame is sufficient confirmation, as is receiving 2760 a stateless reset. The draining period SHOULD end when the closing 2761 period would have ended. In other words, the endpoint can use the 2762 same end time, but cease retransmission of the closing packet. 2764 Disposing of connection state prior to the end of the closing or 2765 draining period could cause delayed or reordered packets to be 2766 handled poorly. Endpoints that have some alternative means to ensure 2767 that late-arriving packets on the connection do not create QUIC 2768 state, such as those that are able to close the UDP socket, MAY use 2769 an abbreviated draining period which can allow for faster resource 2770 recovery. Servers that retain an open socket for accepting new 2771 connections SHOULD NOT exit the closing or draining period early. 2773 Once the closing or draining period has ended, an endpoint SHOULD 2774 discard all connection state. This results in new packets on the 2775 connection being handled generically. For instance, an endpoint MAY 2776 send a stateless reset in response to any further incoming packets. 2778 The draining and closing periods do not apply when a stateless reset 2779 (Section 6.13.4) is sent. 2781 An endpoint is not expected to handle key updates when it is closing 2782 or draining. A key update might prevent the endpoint from moving 2783 from the closing state to draining, but it otherwise has no impact. 2785 An endpoint could receive packets from a new source address, 2786 indicating a client connection migration (Section 6.11), while in the 2787 closing period. An endpoint in the closing state MUST strictly limit 2788 the number of packets it sends to this new address until the address 2789 is validated (see Section 6.10). A server in the closing state MAY 2790 instead choose to discard packets received from a new source address. 2792 6.13.2. Idle Timeout 2794 If the idle timeout is enabled, a connection that remains idle for 2795 longer than the advertised idle timeout (see Section 6.6.1) is 2796 closed. A connection enters the draining state when the idle timeout 2797 expires. 2799 Each endpoint advertises their own idle timeout to their peer. The 2800 idle timeout starts from the last packet received. In order to 2801 ensure that initiating new activity postpones an idle timeout, an 2802 endpoint restarts this timer when sending a packet. An endpoint does 2803 not postpone the idle timeout if another packet has been sent 2804 containing frames other than ACK or PADDING, and that other packet 2805 has not been acknowledged or declared lost. Packets that contain 2806 only ACK or PADDING frames are not acknowledged until an endpoint has 2807 other frames to send, so they could prevent the timeout from being 2808 refreshed. 2810 The value for an idle timeout can be asymmetric. The value 2811 advertised by an endpoint is only used to determine whether the 2812 connection is live at that endpoint. An endpoint that sends packets 2813 near the end of the idle timeout period of a peer risks having those 2814 packets discarded if its peer enters the draining state before the 2815 packets arrive. If a peer could timeout within an RTO (see 2816 Section 4.3.3 of [QUIC-RECOVERY]), it is advisable to test for 2817 liveness before sending any data that cannot be retried safely. 2819 6.13.3. Immediate Close 2821 An endpoint sends a closing frame (CONNECTION_CLOSE or 2822 APPLICATION_CLOSE) to terminate the connection immediately. Any 2823 closing frame causes all streams to immediately become closed; open 2824 streams can be assumed to be implicitly reset. 2826 After sending a closing frame, endpoints immediately enter the 2827 closing state. During the closing period, an endpoint that sends a 2828 closing frame SHOULD respond to any packet that it receives with 2829 another packet containing a closing frame. To minimize the state 2830 that an endpoint maintains for a closing connection, endpoints MAY 2831 send the exact same packet. However, endpoints SHOULD limit the 2832 number of packets they generate containing a closing frame. For 2833 instance, an endpoint could progressively increase the number of 2834 packets that it receives before sending additional packets or 2835 increase the time between packets. 2837 Note: Allowing retransmission of a packet contradicts other advice 2838 in this document that recommends the creation of new packet 2839 numbers for every packet. Sending new packet numbers is primarily 2840 of advantage to loss recovery and congestion control, which are 2841 not expected to be relevant for a closed connection. 2842 Retransmitting the final packet requires less state. 2844 After receiving a closing frame, endpoints enter the draining state. 2845 An endpoint that receives a closing frame MAY send a single packet 2846 containing a closing frame before entering the draining state, using 2847 a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An 2848 endpoint MUST NOT send further packets, which could result in a 2849 constant exchange of closing frames until the closing period on 2850 either peer ended. 2852 An immediate close can be used after an application protocol has 2853 arranged to close a connection. This might be after the application 2854 protocols negotiates a graceful shutdown. The application protocol 2855 exchanges whatever messages that are needed to cause both endpoints 2856 to agree to close the connection, after which the application 2857 requests that the connection be closed. The application protocol can 2858 use an APPLICATION_CLOSE message with an appropriate error code to 2859 signal closure. 2861 6.13.4. Stateless Reset 2863 A stateless reset is provided as an option of last resort for an 2864 endpoint that does not have access to the state of a connection. A 2865 crash or outage might result in peers continuing to send data to an 2866 endpoint that is unable to properly continue the connection. An 2867 endpoint that wishes to communicate a fatal connection error MUST use 2868 a closing frame if it has sufficient state to do so. 2870 To support this process, a token is sent by endpoints. The token is 2871 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2872 servers can specify the stateless_reset_token transport parameter 2873 during the handshake (clients cannot because their transport 2874 parameters don't have confidentiality protection). This value is 2875 protected by encryption, so only client and server know this value. 2876 Tokens sent via NEW_CONNECTION_ID frames are invalidated when their 2877 associated connection ID is retired via a RETIRE_CONNECTION_ID frame 2878 (Section 7.14). 2880 An endpoint that receives packets that it cannot process sends a 2881 packet in the following layout: 2883 0 1 2 3 2884 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 2885 +-+-+-+-+-+-+-+-+ 2886 |0|K|1|1|0|0|0|0| 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 | Random Octets (160..) ... 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 | | 2891 + + 2892 | | 2893 + Stateless Reset Token (128) + 2894 | | 2895 + + 2896 | | 2897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 Figure 11: Stateless Reset Packet 2901 This design ensures that a stateless reset packet is - to the extent 2902 possible - indistinguishable from a regular packet with a short 2903 header. 2905 The message consists of a header octet, followed by an arbitrary 2906 number of random octets, followed by a Stateless Reset Token. 2908 A stateless reset will be interpreted by a recipient as a packet with 2909 a short header. For the packet to appear as valid, the Random Octets 2910 field needs to include at least 20 octets of random or unpredictable 2911 values. This is intended to allow for a destination connection ID of 2912 the maximum length permitted, a packet number, and minimal payload. 2913 The Stateless Reset Token corresponds to the minimum expansion of the 2914 packet protection AEAD. More random octets might be necessary if the 2915 endpoint could have negotiated a packet protection scheme with a 2916 larger minimum AEAD expansion. 2918 An endpoint SHOULD NOT send a stateless reset that is significantly 2919 larger than the packet it receives. Endpoints MUST discard packets 2920 that are too small to be valid QUIC packets. With the set of AEAD 2921 functions defined in [QUIC-TLS], packets less than 19 octets long are 2922 never valid. 2924 An endpoint MAY send a stateless reset in response to a packet with a 2925 long header. This would not be effective if the stateless reset 2926 token was not yet available to a peer. In this QUIC version, packets 2927 with a long header are only used during connection establishment. 2928 Because the stateless reset token is not available until connection 2929 establishment is complete or near completion, ignoring an unknown 2930 packet with a long header might be more effective. 2932 An endpoint cannot determine the Source Connection ID from a packet 2933 with a short header, therefore it cannot set the Destination 2934 Connection ID in the stateless reset packet. The Destination 2935 Connection ID will therefore differ from the value used in previous 2936 packets. A random Destination Connection ID makes the connection ID 2937 appear to be the result of moving to a new connection ID that was 2938 provided using a NEW_CONNECTION_ID frame (Section 7.13). 2940 Using a randomized connection ID results in two problems: 2942 o The packet might not reach the peer. If the Destination 2943 Connection ID is critical for routing toward the peer, then this 2944 packet could be incorrectly routed. This might also trigger 2945 another Stateless Reset in response, see Section 6.13.4.3. A 2946 Stateless Reset that is not correctly routed is ineffective in 2947 causing errors to be quickly detected and recovered. In this 2948 case, endpoints will need to rely on other methods - such as 2949 timers - to detect that the connection has failed. 2951 o The randomly generated connection ID can be used by entities other 2952 than the peer to identify this as a potential stateless reset. An 2953 endpoint that occasionally uses different connection IDs might 2954 introduce some uncertainty about this. 2956 Finally, the last 16 octets of the packet are set to the value of the 2957 Stateless Reset Token. 2959 A stateless reset is not appropriate for signaling error conditions. 2960 An endpoint that wishes to communicate a fatal connection error MUST 2961 use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has 2962 sufficient state to do so. 2964 This stateless reset design is specific to QUIC version 1. An 2965 endpoint that supports multiple versions of QUIC needs to generate a 2966 stateless reset that will be accepted by peers that support any 2967 version that the endpoint might support (or might have supported 2968 prior to losing state). Designers of new versions of QUIC need to be 2969 aware of this and either reuse this design, or use a portion of the 2970 packet other than the last 16 octets for carrying data. 2972 6.13.4.1. Detecting a Stateless Reset 2974 An endpoint detects a potential stateless reset when a packet with a 2975 short header either cannot be decrypted or is marked as a duplicate 2976 packet. The endpoint then compares the last 16 octets of the packet 2977 with the Stateless Reset Token provided by its peer, either in a 2978 NEW_CONNECTION_ID frame or the server's transport parameters. If 2979 these values are identical, the endpoint MUST enter the draining 2980 period and not send any further packets on this connection. If the 2981 comparison fails, the packet can be discarded. 2983 6.13.4.2. Calculating a Stateless Reset Token 2985 The stateless reset token MUST be difficult to guess. In order to 2986 create a Stateless Reset Token, an endpoint could randomly generate 2987 [RFC4086] a secret for every connection that it creates. However, 2988 this presents a coordination problem when there are multiple 2989 instances in a cluster or a storage problem for an endpoint that 2990 might lose state. Stateless reset specifically exists to handle the 2991 case where state is lost, so this approach is suboptimal. 2993 A single static key can be used across all connections to the same 2994 endpoint by generating the proof using a second iteration of a 2995 preimage-resistant function that takes a static key and the 2996 connection ID chosen by the endpoint (see Section 6.1) as input. An 2997 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2998 connection_id)) or HKDF [RFC5869] (for example, using the static key 2999 as input keying material, with the connection ID as salt). The 3000 output of this function is truncated to 16 octets to produce the 3001 Stateless Reset Token for that connection. 3003 An endpoint that loses state can use the same method to generate a 3004 valid Stateless Reset Token. The connection ID comes from the packet 3005 that the endpoint receives. 3007 This design relies on the peer always sending a connection ID in its 3008 packets so that the endpoint can use the connection ID from a packet 3009 to reset the connection. An endpoint that uses this design MUST 3010 either use the same connection ID length for all connections or 3011 encode the length of the connection ID such that it can be recovered 3012 without state. In addition, it MUST NOT provide a zero-length 3013 connection ID. 3015 Revealing the Stateless Reset Token allows any entity to terminate 3016 the connection, so a value can only be used once. This method for 3017 choosing the Stateless Reset Token means that the combination of 3018 connection ID and static key cannot occur for another connection. A 3019 denial of service attack is possible if the same connection ID is 3020 used by instances that share a static key, or if an attacker can 3021 cause a packet to be routed to an instance that has no state but the 3022 same static key (see Section 12.8). A connection ID from a 3023 connection that is reset by revealing the Stateless Reset Token 3024 cannot be reused for new connections at nodes that share a static 3025 key. 3027 Note that Stateless Reset packets do not have any cryptographic 3028 protection. 3030 6.13.4.3. Looping 3032 The design of a Stateless Reset is such that it is indistinguishable 3033 from a valid packet. This means that a Stateless Reset might trigger 3034 the sending of a Stateless Reset in response, which could lead to 3035 infinite exchanges. 3037 An endpoint MUST ensure that every Stateless Reset that it sends is 3038 smaller than the packet which triggered it, unless it maintains state 3039 sufficient to prevent looping. In the event of a loop, this results 3040 in packets eventually being too small to trigger a response. 3042 An endpoint can remember the number of Stateless Reset packets that 3043 it has sent and stop generating new Stateless Reset packets once a 3044 limit is reached. Using separate limits for different remote 3045 addresses will ensure that Stateless Reset packets can be used to 3046 close connections when other peers or connections have exhausted 3047 limits. 3049 Reducing the size of a Stateless Reset below the recommended minimum 3050 size of 37 octets could mean that the packet could reveal to an 3051 observer that it is a Stateless Reset. Conversely, refusing to send 3052 a Stateless Reset in response to a small packet might result in 3053 Stateless Reset not being useful in detecting cases of broken 3054 connections where only very small packets are sent; such failures 3055 might only be detected by other means, such as timers. 3057 An endpoint can increase the odds that a packet will trigger a 3058 Stateless Reset if it cannot be processed by padding it to at least 3059 38 octets. 3061 7. Frame Types and Formats 3063 As described in Section 5, packets contain one or more frames. This 3064 section describes the format and semantics of the core QUIC frame 3065 types. 3067 7.1. Variable-Length Integer Encoding 3069 QUIC frames commonly use a variable-length encoding for non-negative 3070 integer values. This encoding ensures that smaller integer values 3071 need fewer octets to encode. 3073 The QUIC variable-length integer encoding reserves the two most 3074 significant bits of the first octet to encode the base 2 logarithm of 3075 the integer encoding length in octets. The integer value is encoded 3076 on the remaining bits, in network byte order. 3078 This means that integers are encoded on 1, 2, 4, or 8 octets and can 3079 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3080 the encoding properties. 3082 +------+--------+-------------+-----------------------+ 3083 | 2Bit | Length | Usable Bits | Range | 3084 +------+--------+-------------+-----------------------+ 3085 | 00 | 1 | 6 | 0-63 | 3086 | | | | | 3087 | 01 | 2 | 14 | 0-16383 | 3088 | | | | | 3089 | 10 | 4 | 30 | 0-1073741823 | 3090 | | | | | 3091 | 11 | 8 | 62 | 0-4611686018427387903 | 3092 +------+--------+-------------+-----------------------+ 3094 Table 4: Summary of Integer Encodings 3096 For example, the eight octet sequence c2 19 7c 5e ff 14 e8 8c (in 3097 hexadecimal) decodes to the decimal value 151288809941952652; the 3098 four octet sequence 9d 7f 3e 7d decodes to 494878333; the two octet 3099 sequence 7b bd decodes to 15293; and the single octet 25 decodes to 3100 37 (as does the two octet sequence 40 25). 3102 Error codes (Section 11.3) are described using integers, but do not 3103 use this encoding. 3105 7.2. PADDING Frame 3107 The PADDING frame (type=0x00) has no semantic value. PADDING frames 3108 can be used to increase the size of a packet. Padding can be used to 3109 increase an initial client packet to the minimum required size, or to 3110 provide protection against traffic analysis for protected packets. 3112 A PADDING frame has no content. That is, a PADDING frame consists of 3113 the single octet that identifies the frame as a PADDING frame. 3115 7.3. RST_STREAM Frame 3117 An endpoint may use a RST_STREAM frame (type=0x01) to abruptly 3118 terminate a stream. 3120 After sending a RST_STREAM, an endpoint ceases transmission and 3121 retransmission of STREAM frames on the identified stream. A receiver 3122 of RST_STREAM can discard any data that it already received on that 3123 stream. 3125 An endpoint that receives a RST_STREAM frame for a send-only stream 3126 MUST terminate the connection with error PROTOCOL_VIOLATION. 3128 The RST_STREAM frame is as follows: 3130 0 1 2 3 3131 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 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 | Stream ID (i) ... 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 | Application Error Code (16) | 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 | Final Offset (i) ... 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 The fields are: 3142 Stream ID: A variable-length integer encoding of the Stream ID of 3143 the stream being terminated. 3145 Application Protocol Error Code: A 16-bit application protocol error 3146 code (see Section 11.4) which indicates why the stream is being 3147 closed. 3149 Final Offset: A variable-length integer indicating the absolute byte 3150 offset of the end of data written on this stream by the RST_STREAM 3151 sender. 3153 7.4. CONNECTION_CLOSE frame 3155 An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its 3156 peer that the connection is being closed. CONNECTION_CLOSE is used 3157 to signal errors at the QUIC layer, or the absence of errors (with 3158 the NO_ERROR code). 3160 If there are open streams that haven't been explicitly closed, they 3161 are implicitly closed when the connection is closed. 3163 The CONNECTION_CLOSE frame is as follows: 3165 0 1 2 3 3166 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 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | Error Code (16) | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | Frame Type (i) ... 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3172 | Reason Phrase Length (i) ... 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3174 | Reason Phrase (*) ... 3175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 The fields of a CONNECTION_CLOSE frame are as follows: 3179 Error Code: A 16-bit error code which indicates the reason for 3180 closing this connection. CONNECTION_CLOSE uses codes from the 3181 space defined in Section 11.3. 3183 Frame Type: A variable-length integer encoding the type of frame 3184 that triggered the error. A value of 0 (equivalent to the mention 3185 of the PADDING frame) is used when the frame type is unknown. 3187 Reason Phrase Length: A variable-length integer specifying the 3188 length of the reason phrase in bytes. Note that a 3189 CONNECTION_CLOSE frame cannot be split between packets, so in 3190 practice any limits on packet size will also limit the space 3191 available for a reason phrase. 3193 Reason Phrase: A human-readable explanation for why the connection 3194 was closed. This can be zero length if the sender chooses to not 3195 give details beyond the Error Code. This SHOULD be a UTF-8 3196 encoded string [RFC3629]. 3198 7.5. APPLICATION_CLOSE frame 3200 An APPLICATION_CLOSE frame (type=0x03) is used to signal an error 3201 with the protocol that uses QUIC. 3203 The APPLICATION_CLOSE frame is as follows: 3205 0 1 2 3 3206 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 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | Error Code (16) | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | Reason Phrase Length (i) ... 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | Reason Phrase (*) ... 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3215 The fields of an APPLICATION_CLOSE frame are as follows: 3217 Error Code: A 16-bit error code which indicates the reason for 3218 closing this connection. APPLICATION_CLOSE uses codes from the 3219 application protocol error code space, see Section 11.4. 3221 Reason Phrase Length: This field is identical in format and 3222 semantics to the Reason Phrase Length field from CONNECTION_CLOSE. 3224 Reason Phrase: This field is identical in format and semantics to 3225 the Reason Phrase field from CONNECTION_CLOSE. 3227 APPLICATION_CLOSE has similar format and semantics to the 3228 CONNECTION_CLOSE frame (Section 7.4). Aside from the semantics of 3229 the Error Code field and the omission of the Frame Type field, both 3230 frames are used to close the connection. 3232 7.6. MAX_DATA Frame 3234 The MAX_DATA frame (type=0x04) is used in flow control to inform the 3235 peer of the maximum amount of data that can be sent on the connection 3236 as a whole. 3238 The frame is as follows: 3240 0 1 2 3 3241 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 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3243 | Maximum Data (i) ... 3244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 The fields in the MAX_DATA frame are as follows: 3248 Maximum Data: A variable-length integer indicating the maximum 3249 amount of data that can be sent on the entire connection, in units 3250 of octets. 3252 All data sent in STREAM frames counts toward this limit. The sum of 3253 the largest received offsets on all streams - including streams in 3254 terminal states - MUST NOT exceed the value advertised by a receiver. 3255 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 3256 error if it receives more data than the maximum data value that it 3257 has sent, unless this is a result of a change in the initial limits 3258 (see Section 6.6.2). 3260 7.7. MAX_STREAM_DATA Frame 3262 The MAX_STREAM_DATA frame (type=0x05) is used in flow control to 3263 inform a peer of the maximum amount of data that can be sent on a 3264 stream. 3266 An endpoint that receives a MAX_STREAM_DATA frame for a receive-only 3267 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 3269 An endpoint that receives a MAX_STREAM_DATA frame for a send-only 3270 stream it has not opened MUST terminate the connection with error 3271 PROTOCOL_VIOLATION. 3273 Note that an endpoint may legally receive a MAX_STREAM_DATA frame on 3274 a bidirectional stream it has not opened. 3276 The frame is as follows: 3278 0 1 2 3 3279 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 3280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3281 | Stream ID (i) ... 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3283 | Maximum Stream Data (i) ... 3284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 The fields in the MAX_STREAM_DATA frame are as follows: 3288 Stream ID: The stream ID of the stream that is affected encoded as a 3289 variable-length integer. 3291 Maximum Stream Data: A variable-length integer indicating the 3292 maximum amount of data that can be sent on the identified stream, 3293 in units of octets. 3295 When counting data toward this limit, an endpoint accounts for the 3296 largest received offset of data that is sent or received on the 3297 stream. Loss or reordering can mean that the largest received offset 3298 on a stream can be greater than the total size of data received on 3299 that stream. Receiving STREAM frames might not increase the largest 3300 received offset. 3302 The data sent on a stream MUST NOT exceed the largest maximum stream 3303 data value advertised by the receiver. An endpoint MUST terminate a 3304 connection with a FLOW_CONTROL_ERROR error if it receives more data 3305 than the largest maximum stream data that it has sent for the 3306 affected stream, unless this is a result of a change in the initial 3307 limits (see Section 6.6.2). 3309 7.8. MAX_STREAM_ID Frame 3311 The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum 3312 stream ID that they are permitted to open. 3314 The frame is as follows: 3316 0 1 2 3 3317 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 3318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3319 | Maximum Stream ID (i) ... 3320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 The fields in the MAX_STREAM_ID frame are as follows: 3324 Maximum Stream ID: ID of the maximum unidirectional or bidirectional 3325 peer-initiated stream ID for the connection encoded as a variable- 3326 length integer. The limit applies to unidirectional steams if the 3327 second least signification bit of the stream ID is 1, and applies 3328 to bidirectional streams if it is 0. 3330 Loss or reordering can mean that a MAX_STREAM_ID frame can be 3331 received which states a lower stream limit than the client has 3332 previously received. MAX_STREAM_ID frames which do not increase the 3333 maximum stream ID MUST be ignored. 3335 A peer MUST NOT initiate a stream with a higher stream ID than the 3336 greatest maximum stream ID it has received. An endpoint MUST 3337 terminate a connection with a STREAM_ID_ERROR error if a peer 3338 initiates a stream with a higher stream ID than it has sent, unless 3339 this is a result of a change in the initial limits (see 3340 Section 6.6.2). 3342 7.9. PING Frame 3344 Endpoints can use PING frames (type=0x07) to verify that their peers 3345 are still alive or to check reachability to the peer. The PING frame 3346 contains no additional fields. 3348 The receiver of a PING frame simply needs to acknowledge the packet 3349 containing this frame. 3351 The PING frame can be used to keep a connection alive when an 3352 application or application protocol wishes to prevent the connection 3353 from timing out. An application protocol SHOULD provide guidance 3354 about the conditions under which generating a PING is recommended. 3355 This guidance SHOULD indicate whether it is the client or the server 3356 that is expected to send the PING. Having both endpoints send PING 3357 frames without coordination can produce an excessive number of 3358 packets and poor performance. 3360 A connection will time out if no packets are sent or received for a 3361 period longer than the time specified in the idle_timeout transport 3362 parameter (see Section 6.13). However, state in middleboxes might 3363 time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 3364 minute timeout interval, experience shows that sending packets every 3365 15 to 30 seconds is necessary to prevent the majority of middleboxes 3366 from losing state for UDP flows. 3368 7.10. BLOCKED Frame 3370 A sender SHOULD send a BLOCKED frame (type=0x08) when it wishes to 3371 send data, but is unable to due to connection-level flow control (see 3372 Section 10.2.1). BLOCKED frames can be used as input to tuning of 3373 flow control algorithms (see Section 10.1.2). 3375 The BLOCKED frame is as follows: 3377 0 1 2 3 3378 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 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 | Offset (i) ... 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 The BLOCKED frame contains a single field. 3385 Offset: A variable-length integer indicating the connection-level 3386 offset at which the blocking occurred. 3388 7.11. STREAM_BLOCKED Frame 3390 A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it 3391 wishes to send data, but is unable to due to stream-level flow 3392 control. This frame is analogous to BLOCKED (Section 7.10). 3394 An endpoint that receives a STREAM_BLOCKED frame for a send-only 3395 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 3397 The STREAM_BLOCKED frame is as follows: 3399 0 1 2 3 3400 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 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3402 | Stream ID (i) ... 3403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3404 | Offset (i) ... 3405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 The STREAM_BLOCKED frame contains two fields: 3409 Stream ID: A variable-length integer indicating the stream which is 3410 flow control blocked. 3412 Offset: A variable-length integer indicating the offset of the 3413 stream at which the blocking occurred. 3415 7.12. STREAM_ID_BLOCKED Frame 3417 A sender MAY send a STREAM_ID_BLOCKED frame (type=0x0a) when it 3418 wishes to open a stream, but is unable to due to the maximum stream 3419 ID limit set by its peer (see Section 7.8). This does not open the 3420 stream, but informs the peer that a new stream was needed, but the 3421 stream limit prevented the creation of the stream. 3423 The STREAM_ID_BLOCKED frame is as follows: 3425 0 1 2 3 3426 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 3427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3428 | Stream ID (i) ... 3429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3431 The STREAM_ID_BLOCKED frame contains a single field. 3433 Stream ID: A variable-length integer indicating the highest stream 3434 ID that the sender was permitted to open. 3436 7.13. NEW_CONNECTION_ID Frame 3438 An endpoint sends a NEW_CONNECTION_ID frame (type=0x0b) to provide 3439 its peer with alternative connection IDs that can be used to break 3440 linkability when migrating connections (see Section 6.11.5). 3442 The NEW_CONNECTION_ID frame is as follows: 3444 0 1 2 3 3445 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 3446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3447 | Length (8) | Sequence Number (i) ... 3448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3449 | Connection ID (32..144) ... 3450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3451 | | 3452 + + 3453 | | 3454 + Stateless Reset Token (128) + 3455 | | 3456 + + 3457 | | 3458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3460 The fields are: 3462 Length: An 8-bit unsigned integer containing the length of the 3463 connection ID. Values less than 4 and greater than 18 are invalid 3464 and MUST be treated as a connection error of type 3465 PROTOCOL_VIOLATION. 3467 Sequence Number: The sequence number assigned to the connection ID 3468 by the sender. See Section 6.1.1. 3470 Connection ID: A connection ID of the specified length. 3472 Stateless Reset Token: A 128-bit value that will be used for a 3473 stateless reset when the associated connection ID is used (see 3474 Section 6.13.4). 3476 An endpoint MUST NOT send this frame if it currently requires that 3477 its peer send packets with a zero-length Destination Connection ID. 3478 Changing the length of a connection ID to or from zero-length makes 3479 it difficult to identify when the value of the connection ID changed. 3480 An endpoint that is sending packets with a zero-length Destination 3481 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 3482 connection error of type PROTOCOL_VIOLATION. 3484 Transmission errors, timeouts and retransmissions might cause the 3485 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 3486 of the same frame multiple times MUST NOT be treated as a connection 3487 error. A receiver can use the sequence number supplied in the 3488 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 3490 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 3491 previously issued connection ID with a different Stateless Reset 3492 Token or a different sequence number, the endpoint MAY treat that 3493 receipt as a connection error of type PROTOCOL_VIOLATION. 3495 7.14. RETIRE_CONNECTION_ID Frame 3497 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x1b) to 3498 indicate that it will no longer use a connection ID that was issued 3499 by its peer. This may include the connection ID provided during the 3500 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 3501 request to the peer to send additional connection IDs for future use 3502 (see Section 6.1). New connection IDs can be delivered to a peer 3503 using the NEW_CONNECTION_ID frame (Section 7.13). 3505 Retiring a connection ID invalidates the stateless reset token 3506 associated with that connection ID. 3508 The RETIRE_CONNECTION_ID frame is as follows: 3510 0 1 2 3 3511 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 3512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3513 | Sequence Number (i) ... 3514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 The fields are: 3518 Sequence Number: The sequence number of the connection ID being 3519 retired. See Section 6.1.2. 3521 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 3522 greater than any previously sent to the peer MAY be treated as a 3523 connection error of type PROTOCOL_VIOLATION. 3525 An endpoint cannot send this frame if it was provided with a zero- 3526 length connection ID by its peer. An endpoint that provides a zero- 3527 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 3528 frame as a connection error of type PROTOCOL_VIOLATION. 3530 7.15. STOP_SENDING Frame 3532 An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate 3533 that incoming data is being discarded on receipt at application 3534 request. This signals a peer to abruptly terminate transmission on a 3535 stream. 3537 Receipt of a STOP_SENDING frame is only valid for a send stream that 3538 exists and is not in the "Ready" state (see Section 9.2.1). 3539 Receiving a STOP_SENDING frame for a send stream that is "Ready" or 3540 non-existent MUST be treated as a connection error of type 3541 PROTOCOL_VIOLATION. An endpoint that receives a STOP_SENDING frame 3542 for a receive-only stream MUST terminate the connection with error 3543 PROTOCOL_VIOLATION. 3545 The STOP_SENDING frame is as follows: 3547 0 1 2 3 3548 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 3549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3550 | Stream ID (i) ... 3551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3552 | Application Error Code (16) | 3553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3555 The fields are: 3557 Stream ID: A variable-length integer carrying the Stream ID of the 3558 stream being ignored. 3560 Application Error Code: A 16-bit, application-specified reason the 3561 sender is ignoring the stream (see Section 11.4). 3563 7.16. ACK Frame 3565 Receivers send ACK frames (types 0x1a and 0x1b) to inform senders of 3566 packets they have received and processed. The ACK frame contains one 3567 or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. 3568 If the frame type is 0x1b, ACK frames also contain the sum of ECN 3569 marks received on the connection up until this point. 3571 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 3572 remains acknowledged, even if it does not appear in a future ACK 3573 frame. This is unlike TCP SACKs ([RFC2018]). 3575 It is expected that a sender will reuse the same packet number across 3576 different packet number spaces. ACK frames only acknowledge the 3577 packet numbers that were transmitted by the sender in the same packet 3578 number space of the packet that the ACK was received in. 3580 Version Negotiation and Retry packets cannot be acknowledged because 3581 they do not contain a packet number. Rather than relying on ACK 3582 frames, these packets are implicitly acknowledged by the next Initial 3583 packet sent by the client. 3585 An ACK frame is shown below. 3587 0 1 2 3 3588 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 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3590 | Largest Acknowledged (i) ... 3591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3592 | ACK Delay (i) ... 3593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3594 | ACK Block Count (i) ... 3595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3596 | ACK Blocks (*) ... 3597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3598 | [ECN Section] ... 3599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3601 Figure 12: ACK Frame Format 3603 The fields in the ACK frame are as follows: 3605 Largest Acknowledged: A variable-length integer representing the 3606 largest packet number the peer is acknowledging; this is usually 3607 the largest packet number that the peer has received prior to 3608 generating the ACK frame. Unlike the packet number in the QUIC 3609 long or short header, the value in an ACK frame is not truncated. 3611 ACK Delay: A variable-length integer including the time in 3612 microseconds that the largest acknowledged packet, as indicated in 3613 the Largest Acknowledged field, was received by this peer to when 3614 this ACK was sent. The value of the ACK Delay field is scaled by 3615 multiplying the encoded value by 2 to the power of the value of 3616 the "ack_delay_exponent" transport parameter set by the sender of 3617 the ACK frame. The "ack_delay_exponent" defaults to 3, or a 3618 multiplier of 8 (see Section 6.6.1). Scaling in this fashion 3619 allows for a larger range of values with a shorter encoding at the 3620 cost of lower resolution. 3622 ACK Block Count: A variable-length integer specifying the number of 3623 Additional ACK Block (and Gap) fields after the First ACK Block. 3625 ACK Blocks: Contains one or more blocks of packet numbers which have 3626 been successfully received, see Section 7.16.1. 3628 7.16.1. ACK Block Section 3630 The ACK Block Section consists of alternating Gap and ACK Block 3631 fields in descending packet number order. A First Ack Block field is 3632 followed by a variable number of alternating Gap and Additional ACK 3633 Blocks. The number of Gap and Additional ACK Block fields is 3634 determined by the ACK Block Count field. 3636 Gap and ACK Block fields use a relative integer encoding for 3637 efficiency. Though each encoded value is positive, the values are 3638 subtracted, so that each ACK Block describes progressively lower- 3639 numbered packets. As long as contiguous ranges of packets are small, 3640 the variable-length integer encoding ensures that each range can be 3641 expressed in a small number of octets. 3643 The ACK frame uses the least significant bit(bit (that is, type 0x1b) 3644 to indicate ECN feedback and report receipt of packets with ECN 3645 codepoints of ECT(0), ECT(1), or CE in the packet's IP header. 3647 0 1 2 3 3648 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 3649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3650 | First ACK Block (i) ... 3651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3652 | Gap (i) ... 3653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3654 | Additional ACK Block (i) ... 3655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 | Gap (i) ... 3657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3658 | Additional ACK Block (i) ... 3659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 ... 3661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3662 | Gap (i) ... 3663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3664 | Additional ACK Block (i) ... 3665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3667 Figure 13: ACK Block Section 3669 Each ACK Block acknowledges a contiguous range of packets by 3670 indicating the number of acknowledged packets that precede the 3671 largest packet number in that block. A value of zero indicates that 3672 only the largest packet number is acknowledged. Larger ACK Block 3673 values indicate a larger range, with corresponding lower values for 3674 the smallest packet number in the range. Thus, given a largest 3675 packet number for the ACK, the smallest value is determined by the 3676 formula: 3678 smallest = largest - ack_block 3680 The range of packets that are acknowledged by the ACK Block include 3681 the range from the smallest packet number to the largest, inclusive. 3683 The largest value for the First ACK Block is determined by the 3684 Largest Acknowledged field; the largest for Additional ACK Blocks is 3685 determined by cumulatively subtracting the size of all preceding ACK 3686 Blocks and Gaps. 3688 Each Gap indicates a range of packets that are not being 3689 acknowledged. The number of packets in the gap is one higher than 3690 the encoded value of the Gap Field. 3692 The value of the Gap field establishes the largest packet number 3693 value for the ACK Block that follows the gap using the following 3694 formula: 3696 largest = previous_smallest - gap - 2 3698 If the calculated value for largest or smallest packet number for any 3699 ACK Block is negative, an endpoint MUST generate a connection error 3700 of type FRAME_ENCODING_ERROR indicating an error in an ACK frame. 3702 The fields in the ACK Block Section are: 3704 First ACK Block: A variable-length integer indicating the number of 3705 contiguous packets preceding the Largest Acknowledged that are 3706 being acknowledged. 3708 Gap (repeated): A variable-length integer indicating the number of 3709 contiguous unacknowledged packets preceding the packet number one 3710 lower than the smallest in the preceding ACK Block. 3712 Additional ACK Block (repeated): A variable-length integer 3713 indicating the number of contiguous acknowledged packets preceding 3714 the largest packet number, as determined by the preceding Gap. 3716 7.16.2. ECN section 3718 The ECN section should only be parsed when the ACK frame type byte is 3719 0x1b. The ECN section consists of 3 ECN counters as shown below. 3721 0 1 2 3 3722 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 3723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3724 | ECT(0) Count (i) ... 3725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3726 | ECT(1) Count (i) ... 3727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3728 | ECN-CE Count (i) ... 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3730 ECT(0) Count: A variable-length integer representing the total 3731 number packets received with the ECT(0) codepoint. 3733 ECT(1) Count: A variable-length integer representing the total 3734 number packets received with the ECT(1) codepoint. 3736 CE Count: A variable-length integer representing the total number 3737 packets received with the CE codepoint. 3739 7.16.3. Sending ACK Frames 3741 Implementations MUST NOT generate packets that only contain ACK 3742 frames in response to packets which only contain ACK and PADDING 3743 frames. However, they MUST acknowledge packets containing only ACK 3744 and PADDING frames when sending ACK frames in response to other 3745 packets. Implementations MUST NOT send more than one packet 3746 containing only an ACK frame per received packet that contains frames 3747 other than ACK and PADDING frames. Packets containing frames besides 3748 ACK and PADDING MUST be acknowledged immediately or when a delayed 3749 ack timer expires. 3751 The receiver's delayed acknowledgment timer SHOULD NOT exceed the 3752 current RTT estimate or the value it indicates in the "max_ack_delay" 3753 transport parameter. This ensures an acknowledgment is sent at least 3754 once per RTT when packets needing acknowledgement are received. The 3755 sender can use the receiver's "max_ack_delay" value in determining 3756 timeouts for timer-based retransmission. 3758 An acknowledgment SHOULD be sent immediately after receiving 2 3759 packets that require acknowledgement, unless multiple packets are 3760 received together. 3762 To limit ACK Blocks to those that have not yet been received by the 3763 sender, the receiver SHOULD track which ACK frames have been 3764 acknowledged by its peer. Once an ACK frame has been acknowledged, 3765 the packets it acknowledges SHOULD NOT be acknowledged again. 3767 Because ACK frames are not sent in response to ACK-only packets, a 3768 receiver that is only sending ACK frames will only receive 3769 acknowledgements for its packets if the sender includes them in 3770 packets with non-ACK frames. A sender SHOULD bundle ACK frames with 3771 other frames when possible. 3773 Endpoints can only acknowledge packets sent in a particular packet 3774 number space by sending ACK frames in packets from the same packet 3775 number space. 3777 To limit receiver state or the size of ACK frames, a receiver MAY 3778 limit the number of ACK Blocks it sends. A receiver can do this even 3779 without receiving acknowledgment of its ACK frames, with the 3780 knowledge this could cause the sender to unnecessarily retransmit 3781 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 3782 lost after sufficiently newer packets are acknowledged. Therefore, 3783 the receiver SHOULD repeatedly acknowledge newly received packets in 3784 preference to packets received in the past. 3786 7.16.4. ACK Frames and Packet Protection 3788 ACK frames MUST only be carried in a packet that has the same packet 3789 number space as the packet being ACKed (see Section 4.8). For 3790 instance, packets that are protected with 1-RTT keys MUST be 3791 acknowledged in packets that are also protected with 1-RTT keys. 3793 Packets that a client sends with 0-RTT packet protection MUST be 3794 acknowledged by the server in packets protected by 1-RTT keys. This 3795 can mean that the client is unable to use these acknowledgments if 3796 the server cryptographic handshake messages are delayed or lost. 3797 Note that the same limitation applies to other data sent by the 3798 server protected by the 1-RTT keys. 3800 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3801 frames with a reduced delay; see Section 4.3.1 of [QUIC-RECOVERY]. 3803 7.17. PATH_CHALLENGE Frame 3805 Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check 3806 reachability to the peer and for path validation during connection 3807 migration. 3809 PATH_CHALLENGE frames contain an 8-byte payload. 3811 0 1 2 3 3812 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 3813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3814 | | 3815 + Data (8) + 3816 | | 3817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3819 Data: This 8-byte field contains arbitrary data. 3821 A PATH_CHALLENGE frame containing 8 octets that are hard to guess is 3822 sufficient to ensure that it is easier to receive the packet than it 3823 is to guess the value correctly. 3825 The recipient of this frame MUST generate a PATH_RESPONSE frame 3826 (Section 7.18) containing the same Data. 3828 7.18. PATH_RESPONSE Frame 3830 The PATH_RESPONSE frame (type=0x0f) is sent in response to a 3831 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 3832 frame (Section 7.17). 3834 If the content of a PATH_RESPONSE frame does not match the content of 3835 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 3836 MAY generate a connection error of type PROTOCOL_VIOLATION. 3838 7.19. NEW_TOKEN frame 3840 A server sends a NEW_TOKEN frame (type=0x19) to provide the client a 3841 token to send in the header of an Initial packet for a future 3842 connection. 3844 The NEW_TOKEN frame is as follows: 3846 0 1 2 3 3847 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 3848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3849 | Token Length (i) ... 3850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3851 | Token (*) ... 3852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3854 The fields of a NEW_TOKEN frame are as follows: 3856 Token Length: A variable-length integer specifying the length of the 3857 token in bytes. 3859 Token: An opaque blob that the client may use with a future Initial 3860 packet. 3862 7.20. STREAM Frames 3864 STREAM frames implicitly create a stream and carry stream data. The 3865 STREAM frame takes the form 0b00010XXX (or the set of values from 3866 0x10 to 0x17). The value of the three low-order bits of the frame 3867 type determine the fields that are present in the frame. 3869 o The OFF bit (0x04) in the frame type is set to indicate that there 3870 is an Offset field present. When set to 1, the Offset field is 3871 present; when set to 0, the Offset field is absent and the Stream 3872 Data starts at an offset of 0 (that is, the frame contains the 3873 first octets of the stream, or the end of a stream that includes 3874 no data). 3876 o The LEN bit (0x02) in the frame type is set to indicate that there 3877 is a Length field present. If this bit is set to 0, the Length 3878 field is absent and the Stream Data field extends to the end of 3879 the packet. If this bit is set to 1, the Length field is present. 3881 o The FIN bit (0x01) of the frame type is set only on frames that 3882 contain the final offset of the stream. Setting this bit 3883 indicates that the frame marks the end of the stream. 3885 An endpoint that receives a STREAM frame for a send-only stream MUST 3886 terminate the connection with error PROTOCOL_VIOLATION. 3888 A STREAM frame is shown below. 3890 0 1 2 3 3891 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 3892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3893 | Stream ID (i) ... 3894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3895 | [Offset (i)] ... 3896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3897 | [Length (i)] ... 3898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3899 | Stream Data (*) ... 3900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3902 Figure 14: STREAM Frame Format 3904 The STREAM frame contains the following fields: 3906 Stream ID: A variable-length integer indicating the stream ID of the 3907 stream (see Section 9.1). 3909 Offset: A variable-length integer specifying the byte offset in the 3910 stream for the data in this STREAM frame. This field is present 3911 when the OFF bit is set to 1. When the Offset field is absent, 3912 the offset is 0. 3914 Length: A variable-length integer specifying the length of the 3915 Stream Data field in this STREAM frame. This field is present 3916 when the LEN bit is set to 1. When the LEN bit is set to 0, the 3917 Stream Data field consumes all the remaining octets in the packet. 3919 Stream Data: The bytes from the designated stream to be delivered. 3921 When a Stream Data field has a length of 0, the offset in the STREAM 3922 frame is the offset of the next byte that would be sent. 3924 The first byte in the stream has an offset of 0. The largest offset 3925 delivered on a stream - the sum of the re-constructed offset and data 3926 length - MUST be less than 2^62. 3928 Stream multiplexing is achieved by interleaving STREAM frames from 3929 multiple streams into one or more QUIC packets. A single QUIC packet 3930 can include multiple STREAM frames from one or more streams. 3932 Implementation note: One of the benefits of QUIC is avoidance of 3933 head-of-line blocking across multiple streams. When a packet loss 3934 occurs, only streams with data in that packet are blocked waiting for 3935 a retransmission to be received, while other streams can continue 3936 making progress. Note that when data from multiple streams is 3937 bundled into a single QUIC packet, loss of that packet blocks all 3938 those streams from making progress. An implementation is therefore 3939 advised to bundle as few streams as necessary in outgoing packets 3940 without losing transmission efficiency to underfilled packets. 3942 7.21. CRYPTO Frame 3944 The CRYPTO frame (type=0x18) is used to transmit cryptographic 3945 handshake messages. It can be sent in all packet types. The CRYPTO 3946 frame offers the cryptographic protocol an in-order stream of bytes. 3947 CRYPTO frames are functionally identical to STREAM frames, except 3948 that they do not bear a stream identifier; they are not flow 3949 controlled; and they do not carry markers for optional offset, 3950 optional length, and the end of the stream. 3952 A CRYPTO frame is shown below. 3954 0 1 2 3 3955 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 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3957 | Offset (i) ... 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 | Length (i) ... 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3961 | Crypto Data (*) ... 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3964 Figure 15: CRYPTO Frame Format 3966 The CRYPTO frame contains the following fields: 3968 Offset: A variable-length integer specifying the byte offset in the 3969 stream for the data in this CRYPTO frame. 3971 Length: A variable-length integer specifying the length of the 3972 Crypto Data field in this CRYPTO frame. 3974 Crypto Data: The cryptographic message data. 3976 There is a separate flow of cryptographic handshake data in each 3977 encryption level, each of which starts at an offset of 0. This 3978 implies that each encryption level is treated as a separate CRYPTO 3979 stream of data. 3981 Unlike STREAM frames, which include a Stream ID indicating to which 3982 stream the data belongs, the CRYPTO frame carries data for a single 3983 stream per encryption level. The stream does not have an explicit 3984 end, so CRYPTO frames do not have a FIN bit. 3986 8. Packetization and Reliability 3988 A sender bundles one or more frames in a QUIC packet (see Section 5). 3990 A sender SHOULD minimize per-packet bandwidth and computational costs 3991 by bundling as many frames as possible within a QUIC packet. A 3992 sender MAY wait for a short period of time to bundle multiple frames 3993 before sending a packet that is not maximally packed, to avoid 3994 sending out large numbers of small packets. An implementation may 3995 use knowledge about application sending behavior or heuristics to 3996 determine whether and for how long to wait. This waiting period is 3997 an implementation decision, and an implementation should be careful 3998 to delay conservatively, since any delay is likely to increase 3999 application-visible latency. 4001 8.1. Packet Processing and Acknowledgment 4003 A packet MUST NOT be acknowledged until packet protection has been 4004 successfully removed and all frames contained in the packet have been 4005 processed. For STREAM frames, this means the data has been enqueued 4006 in preparation to be received by the application protocol, but it 4007 does not require that data is delivered and consumed. 4009 Once the packet has been fully processed, a receiver acknowledges 4010 receipt by sending one or more ACK frames containing the packet 4011 number of the received packet. To avoid creating an indefinite 4012 feedback loop, an endpoint MUST NOT send an ACK frame in response to 4013 a packet containing only ACK or PADDING frames, even if there are 4014 packet gaps which precede the received packet. The endpoint MUST 4015 acknowledge packets containing only ACK or PADDING frames in the next 4016 ACK frame that it sends. 4018 While PADDING frames do not elicit an ACK frame from a receiver, they 4019 are considered to be in flight for congestion control purposes 4020 [QUIC-RECOVERY]. Sending only PADDING frames might cause the sender 4021 to become limited by the congestion controller (as described in 4022 [QUIC-RECOVERY]) with no acknowledgments forthcoming from the 4023 receiver. Therefore, a sender should ensure that other frames are 4024 sent in addition to PADDING frames to elicit acknowledgments from the 4025 receiver. 4027 Strategies and implications of the frequency of generating 4028 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 4030 8.2. Retransmission of Information 4032 QUIC packets that are determined to be lost are not retransmitted 4033 whole. The same applies to the frames that are contained within lost 4034 packets. Instead, the information that might be carried in frames is 4035 sent again in new frames as needed. 4037 New frames and packets are used to carry information that is 4038 determined to have been lost. In general, information is sent again 4039 when a packet containing that information is determined to be lost 4040 and sending ceases when a packet containing that information is 4041 acknowledged. 4043 o Data sent in CRYPTO frames is retransmitted according to the rules 4044 in [QUIC-RECOVERY], until either all data has been acknowledged or 4045 the crypto state machine implicitly knows that the peer received 4046 the data. 4048 o Application data sent in STREAM frames is retransmitted in new 4049 STREAM frames unless the endpoint has sent a RST_STREAM for that 4050 stream. Once an endpoint sends a RST_STREAM frame, no further 4051 STREAM frames are needed. 4053 o The most recent set of acknowledgments are sent in ACK frames. An 4054 ACK frame SHOULD contain all unacknowledged acknowledgments, as 4055 described in Section 7.16.3. 4057 o Cancellation of stream transmission, as carried in a RST_STREAM 4058 frame, is sent until acknowledged or until all stream data is 4059 acknowledged by the peer (that is, either the "Reset Recvd" or 4060 "Data Recvd" state is reached on the send stream). The content of 4061 a RST_STREAM frame MUST NOT change when it is sent again. 4063 o Similarly, a request to cancel stream transmission, as encoded in 4064 a STOP_SENDING frame, is sent until the receive stream enters 4065 either a "Data Recvd" or "Reset Recvd" state, see Section 9.3. 4067 o Connection close signals, including those that use 4068 CONNECTION_CLOSE and APPLICATION_CLOSE frames, are not sent again 4069 when packet loss is detected, but as described in Section 6.13. 4071 o The current connection maximum data is sent in MAX_DATA frames. 4072 An updated value is sent in a MAX_DATA frame if the packet 4073 containing the most recently sent MAX_DATA frame is declared lost, 4074 or when the endpoint decides to update the limit. Care is 4075 necessary to avoid sending this frame too often as the limit can 4076 increase frequently and cause an unnecessarily large number of 4077 MAX_DATA frames to be sent. 4079 o The current maximum stream data offset is sent in MAX_STREAM_DATA 4080 frames. Like MAX_DATA, an updated value is sent when the packet 4081 containing the most recent MAX_STREAM_DATA frame for a stream is 4082 lost or when the limit is updated, with care taken to prevent the 4083 frame from being sent too often. An endpoint SHOULD stop sending 4084 MAX_STREAM_DATA frames when the receive stream enters a "Size 4085 Known" state. 4087 o The maximum stream ID for a stream of a given type is sent in 4088 MAX_STREAM_ID frames. Like MAX_DATA, an updated value is sent 4089 when a packet containing the most recent MAX_STREAM_ID for a 4090 stream type frame is declared lost or when the limit is updated, 4091 with care taken to prevent the frame from being sent too often. 4093 o Blocked signals are carried in BLOCKED, STREAM_BLOCKED, and 4094 STREAM_ID_BLOCKED frames. BLOCKED streams have connection scope, 4095 STREAM_BLOCKED frames have stream scope, and STREAM_ID_BLOCKED 4096 frames are scoped to a specific stream type. New frames are sent 4097 if packets containing the most recent frame for a scope is lost, 4098 but only while the endpoint is blocked on the corresponding limit. 4099 These frames always include the limit that is causing blocking at 4100 the time that they are transmitted. 4102 o A liveness or path validation check using PATH_CHALLENGE frames is 4103 sent periodically until a matching PATH_RESPONSE frame is received 4104 or until there is no remaining need for liveness or path 4105 validation checking. PATH_CHALLENGE frames include a different 4106 payload each time they are sent. 4108 o Responses to path validation using PATH_RESPONSE frames are sent 4109 just once. A new PATH_CHALLENGE frame will be sent if another 4110 PATH_RESPONSE frame is needed. 4112 o New connection IDs are sent in NEW_CONNECTION_ID frames and 4113 retransmitted if the packet containing them is lost. 4114 Retransmissions of this frame carry the same sequence number 4115 value. Likewise, retired connection IDs are sent in 4116 RETIRE_CONNECTION_ID frames and retransmitted if the packet 4117 containing them is lost. 4119 o PADDING frames contain no information, so lost PADDING frames do 4120 not require repair. 4122 Upon detecting losses, a sender MUST take appropriate congestion 4123 control action. The details of loss detection and congestion control 4124 are described in [QUIC-RECOVERY]. 4126 8.3. Packet Size 4128 The QUIC packet size includes the QUIC header and integrity check, 4129 but not the UDP or IP header. 4131 Clients MUST ensure that the first Initial packet they send is sent 4132 in a UDP datagram that is at least 1200 octets. Padding the Initial 4133 packet or including a 0-RTT packet in the same datagram are ways to 4134 meet this requirement. Sending a UDP datagram of this size ensures 4135 that the network path supports a reasonable Maximum Transmission Unit 4136 (MTU), and helps reduce the amplitude of amplification attacks caused 4137 by server responses toward an unverified client address. 4139 The datagram containing the first Initial packet from a client MAY 4140 exceed 1200 octets if the client believes that the Path Maximum 4141 Transmission Unit (PMTU) supports the size that it chooses. 4143 A server MAY send a CONNECTION_CLOSE frame with error code 4144 PROTOCOL_VIOLATION in response to the first Initial packet it 4145 receives from a client if the UDP datagram is smaller than 1200 4146 octets. It MUST NOT send any other frame type in response, or 4147 otherwise behave as if any part of the offending packet was processed 4148 as valid. 4150 8.4. Path Maximum Transmission Unit 4152 The Path Maximum Transmission Unit (PMTU) is the maximum size of the 4153 entire IP header, UDP header, and UDP payload. The UDP payload 4154 includes the QUIC packet header, protected payload, and any 4155 authentication fields. 4157 All QUIC packets SHOULD be sized to fit within the estimated PMTU to 4158 avoid IP fragmentation or packet drops. To optimize bandwidth 4159 efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery 4160 ([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) 4161 for detecting the PMTU, setting the PMTU appropriately, and storing 4162 the result of previous PMTU determinations. 4164 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 4165 packets larger than 1280 octets. Assuming the minimum IP header 4166 size, this results in a QUIC packet size of 1232 octets for IPv6 and 4167 1252 octets for IPv4. Some QUIC implementations MAY be more 4168 conservative in computing allowed QUIC packet size given unknown 4169 tunneling overheads or IP header options. 4171 QUIC endpoints that implement any kind of PMTU discovery SHOULD 4172 maintain an estimate for each combination of local and remote IP 4173 addresses. Each pairing of local and remote addresses could have a 4174 different maximum MTU in the path. 4176 QUIC depends on the network path supporting an MTU of at least 1280 4177 octets. This is the IPv6 minimum MTU and therefore also supported by 4178 most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below 4179 this number, even if it receives signals that indicate a smaller 4180 limit might exist. 4182 If a QUIC endpoint determines that the PMTU between any pair of local 4183 and remote IP addresses has fallen below 1280 octets, it MUST 4184 immediately cease sending QUIC packets on the affected path. This 4185 could result in termination of the connection if an alternative path 4186 cannot be found. 4188 8.4.1. IPv4 PMTU Discovery 4190 Traditional ICMP-based path MTU discovery in IPv4 [PMTUDv4] is 4191 potentially vulnerable to off-path attacks that successfully guess 4192 the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient 4193 value. TCP connections mitigate this risk by using the (at minimum) 4194 8 bytes of transport header echoed in the ICMP message to validate 4195 the TCP sequence number as valid for the current connection. 4196 However, as QUIC operates over UDP, in IPv4 the echoed information 4197 could consist only of the IP and UDP headers, which usually has 4198 insufficient entropy to mitigate off-path attacks. 4200 As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps 4201 to mitigate this risk. For instance, an application could: 4203 o Set the IPv4 Don't Fragment (DF) bit on a small proportion of 4204 packets, so that most invalid ICMP messages arrive when there are 4205 no DF packets outstanding, and can therefore be identified as 4206 spurious. 4208 o Store additional information from the IP or UDP headers from DF 4209 packets (for example, the IP ID or UDP checksum) to further 4210 authenticate incoming Datagram Too Big messages. 4212 o Any reduction in PMTU due to a report contained in an ICMP packet 4213 is provisional until QUIC's loss detection algorithm determines 4214 that the packet is actually lost. 4216 8.4.2. Special Considerations for Packetization Layer PMTU Discovery 4218 The PADDING frame provides a useful option for PMTU probe packets. 4219 PADDING frames generate acknowledgements, but they need not be 4220 delivered reliably. As a result, the loss of PADDING frames in probe 4221 packets does not require delay-inducing retransmission. However, 4222 PADDING frames do consume congestion window, which may delay the 4223 transmission of subsequent application data. 4225 When implementing the algorithm in Section 7.2 of [PLPMTUD], the 4226 initial value of search_low SHOULD be consistent with the IPv6 4227 minimum packet size. Paths that do not support this size cannot 4228 deliver Initial packets, and therefore are not QUIC-compliant. 4230 Section 7.3 of [PLPMTUD] discusses trade-offs between small and large 4231 increases in the size of probe packets. As QUIC probe packets need 4232 not contain application data, aggressive increases in probe size 4233 carry fewer consequences. 4235 9. Streams: QUIC's Data Structuring Abstraction 4237 Streams in QUIC provide a lightweight, ordered byte-stream 4238 abstraction. 4240 There are two basic types of stream in QUIC. Unidirectional streams 4241 carry data in one direction: from the initiator of the stream to its 4242 peer; bidirectional streams allow for data to be sent in both 4243 directions. Different stream identifiers are used to distinguish 4244 between unidirectional and bidirectional streams, as well as to 4245 create a separation between streams that are initiated by the client 4246 and server (see Section 9.1). 4248 Either type of stream can be created by either endpoint, can 4249 concurrently send data interleaved with other streams, and can be 4250 cancelled. 4252 Stream offsets allow for the octets on a stream to be placed in 4253 order. An endpoint MUST be capable of delivering data received on a 4254 stream in order. Implementations MAY choose to offer the ability to 4255 deliver data out of order. There is no means of ensuring ordering 4256 between octets on different streams. 4258 The creation and destruction of streams are expected to have minimal 4259 bandwidth and computational cost. A single STREAM frame may create, 4260 carry data for, and terminate a stream, or a stream may last the 4261 entire duration of a connection. 4263 Streams are individually flow controlled, allowing an endpoint to 4264 limit memory commitment and to apply back pressure. The creation of 4265 streams is also flow controlled, with each peer declaring the maximum 4266 stream ID it is willing to accept at a given time. 4268 An alternative view of QUIC streams is as an elastic "message" 4269 abstraction, similar to the way ephemeral streams are used in SST 4270 [SST], which may be a more appealing description for some 4271 applications. 4273 9.1. Stream Identifiers 4275 Streams are identified by an unsigned 62-bit integer, referred to as 4276 the Stream ID. The least significant two bits of the Stream ID are 4277 used to identify the type of stream (unidirectional or bidirectional) 4278 and the initiator of the stream. 4280 The least significant bit (0x1) of the Stream ID identifies the 4281 initiator of the stream. Clients initiate even-numbered streams 4282 (those with the least significant bit set to 0); servers initiate 4283 odd-numbered streams (with the bit set to 1). Separation of the 4284 stream identifiers ensures that client and server are able to open 4285 streams without the latency imposed by negotiating for an identifier. 4287 If an endpoint receives a frame for a stream that it expects to 4288 initiate (i.e., odd-numbered for the client or even-numbered for the 4289 server), but which it has not yet opened, it MUST close the 4290 connection with error code STREAM_STATE_ERROR. 4292 The second least significant bit (0x2) of the Stream ID 4293 differentiates between unidirectional streams and bidirectional 4294 streams. Unidirectional streams always have this bit set to 1 and 4295 bidirectional streams have this bit set to 0. 4297 The two type bits from a Stream ID therefore identify streams as 4298 summarized in Table 5. 4300 +----------+----------------------------------+ 4301 | Low Bits | Stream Type | 4302 +----------+----------------------------------+ 4303 | 0x0 | Client-Initiated, Bidirectional | 4304 | | | 4305 | 0x1 | Server-Initiated, Bidirectional | 4306 | | | 4307 | 0x2 | Client-Initiated, Unidirectional | 4308 | | | 4309 | 0x3 | Server-Initiated, Unidirectional | 4310 +----------+----------------------------------+ 4312 Table 5: Stream ID Types 4314 The first bi-directional stream opened by the client is stream 0. 4316 A QUIC endpoint MUST NOT reuse a Stream ID. Streams of each type are 4317 created in numeric order. Streams that are used out of order result 4318 in opening all lower-numbered streams of the same type in the same 4319 direction. 4321 Stream IDs are encoded as a variable-length integer (see 4322 Section 7.1). 4324 9.2. Stream States 4326 This section describes the two types of QUIC stream in terms of the 4327 states of their send or receive components. Two state machines are 4328 described: one for streams on which an endpoint transmits data 4329 (Section 9.2.1); another for streams from which an endpoint receives 4330 data (Section 9.2.2). 4332 Unidirectional streams use the applicable state machine directly. 4333 Bidirectional streams use both state machines. For the most part, 4334 the use of these state machines is the same whether the stream is 4335 unidirectional or bidirectional. The conditions for opening a stream 4336 are slightly more complex for a bidirectional stream because the 4337 opening of either send or receive sides causes the stream to open in 4338 both directions. 4340 An endpoint can open streams up to its maximum stream limit in any 4341 order, however endpoints SHOULD open the send side of streams for 4342 each type in order. 4344 Note: These states are largely informative. This document uses 4345 stream states to describe rules for when and how different types 4346 of frames can be sent and the reactions that are expected when 4347 different types of frames are received. Though these state 4348 machines are intended to be useful in implementing QUIC, these 4349 states aren't intended to constrain implementations. An 4350 implementation can define a different state machine as long as its 4351 behavior is consistent with an implementation that implements 4352 these states. 4354 9.2.1. Send Stream States 4356 Figure 16 shows the states for the part of a stream that sends data 4357 to a peer. 4359 o 4360 | Create Stream (Sending) 4361 | Create Bidirectional Stream (Receiving) 4362 v 4363 +-------+ 4364 | Ready | Send RST_STREAM 4365 | |-----------------------. 4366 +-------+ | 4367 | | 4368 | Send STREAM / | 4369 | STREAM_BLOCKED | 4370 | | 4371 | Create Bidirectional | 4372 | Stream (Receiving) | 4373 v | 4374 +-------+ | 4375 | Send | Send RST_STREAM | 4376 | |---------------------->| 4377 +-------+ | 4378 | | 4379 | Send STREAM + FIN | 4380 v v 4381 +-------+ +-------+ 4382 | Data | Send RST_STREAM | Reset | 4383 | Sent |------------------>| Sent | 4384 +-------+ +-------+ 4385 | | 4386 | Recv All ACKs | Recv ACK 4387 v v 4388 +-------+ +-------+ 4389 | Data | | Reset | 4390 | Recvd | | Recvd | 4391 +-------+ +-------+ 4393 Figure 16: States for Send Streams 4395 The sending part of stream that the endpoint initiates (types 0 and 2 4396 for clients, 1 and 3 for servers) is opened by the application or 4397 application protocol. The "Ready" state represents a newly created 4398 stream that is able to accept data from the application. Stream data 4399 might be buffered in this state in preparation for sending. 4401 Sending the first STREAM or STREAM_BLOCKED frame causes a send stream 4402 to enter the "Send" state. An implementation might choose to defer 4403 allocating a Stream ID to a send stream until it sends the first 4404 frame and enters this state, which can allow for better stream 4405 prioritization. 4407 The sending part of a bidirectional stream initiated by a peer (type 4408 0 for a server, type 1 for a client) enters the "Ready" state then 4409 immediately transitions to the "Send" state if the receiving part 4410 enters the "Recv" state. 4412 In the "Send" state, an endpoint transmits - and retransmits as 4413 necessary - data in STREAM frames. The endpoint respects the flow 4414 control limits of its peer, accepting MAX_STREAM_DATA frames. An 4415 endpoint in the "Send" state generates STREAM_BLOCKED frames if it 4416 encounters flow control limits. 4418 After the application indicates that stream data is complete and a 4419 STREAM frame containing the FIN bit is sent, the send stream enters 4420 the "Data Sent" state. From this state, the endpoint only 4421 retransmits stream data as necessary. The endpoint no longer needs 4422 to track flow control limits or send STREAM_BLOCKED frames for a send 4423 stream in this state. The endpoint can ignore any MAX_STREAM_DATA 4424 frames it receives from its peer in this state; MAX_STREAM_DATA 4425 frames might be received until the peer receives the final stream 4426 offset. 4428 Once all stream data has been successfully acknowledged, the send 4429 stream enters the "Data Recvd" state, which is a terminal state. 4431 From any of the "Ready", "Send", or "Data Sent" states, an 4432 application can signal that it wishes to abandon transmission of 4433 stream data. Similarly, the endpoint might receive a STOP_SENDING 4434 frame from its peer. In either case, the endpoint sends a RST_STREAM 4435 frame, which causes the stream to enter the "Reset Sent" state. 4437 An endpoint MAY send a RST_STREAM as the first frame on a send 4438 stream; this causes the send stream to open and then immediately 4439 transition to the "Reset Sent" state. 4441 Once a packet containing a RST_STREAM has been acknowledged, the send 4442 stream enters the "Reset Recvd" state, which is a terminal state. 4444 9.2.2. Receive Stream States 4446 Figure 17 shows the states for the part of a stream that receives 4447 data from a peer. The states for a receive stream mirror only some 4448 of the states of the send stream at the peer. A receive stream 4449 doesn't track states on the send stream that cannot be observed, such 4450 as the "Ready" state; instead, receive streams track the delivery of 4451 data to the application or application protocol some of which cannot 4452 be observed by the sender. 4454 o 4455 | Recv STREAM / STREAM_BLOCKED / RST_STREAM 4456 | Create Bidirectional Stream (Sending) 4457 | Recv MAX_STREAM_DATA 4458 | Create Higher-Numbered Stream 4459 v 4460 +-------+ 4461 | Recv | Recv RST_STREAM 4462 | |-----------------------. 4463 +-------+ | 4464 | | 4465 | Recv STREAM + FIN | 4466 v | 4467 +-------+ | 4468 | Size | Recv RST_STREAM | 4469 | Known |---------------------->| 4470 +-------+ | 4471 | | 4472 | Recv All Data | 4473 v v 4474 +-------+ Recv RST_STREAM +-------+ 4475 | Data |--- (optional) --->| Reset | 4476 | Recvd | Recv All Data | Recvd | 4477 +-------+<-- (optional) ----+-------+ 4478 | | 4479 | App Read All Data | App Read RST 4480 v v 4481 +-------+ +-------+ 4482 | Data | | Reset | 4483 | Read | | Read | 4484 +-------+ +-------+ 4486 Figure 17: States for Receive Streams 4488 The receiving part of a stream initiated by a peer (types 1 and 3 for 4489 a client, or 0 and 2 for a server) are created when the first STREAM, 4490 STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only, 4491 see below) is received for that stream. The initial state for a 4492 receive stream is "Recv". Receiving a RST_STREAM frame causes the 4493 receive stream to immediately transition to the "Reset Recvd". 4495 The receive stream enters the "Recv" state when the sending part of a 4496 bidirectional stream initiated by the endpoint (type 0 for a client, 4497 type 1 for a server) enters the "Ready" state. 4499 A bidirectional stream also opens when a MAX_STREAM_DATA frame is 4500 received. Receiving a MAX_STREAM_DATA frame implies that the remote 4501 peer has opened the stream and is providing flow control credit. A 4502 MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED 4503 frame if packets are lost or reordered. 4505 Before creating a stream, all lower-numbered streams of the same type 4506 MUST be created. That means that receipt of a frame that would open 4507 a stream causes all lower-numbered streams of the same type to be 4508 opened in numeric order. This ensures that the creation order for 4509 streams is consistent on both endpoints. 4511 In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED 4512 frames. Incoming data is buffered and can be reassembled into the 4513 correct order for delivery to the application. As data is consumed 4514 by the application and buffer space becomes available, the endpoint 4515 sends MAX_STREAM_DATA frames to allow the peer to send more data. 4517 When a STREAM frame with a FIN bit is received, the final offset (see 4518 Section 10.3) is known. The receive stream enters the "Size Known" 4519 state. In this state, the endpoint no longer needs to send 4520 MAX_STREAM_DATA frames, it only receives any retransmissions of 4521 stream data. 4523 Once all data for the stream has been received, the receive stream 4524 enters the "Data Recvd" state. This might happen as a result of 4525 receiving the same STREAM frame that causes the transition to "Size 4526 Known". In this state, the endpoint has all stream data. Any STREAM 4527 or STREAM_BLOCKED frames it receives for the stream can be discarded. 4529 The "Data Recvd" state persists until stream data has been delivered 4530 to the application or application protocol. Once stream data has 4531 been delivered, the stream enters the "Data Read" state, which is a 4532 terminal state. 4534 Receiving a RST_STREAM frame in the "Recv" or "Size Known" states 4535 causes the stream to enter the "Reset Recvd" state. This might cause 4536 the delivery of stream data to the application to be interrupted. 4538 It is possible that all stream data is received when a RST_STREAM is 4539 received (that is, from the "Data Recvd" state). Similarly, it is 4540 possible for remaining stream data to arrive after receiving a 4541 RST_STREAM frame (the "Reset Recvd" state). An implementation is 4542 able to manage this situation as they choose. Sending RST_STREAM 4543 means that an endpoint cannot guarantee delivery of stream data; 4544 however there is no requirement that stream data not be delivered if 4545 a RST_STREAM is received. An implementation MAY interrupt delivery 4546 of stream data, discard any data that was not consumed, and signal 4547 the existence of the RST_STREAM immediately. Alternatively, the 4548 RST_STREAM signal might be suppressed or withheld if stream data is 4549 completely received. In the latter case, the receive stream 4550 effectively transitions to "Data Recvd" from "Reset Recvd". 4552 Once the application has been delivered the signal indicating that 4553 the receive stream was reset, the receive stream transitions to the 4554 "Reset Read" state, which is a terminal state. 4556 9.2.3. Permitted Frame Types 4558 The sender of a stream sends just three frame types that affect the 4559 state of a stream at either sender or receiver: STREAM 4560 (Section 7.20), STREAM_BLOCKED (Section 7.11), and RST_STREAM 4561 (Section 7.3). 4563 A sender MUST NOT send any of these frames from a terminal state 4564 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 4565 STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset 4566 Sent" state in addition to the terminal states. A receiver could 4567 receive any of these frames in any state, but only due to the 4568 possibility of delayed delivery of packets carrying them. 4570 The receiver of a stream sends MAX_STREAM_DATA (Section 7.7) and 4571 STOP_SENDING frames (Section 7.15). 4573 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 4574 receiver can send STOP_SENDING in any state where it has not received 4575 a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset 4576 Read". However there is little value in sending a STOP_SENDING frame 4577 after all stream data has been received in the "Data Recvd" state. A 4578 sender could receive these frames in any state as a result of delayed 4579 delivery of packets. 4581 9.2.4. Bidirectional Stream States 4583 A bidirectional stream is composed of a send stream and a receive 4584 stream. Implementations may represent states of the bidirectional 4585 stream as composites of send and receive stream states. The simplest 4586 model presents the stream as "open" when either send or receive 4587 stream is in a non-terminal state and "closed" when both send and 4588 receive streams are in a terminal state. 4590 Table 6 shows a more complex mapping of bidirectional stream states 4591 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 4592 shows that multiple states on send or receive streams are mapped to 4593 the same composite state. Note that this is just one possibility for 4594 such a mapping; this mapping requires that data is acknowledged 4595 before the transition to a "closed" or "half-closed" state. 4597 +-----------------------+---------------------+---------------------+ 4598 | Send Stream | Receive Stream | Composite State | 4599 +-----------------------+---------------------+---------------------+ 4600 | No Stream/Ready | No Stream/Recv *1 | idle | 4601 | | | | 4602 | Ready/Send/Data Sent | Recv/Size Known | open | 4603 | | | | 4604 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 4605 | | Read | (remote) | 4606 | | | | 4607 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 4608 | | Read | (remote) | 4609 | | | | 4610 | Data Recvd | Recv/Size Known | half-closed (local) | 4611 | | | | 4612 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 4613 | Recvd | | | 4614 | | | | 4615 | Data Recvd | Recv/Size Known | half-closed (local) | 4616 | | | | 4617 | Reset Sent/Reset | Data Recvd/Data | closed | 4618 | Recvd | Read | | 4619 | | | | 4620 | Reset Sent/Reset | Reset Recvd/Reset | closed | 4621 | Recvd | Read | | 4622 | | | | 4623 | Data Recvd | Data Recvd/Data | closed | 4624 | | Read | | 4625 | | | | 4626 | Data Recvd | Reset Recvd/Reset | closed | 4627 | | Read | | 4628 +-----------------------+---------------------+---------------------+ 4630 Table 6: Possible Mapping of Stream States to HTTP/2 4632 Note (*1): A stream is considered "idle" if it has not yet been 4633 created, or if the receive stream is in the "Recv" state without 4634 yet having received any frames. 4636 9.3. Solicited State Transitions 4638 If an endpoint is no longer interested in the data it is receiving on 4639 a stream, it MAY send a STOP_SENDING frame identifying that stream to 4640 prompt closure of the stream in the opposite direction. This 4641 typically indicates that the receiving application is no longer 4642 reading data it receives from the stream, but is not a guarantee that 4643 incoming data will be ignored. 4645 STREAM frames received after sending STOP_SENDING are still counted 4646 toward the connection and stream flow-control windows, even though 4647 these frames will be discarded upon receipt. This avoids potential 4648 ambiguity about which STREAM frames count toward flow control. 4650 A STOP_SENDING frame requests that the receiving endpoint send a 4651 RST_STREAM frame. An endpoint that receives a STOP_SENDING frame 4652 MUST send a RST_STREAM frame for that stream, and can use an error 4653 code of STOPPING. If the STOP_SENDING frame is received on a send 4654 stream that is already in the "Data Sent" state, a RST_STREAM frame 4655 MAY still be sent in order to cancel retransmission of previously- 4656 sent STREAM frames. 4658 STOP_SENDING SHOULD only be sent for a receive stream that has not 4659 been reset. STOP_SENDING is most useful for streams in the "Recv" or 4660 "Size Known" states. 4662 An endpoint is expected to send another STOP_SENDING frame if a 4663 packet containing a previous STOP_SENDING is lost. However, once 4664 either all stream data or a RST_STREAM frame has been received for 4665 the stream - that is, the stream is in any state other than "Recv" or 4666 "Size Known" - sending a STOP_SENDING frame is unnecessary. 4668 9.4. Stream Concurrency 4670 An endpoint limits the number of concurrently active incoming streams 4671 by adjusting the maximum stream ID. An initial value is set in the 4672 transport parameters (see Section 6.6.1) and is subsequently 4673 increased by MAX_STREAM_ID frames (see Section 7.8). 4675 The maximum stream ID is specific to each endpoint and applies only 4676 to the peer that receives the setting. That is, clients specify the 4677 maximum stream ID the server can initiate, and servers specify the 4678 maximum stream ID the client can initiate. Each endpoint may respond 4679 on streams initiated by the other peer, regardless of whether it is 4680 permitted to initiate new streams. 4682 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 4683 that receives a STREAM frame with an ID greater than the limit it has 4684 sent MUST treat this as a stream error of type STREAM_ID_ERROR 4685 (Section 11), unless this is a result of a change in the initial 4686 limits (see Section 6.6.2). 4688 A receiver cannot renege on an advertisement; that is, once a 4689 receiver advertises a stream ID via a MAX_STREAM_ID frame, 4690 advertising a smaller maximum ID has no effect. A sender MUST ignore 4691 any MAX_STREAM_ID frame that does not increase the maximum stream ID. 4693 9.5. Sending and Receiving Data 4695 Once a stream is created, endpoints may use the stream to send and 4696 receive data. Each endpoint may send a series of STREAM frames 4697 encapsulating data on a stream until the stream is terminated in that 4698 direction. Streams are an ordered byte-stream abstraction, and they 4699 have no other structure within them. STREAM frame boundaries are not 4700 expected to be preserved in retransmissions from the sender or during 4701 delivery to the application at the receiver. 4703 When new data is to be sent on a stream, a sender MUST set the 4704 encapsulating STREAM frame's offset field to the stream offset of the 4705 first byte of this new data. The first octet of data on a stream has 4706 an offset of 0. An endpoint is expected to send every stream octet. 4707 The largest offset delivered on a stream MUST be less than 2^62. 4709 QUIC makes no specific allowances for partial reliability or delivery 4710 of stream data out of order. Endpoints MUST be able to deliver 4711 stream data to an application as an ordered byte-stream. Delivering 4712 an ordered byte-stream requires that an endpoint buffer any data that 4713 is received out of order, up to the advertised flow control limit. 4715 An endpoint could receive the same octets multiple times; octets that 4716 have already been received can be discarded. The value for a given 4717 octet MUST NOT change if it is sent multiple times; an endpoint MAY 4718 treat receipt of a changed octet as a connection error of type 4719 PROTOCOL_VIOLATION. 4721 An endpoint MUST NOT send data on any stream without ensuring that it 4722 is within the data limits set by its peer. 4724 Flow control is described in detail in Section 10, and congestion 4725 control is described in the companion document [QUIC-RECOVERY]. 4727 9.6. Stream Prioritization 4729 Stream multiplexing has a significant effect on application 4730 performance if resources allocated to streams are correctly 4731 prioritized. Experience with other multiplexed protocols, such as 4732 HTTP/2 [HTTP2], shows that effective prioritization strategies have a 4733 significant positive impact on performance. 4735 QUIC does not provide frames for exchanging prioritization 4736 information. Instead it relies on receiving priority information 4737 from the application that uses QUIC. Protocols that use QUIC are 4738 able to define any prioritization scheme that suits their application 4739 semantics. A protocol might define explicit messages for signaling 4740 priority, such as those defined in HTTP/2; it could define rules that 4741 allow an endpoint to determine priority based on context; or it could 4742 leave the determination to the application. 4744 A QUIC implementation SHOULD provide ways in which an application can 4745 indicate the relative priority of streams. When deciding which 4746 streams to dedicate resources to, QUIC SHOULD use the information 4747 provided by the application. Failure to account for priority of 4748 streams can result in suboptimal performance. 4750 Stream priority is most relevant when deciding which stream data will 4751 be transmitted. Often, there will be limits on what can be 4752 transmitted as a result of connection flow control or the current 4753 congestion controller state. 4755 Giving preference to the transmission of its own management frames 4756 ensures that the protocol functions efficiently. That is, 4757 prioritizing frames other than STREAM frames ensures that loss 4758 recovery, congestion control, and flow control operate effectively. 4760 CRYPTO frames SHOULD be prioritized over other streams prior to the 4761 completion of the cryptographic handshake. This includes the 4762 retransmission of the second flight of client handshake messages, 4763 that is, the TLS Finished and any client authentication messages. 4765 STREAM data in frames determined to be lost SHOULD be retransmitted 4766 before sending new data, unless application priorities indicate 4767 otherwise. Retransmitting lost stream data can fill in gaps, which 4768 allows the peer to consume already received data and free up the flow 4769 control window. 4771 10. Flow Control 4773 It is necessary to limit the amount of data that a sender may have 4774 outstanding at any time, so as to prevent a fast sender from 4775 overwhelming a slow receiver, or to prevent a malicious sender from 4776 consuming significant resources at a receiver. This section 4777 describes QUIC's flow-control mechanisms. 4779 QUIC employs a credit-based flow-control scheme similar to HTTP/2's 4780 flow control [HTTP2]. A receiver advertises the number of octets it 4781 is prepared to receive on a given stream and for the entire 4782 connection. This leads to two levels of flow control in QUIC: (i) 4783 Connection flow control, which prevents senders from exceeding a 4784 receiver's buffer capacity for the connection, and (ii) Stream flow 4785 control, which prevents a single stream from consuming the entire 4786 receive buffer for a connection. 4788 A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the 4789 sender to advertise additional credit. MAX_STREAM_DATA frames send 4790 the maximum absolute byte offset of a stream, while MAX_DATA sends 4791 the maximum of the sum of the absolute byte offsets of all streams. 4793 A receiver MAY advertise a larger offset at any point by sending 4794 MAX_DATA or MAX_STREAM_DATA frames. A receiver cannot renege on an 4795 advertisement; that is, once a receiver advertises an offset, 4796 advertising a smaller offset has no effect. A sender MUST therefore 4797 ignore any MAX_DATA or MAX_STREAM_DATA frames that do not increase 4798 flow control limits. 4800 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 4801 (Section 11) if the peer violates the advertised connection or stream 4802 data limits. 4804 A sender SHOULD send BLOCKED or STREAM_BLOCKED frames to indicate it 4805 has data to write but is blocked by flow control limits. These 4806 frames are expected to be sent infrequently in common cases, but they 4807 are considered useful for debugging and monitoring purposes. 4809 A receiver advertises credit for a stream by sending a 4810 MAX_STREAM_DATA frame with the Stream ID set appropriately. A 4811 receiver could use the current offset of data consumed to determine 4812 the flow control offset to be advertised. A receiver MAY send 4813 MAX_STREAM_DATA frames in multiple packets in order to make sure that 4814 the sender receives an update before running out of flow control 4815 credit, even if one of the packets is lost. 4817 Connection flow control is a limit to the total bytes of stream data 4818 sent in STREAM frames on all streams. A receiver advertises credit 4819 for a connection by sending a MAX_DATA frame. A receiver maintains a 4820 cumulative sum of bytes received on all contributing streams, which 4821 are used to check for flow control violations. A receiver might use 4822 a sum of bytes consumed on all contributing streams to determine the 4823 maximum data limit to be advertised. 4825 10.1. Edge Cases and Other Considerations 4827 There are some edge cases which must be considered when dealing with 4828 stream and connection level flow control. Given enough time, both 4829 endpoints must agree on flow control state. If one end believes it 4830 can send more than the other end is willing to receive, the 4831 connection will be torn down when too much data arrives. 4833 Conversely if a sender believes it is blocked, while endpoint B 4834 expects more data can be received, then the connection can be in a 4835 deadlock, with the sender waiting for a MAX_DATA or MAX_STREAM_DATA 4836 frame which will never come. 4838 On receipt of a RST_STREAM frame, an endpoint will tear down state 4839 for the matching stream and ignore further data arriving on that 4840 stream. This could result in the endpoints getting out of sync, 4841 since the RST_STREAM frame may have arrived out of order and there 4842 may be further bytes in flight. The data sender would have counted 4843 the data against its connection level flow control budget, but a 4844 receiver that has not received these bytes would not know to include 4845 them as well. The receiver must learn the number of bytes that were 4846 sent on the stream to make the same adjustment in its connection flow 4847 controller. 4849 To avoid this de-synchronization, a RST_STREAM sender MUST include 4850 the final byte offset sent on the stream in the RST_STREAM frame. On 4851 receiving a RST_STREAM frame, a receiver definitively knows how many 4852 bytes were sent on that stream before the RST_STREAM frame, and the 4853 receiver MUST use the final offset to account for all bytes sent on 4854 the stream in its connection level flow controller. 4856 10.1.1. Response to a RST_STREAM 4858 RST_STREAM terminates one direction of a stream abruptly. Whether 4859 any action or response can or should be taken on the data already 4860 received is an application-specific issue, but it will often be the 4861 case that upon receipt of a RST_STREAM an endpoint will choose to 4862 stop sending data in its own direction. If the sender of a 4863 RST_STREAM wishes to explicitly state that no future data will be 4864 processed, that endpoint MAY send a STOP_SENDING frame at the same 4865 time. 4867 10.1.2. Data Limit Increments 4869 This document leaves when and how many bytes to advertise in a 4870 MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few 4871 considerations. These frames contribute to connection overhead. 4872 Therefore frequently sending frames with small changes is 4873 undesirable. At the same time, infrequent updates require larger 4874 increments to limits if blocking is to be avoided. Thus, larger 4875 updates require a receiver to commit to larger resource commitments. 4876 Thus there is a trade-off between resource commitment and overhead 4877 when determining how large a limit is advertised. 4879 A receiver MAY use an autotuning mechanism to tune the frequency and 4880 amount that it increases data limits based on a round-trip time 4881 estimate and the rate at which the receiving application consumes 4882 data, similar to common TCP implementations. 4884 10.2. Stream Limit Increment 4886 As with flow control, this document leaves when and how many streams 4887 to make available to a peer via MAX_STREAM_ID to implementations, but 4888 offers a few considerations. MAX_STREAM_ID frames constitute minimal 4889 overhead, while withholding MAX_STREAM_ID frames can prevent the peer 4890 from using the available parallelism. 4892 Implementations will likely want to increase the maximum stream ID as 4893 peer-initiated streams close. A receiver MAY also advance the 4894 maximum stream ID based on current activity, system conditions, and 4895 other environmental factors. 4897 10.2.1. Blocking on Flow Control 4899 If a sender does not receive a MAX_DATA or MAX_STREAM_DATA frame when 4900 it has run out of flow control credit, the sender will be blocked and 4901 SHOULD send a BLOCKED or STREAM_BLOCKED frame. These frames are 4902 expected to be useful for debugging at the receiver; they do not 4903 require any other action. A receiver SHOULD NOT wait for a BLOCKED 4904 or STREAM_BLOCKED frame before sending MAX_DATA or MAX_STREAM_DATA, 4905 since doing so will mean that a sender is unable to send for an 4906 entire round trip. 4908 For smooth operation of the congestion controller, it is generally 4909 considered best to not let the sender go into quiescence if 4910 avoidable. To avoid blocking a sender, and to reasonably account for 4911 the possibility of loss, a receiver should send a MAX_DATA or 4912 MAX_STREAM_DATA frame at least two round trips before it expects the 4913 sender to get blocked. 4915 A sender sends a single BLOCKED or STREAM_BLOCKED frame only once 4916 when it reaches a data limit. A sender SHOULD NOT send multiple 4917 BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the 4918 original frame is determined to be lost. Another BLOCKED or 4919 STREAM_BLOCKED frame can be sent after the data limit is increased. 4921 10.3. Stream Final Offset 4923 The final offset is the count of the number of octets that are 4924 transmitted on a stream. For a stream that is reset, the final 4925 offset is carried explicitly in a RST_STREAM frame. Otherwise, the 4926 final offset is the offset of the end of the data carried in a STREAM 4927 frame marked with a FIN flag, or 0 in the case of incoming 4928 unidirectional streams. 4930 An endpoint will know the final offset for a stream when the receive 4931 stream enters the "Size Known" or "Reset Recvd" state. 4933 An endpoint MUST NOT send data on a stream at or beyond the final 4934 offset. 4936 Once a final offset for a stream is known, it cannot change. If a 4937 RST_STREAM or STREAM frame causes the final offset to change for a 4938 stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error 4939 (see Section 11). A receiver SHOULD treat receipt of data at or 4940 beyond the final offset as a FINAL_OFFSET_ERROR error, even after a 4941 stream is closed. Generating these errors is not mandatory, but only 4942 because requiring that an endpoint generate these errors also means 4943 that the endpoint needs to maintain the final offset state for closed 4944 streams, which could mean a significant state commitment. 4946 10.4. Flow Control for Cryptographic Handshake 4948 Data sent in CRYPTO frames is not flow controlled in the same way as 4949 STREAM frames. QUIC relies on the cryptographic protocol 4950 implementation to avoid excessive buffering of data, see [QUIC-TLS]. 4951 The implementation SHOULD provide an interface to QUIC to tell it 4952 about its buffering limits so that there is not excessive buffering 4953 at multiple layers. 4955 11. Error Handling 4957 An endpoint that detects an error SHOULD signal the existence of that 4958 error to its peer. Both transport-level and application-level errors 4959 can affect an entire connection (see Section 11.1), while only 4960 application-level errors can be isolated to a single stream (see 4961 Section 11.2). 4963 The most appropriate error code (Section 11.3) SHOULD be included in 4964 the frame that signals the error. Where this specification 4965 identifies error conditions, it also identifies the error code that 4966 is used. 4968 A stateless reset (Section 6.13.4) is not suitable for any error that 4969 can be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or 4970 RST_STREAM frame. A stateless reset MUST NOT be used by an endpoint 4971 that has the state necessary to send a frame on the connection. 4973 11.1. Connection Errors 4975 Errors that result in the connection being unusable, such as an 4976 obvious violation of protocol semantics or corruption of state that 4977 affects an entire connection, MUST be signaled using a 4978 CONNECTION_CLOSE or APPLICATION_CLOSE frame (Section 7.4, 4979 Section 7.5). An endpoint MAY close the connection in this manner 4980 even if the error only affects a single stream. 4982 Application protocols can signal application-specific protocol errors 4983 using the APPLICATION_CLOSE frame. Errors that are specific to the 4984 transport, including all those described in this document, are 4985 carried in a CONNECTION_CLOSE frame. Other than the type of error 4986 code they carry, these frames are identical in format and semantics. 4988 A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a 4989 packet that is lost. An endpoint SHOULD be prepared to retransmit a 4990 packet containing either frame type if it receives more packets on a 4991 terminated connection. Limiting the number of retransmissions and 4992 the time over which this final packet is sent limits the effort 4993 expended on terminated connections. 4995 An endpoint that chooses not to retransmit packets containing 4996 CONNECTION_CLOSE or APPLICATION_CLOSE risks a peer missing the first 4997 such packet. The only mechanism available to an endpoint that 4998 continues to receive data for a terminated connection is to use the 4999 stateless reset process (Section 6.13.4). 5001 An endpoint that receives an invalid CONNECTION_CLOSE or 5002 APPLICATION_CLOSE frame MUST NOT signal the existence of the error to 5003 its peer. 5005 11.2. Stream Errors 5007 If an application-level error affects a single stream, but otherwise 5008 leaves the connection in a recoverable state, the endpoint can send a 5009 RST_STREAM frame (Section 7.3) with an appropriate error code to 5010 terminate just the affected stream. 5012 Other than STOPPING (Section 9.3), RST_STREAM MUST be instigated by 5013 the application and MUST carry an application error code. Resetting 5014 a stream without knowledge of the application protocol could cause 5015 the protocol to enter an unrecoverable state. Application protocols 5016 might require certain streams to be reliably delivered in order to 5017 guarantee consistent state between endpoints. 5019 11.3. Transport Error Codes 5021 QUIC error codes are 16-bit unsigned integers. 5023 This section lists the defined QUIC transport error codes that may be 5024 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5025 connection. 5027 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5028 signal that the connection is being closed abruptly in the absence 5029 of any error. 5031 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5032 cannot continue with the connection. 5034 SERVER_BUSY (0x2): The server is currently busy and does not accept 5035 any new connections. 5037 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5038 permitted in its advertised data limits (see Section 10). 5040 STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream 5041 identifier that exceeded its advertised maximum stream ID. 5043 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5044 that was not in a state that permitted that frame (see 5045 Section 9.2). 5047 FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame 5048 containing data that exceeded the previously established final 5049 offset. Or an endpoint received a RST_STREAM frame containing a 5050 final offset that was lower than the maximum offset of data that 5051 was already received. Or an endpoint received a RST_STREAM frame 5052 containing a different final offset to the one already 5053 established. 5055 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5056 badly formatted. For instance, a frame of an unknown type, or an 5057 ACK frame that has more acknowledgment ranges than the remainder 5058 of the packet could carry. 5060 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5061 parameters that were badly formatted, included an invalid value, 5062 was absent even though it is mandatory, was present though it is 5063 forbidden, or is otherwise in error. 5065 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 5066 parameters that contained version negotiation parameters that 5067 disagreed with the version negotiation that it performed. This 5068 error code indicates a potential version downgrade attack. 5070 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5071 protocol compliance that was not covered by more specific error 5072 codes. 5074 INVALID_MIGRATION (0xC): A peer has migrated to a different network 5075 when the endpoint had disabled migration. 5077 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5078 of 256 values is reserved for carrying error codes specific to the 5079 cryptographic handshake that is used. Codes for errors occurring 5080 when TLS is used for the crypto handshake are described in 5081 Section 4.8 of [QUIC-TLS]. 5083 See Section 13.3 for details of registering new error codes. 5085 11.4. Application Protocol Error Codes 5087 Application protocol error codes are 16-bit unsigned integers, but 5088 the management of application error codes are left to application 5089 protocols. Application protocol error codes are used for the 5090 RST_STREAM (Section 7.3) and APPLICATION_CLOSE (Section 7.5) frames. 5092 There is no restriction on the use of the 16-bit error code space for 5093 application protocols. However, QUIC reserves the error code with a 5094 value of 0 to mean STOPPING. The application error code of STOPPING 5095 (0) is used by the transport to cancel a stream in response to 5096 receipt of a STOP_SENDING frame. 5098 12. Security Considerations 5100 12.1. Handshake Denial of Service 5102 As an encrypted and authenticated transport QUIC provides a range of 5103 protections against denial of service. Once the cryptographic 5104 handshake is complete, QUIC endpoints discard most packets that are 5105 not authenticated, greatly limiting the ability of an attacker to 5106 interfere with existing connections. 5108 Once a connection is established QUIC endpoints might accept some 5109 unauthenticated ICMP packets (see Section 8.4.1), but the use of 5110 these packets is extremely limited. The only other type of packet 5111 that an endpoint might accept is a stateless reset (Section 6.13.4) 5112 which relies on the token being kept secret until it is used. 5114 During the creation of a connection, QUIC only provides protection 5115 against attack from off the network path. All QUIC packets contain 5116 proof that the recipient saw a preceding packet from its peer. 5118 The first mechanism used is the source and destination connection 5119 IDs, which are required to match those set by a peer. Except for an 5120 Initial and stateless reset packets, an endpoint only accepts packets 5121 that include a destination connection that matches a connection ID 5122 the endpoint previously chose. This is the only protection offered 5123 for Version Negotiation packets. 5125 The destination connection ID in an Initial packet is selected by a 5126 client to be unpredictable, which serves an additional purpose. The 5127 packets that carry the cryptographic handshake are protected with a 5128 key that is derived from this connection ID and salt specific to the 5129 QUIC version. This allows endpoints to use the same process for 5130 authenticating packets that they receive as they use after the 5131 cryptographic handshake completes. Packets that cannot be 5132 authenticated are discarded. Protecting packets in this fashion 5133 provides a strong assurance that the sender of the packet saw the 5134 Initial packet and understood it. 5136 These protections are not intended to be effective against an 5137 attacker that is able to receive QUIC packets prior to the connection 5138 being established. Such an attacker can potentially send packets 5139 that will be accepted by QUIC endpoints. This version of QUIC 5140 attempts to detect this sort of attack, but it expects that endpoints 5141 will fail to establish a connection rather than recovering. For the 5142 most part, the cryptographic handshake protocol [QUIC-TLS] is 5143 responsible for detecting tampering during the handshake, though 5144 additional validation is required for version negotiation (see 5145 Section 6.6.4). 5147 Endpoints are permitted to use other methods to detect and attempt to 5148 recover from interference with the handshake. Invalid packets may be 5149 identified and discarded using other methods, but no specific method 5150 is mandated in this document. 5152 12.2. Spoofed ACK Attack 5154 An attacker might be able to receive an address validation token 5155 (Section 6.9) from the server and then release the IP address it used 5156 to acquire that token. The attacker may, in the future, spoof this 5157 same address (which now presumably addresses a different endpoint), 5158 and initiate a 0-RTT connection with a server on the victim's behalf. 5159 The attacker can then spoof ACK frames to the server which cause the 5160 server to send excessive amounts of data toward the new owner of the 5161 IP address. 5163 There are two possible mitigations to this attack. The simplest one 5164 is that a server can unilaterally create a gap in packet-number 5165 space. In the non-attack scenario, the client will send an ACK frame 5166 with the larger value for largest acknowledged. In the attack 5167 scenario, the attacker could acknowledge a packet in the gap. If the 5168 server sees an acknowledgment for a packet that was never sent, the 5169 connection can be aborted. 5171 The second mitigation is that the server can require that 5172 acknowledgments for sent packets match the encryption level of the 5173 sent packet. This mitigation is useful if the connection has an 5174 ephemeral forward-secure key that is generated and used for every new 5175 connection. If a packet sent is protected with a forward-secure key, 5176 then any acknowledgments that are received for them MUST also be 5177 forward-secure protected. Since the attacker will not have the 5178 forward-secure key, the attacker will not be able to generate 5179 forward-secure protected packets with ACK frames. 5181 12.3. Optimistic ACK Attack 5183 An endpoint that acknowledges packets it has not received might cause 5184 a congestion controller to permit sending at rates beyond what the 5185 network supports. An endpoint MAY skip packet numbers when sending 5186 packets to detect this behavior. An endpoint can then immediately 5187 close the connection with a connection error of type 5188 PROTOCOL_VIOLATION (see Section 6.13.3). 5190 12.4. Slowloris Attacks 5192 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 5193 connections to the target endpoint open and hold them open as long as 5194 possible. These attacks can be executed against a QUIC endpoint by 5195 generating the minimum amount of activity necessary to avoid being 5196 closed for inactivity. This might involve sending small amounts of 5197 data, gradually opening flow control windows in order to control the 5198 sender rate, or manufacturing ACK frames that simulate a high loss 5199 rate. 5201 QUIC deployments SHOULD provide mitigations for the Slowloris 5202 attacks, such as increasing the maximum number of clients the server 5203 will allow, limiting the number of connections a single IP address is 5204 allowed to make, imposing restrictions on the minimum transfer speed 5205 a connection is allowed to have, and restricting the length of time 5206 an endpoint is allowed to stay connected. 5208 12.5. Stream Fragmentation and Reassembly Attacks 5210 An adversarial sender might intentionally send fragments of stream 5211 data in order to cause disproportionate receive buffer memory 5212 commitment and/or creation of a large and inefficient data structure. 5214 An adversarial receiver might intentionally not acknowledge packets 5215 containing stream data in order to force the sender to store the 5216 unacknowledged stream data for retransmission. 5218 The attack on receivers is mitigated if flow control windows 5219 correspond to available memory. However, some receivers will over- 5220 commit memory and advertise flow control offsets in the aggregate 5221 that exceed actual available memory. The over-commitment strategy 5222 can lead to better performance when endpoints are well behaved, but 5223 renders endpoints vulnerable to the stream fragmentation attack. 5225 QUIC deployments SHOULD provide mitigations against stream 5226 fragmentation attacks. Mitigations could consist of avoiding over- 5227 committing memory, limiting the size of tracking data structures, 5228 delaying reassembly of STREAM frames, implementing heuristics based 5229 on the age and duration of reassembly holes, or some combination. 5231 12.6. Stream Commitment Attack 5233 An adversarial endpoint can open lots of streams, exhausting state on 5234 an endpoint. The adversarial endpoint could repeat the process on a 5235 large number of connections, in a manner similar to SYN flooding 5236 attacks in TCP. 5238 Normally, clients will open streams sequentially, as explained in 5239 Section 9.1. However, when several streams are initiated at short 5240 intervals, transmission error may cause STREAM DATA frames opening 5241 streams to be received out of sequence. A receiver is obligated to 5242 open intervening streams if a higher-numbered stream ID is received. 5243 Thus, on a new connection, opening stream 2000001 opens 1 million 5244 streams, as required by the specification. 5246 The number of active streams is limited by the concurrent stream 5247 limit transport parameter, as explained in Section 9.4. If chosen 5248 judiciously, this limit mitigates the effect of the stream commitment 5249 attack. However, setting the limit too low could affect performance 5250 when applications expect to open large number of streams. 5252 12.7. Explicit Congestion Notification Attacks 5254 An on-path attacker could manipulate the value of ECN codepoints in 5255 the IP header to influence the sender's rate. [RFC3168] discusses 5256 manipulations and their effects in more detail. 5258 An on-the-side attacker can duplicate and send packets with modified 5259 ECN codepoints to affect the sender's rate. If duplicate packets are 5260 discarded by a receiver, an off-path attacker will need to race the 5261 duplicate packet against the original to be successful in this 5262 attack. Therefore, QUIC receivers ignore ECN codepoints set in 5263 duplicate packets (see Section 6.8). 5265 12.8. Stateless Reset Oracle 5267 Stateless resets create a possible denial of service attack analogous 5268 to a TCP reset injection. This attack is possible if an attacker is 5269 able to cause a stateless reset token to be generated for a 5270 connection with a selected connection ID. An attacker that can cause 5271 this token to be generated can reset an active connection with the 5272 same connection ID. 5274 If a packet can be routed to different instances that share a static 5275 key, for example by changing an IP address or port, then an attacker 5276 can cause the server to send a stateless reset. To defend against 5277 this style of denial service, endpoints that share a static key for 5278 stateless reset (see Section 6.13.4.2) MUST be arranged so that 5279 packets with a given connection ID always arrive at an instance that 5280 has connection state, unless that connection is no longer active. 5282 In the case of a cluster that uses dynamic load balancing, it's 5283 possible that a change in load balancer configuration could happen 5284 while an active instance retains connection state; even if an 5285 instance retains connection state, the change in routing and 5286 resulting stateless reset will result in the connection being 5287 terminated. If there is no chance in the packet being routed to the 5288 correct instance, it is better to send a stateless reset than wait 5289 for connections to time out. However, this is acceptable only if the 5290 routing cannot be influenced by an attacker. 5292 13. IANA Considerations 5294 13.1. QUIC Transport Parameter Registry 5296 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 5297 under a "QUIC Protocol" heading. 5299 The "QUIC Transport Parameters" registry governs a 16-bit space. 5300 This space is split into two spaces that are governed by different 5301 policies. Values with the first byte in the range 0x00 to 0xfe (in 5302 hexadecimal) are assigned via the Specification Required policy 5303 [RFC8126]. Values with the first byte 0xff are reserved for Private 5304 Use [RFC8126]. 5306 Registrations MUST include the following fields: 5308 Value: The numeric value of the assignment (registrations will be 5309 between 0x0000 and 0xfeff). 5311 Parameter Name: A short mnemonic for the parameter. 5313 Specification: A reference to a publicly available specification for 5314 the value. 5316 The nominated expert(s) verify that a specification exists and is 5317 readily accessible. Expert(s) are encouraged to be biased towards 5318 approving registrations unless they are abusive, frivolous, or 5319 actively harmful (not merely aesthetically displeasing, or 5320 architecturally dubious). 5322 The initial contents of this registry are shown in Table 7. 5324 +--------+-------------------------------------+---------------+ 5325 | Value | Parameter Name | Specification | 5326 +--------+-------------------------------------+---------------+ 5327 | 0x0000 | initial_max_stream_data_bidi_local | Section 6.6.1 | 5328 | | | | 5329 | 0x0001 | initial_max_data | Section 6.6.1 | 5330 | | | | 5331 | 0x0002 | initial_max_bidi_streams | Section 6.6.1 | 5332 | | | | 5333 | 0x0003 | idle_timeout | Section 6.6.1 | 5334 | | | | 5335 | 0x0004 | preferred_address | Section 6.6.1 | 5336 | | | | 5337 | 0x0005 | max_packet_size | Section 6.6.1 | 5338 | | | | 5339 | 0x0006 | stateless_reset_token | Section 6.6.1 | 5340 | | | | 5341 | 0x0007 | ack_delay_exponent | Section 6.6.1 | 5342 | | | | 5343 | 0x0008 | initial_max_uni_streams | Section 6.6.1 | 5344 | | | | 5345 | 0x0009 | disable_migration | Section 6.6.1 | 5346 | | | | 5347 | 0x000a | initial_max_stream_data_bidi_remote | Section 6.6.1 | 5348 | | | | 5349 | 0x000b | initial_max_stream_data_uni | Section 6.6.1 | 5350 | | | | 5351 | 0x000c | max_ack_delay | Section 6.6.1 | 5352 | | | | 5353 | 0x000d | original_connection_id | Section 6.6.1 | 5354 +--------+-------------------------------------+---------------+ 5356 Table 7: Initial QUIC Transport Parameters Entries 5358 13.2. QUIC Frame Type Registry 5360 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 5361 "QUIC Protocol" heading. 5363 The "QUIC Frame Types" registry governs a 62-bit space. This space 5364 is split into three spaces that are governed by different policies. 5365 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 5366 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 5367 to 0x3fff operate on the Specification Required policy [RFC8126]. 5368 All other values are assigned to Private Use [RFC8126]. 5370 Registrations MUST include the following fields: 5372 Value: The numeric value of the assignment (registrations will be 5373 between 0x00 and 0x3fff). A range of values MAY be assigned. 5375 Frame Name: A short mnemonic for the frame type. 5377 Specification: A reference to a publicly available specification for 5378 the value. 5380 The nominated expert(s) verify that a specification exists and is 5381 readily accessible. Specifications for new registrations need to 5382 describe the means by which an endpoint might determine that it can 5383 send the identified type of frame. An accompanying transport 5384 parameter registration (see Section 13.1) is expected for most 5385 registrations. The specification needs to describe the format and 5386 assigned semantics of any fields in the frame. 5388 Expert(s) are encouraged to be biased towards approving registrations 5389 unless they are abusive, frivolous, or actively harmful (not merely 5390 aesthetically displeasing, or architecturally dubious). 5392 The initial contents of this registry are tabulated in Table 3. 5394 13.3. QUIC Transport Error Codes Registry 5396 IANA [SHALL add/has added] a registry for "QUIC Transport Error 5397 Codes" under a "QUIC Protocol" heading. 5399 The "QUIC Transport Error Codes" registry governs a 16-bit space. 5400 This space is split into two spaces that are governed by different 5401 policies. Values with the first byte in the range 0x00 to 0xfe (in 5402 hexadecimal) are assigned via the Specification Required policy 5403 [RFC8126]. Values with the first byte 0xff are reserved for Private 5404 Use [RFC8126]. 5406 Registrations MUST include the following fields: 5408 Value: The numeric value of the assignment (registrations will be 5409 between 0x0000 and 0xfeff). 5411 Code: A short mnemonic for the parameter. 5413 Description: A brief description of the error code semantics, which 5414 MAY be a summary if a specification reference is provided. 5416 Specification: A reference to a publicly available specification for 5417 the value. 5419 The initial contents of this registry are shown in Table 8. Values 5420 from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. 5422 +------+---------------------------+----------------+---------------+ 5423 | Valu | Error | Description | Specification | 5424 | e | | | | 5425 +------+---------------------------+----------------+---------------+ 5426 | 0x0 | NO_ERROR | No error | Section 11.3 | 5427 | | | | | 5428 | 0x1 | INTERNAL_ERROR | Implementation | Section 11.3 | 5429 | | | error | | 5430 | | | | | 5431 | 0x2 | SERVER_BUSY | Server | Section 11.3 | 5432 | | | currently busy | | 5433 | | | | | 5434 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 11.3 | 5435 | | | error | | 5436 | | | | | 5437 | 0x4 | STREAM_ID_ERROR | Invalid stream | Section 11.3 | 5438 | | | ID | | 5439 | | | | | 5440 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 11.3 | 5441 | | | in invalid | | 5442 | | | stream state | | 5443 | | | | | 5444 | 0x6 | FINAL_OFFSET_ERROR | Change to | Section 11.3 | 5445 | | | final stream | | 5446 | | | offset | | 5447 | | | | | 5448 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 11.3 | 5449 | | | error | | 5450 | | | | | 5451 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 11.3 | 5452 | | | transport | | 5453 | | | parameters | | 5454 | | | | | 5455 | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 11.3 | 5456 | | | negotiation | | 5457 | | | failure | | 5458 | | | | | 5459 | 0xA | PROTOCOL_VIOLATION | Generic | Section 11.3 | 5460 | | | protocol | | 5461 | | | violation | | 5462 | | | | | 5463 | 0xC | INVALID_MIGRATION | Violated | Section 11.3 | 5464 | | | disabled | | 5465 | | | migration | | 5466 +------+---------------------------+----------------+---------------+ 5468 Table 8: Initial QUIC Transport Error Codes Entries 5470 14. References 5472 14.1. Normative References 5474 [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 5475 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 5476 . 5478 [PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5479 DOI 10.17487/RFC1191, November 1990, 5480 . 5482 [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5483 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5484 DOI 10.17487/RFC8201, July 2017, 5485 . 5487 [QUIC-RECOVERY] 5488 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5489 and Congestion Control", draft-ietf-quic-recovery-15 (work 5490 in progress), October 2018. 5492 [QUIC-TLS] 5493 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5494 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5495 tls-15 (work in progress), October 2018. 5497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5498 Requirement Levels", BCP 14, RFC 2119, 5499 DOI 10.17487/RFC2119, March 1997, 5500 . 5502 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5503 of Explicit Congestion Notification (ECN) to IP", 5504 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5505 . 5507 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 5508 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 5509 2003, . 5511 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5512 "Randomness Requirements for Security", BCP 106, RFC 4086, 5513 DOI 10.17487/RFC4086, June 2005, 5514 . 5516 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5517 Writing an IANA Considerations Section in RFCs", BCP 26, 5518 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5519 . 5521 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5522 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5523 May 2017, . 5525 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 5526 Notification (ECN) Experimentation", RFC 8311, 5527 DOI 10.17487/RFC8311, January 2018, 5528 . 5530 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5531 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5532 . 5534 14.2. Informative References 5536 [EARLY-DESIGN] 5537 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 5538 December 2013, . 5540 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 5541 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 5542 DOI 10.17487/RFC7540, May 2015, 5543 . 5545 [QUIC-INVARIANTS] 5546 Thomson, M., "Version-Independent Properties of QUIC", 5547 draft-ietf-quic-invariants-03 (work in progress), October 5548 2018. 5550 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 5551 Selective Acknowledgment Options", RFC 2018, 5552 DOI 10.17487/RFC2018, October 1996, 5553 . 5555 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5556 Hashing for Message Authentication", RFC 2104, 5557 DOI 10.17487/RFC2104, February 1997, 5558 . 5560 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 5561 RFC 2360, DOI 10.17487/RFC2360, June 1998, 5562 . 5564 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 5565 Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November 5566 1998, . 5568 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 5569 Translation (NAT) Behavioral Requirements for Unicast 5570 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 5571 2007, . 5573 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5574 Key Derivation Function (HKDF)", RFC 5869, 5575 DOI 10.17487/RFC5869, May 2010, 5576 . 5578 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5579 "Transport Layer Security (TLS) Application-Layer Protocol 5580 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5581 July 2014, . 5583 [SLOWLORIS] 5584 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 5585 . 5588 [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer 5589 Communication Review Vol. 37, pp. 361, 5590 DOI 10.1145/1282427.1282421, October 2007. 5592 Appendix A. Sample Packet Number Decoding Algorithm 5594 The following pseudo-code shows how an implementation can decode 5595 packet numbers after packet number protection has been removed. 5597 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 5598 expected_pn = largest_pn + 1 5599 pn_win = 1 << pn_nbits 5600 pn_hwin = pn_win / 2 5601 pn_mask = pn_win - 1 5602 // The incoming packet number should be greater than 5603 // expected_pn - pn_hwin and less than or equal to 5604 // expected_pn + pn_hwin 5605 // 5606 // This means we can't just strip the trailing bits from 5607 // expected_pn and add the truncated_pn because that might 5608 // yield a value outside the window. 5609 // 5610 // The following code calculates a candidate value and 5611 // makes sure it's within the packet number window. 5612 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 5613 if candidate_pn <= expected_pn - pn_hwin: 5614 return candidate_pn + pn_win 5615 // Note the extra check for underflow when candidate_pn 5616 // is near zero. 5617 if candidate_pn > expected_pn + pn_hwin and 5618 candidate_pn > pn_win: 5619 return candidate_pn - pn_win 5620 return candidate_pn 5622 Appendix B. Change Log 5624 *RFC Editor's Note:* Please remove this section prior to 5625 publication of a final version of this document. 5627 Issue and pull request numbers are listed with a leading octothorp. 5629 B.1. Since draft-ietf-quic-transport-14 5631 o Merge ACK and ACK_ECN (#1778, #1801) 5633 o Explicitly communicate max_ack_delay (#981, #1781) 5635 o Validate original connection ID after Retry packets (#1710, #1486, 5636 #1793) 5638 o Idle timeout is optional and has no specified maximum (#1520, 5639 #1521) 5641 o Update connection ID handling; add RETIRE_CONNECTION_ID type 5642 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 5643 #1821) 5645 o Include a Token in all Initial packets (#1649, #1794) 5647 o Prevent handshake deadlock (#1764, #1824) 5649 B.2. Since draft-ietf-quic-transport-13 5651 o Streams open when higher-numbered streams of the same type open 5652 (#1342, #1549) 5654 o Split initial stream flow control limit into 3 transport 5655 parameters (#1016, #1542) 5657 o All flow control transport parameters are optional (#1610) 5659 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 5661 o Permit stateless reset in response to any packet (#1348, #1553) 5663 o Recommended defense against stateless reset spoofing (#1386, 5664 #1554) 5666 o Prevent infinite stateless reset exchanges (#1443, #1627) 5668 o Forbid processing of the same packet number twice (#1405, #1624) 5670 o Added a packet number decoding example (#1493) 5672 o More precisely define idle timeout (#1429, #1614, #1652) 5674 o Corrected format of Retry packet and prevented looping (#1492, 5675 #1451, #1448, #1498) 5677 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 5678 #1514, #1621) 5680 o Permit Retry in response to 0-RTT (#1547, #1552) 5682 o Looser verification of ECN counters to account for ACK loss 5683 (#1555, #1481, #1565) 5685 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 5687 B.3. Since draft-ietf-quic-transport-12 5689 o Changes to integration of the TLS handshake (#829, #1018, #1094, 5690 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 5692 * The cryptographic handshake uses CRYPTO frames, not stream 0 5693 * QUIC packet protection is used in place of TLS record 5694 protection 5696 * Separate QUIC packet number spaces are used for the handshake 5698 * Changed Retry to be independent of the cryptographic handshake 5700 * Added NEW_TOKEN frame and Token fields to Initial packet 5702 * Limit the use of HelloRetryRequest to address TLS needs (like 5703 key shares) 5705 o Enable server to transition connections to a preferred address 5706 (#560, #1251, #1373) 5708 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 5709 (#804, #805, #1372) 5711 o Changed rules and recommendations for use of new connection IDs 5712 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 5714 o Added a transport parameter to disable intentional connection 5715 migration (#1271, #1447) 5717 o Packets from different connection ID can't be coalesced (#1287, 5718 #1423) 5720 o Fixed sampling method for packet number encryption; the length 5721 field in long headers includes the packet number field in addition 5722 to the packet payload (#1387, #1389) 5724 o Stateless Reset is now symmetric and subject to size constraints 5725 (#466, #1346) 5727 o Added frame type extension mechanism (#58, #1473) 5729 B.4. Since draft-ietf-quic-transport-11 5731 o Enable server to transition connections to a preferred address 5732 (#560, #1251) 5734 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 5735 #990, #734, #1317, #1267, #1079) 5737 o Packet numbers use a variable-length encoding (#989, #1334) 5739 o STREAM frames can now be empty (#1350) 5741 B.5. Since draft-ietf-quic-transport-10 5743 o Swap payload length and packed number fields in long header 5744 (#1294) 5746 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 5747 (#1274) 5749 o Spin bit reserved (#1283) 5751 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 5753 o A more complete connection migration (#1249) 5755 o Refine opportunistic ACK defense text (#305, #1030, #1185) 5757 o A Stateless Reset Token isn't mandatory (#818, #1191) 5759 o Removed implicit stream opening (#896, #1193) 5761 o An empty STREAM frame can be used to open a stream without sending 5762 data (#901, #1194) 5764 o Define stream counts in transport parameters rather than a maximum 5765 stream ID (#1023, #1065) 5767 o STOP_SENDING is now prohibited before streams are used (#1050) 5769 o Recommend including ACK in Retry packets and allow PADDING (#1067, 5770 #882) 5772 o Endpoints now become closing after an idle timeout (#1178, #1179) 5774 o Remove implication that Version Negotiation is sent when a packet 5775 of the wrong version is received (#1197) 5777 B.6. Since draft-ietf-quic-transport-09 5779 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 5780 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 5781 (#1091, #725, #1086) 5783 o A server can now only send 3 packets without validating the client 5784 address (#38, #1090) 5786 o Delivery order of stream data is no longer strongly specified 5787 (#252, #1070) 5789 o Rework of packet handling and version negotiation (#1038) 5791 o Stream 0 is now exempt from flow control until the handshake 5792 completes (#1074, #725, #825, #1082) 5794 o Improved retransmission rules for all frame types: information is 5795 retransmitted, not packets or frames (#463, #765, #1095, #1053) 5797 o Added an error code for server busy signals (#1137) 5799 o Endpoints now set the connection ID that their peer uses. 5800 Connection IDs are variable length. Removed the 5801 omit_connection_id transport parameter and the corresponding short 5802 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 5804 B.7. Since draft-ietf-quic-transport-08 5806 o Clarified requirements for BLOCKED usage (#65, #924) 5808 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 5809 #928) 5811 o GAP limitation in ACK Frame (#613) 5813 o Improved PMTUD description (#614, #1036) 5815 o Clarified stream state machine (#634, #662, #743, #894) 5817 o Reserved versions don't need to be generated deterministically 5818 (#831, #931) 5820 o You don't always need the draining period (#871) 5822 o Stateless reset clarified as version-specific (#930, #986) 5824 o initial_max_stream_id_x transport parameters are optional (#970, 5825 #971) 5827 o Ack Delay assumes a default value during the handshake (#1007, 5828 #1009) 5830 o Removed transport parameters from NewSessionTicket (#1015) 5832 B.8. Since draft-ietf-quic-transport-07 5834 o The long header now has version before packet number (#926, #939) 5836 o Rename and consolidate packet types (#846, #822, #847) 5837 o Packet types are assigned new codepoints and the Connection ID 5838 Flag is inverted (#426, #956) 5840 o Removed type for Version Negotiation and use Version 0 (#963, 5841 #968) 5843 o Streams are split into unidirectional and bidirectional (#643, 5844 #656, #720, #872, #175, #885) 5846 * Stream limits now have separate uni- and bi-directional 5847 transport parameters (#909, #958) 5849 * Stream limit transport parameters are now optional and default 5850 to 0 (#970, #971) 5852 o The stream state machine has been split into read and write (#634, 5853 #894) 5855 o Employ variable-length integer encodings throughout (#595) 5857 o Improvements to connection close 5859 * Added distinct closing and draining states (#899, #871) 5861 * Draining period can terminate early (#869, #870) 5863 * Clarifications about stateless reset (#889, #890) 5865 o Address validation for connection migration (#161, #732, #878) 5867 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 5869 o negotiated_version is sent in server transport parameters (#710, 5870 #959) 5872 o Increased the range over which packet numbers are randomized 5873 (#864, #850, #964) 5875 B.9. Since draft-ietf-quic-transport-06 5877 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 5879 o Split error code space between application and transport (#485) 5881 o Stateless reset token moved to end (#820) 5883 o 1-RTT-protected long header types removed (#848) 5884 o No acknowledgments during draining period (#852) 5886 o Remove "application close" as a separate close type (#854) 5888 o Remove timestamps from the ACK frame (#841) 5890 o Require transport parameters to only appear once (#792) 5892 B.10. Since draft-ietf-quic-transport-05 5894 o Stateless token is server-only (#726) 5896 o Refactor section on connection termination (#733, #748, #328, 5897 #177) 5899 o Limit size of Version Negotiation packet (#585) 5901 o Clarify when and what to ack (#736) 5903 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 5905 o Clarify Keep-alive requirements (#729) 5907 B.11. Since draft-ietf-quic-transport-04 5909 o Introduce STOP_SENDING frame, RST_STREAM only resets in one 5910 direction (#165) 5912 o Removed GOAWAY; application protocols are responsible for graceful 5913 shutdown (#696) 5915 o Reduced the number of error codes (#96, #177, #184, #211) 5917 o Version validation fields can't move or change (#121) 5919 o Removed versions from the transport parameters in a 5920 NewSessionTicket message (#547) 5922 o Clarify the meaning of "bytes in flight" (#550) 5924 o Public reset is now stateless reset and not visible to the path 5925 (#215) 5927 o Reordered bits and fields in STREAM frame (#620) 5929 o Clarifications to the stream state machine (#572, #571) 5930 o Increased the maximum length of the Largest Acknowledged field in 5931 ACK frames to 64 bits (#629) 5933 o truncate_connection_id is renamed to omit_connection_id (#659) 5935 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 5936 #328) 5938 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 5940 B.12. Since draft-ietf-quic-transport-03 5942 o Change STREAM and RST_STREAM layout 5944 o Add MAX_STREAM_ID settings 5946 B.13. Since draft-ietf-quic-transport-02 5948 o The size of the initial packet payload has a fixed minimum (#267, 5949 #472) 5951 o Define when Version Negotiation packets are ignored (#284, #294, 5952 #241, #143, #474) 5954 o The 64-bit FNV-1a algorithm is used for integrity protection of 5955 unprotected packets (#167, #480, #481, #517) 5957 o Rework initial packet types to change how the connection ID is 5958 chosen (#482, #442, #493) 5960 o No timestamps are forbidden in unprotected packets (#542, #429) 5962 o Cryptographic handshake is now on stream 0 (#456) 5964 o Remove congestion control exemption for cryptographic handshake 5965 (#248, #476) 5967 o Version 1 of QUIC uses TLS; a new version is needed to use a 5968 different handshake protocol (#516) 5970 o STREAM frames have a reduced number of offset lengths (#543, #430) 5972 o Split some frames into separate connection- and stream- level 5973 frames (#443) 5975 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 5977 * BLOCKED split to match WINDOW_UPDATE split (#454) 5978 * Define STREAM_ID_NEEDED frame (#455) 5980 o A NEW_CONNECTION_ID frame supports connection migration without 5981 linkability (#232, #491, #496) 5983 o Transport parameters for 0-RTT are retained from a previous 5984 connection (#405, #513, #512) 5986 * A client in 0-RTT no longer required to reset excess streams 5987 (#425, #479) 5989 o Expanded security considerations (#440, #444, #445, #448) 5991 B.14. Since draft-ietf-quic-transport-01 5993 o Defined short and long packet headers (#40, #148, #361) 5995 o Defined a versioning scheme and stable fields (#51, #361) 5997 o Define reserved version values for "greasing" negotiation (#112, 5998 #278) 6000 o The initial packet number is randomized (#35, #283) 6002 o Narrow the packet number encoding range requirement (#67, #286, 6003 #299, #323, #356) 6005 o Defined client address validation (#52, #118, #120, #275) 6007 o Define transport parameters as a TLS extension (#49, #122) 6009 o SCUP and COPT parameters are no longer valid (#116, #117) 6011 o Transport parameters for 0-RTT are either remembered from before, 6012 or assume default values (#126) 6014 o The server chooses connection IDs in its final flight (#119, #349, 6015 #361) 6017 o The server echoes the Connection ID and packet number fields when 6018 sending a Version Negotiation packet (#133, #295, #244) 6020 o Defined a minimum packet size for the initial handshake packet 6021 from the client (#69, #136, #139, #164) 6023 o Path MTU Discovery (#64, #106) 6024 o The initial handshake packet from the client needs to fit in a 6025 single packet (#338) 6027 o Forbid acknowledgment of packets containing only ACK and PADDING 6028 (#291) 6030 o Require that frames are processed when packets are acknowledged 6031 (#381, #341) 6033 o Removed the STOP_WAITING frame (#66) 6035 o Don't require retransmission of old timestamps for lost ACK frames 6036 (#308) 6038 o Clarified that frames are not retransmitted, but the information 6039 in them can be (#157, #298) 6041 o Error handling definitions (#335) 6043 o Split error codes into four sections (#74) 6045 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 6046 (#289) 6048 o Define packet protection rules (#336) 6050 o Require that stream be entirely delivered or reset, including 6051 acknowledgment of all STREAM frames or the RST_STREAM, before it 6052 closes (#381) 6054 o Remove stream reservation from state machine (#174, #280) 6056 o Only stream 1 does not contribute to connection-level flow control 6057 (#204) 6059 o Stream 1 counts towards the maximum concurrent stream limit (#201, 6060 #282) 6062 o Remove connection-level flow control exclusion for some streams 6063 (except 1) (#246) 6065 o RST_STREAM affects connection-level flow control (#162, #163) 6067 o Flow control accounting uses the maximum data offset on each 6068 stream, rather than bytes received (#378) 6070 o Moved length-determining fields to the start of STREAM and ACK 6071 (#168, #277) 6073 o Added the ability to pad between frames (#158, #276) 6075 o Remove error code and reason phrase from GOAWAY (#352, #355) 6077 o GOAWAY includes a final stream number for both directions (#347) 6079 o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a 6080 consistent offset (#249) 6082 o Defined priority as the responsibility of the application protocol 6083 (#104, #303) 6085 B.15. Since draft-ietf-quic-transport-00 6087 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 6089 o Defined versioning 6091 o Reworked description of packet and frame layout 6093 o Error code space is divided into regions for each component 6095 o Use big endian for all numeric values 6097 B.16. Since draft-hamilton-quic-transport-protocol-01 6099 o Adopted as base for draft-ietf-quic-tls 6101 o Updated authors/editors list 6103 o Added IANA Considerations section 6105 o Moved Contributors and Acknowledgments to appendices 6107 Acknowledgments 6109 Special thanks are due to the following for helping shape pre-IETF 6110 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 6111 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 6113 This document has benefited immensely from various private 6114 discussions and public ones on the quic@ietf.org and proto- 6115 quic@chromium.org mailing lists. Our thanks to all. 6117 Contributors 6119 The original authors of this specification were Ryan Hamilton, Jana 6120 Iyengar, Ian Swett, and Alyssa Wilk. 6122 The original design and rationale behind this protocol draw 6123 significantly from work by Jim Roskind [EARLY-DESIGN]. In 6124 alphabetical order, the contributors to the pre-IETF QUIC project at 6125 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 6126 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 6127 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 6128 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 6129 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 6131 Authors' Addresses 6133 Jana Iyengar (editor) 6134 Fastly 6136 Email: jri.ietf@gmail.com 6138 Martin Thomson (editor) 6139 Mozilla 6141 Email: martin.thomson@gmail.com