idnits 2.17.1 draft-ietf-quic-transport-16.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 23, 2018) is 2010 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 1809 == Missing Reference: 'CH' is mentioned on line 1805, but not defined == Missing Reference: 'SH' is mentioned on line 1807, but not defined == Missing Reference: 'EE' is mentioned on line 1808, but not defined == Missing Reference: 'CERT' is mentioned on line 1808, but not defined == Missing Reference: 'CV' is mentioned on line 1808, but not defined == Missing Reference: 'FIN' is mentioned on line 1808, but not defined -- Looks like a reference, but probably isn't: '1' on line 1516 -- Looks like a reference, but probably isn't: '2' on line 1515 -- Looks like a reference, but probably isn't: '16' on line 4128 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-16 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-16 ** Downref: Normative reference to an Informational RFC: RFC 5119 -- 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: 1 error (**), 0 flaws (~~), 11 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 26, 2019 Mozilla 6 October 23, 2018 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-16 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 26, 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 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 64 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 7 65 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 66 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 9 68 2.2. Stream Concurrency . . . . . . . . . . . . . . . . . . . 10 69 2.3. Sending and Receiving Data . . . . . . . . . . . . . . . 11 70 2.4. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 71 3. Stream States: Life of a Stream . . . . . . . . . . . . . . . 12 72 3.1. Send Stream States . . . . . . . . . . . . . . . . . . . 13 73 3.2. Receive Stream States . . . . . . . . . . . . . . . . . . 15 74 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 18 75 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 18 76 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19 77 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 20 78 4.1. Handling of Stream Cancellation . . . . . . . . . . . . . 21 79 4.2. Data Limit Increments . . . . . . . . . . . . . . . . . . 22 80 4.3. Stream Final Offset . . . . . . . . . . . . . . . . . . . 23 81 4.4. Flow Control for Cryptographic Handshake . . . . . . . . 24 82 4.5. Stream Limit Increment . . . . . . . . . . . . . . . . . 24 83 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24 85 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25 86 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26 87 5.2. Matching Packets to Connections . . . . . . . . . . . . . 27 88 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27 89 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27 90 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 28 91 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28 92 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 29 93 6.2. Handling Version Negotiation Packets . . . . . . . . . . 29 94 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 30 95 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 31 96 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 32 97 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 33 98 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34 99 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 35 100 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 36 101 7.3.3. Version Negotiation Validation . . . . . . . . . . . 36 102 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 103 8.1. Address Validation During Connection Establishment . . . 38 104 8.1.1. Address Validation using Retry Packets . . . . . . . 38 105 8.1.2. Address Validation for Future Connections . . . . . . 39 106 8.1.3. Address Validation Token Integrity . . . . . . . . . 41 107 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41 108 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 42 109 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 110 8.5. Successful Path Validation . . . . . . . . . . . . . . . 42 111 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 112 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43 113 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44 114 9.2. Initiating Connection Migration . . . . . . . . . . . . . 45 115 9.3. Responding to Connection Migration . . . . . . . . . . . 45 116 9.3.1. Handling Address Spoofing by a Peer . . . . . . . . . 46 117 9.3.2. Handling Address Spoofing by an On-path Attacker . . 46 118 9.4. Loss Detection and Congestion Control . . . . . . . . . . 47 119 9.5. Privacy Implications of Connection Migration . . . . . . 48 120 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 49 121 9.6.1. Communicating A Preferred Address . . . . . . . . . . 49 122 9.6.2. Responding to Connection Migration . . . . . . . . . 49 123 9.6.3. Interaction of Client Migration and Preferred Address 50 124 10. Connection Termination . . . . . . . . . . . . . . . . . . . 50 125 10.1. Closing and Draining Connection States . . . . . . . . . 51 126 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 52 127 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 52 128 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 53 129 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 56 130 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 56 131 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 57 132 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 58 133 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 58 134 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 59 135 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 59 136 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 59 137 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 60 138 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 61 139 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 62 140 13. Packetization and Reliability . . . . . . . . . . . . . . . . 65 141 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 66 142 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 66 143 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 67 144 13.2. Retransmission of Information . . . . . . . . . . . . . 67 145 13.3. Explicit Congestion Notification . . . . . . . . . . . . 69 146 13.3.1. ECN Counters . . . . . . . . . . . . . . . . . . . . 70 147 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 70 148 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 71 149 14.1. Path Maximum Transmission Unit . . . . . . . . . . . . . 72 150 14.1.1. IPv4 PMTU Discovery . . . . . . . . . . . . . . . . 73 151 14.2. Special Considerations for Packetization Layer PMTU 152 Discovery . . . . . . . . . . . . . . . . . . . . . . . 73 153 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 74 154 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 75 155 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 75 156 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 76 157 17.2. Long Header Packet . . . . . . . . . . . . . . . . . . . 77 158 17.3. Short Header Packet . . . . . . . . . . . . . . . . . . 79 159 17.4. Version Negotiation Packet . . . . . . . . . . . . . . . 81 160 17.5. Initial Packet . . . . . . . . . . . . . . . . . . . . . 82 161 17.5.1. Starting Packet Numbers . . . . . . . . . . . . . . 84 162 17.5.2. 0-RTT Packet Numbers . . . . . . . . . . . . . . . . 84 163 17.6. Handshake Packet . . . . . . . . . . . . . . . . . . . . 85 164 17.7. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 85 165 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 88 166 18.1. Transport Parameter Definitions . . . . . . . . . . . . 90 167 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 92 168 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 93 169 19.2. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 93 170 19.3. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 94 171 19.4. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . 95 172 19.5. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 95 173 19.6. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 96 174 19.7. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . 97 175 19.8. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 98 176 19.9. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . 98 177 19.10. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 99 178 19.11. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . 99 179 19.12. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 100 180 19.13. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 101 181 19.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 102 182 19.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . 102 183 19.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 104 184 19.15.2. ECN section . . . . . . . . . . . . . . . . . . . . 105 185 19.16. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 106 186 19.17. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 107 187 19.18. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . 107 188 19.19. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 107 189 19.20. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 109 190 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 110 191 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 110 192 20.1. Application Protocol Error Codes . . . . . . . . . . . . 111 193 21. Security Considerations . . . . . . . . . . . . . . . . . . . 112 194 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 112 195 21.2. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 113 196 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 113 197 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 114 198 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 114 199 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 114 200 21.7. Explicit Congestion Notification Attacks . . . . . . . . 115 201 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 115 202 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 203 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 116 204 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 117 205 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 118 206 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 207 23.1. Normative References . . . . . . . . . . . . . . . . . . 121 208 23.2. Informative References . . . . . . . . . . . . . . . . . 122 209 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 123 210 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 124 211 B.1. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 124 212 B.2. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 124 213 B.3. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 125 214 B.4. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 126 215 B.5. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 126 216 B.6. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 127 217 B.7. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 127 218 B.8. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 128 219 B.9. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 129 220 B.10. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 130 221 B.11. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 130 222 B.12. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 130 223 B.13. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 131 224 B.14. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 131 225 B.15. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 132 226 B.16. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 134 227 B.17. Since draft-hamilton-quic-transport-protocol-01 . . . . . 134 228 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 134 229 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 135 230 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 135 232 1. Introduction 234 QUIC is a multiplexed and secure transport protocol that runs on top 235 of UDP. QUIC aims to provide a flexible set of features that allow 236 it to be a general-purpose secure transport for multiple 237 applications. 239 o Version negotiation 241 o Low-latency connection establishment 243 o Authenticated and encrypted header and payload 245 o Stream multiplexing 247 o Stream and connection-level flow control 249 o Connection migration and resilience to NAT rebinding 251 QUIC uses UDP as a substrate to avoid requiring changes in legacy 252 client operating systems and middleboxes. QUIC authenticates all of 253 its headers and encrypts most of the data it exchanges, including its 254 signaling. This allows the protocol to evolve without incurring a 255 dependency on upgrades to middleboxes. 257 1.1. Document Structure 259 This document describes the core QUIC protocol, and is structured as 260 follows: 262 o Streams are the basic service abstraction that QUIC provides. 264 * Section 2 describes core concepts related to streams, 266 * Section 3 provides a reference model for stream states, and 268 * Section 4 outlines the operation of flow control. 270 o Connections are the context in which QUIC endpoints communicate. 272 * Section 5 describes core concepts related to connections, 274 * Section 6 describes version negotiation, 276 * Section 7 details the process for establishing connections, 278 * Section 8 specifies critical denial of service mitigation 279 mechanisms, 281 * Section 9 describes how endpoints migrate a connection to use a 282 new network paths, and 284 * Section 10 lists the options for terminating an open 285 connection. 287 o Packets and frames are the basic unit used by QUIC to communicate. 289 * Section 12 describes concepts related to packets and frames, 291 * Section 13 defines models for the transmission, retransmission, 292 and acknowledgement of information, and 294 * Section 14 contains a rules for managing the size of packets. 296 o Details of encoding of QUIC protocol elements is described in: 298 * Section 15 (Versions), 300 * Section 17 (Packet Headers), 302 * Section 18 (Transport Parameters), 304 * Section 19 (Frames), and 306 * Section 20 (Errors). 308 Accompanying documents describe QUIC's loss detection and congestion 309 control [QUIC-RECOVERY], and the use of TLS 1.3 for key negotiation 310 [QUIC-TLS]. 312 QUIC version 1 conforms to the protocol invariants in 313 [QUIC-INVARIANTS]. 315 1.2. Conventions and Definitions 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 319 "OPTIONAL" in this document are to be interpreted as described in BCP 320 14 [RFC2119] [RFC8174] when, and only when, they appear in all 321 capitals, as shown here. 323 Definitions of terms that are used in this document: 325 Client: The endpoint initiating a QUIC connection. 327 Server: The endpoint accepting incoming QUIC connections. 329 Endpoint: The client or server end of a connection. 331 Stream: A logical unidirectional or bidirectional channel of ordered 332 bytes within a QUIC connection. 334 Connection: A conversation between two QUIC endpoints with a single 335 encryption context that multiplexes streams within it. 337 Connection ID: An opaque identifier that is used to identify a QUIC 338 connection at an endpoint. Each endpoint sets a value that its 339 peer includes in packets. 341 QUIC packet: The smallest unit of data that can be exchanged by QUIC 342 endpoints. 344 QUIC is a name, not an acronym. 346 1.3. Notational Conventions 348 Packet and frame diagrams use the format described in Section 3.1 of 349 [RFC2360], with the following additional conventions: 351 [x] Indicates that x is optional 353 x (A) Indicates that x is A bits long 355 x (A/B/C) ... Indicates that x is one of A, B, or C bits long 357 x (i) ... Indicates that x uses the variable-length encoding in 358 Section 16 360 x (*) ... Indicates that x is variable-length 362 2. Streams 364 Streams in QUIC provide a lightweight, ordered byte-stream 365 abstraction. 367 There are two basic types of stream in QUIC. Unidirectional streams 368 carry data in one direction: from the initiator of the stream to its 369 peer; bidirectional streams allow for data to be sent in both 370 directions. Different stream identifiers are used to distinguish 371 between unidirectional and bidirectional streams, as well as to 372 create a separation between streams that are initiated by the client 373 and server (see Section 2.1). 375 Either type of stream can be created by either endpoint, can 376 concurrently send data interleaved with other streams, and can be 377 cancelled. 379 Streams can be created by sending data. Other processes associated 380 with stream management - ending, cancelling, and managing flow 381 control - are all designed to impose minimal overheads. For 382 instance, a single STREAM frame (Section 19.19) can open, carry data 383 for, and close a stream. Streams can also be long-lived and can last 384 the entire duration of a connection. 386 Stream offsets allow for the octets on a stream to be placed in 387 order. An endpoint MUST be capable of delivering data received on a 388 stream in order. Implementations MAY choose to offer the ability to 389 deliver data out of order. There is no means of ensuring ordering 390 between octets on different streams. 392 Streams are individually flow controlled, allowing an endpoint to 393 limit memory commitment and to apply back pressure. The creation of 394 streams is also flow controlled, with each peer declaring the maximum 395 stream ID it is willing to accept at a given time. 397 An alternative view of QUIC streams is as an elastic "message" 398 abstraction, similar to the way ephemeral streams are used in SST 399 [SST], which may be a more appealing description for some 400 applications. 402 2.1. Stream Identifiers 404 Streams are identified by an unsigned 62-bit integer, referred to as 405 the Stream ID. Stream IDs are encoded as a variable-length integer 406 (see Section 16). The least significant two bits of the Stream ID 407 are used to identify the type of stream (unidirectional or 408 bidirectional) and the initiator of the stream. 410 The least significant bit (0x1) of the Stream ID identifies the 411 initiator of the stream. Clients initiate even-numbered streams 412 (those with the least significant bit set to 0); servers initiate 413 odd-numbered streams (with the bit set to 1). Separation of the 414 stream identifiers ensures that client and server are able to open 415 streams without the latency imposed by negotiating for an identifier. 417 If an endpoint receives a frame for a stream that it expects to 418 initiate (i.e., odd-numbered for the client or even-numbered for the 419 server), but which it has not yet opened, it MUST close the 420 connection with error code STREAM_STATE_ERROR. 422 The second least significant bit (0x2) of the Stream ID 423 differentiates between unidirectional streams and bidirectional 424 streams. Unidirectional streams always have this bit set to 1 and 425 bidirectional streams have this bit set to 0. 427 The two type bits from a Stream ID therefore identify streams as 428 summarized in Table 1. 430 +----------+----------------------------------+ 431 | Low Bits | Stream Type | 432 +----------+----------------------------------+ 433 | 0x0 | Client-Initiated, Bidirectional | 434 | | | 435 | 0x1 | Server-Initiated, Bidirectional | 436 | | | 437 | 0x2 | Client-Initiated, Unidirectional | 438 | | | 439 | 0x3 | Server-Initiated, Unidirectional | 440 +----------+----------------------------------+ 442 Table 1: Stream ID Types 444 The first bidirectional stream opened by the client is stream 0. 446 A QUIC endpoint MUST NOT reuse a Stream ID. Streams of each type are 447 created in numeric order. Streams that are used out of order result 448 in opening all lower-numbered streams of the same type in the same 449 direction. 451 2.2. Stream Concurrency 453 QUIC allows for an arbitrary number of streams to operate 454 concurrently. An endpoint limits the number of concurrently active 455 incoming streams by limiting the maximum stream ID (see Section 4.5). 457 The maximum stream ID is specific to each endpoint and applies only 458 to the peer that receives the setting. That is, clients specify the 459 maximum stream ID the server can initiate, and servers specify the 460 maximum stream ID the client can initiate. Each endpoint may respond 461 on streams initiated by the other peer, regardless of whether it is 462 permitted to initiate new streams. 464 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 465 that receives a STREAM frame with an ID greater than the limit it has 466 sent MUST treat this as a stream error of type STREAM_ID_ERROR 467 (Section 11), unless this is a result of a change in the initial 468 limits (see Section 7.3.1). 470 A receiver cannot renege on an advertisement; that is, once a 471 receiver advertises a stream ID via a MAX_STREAM_ID frame, 472 advertising a smaller maximum ID has no effect. A receiver MUST 473 ignore any MAX_STREAM_ID frame that does not increase the maximum 474 stream ID. 476 2.3. Sending and Receiving Data 478 Endpoints uses streams to send and receive data. Endpoints send 479 STREAM frames, which encapsulate data for a stream. STREAM frames 480 carry a flag that can be used to signal the end of a stream. 482 Streams are an ordered byte-stream abstraction with no other 483 structure that is visible to QUIC. STREAM frame boundaries are not 484 expected to preserved when data is transmitted, when data is 485 retransmitted after packet loss, or when data is delivered to the 486 application at the receiver. 488 When new data is to be sent on a stream, a sender MUST set the 489 encapsulating STREAM frame's offset field to the stream offset of the 490 first octet of this new data. The first octet of data on a stream 491 has an offset of 0. An endpoint is expected to send every stream 492 octet. The largest offset delivered on a stream MUST be less than 493 2^62. 495 QUIC makes no specific allowances for partial reliability or delivery 496 of stream data out of order. Endpoints MUST be able to deliver 497 stream data to an application as an ordered byte-stream. Delivering 498 an ordered byte-stream requires that an endpoint buffer any data that 499 is received out of order, up to the advertised flow control limit. 501 An endpoint could receive the same octets multiple times; octets that 502 have already been received can be discarded. The value for a given 503 octet MUST NOT change if it is sent multiple times; an endpoint MAY 504 treat receipt of a changed octet as a connection error of type 505 PROTOCOL_VIOLATION. 507 An endpoint MUST NOT send data on any stream without ensuring that it 508 is within the data limits set by its peer. Flow control is described 509 in detail in Section 4. 511 2.4. Stream Prioritization 513 Stream multiplexing has a significant effect on application 514 performance if resources allocated to streams are correctly 515 prioritized. Experience with other multiplexed protocols, such as 516 HTTP/2 [HTTP2], shows that effective prioritization strategies have a 517 significant positive impact on performance. 519 QUIC does not provide frames for exchanging prioritization 520 information. Instead it relies on receiving priority information 521 from the application that uses QUIC. Protocols that use QUIC are 522 able to define any prioritization scheme that suits their application 523 semantics. A protocol might define explicit messages for signaling 524 priority, such as those defined in HTTP/2; it could define rules that 525 allow an endpoint to determine priority based on context; or it could 526 leave the determination to the application. 528 A QUIC implementation SHOULD provide ways in which an application can 529 indicate the relative priority of streams. When deciding which 530 streams to dedicate resources to, QUIC SHOULD use the information 531 provided by the application. Failure to account for priority of 532 streams can result in suboptimal performance. 534 Stream priority is most relevant when deciding which stream data will 535 be transmitted. Often, there will be limits on what can be 536 transmitted as a result of connection flow control or the current 537 congestion controller state. 539 Giving preference to the transmission of its own management frames 540 ensures that the protocol functions efficiently. That is, 541 prioritizing frames other than STREAM frames ensures that loss 542 recovery, congestion control, and flow control operate effectively. 544 CRYPTO frames SHOULD be prioritized over other streams prior to the 545 completion of the cryptographic handshake. This includes the 546 retransmission of the second flight of client handshake messages, 547 that is, the TLS Finished and any client authentication messages. 549 STREAM data in frames determined to be lost SHOULD be retransmitted 550 before sending new data, unless application priorities indicate 551 otherwise. Retransmitting lost stream data can fill in gaps, which 552 allows the peer to consume already received data and free up the flow 553 control window. 555 3. Stream States: Life of a Stream 557 This section describes the two types of QUIC stream in terms of the 558 states of their send or receive components. Two state machines are 559 described: one for streams on which an endpoint transmits data 560 (Section 3.1); another for streams from which an endpoint receives 561 data (Section 3.2). 563 Unidirectional streams use the applicable state machine directly. 564 Bidirectional streams use both state machines. For the most part, 565 the use of these state machines is the same whether the stream is 566 unidirectional or bidirectional. The conditions for opening a stream 567 are slightly more complex for a bidirectional stream because the 568 opening of either send or receive sides causes the stream to open in 569 both directions. 571 An endpoint can open streams up to its maximum stream limit in any 572 order, however endpoints SHOULD open the send side of streams for 573 each type in order. 575 Note: These states are largely informative. This document uses 576 stream states to describe rules for when and how different types 577 of frames can be sent and the reactions that are expected when 578 different types of frames are received. Though these state 579 machines are intended to be useful in implementing QUIC, these 580 states aren't intended to constrain implementations. An 581 implementation can define a different state machine as long as its 582 behavior is consistent with an implementation that implements 583 these states. 585 3.1. Send Stream States 587 Figure 1 shows the states for the part of a stream that sends data to 588 a peer. 590 o 591 | Create Stream (Sending) 592 | Create Bidirectional Stream (Receiving) 593 v 594 +-------+ 595 | Ready | Send RST_STREAM 596 | |-----------------------. 597 +-------+ | 598 | | 599 | Send STREAM / | 600 | STREAM_BLOCKED | 601 | | 602 | Create Bidirectional | 603 | Stream (Receiving) | 604 v | 605 +-------+ | 606 | Send | Send RST_STREAM | 607 | |---------------------->| 608 +-------+ | 609 | | 610 | Send STREAM + FIN | 611 v v 612 +-------+ +-------+ 613 | Data | Send RST_STREAM | Reset | 614 | Sent |------------------>| Sent | 615 +-------+ +-------+ 616 | | 617 | Recv All ACKs | Recv ACK 618 v v 619 +-------+ +-------+ 620 | Data | | Reset | 621 | Recvd | | Recvd | 622 +-------+ +-------+ 624 Figure 1: States for Send Streams 626 The sending part of stream that the endpoint initiates (types 0 and 2 627 for clients, 1 and 3 for servers) is opened by the application or 628 application protocol. The "Ready" state represents a newly created 629 stream that is able to accept data from the application. Stream data 630 might be buffered in this state in preparation for sending. 632 Sending the first STREAM or STREAM_BLOCKED frame causes a send stream 633 to enter the "Send" state. An implementation might choose to defer 634 allocating a Stream ID to a send stream until it sends the first 635 frame and enters this state, which can allow for better stream 636 prioritization. 638 The sending part of a bidirectional stream initiated by a peer (type 639 0 for a server, type 1 for a client) enters the "Ready" state then 640 immediately transitions to the "Send" state if the receiving part 641 enters the "Recv" state. 643 In the "Send" state, an endpoint transmits - and retransmits as 644 necessary - data in STREAM frames. The endpoint respects the flow 645 control limits of its peer, accepting MAX_STREAM_DATA frames. An 646 endpoint in the "Send" state generates STREAM_BLOCKED frames if it 647 encounters flow control limits. 649 After the application indicates that stream data is complete and a 650 STREAM frame containing the FIN bit is sent, the send stream enters 651 the "Data Sent" state. From this state, the endpoint only 652 retransmits stream data as necessary. The endpoint no longer needs 653 to track flow control limits or send STREAM_BLOCKED frames for a send 654 stream in this state. The endpoint can ignore any MAX_STREAM_DATA 655 frames it receives from its peer in this state; MAX_STREAM_DATA 656 frames might be received until the peer receives the final stream 657 offset. 659 Once all stream data has been successfully acknowledged, the send 660 stream enters the "Data Recvd" state, which is a terminal state. 662 From any of the "Ready", "Send", or "Data Sent" states, an 663 application can signal that it wishes to abandon transmission of 664 stream data. Similarly, the endpoint might receive a STOP_SENDING 665 frame from its peer. In either case, the endpoint sends a RST_STREAM 666 frame, which causes the stream to enter the "Reset Sent" state. 668 An endpoint MAY send a RST_STREAM as the first frame on a send 669 stream; this causes the send stream to open and then immediately 670 transition to the "Reset Sent" state. 672 Once a packet containing a RST_STREAM has been acknowledged, the send 673 stream enters the "Reset Recvd" state, which is a terminal state. 675 3.2. Receive Stream States 677 Figure 2 shows the states for the part of a stream that receives data 678 from a peer. The states for a receive stream mirror only some of the 679 states of the send stream at the peer. A receive stream doesn't 680 track states on the send stream that cannot be observed, such as the 681 "Ready" state; instead, receive streams track the delivery of data to 682 the application or application protocol some of which cannot be 683 observed by the sender. 685 o 686 | Recv STREAM / STREAM_BLOCKED / RST_STREAM 687 | Create Bidirectional Stream (Sending) 688 | Recv MAX_STREAM_DATA 689 | Create Higher-Numbered Stream 690 v 691 +-------+ 692 | Recv | Recv RST_STREAM 693 | |-----------------------. 694 +-------+ | 695 | | 696 | Recv STREAM + FIN | 697 v | 698 +-------+ | 699 | Size | Recv RST_STREAM | 700 | Known |---------------------->| 701 +-------+ | 702 | | 703 | Recv All Data | 704 v v 705 +-------+ Recv RST_STREAM +-------+ 706 | Data |--- (optional) --->| Reset | 707 | Recvd | Recv All Data | Recvd | 708 +-------+<-- (optional) ----+-------+ 709 | | 710 | App Read All Data | App Read RST 711 v v 712 +-------+ +-------+ 713 | Data | | Reset | 714 | Read | | Read | 715 +-------+ +-------+ 717 Figure 2: States for Receive Streams 719 The receiving part of a stream initiated by a peer (types 1 and 3 for 720 a client, or 0 and 2 for a server) are created when the first STREAM, 721 STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only, 722 see below) is received for that stream. The initial state for a 723 receive stream is "Recv". Receiving a RST_STREAM frame causes the 724 receive stream to immediately transition to the "Reset Recvd". 726 The receive stream enters the "Recv" state when the sending part of a 727 bidirectional stream initiated by the endpoint (type 0 for a client, 728 type 1 for a server) enters the "Ready" state. 730 A bidirectional stream also opens when a MAX_STREAM_DATA frame is 731 received. Receiving a MAX_STREAM_DATA frame implies that the remote 732 peer has opened the stream and is providing flow control credit. A 733 MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED 734 frame if packets are lost or reordered. 736 Before creating a stream, all lower-numbered streams of the same type 737 MUST be created. That means that receipt of a frame that would open 738 a stream causes all lower-numbered streams of the same type to be 739 opened in numeric order. This ensures that the creation order for 740 streams is consistent on both endpoints. 742 In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED 743 frames. Incoming data is buffered and can be reassembled into the 744 correct order for delivery to the application. As data is consumed 745 by the application and buffer space becomes available, the endpoint 746 sends MAX_STREAM_DATA frames to allow the peer to send more data. 748 When a STREAM frame with a FIN bit is received, the final offset (see 749 Section 4.3) is known. The receive stream enters the "Size Known" 750 state. In this state, the endpoint no longer needs to send 751 MAX_STREAM_DATA frames, it only receives any retransmissions of 752 stream data. 754 Once all data for the stream has been received, the receive stream 755 enters the "Data Recvd" state. This might happen as a result of 756 receiving the same STREAM frame that causes the transition to "Size 757 Known". In this state, the endpoint has all stream data. Any STREAM 758 or STREAM_BLOCKED frames it receives for the stream can be discarded. 760 The "Data Recvd" state persists until stream data has been delivered 761 to the application or application protocol. Once stream data has 762 been delivered, the stream enters the "Data Read" state, which is a 763 terminal state. 765 Receiving a RST_STREAM frame in the "Recv" or "Size Known" states 766 causes the stream to enter the "Reset Recvd" state. This might cause 767 the delivery of stream data to the application to be interrupted. 769 It is possible that all stream data is received when a RST_STREAM is 770 received (that is, from the "Data Recvd" state). Similarly, it is 771 possible for remaining stream data to arrive after receiving a 772 RST_STREAM frame (the "Reset Recvd" state). An implementation is 773 able to manage this situation as they choose. Sending RST_STREAM 774 means that an endpoint cannot guarantee delivery of stream data; 775 however there is no requirement that stream data not be delivered if 776 a RST_STREAM is received. An implementation MAY interrupt delivery 777 of stream data, discard any data that was not consumed, and signal 778 the existence of the RST_STREAM immediately. Alternatively, the 779 RST_STREAM signal might be suppressed or withheld if stream data is 780 completely received. In the latter case, the receive stream 781 effectively transitions to "Data Recvd" from "Reset Recvd". 783 Once the application has been delivered the signal indicating that 784 the receive stream was reset, the receive stream transitions to the 785 "Reset Read" state, which is a terminal state. 787 3.3. Permitted Frame Types 789 The sender of a stream sends just three frame types that affect the 790 state of a stream at either sender or receiver: STREAM 791 (Section 19.19), STREAM_BLOCKED (Section 19.10), and RST_STREAM 792 (Section 19.2). 794 A sender MUST NOT send any of these frames from a terminal state 795 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 796 STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset 797 Sent" state in addition to the terminal states. A receiver could 798 receive any of these frames in any state, but only due to the 799 possibility of delayed delivery of packets carrying them. 801 The receiver of a stream sends MAX_STREAM_DATA (Section 19.6) and 802 STOP_SENDING frames (Section 19.14). 804 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 805 receiver can send STOP_SENDING in any state where it has not received 806 a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset 807 Read". However there is little value in sending a STOP_SENDING frame 808 after all stream data has been received in the "Data Recvd" state. A 809 sender could receive these frames in any state as a result of delayed 810 delivery of packets. 812 3.4. Bidirectional Stream States 814 A bidirectional stream is composed of a send stream and a receive 815 stream. Implementations may represent states of the bidirectional 816 stream as composites of send and receive stream states. The simplest 817 model presents the stream as "open" when either send or receive 818 stream is in a non-terminal state and "closed" when both send and 819 receive streams are in a terminal state. 821 Table 2 shows a more complex mapping of bidirectional stream states 822 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 823 shows that multiple states on send or receive streams are mapped to 824 the same composite state. Note that this is just one possibility for 825 such a mapping; this mapping requires that data is acknowledged 826 before the transition to a "closed" or "half-closed" state. 828 +-----------------------+---------------------+---------------------+ 829 | Send Stream | Receive Stream | Composite State | 830 +-----------------------+---------------------+---------------------+ 831 | No Stream/Ready | No Stream/Recv *1 | idle | 832 | | | | 833 | Ready/Send/Data Sent | Recv/Size Known | open | 834 | | | | 835 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 836 | | Read | (remote) | 837 | | | | 838 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 839 | | Read | (remote) | 840 | | | | 841 | Data Recvd | Recv/Size Known | half-closed (local) | 842 | | | | 843 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 844 | Recvd | | | 845 | | | | 846 | Data Recvd | Recv/Size Known | half-closed (local) | 847 | | | | 848 | Reset Sent/Reset | Data Recvd/Data | closed | 849 | Recvd | Read | | 850 | | | | 851 | Reset Sent/Reset | Reset Recvd/Reset | closed | 852 | Recvd | Read | | 853 | | | | 854 | Data Recvd | Data Recvd/Data | closed | 855 | | Read | | 856 | | | | 857 | Data Recvd | Reset Recvd/Reset | closed | 858 | | Read | | 859 +-----------------------+---------------------+---------------------+ 861 Table 2: Possible Mapping of Stream States to HTTP/2 863 Note (*1): A stream is considered "idle" if it has not yet been 864 created, or if the receive stream is in the "Recv" state without 865 yet having received any frames. 867 3.5. Solicited State Transitions 869 If an endpoint is no longer interested in the data it is receiving on 870 a stream, it MAY send a STOP_SENDING frame identifying that stream to 871 prompt closure of the stream in the opposite direction. This 872 typically indicates that the receiving application is no longer 873 reading data it receives from the stream, but is not a guarantee that 874 incoming data will be ignored. 876 STREAM frames received after sending STOP_SENDING are still counted 877 toward the connection and stream flow-control windows, even though 878 these frames will be discarded upon receipt. This avoids potential 879 ambiguity about which STREAM frames count toward flow control. 881 A STOP_SENDING frame requests that the receiving endpoint send a 882 RST_STREAM frame. An endpoint that receives a STOP_SENDING frame 883 MUST send a RST_STREAM frame for that stream, and can use an error 884 code of STOPPING. If the STOP_SENDING frame is received on a send 885 stream that is already in the "Data Sent" state, a RST_STREAM frame 886 MAY still be sent in order to cancel retransmission of previously- 887 sent STREAM frames. 889 STOP_SENDING SHOULD only be sent for a receive stream that has not 890 been reset. STOP_SENDING is most useful for streams in the "Recv" or 891 "Size Known" states. 893 An endpoint is expected to send another STOP_SENDING frame if a 894 packet containing a previous STOP_SENDING is lost. However, once 895 either all stream data or a RST_STREAM frame has been received for 896 the stream - that is, the stream is in any state other than "Recv" or 897 "Size Known" - sending a STOP_SENDING frame is unnecessary. 899 4. Flow Control 901 It is necessary to limit the amount of data that a sender may have 902 outstanding at any time, so as to prevent a fast sender from 903 overwhelming a slow receiver, or to prevent a malicious sender from 904 consuming significant resources at a receiver. To this end, QUIC 905 employs a credit-based flow-control scheme similar to that in HTTP/2 906 [HTTP2]. A receiver advertises the number of octets it is prepared 907 to receive on a given stream and for the entire connection. This 908 leads to two levels of flow control in QUIC: 910 o Stream flow control, which prevents a single stream from consuming 911 the entire receive buffer for a connection. 913 o Connection flow control, which prevents senders from exceeding a 914 receiver's buffer capacity for the connection, and 916 A data receiver sets initial credits for all streams by sending 917 transport parameters during the handshake (Section 7.3). 919 A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the 920 sender to advertise additional credit. MAX_STREAM_DATA frames send 921 the maximum absolute byte offset of a stream, while MAX_DATA frames 922 send the maximum of the sum of the absolute byte offsets of all 923 streams. 925 A receiver advertises credit for a stream by sending a 926 MAX_STREAM_DATA frame with the Stream ID set appropriately. A 927 receiver could use the current offset of data consumed to determine 928 the flow control offset to be advertised. A receiver MAY send 929 MAX_STREAM_DATA frames in multiple packets in order to make sure that 930 the sender receives an update before running out of flow control 931 credit, even if one of the packets is lost. 933 Connection flow control is a limit to the total bytes of stream data 934 sent in STREAM frames on all streams. A receiver advertises credit 935 for a connection by sending a MAX_DATA frame. A receiver maintains a 936 cumulative sum of bytes received on all contributing streams, which 937 are used to check for flow control violations. A receiver might use 938 a sum of bytes consumed on all streams to determine the maximum data 939 limit to be advertised. 941 A receiver MAY advertise a larger offset at any point by sending 942 MAX_STREAM_DATA or MAX_DATA frames. A receiver cannot renege on an 943 advertisement; that is, once a receiver advertises an offset, 944 advertising a smaller offset has no effect. A sender MUST therefore 945 ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase 946 flow control limits. 948 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 949 (Section 11) if the peer violates the advertised connection or stream 950 data limits. 952 A sender SHOULD send STREAM_BLOCKED or BLOCKED frames to indicate it 953 has data to write but is blocked by flow control limits. These 954 frames are expected to be sent infrequently in common cases, but they 955 are considered useful for debugging and monitoring purposes. 957 A similar method is used to control the number of open streams (see 958 Section 4.5 for details). 960 4.1. Handling of Stream Cancellation 962 There are some edge cases which must be considered when dealing with 963 stream and connection level flow control. Given enough time, both 964 endpoints must agree on flow control state. If one end believes it 965 can send more than the other end is willing to receive, the 966 connection will be torn down when too much data arrives. Conversely 967 if a sender believes it is blocked, while endpoint B expects more 968 data can be received, then the connection can be in a deadlock, with 969 the sender waiting for a MAX_STREAM_DATA or MAX_DATA frame which will 970 never come. 972 On receipt of a RST_STREAM frame, an endpoint will tear down state 973 for the matching stream and ignore further data arriving on that 974 stream. This could result in the endpoints getting out of sync, 975 since the RST_STREAM frame may have arrived out of order and there 976 may be further bytes in flight. The data sender would have counted 977 the data against its connection level flow control budget, but a 978 receiver that has not received these bytes would not know to include 979 them as well. The receiver must learn the number of bytes that were 980 sent on the stream to make the same adjustment in its connection flow 981 controller. 983 To ensure that endpoints maintain a consistent connection-level flow 984 control state, the RST_STREAM frame (Section 19.2) includes the 985 largest offset of data sent on the stream. On receiving a RST_STREAM 986 frame, a receiver definitively knows how many bytes were sent on that 987 stream before the RST_STREAM frame, and the receiver MUST use the 988 final offset to account for all bytes sent on the stream in its 989 connection level flow controller. 991 RST_STREAM terminates one direction of a stream abruptly. Whether 992 any action or response can or should be taken on the data already 993 received is application specific. 995 For a bidirectional stream, RST_STREAM has no effect on data flow in 996 the opposite direction. The RST_STREAM sender can send a 997 STOP_SENDING frame to encourage prompt termination. Both endpoints 998 MUST maintain state for the stream in the unterminated direction 999 until that direction enters a terminal state, or either side sends 1000 CONNECTION_CLOSE or APPLICATION_CLOSE. 1002 4.2. Data Limit Increments 1004 This document leaves when and how many bytes to advertise in a 1005 MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few 1006 considerations. These frames contribute to connection overhead. 1007 Therefore frequently sending frames with small changes is 1008 undesirable. At the same time, larger increments to limits are 1009 necessary to avoid blocking if updates are less frequent, requiring 1010 larger resource commitments at the receiver. Thus there is a trade- 1011 off between resource commitment and overhead when determining how 1012 large a limit is advertised. 1014 A receiver MAY use an autotuning mechanism to tune the frequency and 1015 amount that it increases data limits based on a round-trip time 1016 estimate and the rate at which the receiving application consumes 1017 data, similar to common TCP implementations. 1019 If a sender runs out of flow control credit, it will be unable to 1020 send new data. That is, the sender is blocked. A blocked sender 1021 SHOULD send a STREAM_BLOCKED or BLOCKED frame. A receiver uses these 1022 frames for debugging purposes. A receiver MUST NOT wait for a 1023 STREAM_BLOCKED or BLOCKED frame before sending MAX_STREAM_DATA or 1024 MAX_DATA, since doing so will mean that a sender will be blocked for 1025 an entire round trip and the peer may never send a STREAM_BLOCKED or 1026 BLOCKED frame. 1028 It is generally considered best to not let the sender go into 1029 quiescence if avoidable. To avoid blocking a sender, and to 1030 reasonably account for the possibility of loss, a receiver should 1031 send a MAX_DATA or MAX_STREAM_DATA frame at least two round trips 1032 before it expects the sender to get blocked. 1034 A sender sends a single BLOCKED or STREAM_BLOCKED frame only once 1035 when it reaches a data limit. A sender SHOULD NOT send multiple 1036 BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the 1037 original frame is determined to be lost. Another BLOCKED or 1038 STREAM_BLOCKED frame can be sent after the data limit is increased. 1040 4.3. Stream Final Offset 1042 The final offset is the count of the number of octets that are 1043 transmitted on a stream. For a stream that is reset, the final 1044 offset is carried explicitly in a RST_STREAM frame. Otherwise, the 1045 final offset is the offset of the end of the data carried in a STREAM 1046 frame marked with a FIN flag, or 0 in the case of incoming 1047 unidirectional streams. 1049 An endpoint will know the final offset for a stream when the receive 1050 stream enters the "Size Known" or "Reset Recvd" state. 1052 An endpoint MUST NOT send data on a stream at or beyond the final 1053 offset. 1055 Once a final offset for a stream is known, it cannot change. If a 1056 RST_STREAM or STREAM frame causes the final offset to change for a 1057 stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error 1058 (see Section 11). A receiver SHOULD treat receipt of data at or 1059 beyond the final offset as a FINAL_OFFSET_ERROR error, even after a 1060 stream is closed. Generating these errors is not mandatory, but only 1061 because requiring that an endpoint generate these errors also means 1062 that the endpoint needs to maintain the final offset state for closed 1063 streams, which could mean a significant state commitment. 1065 4.4. Flow Control for Cryptographic Handshake 1067 Data sent in CRYPTO frames is not flow controlled in the same way as 1068 STREAM frames. QUIC relies on the cryptographic protocol 1069 implementation to avoid excessive buffering of data, see [QUIC-TLS]. 1070 The implementation SHOULD provide an interface to QUIC to tell it 1071 about its buffering limits so that there is not excessive buffering 1072 at multiple layers. 1074 4.5. Stream Limit Increment 1076 An endpoint limits the number of concurrently active incoming streams 1077 by limiting the maximum stream ID. An initial value is set in the 1078 transport parameters (see Section 18.1) and is subsequently increased 1079 by MAX_STREAM_ID frames (see Section 19.7). 1081 As with stream and connection flow control, this document leaves when 1082 and how many streams to make available to a peer via MAX_STREAM_ID to 1083 implementations, but offers a few considerations. MAX_STREAM_ID 1084 frames constitute minimal overhead, while withholding MAX_STREAM_ID 1085 frames can prevent the peer from using the available parallelism. 1087 The STREAM_ID_BLOCKED frame (Section 19.11) can be used to signal a 1088 shortage of available streams. Implementations will likely want to 1089 increase the maximum stream ID as peer-initiated streams close. 1091 5. Connections 1093 A QUIC connection is a single conversation between two QUIC 1094 endpoints. QUIC's connection establishment combines version 1095 negotiation with the cryptographic and transport handshakes to reduce 1096 connection establishment latency, as described in Section 7. Once 1097 established, a connection may migrate to a different IP or port at 1098 either endpoint as described in Section 9. Finally, a connection may 1099 be terminated by either endpoint, as described in Section 10. 1101 5.1. Connection ID 1103 Each connection possesses a set of connection identifiers, or 1104 connection IDs, each of which can be identify the connection. 1105 Connection IDs are independently selected by endpoints; each endpoint 1106 selects the connection IDs that its peer uses. 1108 The primary function of a connection ID is to ensure that changes in 1109 addressing at lower protocol layers (UDP, IP, and below) don't cause 1110 packets for a QUIC connection to be delivered to the wrong endpoint. 1111 Each endpoint selects connection IDs using an implementation-specific 1112 (and perhaps deployment-specific) method which will allow packets 1113 with that connection ID to be routed back to the endpoint and 1114 identified by the endpoint upon receipt. 1116 Connection IDs MUST NOT contain any information that can be used to 1117 correlate them with other connection IDs for the same connection. As 1118 a trivial example, this means the same connection ID MUST NOT be 1119 issued more than once on the same connection. 1121 Packets with long headers include Source Connection ID and 1122 Destination Connection ID fields. These fields are used to set the 1123 connection IDs for new connections, see Section 7.2 for details. 1125 Packets with short headers (Section 17.3) only include the 1126 Destination Connection ID and omit the explicit length. The length 1127 of the Destination Connection ID field is expected to be known to 1128 endpoints. Endpoints using a load balancer that routes based on 1129 connection ID could agree with the load balancer on a fixed length 1130 for connection IDs, or agree on an encoding scheme. A fixed portion 1131 could encode an explicit length, which allows the entire connection 1132 ID to vary in length and still be used by the load balancer. 1134 A Version Negotiation (Section 17.4) packet echoes the connection IDs 1135 selected by the client, both to ensure correct routing toward the 1136 client and to allow the client to validate that the packet is in 1137 response to an Initial packet. 1139 A zero-length connection ID MAY be used when the connection ID is not 1140 needed for routing and the address/port tuple of packets is 1141 sufficient to identify a connection. An endpoint whose peer has 1142 selected a zero-length connection ID MUST continue to use a zero- 1143 length connection ID for the lifetime of the connection and MUST NOT 1144 send packets from any other local address. 1146 When an endpoint has requested a non-zero-length connection ID, it 1147 needs to ensure that the peer has a supply of connection IDs from 1148 which to choose for packets sent to the endpoint. These connection 1149 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1150 (Section 19.12). 1152 5.1.1. Issuing Connection IDs 1154 Each Connection ID has an associated sequence number to assist in 1155 deduplicating messages. The initial connection ID issued by an 1156 endpoint is sent in the Source Connection ID field of the long packet 1157 header (Section 17.2) during the handshake. The sequence number of 1158 the initial connection ID is 0. If the preferred_address transport 1159 parameter is sent, the sequence number of the supplied connection ID 1160 is 1. 1162 Additional connection IDs are communicated to the peer using 1163 NEW_CONNECTION_ID frames (Section 19.12). The sequence number on 1164 each newly-issued connection ID MUST increase by 1. The connection 1165 ID randomly selected by the client in the Initial packet and any 1166 connection ID provided by a Reset packet are not assigned sequence 1167 numbers unless a server opts to retain them as its initial connection 1168 ID. 1170 When an endpoint issues a connection ID, it MUST accept packets that 1171 carry this connection ID for the duration of the connection or until 1172 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1173 frame (Section 19.13). 1175 An endpoint SHOULD ensure that its peer has a sufficient number of 1176 available and unused connection IDs. While each endpoint 1177 independently chooses how many connection IDs to issue, endpoints 1178 SHOULD provide and maintain at least eight connection IDs. The 1179 endpoint can do this by always supplying a new connection ID when a 1180 connection ID is retired by its peer or when the endpoint receives a 1181 packet with a previously unused connection ID. Endpoints that 1182 initiate migration and require non-zero-length connection IDs SHOULD 1183 provide their peers with new connection IDs before migration, or risk 1184 the peer closing the connection. 1186 5.1.2. Consuming and Retiring Connection IDs 1188 An endpoint can change the connection ID it uses for a peer to 1189 another available one at any time during the connection. An endpoint 1190 consumes connection IDs in response to a migrating peer, see 1191 Section 9.5 for more. 1193 An endpoint maintains a set of connection IDs received from its peer, 1194 any of which it can use when sending packets. When the endpoint 1195 wishes to remove a connection ID from use, it sends a 1196 RETIRE_CONNECTION_ID frame to its peer, indicating that the peer 1197 might bring a new connection ID into circulation using the 1198 NEW_CONNECTION_ID frame. 1200 An endpoint that retires a connection ID can retain knowledge of that 1201 connection ID for a period of time after sending the 1202 RETIRE_CONNECTION_ID frame, or until that frame is acknowledged. 1204 As discussed in Section 9.5, each connection ID MUST be used on 1205 packets sent from only one local address. An endpoint that migrates 1206 away from a local address SHOULD retire all connection IDs used on 1207 that address once it no longer plans to use that address. 1209 5.2. Matching Packets to Connections 1211 Incoming packets are classified on receipt. Packets can either be 1212 associated with an existing connection, or - for servers - 1213 potentially create a new connection. 1215 Hosts try to associate a packet with an existing connection. If the 1216 packet has a Destination Connection ID corresponding to an existing 1217 connection, QUIC processes that packet accordingly. Note that more 1218 than one connection ID can be associated with a connection; see 1219 Section 5.1. 1221 If the Destination Connection ID is zero length and the packet 1222 matches the address/port tuple of a connection where the host did not 1223 require connection IDs, QUIC processes the packet as part of that 1224 connection. Endpoints MUST drop packets with zero-length Destination 1225 Connection ID fields if they do not correspond to a single 1226 connection. 1228 Endpoints SHOULD send a Stateless Reset (Section 10.4) for any 1229 packets that cannot be attributed to an existing connection. 1231 Packets that are matched to an existing connection, but for which the 1232 endpoint cannot remove packet protection, are discarded. 1234 5.2.1. Client Packet Handling 1236 Valid packets sent to clients always include a Destination Connection 1237 ID that matches a value the client selects. Clients that choose to 1238 receive zero-length connection IDs can use the address/port tuple to 1239 identify a connection. Packets that don't match an existing 1240 connection are discarded. 1242 Due to packet reordering or loss, clients might receive packets for a 1243 connection that are encrypted with a key it has not yet computed. 1244 Clients MAY drop these packets, or MAY buffer them in anticipation of 1245 later packets that allow it to compute the key. 1247 If a client receives a packet that has an unsupported version, it 1248 MUST discard that packet. 1250 5.2.2. Server Packet Handling 1252 If a server receives a packet that has an unsupported version, but 1253 the packet is sufficiently large to initiate a new connection for any 1254 version supported by the server, it SHOULD send a Version Negotiation 1255 packet as described in Section 6.1. Servers MAY rate control these 1256 packets to avoid storms of Version Negotiation packets. 1258 The first packet for an unsupported version can use different 1259 semantics and encodings for any version-specific field. In 1260 particular, different packet protection keys might be used for 1261 different versions. Servers that do not support a particular version 1262 are unlikely to be able to decrypt the payload of the packet. 1263 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1264 unknown version, but instead send a Version Negotiation packet, 1265 provided that the packet is sufficiently long. 1267 Servers MUST drop other packets that contain unsupported versions. 1269 Packets with a supported version, or no version field, are matched to 1270 a connection using the connection ID or - for packets with zero- 1271 length connection IDs - the address tuple. If the packet doesn't 1272 match an existing connection, the server continues below. 1274 If the packet is an Initial packet fully conforming with the 1275 specification, the server proceeds with the handshake (Section 7). 1276 This commits the server to the version that the client selected. 1278 If a server isn't currently accepting any new connections, it SHOULD 1279 send an Initial packet containing a CONNECTION_CLOSE frame with error 1280 code SERVER_BUSY. 1282 If the packet is a 0-RTT packet, the server MAY buffer a limited 1283 number of these packets in anticipation of a late-arriving Initial 1284 Packet. Clients are forbidden from sending Handshake packets prior 1285 to receiving a server response, so servers SHOULD ignore any such 1286 packets. 1288 Servers MUST drop incoming packets under all other circumstances. 1290 5.3. Life of a QUIC Connection 1292 TBD. 1294 6. Version Negotiation 1296 Version negotiation ensures that client and server agree to a QUIC 1297 version that is mutually supported. A server sends a Version 1298 Negotiation packet in response to each packet that might initiate a 1299 new connection, see Section 5.2 for details. 1301 The first few messages of an exchange between a client attempting to 1302 create a new connection with server is shown in Figure 3. After 1303 version negotiation completes, connection establishment can proceed, 1304 for example as shown in Section 7.1. 1306 Client Server 1308 Packet (v=X) -> 1310 <- Version Negotiation (supported=Y,Z) 1312 Packet (v=Y) -> 1314 <- Packet(s) (v=Y) 1316 Figure 3: Example Version Negotiation Exchange 1318 The size of the first packet sent by a client will determine whether 1319 a server sends a Version Negotiation packet. Clients that support 1320 multiple QUIC versions SHOULD pad the first packet they send to the 1321 largest of the minimum packet sizes across all versions they support. 1322 This ensures that the server responds if there is a mutually 1323 supported version. 1325 6.1. Sending Version Negotiation Packets 1327 If the version selected by the client is not acceptable to the 1328 server, the server responds with a Version Negotiation packet (see 1329 Section 17.4). This includes a list of versions that the server will 1330 accept. 1332 This system allows a server to process packets with unsupported 1333 versions without retaining state. Though either the Initial packet 1334 or the Version Negotiation packet that is sent in response could be 1335 lost, the client will send new packets until it successfully receives 1336 a response or it abandons the connection attempt. 1338 A server MAY limit the number of Version Negotiation packets it 1339 sends. For instance, a server that is able to recognize packets as 1340 0-RTT might choose not to send Version Negotiation packets in 1341 response to 0-RTT packets with the expectation that it will 1342 eventually receive an Initial packet. 1344 6.2. Handling Version Negotiation Packets 1346 When the client receives a Version Negotiation packet, it first 1347 checks that the Destination and Source Connection ID fields match the 1348 Source and Destination Connection ID fields in a packet that the 1349 client sent. If this check fails, the packet MUST be discarded. 1351 Once the Version Negotiation packet is determined to be valid, the 1352 client then selects an acceptable protocol version from the list 1353 provided by the server. The client then attempts to create a 1354 connection using that version. Though the content of the Initial 1355 packet the client sends might not change in response to version 1356 negotiation, a client MUST increase the packet number it uses on 1357 every packet it sends. Packets MUST continue to use long headers 1358 (Section 17.2) and MUST include the new negotiated protocol version. 1360 The client MUST use the long header format and include its selected 1361 version on all packets until it has 1-RTT keys and it has received a 1362 packet from the server which is not a Version Negotiation packet. 1364 A client MUST NOT change the version it uses unless it is in response 1365 to a Version Negotiation packet from the server. Once a client 1366 receives a packet from the server which is not a Version Negotiation 1367 packet, it MUST discard other Version Negotiation packets on the same 1368 connection. Similarly, a client MUST ignore a Version Negotiation 1369 packet if it has already received and acted on a Version Negotiation 1370 packet. 1372 A client MUST ignore a Version Negotiation packet that lists the 1373 client's chosen version. 1375 A client MAY attempt 0-RTT after receiving a Version Negotiation 1376 packet. A client that sends additional 0-RTT packets MUST NOT reset 1377 the packet number to 0 as a result, see Section 17.5.2. 1379 Version negotiation packets have no cryptographic protection. The 1380 result of the negotiation MUST be revalidated as part of the 1381 cryptographic handshake (see Section 7.3.3). 1383 6.3. Using Reserved Versions 1385 For a server to use a new version in the future, clients must 1386 correctly handle unsupported versions. To help ensure this, a server 1387 SHOULD include a reserved version (see Section 15) while generating a 1388 Version Negotiation packet. 1390 The design of version negotiation permits a server to avoid 1391 maintaining state for packets that it rejects in this fashion. The 1392 validation of version negotiation (see Section 7.3.3) only validates 1393 the result of version negotiation, which is the same no matter which 1394 reserved version was sent. A server MAY therefore send different 1395 reserved version numbers in the Version Negotiation Packet and in its 1396 transport parameters. 1398 A client MAY send a packet using a reserved version number. This can 1399 be used to solicit a list of supported versions from a server. 1401 7. Cryptographic and Transport Handshake 1403 QUIC relies on a combined cryptographic and transport handshake to 1404 minimize connection establishment latency. QUIC uses the CRYPTO 1405 frame Section 19.20 to transmit the cryptographic handshake. Version 1406 0x00000001 of QUIC uses TLS 1.3 as described in [QUIC-TLS]; a 1407 different QUIC version number could indicate that a different 1408 cryptographic handshake protocol is in use. 1410 QUIC provides reliable, ordered delivery of the cryptographic 1411 handshake data. QUIC packet protection ensures confidentiality and 1412 integrity protection that meets the requirements of the cryptographic 1413 handshake protocol: 1415 o authenticated key exchange, where 1417 * a server is always authenticated, 1419 * a client is optionally authenticated, 1421 * every connection produces distinct and unrelated keys, 1423 * keying material is usable for packet protection for both 0-RTT 1424 and 1-RTT packets, and 1426 * 1-RTT keys have forward secrecy 1428 o authenticated values for the transport parameters of the peer (see 1429 Section 7.3) 1431 o authenticated confirmation of version negotiation (see 1432 Section 7.3.3) 1434 o authenticated negotiation of an application protocol (TLS uses 1435 ALPN [RFC7301] for this purpose) 1437 The first CRYPTO frame from a client MUST be sent in a single packet. 1438 Any second attempt that is triggered by address validation (see 1439 Section 8.1) MUST also be sent within a single packet. This avoids 1440 having to reassemble a message from multiple packets. 1442 The first client packet of the cryptographic handshake protocol MUST 1443 fit within a 1232 octet QUIC packet payload. This includes overheads 1444 that reduce the space available to the cryptographic handshake 1445 protocol. 1447 The CRYPTO frame can be sent in different packet number spaces. The 1448 sequence numbers used by CRYPTO frames to ensure ordered delivery of 1449 cryptographic handshake data start from zero in each packet number 1450 space. 1452 7.1. Example Handshake Flows 1454 Details of how TLS is integrated with QUIC are provided in 1455 [QUIC-TLS], but some examples are provided here. An extension of 1456 this exchange to support client address validation is shown in 1457 Section 8.1.1. 1459 Once any version negotiation and address validation exchanges are 1460 complete, the cryptographic handshake is used to agree on 1461 cryptographic keys. The cryptographic handshake is carried in 1462 Initial (Section 17.5) and Handshake (Section 17.6) packets. 1464 Figure 4 provides an overview of the 1-RTT handshake. Each line 1465 shows a QUIC packet with the packet type and packet number shown 1466 first, followed by the frames that are typically contained in those 1467 packets. So, for instance the first packet is of type Initial, with 1468 packet number 0, and contains a CRYPTO frame carrying the 1469 ClientHello. 1471 Note that multiple QUIC packets - even of different encryption levels 1472 - may be coalesced into a single UDP datagram (see Section 12.2), and 1473 so this handshake may consist of as few as 4 UDP datagrams, or any 1474 number more. For instance, the server's first flight contains 1475 packets from the Initial encryption level (obfuscation), the 1476 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1477 encryption level. 1479 Client Server 1481 Initial[0]: CRYPTO[CH] -> 1483 Initial[0]: CRYPTO[SH] ACK[0] 1484 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1485 <- 1-RTT[0]: STREAM[1, "..."] 1487 Initial[1]: ACK[0] 1488 Handshake[0]: CRYPTO[FIN], ACK[0] 1489 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1491 1-RTT[1]: STREAM[55, "..."], ACK[0] 1492 <- Handshake[1]: ACK[0] 1494 Figure 4: Example 1-RTT Handshake 1496 Figure 5 shows an example of a connection with a 0-RTT handshake and 1497 a single packet of 0-RTT data. Note that as described in 1498 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1499 encryption level, and the client sends 1-RTT packets in the same 1500 packet number space. 1502 Client Server 1504 Initial[0]: CRYPTO[CH] 1505 0-RTT[0]: STREAM[0, "..."] -> 1507 Initial[0]: CRYPTO[SH] ACK[0] 1508 Handshake[0] CRYPTO[EE, CERT, CV, FIN] 1509 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1511 Initial[1]: ACK[0] 1512 Handshake[0]: CRYPTO[FIN], ACK[0] 1513 1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1515 1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1516 <- Handshake[1]: ACK[0] 1518 Figure 5: Example 0-RTT Handshake 1520 7.2. Negotiating Connection IDs 1522 A connection ID is used to ensure consistent routing of packets, as 1523 described in Section 5.1. The long header contains two connection 1524 IDs: the Destination Connection ID is chosen by the recipient of the 1525 packet and is used to provide consistent routing; the Source 1526 Connection ID is used to set the Destination Connection ID used by 1527 the peer. 1529 During the handshake, packets with the long header (Section 17.2) are 1530 used to establish the connection ID that each endpoint uses. Each 1531 endpoint uses the Source Connection ID field to specify the 1532 connection ID that is used in the Destination Connection ID field of 1533 packets being sent to them. Upon receiving a packet, each endpoint 1534 sets the Destination Connection ID it sends to match the value of the 1535 Source Connection ID that they receive. 1537 When an Initial packet is sent by a client which has not previously 1538 received a Retry packet from the server, it populates the Destination 1539 Connection ID field with an unpredictable value. This MUST be at 1540 least 8 octets in length. Until a packet is received from the 1541 server, the client MUST use the same value unless it abandons the 1542 connection attempt and starts a new one. The initial Destination 1543 Connection ID is used to determine packet protection keys for Initial 1544 packets. 1546 The client populates the Source Connection ID field with a value of 1547 its choosing and sets the SCIL field to match. 1549 The Destination Connection ID field in the server's Initial packet 1550 contains a connection ID that is chosen by the recipient of the 1551 packet (i.e., the client); the Source Connection ID includes the 1552 connection ID that the sender of the packet wishes to use (see 1553 Section 5.1). The server MUST use consistent Source Connection IDs 1554 during the handshake. 1556 On first receiving an Initial or Retry packet from the server, the 1557 client uses the Source Connection ID supplied by the server as the 1558 Destination Connection ID for subsequent packets. That means that a 1559 client might change the Destination Connection ID twice during 1560 connection establishment. Once a client has received an Initial 1561 packet from the server, it MUST discard any packet it receives with a 1562 different Source Connection ID. 1564 A client MUST only change the value it sends in the Destination 1565 Connection ID in response to the first packet of each type it 1566 receives from the server (Retry or Initial); a server MUST set its 1567 value based on the Initial packet. Any additional changes are not 1568 permitted; if subsequent packets of those types include a different 1569 Source Connection ID, they MUST be discarded. This avoids problems 1570 that might arise from stateless processing of multiple Initial 1571 packets producing different connection IDs. 1573 The connection ID can change over the lifetime of a connection, 1574 especially in response to connection migration (Section 9), see 1575 Section 5.1.1 for details. 1577 7.3. Transport Parameters 1579 During connection establishment, both endpoints make authenticated 1580 declarations of their transport parameters. These declarations are 1581 made unilaterally by each endpoint. Endpoints are required to comply 1582 with the restrictions implied by these parameters; the description of 1583 each parameter includes rules for its handling. 1585 The encoding of the transport parameters is detailed in Section 18. 1587 QUIC includes the encoded transport parameters in the cryptographic 1588 handshake. Once the handshake completes, the transport parameters 1589 declared by the peer are available. Each endpoint validates the 1590 value provided by its peer. In particular, version negotiation MUST 1591 be validated (see Section 7.3.3) before the connection establishment 1592 is considered properly complete. 1594 Definitions for each of the defined transport parameters are included 1595 in Section 18.1. Any given parameter MUST appear at most once in a 1596 given transport parameters extension. An endpoint MUST treat receipt 1597 of duplicate transport parameters as a connection error of type 1598 TRANSPORT_PARAMETER_ERROR. 1600 A server MUST include the original_connection_id transport parameter 1601 (Section 18.1) if it sent a Retry packet. 1603 7.3.1. Values of Transport Parameters for 0-RTT 1605 A client that attempts to send 0-RTT data MUST remember the transport 1606 parameters used by the server. The transport parameters that the 1607 server advertises during connection establishment apply to all 1608 connections that are resumed using the keying material established 1609 during that handshake. Remembered transport parameters apply to the 1610 new connection until the handshake completes and new transport 1611 parameters from the server can be provided. 1613 A server can remember the transport parameters that it advertised, or 1614 store an integrity-protected copy of the values in the ticket and 1615 recover the information when accepting 0-RTT data. A server uses the 1616 transport parameters in determining whether to accept 0-RTT data. 1618 A server MAY accept 0-RTT and subsequently provide different values 1619 for transport parameters for use in the new connection. If 0-RTT 1620 data is accepted by the server, the server MUST NOT reduce any limits 1621 or alter any values that might be violated by the client with its 1622 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1623 set values for initial_max_data, initial_max_stream_data_bidi_local, 1624 initial_max_stream_data_bidi_remote, initial_max_stream_data_uni, 1625 initial_max_bidi_streams, or initial_max_uni_streams (Section 18.1) 1626 that are smaller than the remembered value of those parameters. 1628 Omitting or setting a zero value for certain transport parameters can 1629 result in 0-RTT data being enabled, but not usable. The applicable 1630 subset of transport parameters that permit sending of application 1631 data SHOULD be set to non-zero values for 0-RTT. This includes 1632 initial_max_data and either initial_max_bidi_streams and 1633 initial_max_stream_data_bidi_remote, or initial_max_uni_streams and 1634 initial_max_stream_data_uni. 1636 The value of the server's previous preferred_address MUST NOT be used 1637 when establishing a new connection; rather, the client should wait to 1638 observe the server's new preferred_address value in the handshake. 1640 A server MUST reject 0-RTT data or even abort a handshake if the 1641 implied values for transport parameters cannot be supported. 1643 7.3.2. New Transport Parameters 1645 New transport parameters can be used to negotiate new protocol 1646 behavior. An endpoint MUST ignore transport parameters that it does 1647 not support. Absence of a transport parameter therefore disables any 1648 optional protocol feature that is negotiated using the parameter. 1650 New transport parameters can be registered according to the rules in 1651 Section 22.1. 1653 7.3.3. Version Negotiation Validation 1655 Though the cryptographic handshake has integrity protection, two 1656 forms of QUIC version downgrade are possible. In the first, an 1657 attacker replaces the QUIC version in the Initial packet. In the 1658 second, a fake Version Negotiation packet is sent by an attacker. To 1659 protect against these attacks, the transport parameters include three 1660 fields that encode version information. These parameters are used to 1661 retroactively authenticate the choice of version (see Section 6). 1663 The cryptographic handshake provides integrity protection for the 1664 negotiated version as part of the transport parameters (see 1665 Section 18.1). As a result, attacks on version negotiation by an 1666 attacker can be detected. 1668 The client includes the initial_version field in its transport 1669 parameters. The initial_version is the version that the client 1670 initially attempted to use. If the server did not send a Version 1671 Negotiation packet Section 17.4, this will be identical to the 1672 negotiated_version field in the server transport parameters. 1674 A server that processes all packets in a stateful fashion can 1675 remember how version negotiation was performed and validate the 1676 initial_version value. 1678 A server that does not maintain state for every packet it receives 1679 (i.e., a stateless server) uses a different process. If the 1680 initial_version matches the version of QUIC that is in use, a 1681 stateless server can accept the value. 1683 If the initial_version is different from the version of QUIC that is 1684 in use, a stateless server MUST check that it would have sent a 1685 Version Negotiation packet if it had received a packet with the 1686 indicated initial_version. If a server would have accepted the 1687 version included in the initial_version and the value differs from 1688 the QUIC version that is in use, the server MUST terminate the 1689 connection with a VERSION_NEGOTIATION_ERROR error. 1691 The server includes both the version of QUIC that is in use and a 1692 list of the QUIC versions that the server supports (see 1693 Section 18.1). 1695 The negotiated_version field is the version that is in use. This 1696 MUST be set by the server to the value that is on the Initial packet 1697 that it accepts (not an Initial packet that triggers a Retry or 1698 Version Negotiation packet). A client that receives a 1699 negotiated_version that does not match the version of QUIC that is in 1700 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 1701 error code. 1703 The server includes a list of versions that it would send in any 1704 version negotiation packet (Section 17.4) in the supported_versions 1705 field. The server populates this field even if it did not send a 1706 version negotiation packet. 1708 The client validates that the negotiated_version is included in the 1709 supported_versions list and - if version negotiation was performed - 1710 that it would have selected the negotiated version. A client MUST 1711 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 1712 if the current QUIC version is not listed in the supported_versions 1713 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 1714 code if version negotiation occurred but it would have selected a 1715 different version based on the value of the supported_versions list. 1717 When an endpoint accepts multiple QUIC versions, it can potentially 1718 interpret transport parameters as they are defined by any of the QUIC 1719 versions it supports. The version field in the QUIC packet header is 1720 authenticated using transport parameters. The position and the 1721 format of the version fields in transport parameters MUST either be 1722 identical across different QUIC versions, or be unambiguously 1723 different to ensure no confusion about their interpretation. One way 1724 that a new format could be introduced is to define a TLS extension 1725 with a different codepoint. 1727 8. Address Validation 1729 Address validation is used by QUIC to avoid being used for a traffic 1730 amplification attack. In such an attack, a packet is sent to a 1731 server with spoofed source address information that identifies a 1732 victim. If a server generates more or larger packets in response to 1733 that packet, the attacker can use the server to send more data toward 1734 the victim than it would be able to send on its own. 1736 The primary defense against amplification attack is verifying that an 1737 endpoint is able to receive packets at the transport address that it 1738 claims. Address validation is performed both during connection 1739 establishment (see Section 8.1) and during connection migration (see 1740 Section 8.2). 1742 8.1. Address Validation During Connection Establishment 1744 Connection establishment implicitly provides address validation for 1745 both endpoints. In particular, receipt of a packet protected with 1746 Handshake keys confirms that the client received the Initial packet 1747 from the server. Once the server has successfully processed a 1748 Handshake packet from the client, it can consider the client address 1749 to have been validated. 1751 Prior to validating the client address, servers MUST NOT send more 1752 than three times as many bytes as the number of bytes they have 1753 received. This limits the magnitude of any amplification attack that 1754 can be mounted using spoofed source addresses. 1756 To ensure that the server is not overly constrained by this 1757 restriction, clients MUST send UDP datagrams with at least 1200 1758 octets of payload until the server has completed address validation, 1759 see Section 14. 1761 In order to prevent a handshake deadlock as a result of the server 1762 being unable to send, clients SHOULD send a packet upon a handshake 1763 timeout, as described in [QUIC-RECOVERY]. If the client has no data 1764 to retransmit and does not have Handshake keys, it SHOULD send an 1765 Initial packet in a UDP datagram of at least 1200 octets. If the 1766 client has Handshake keys, it SHOULD send a Handshake packet. 1768 A server might wish to validate the client address before starting 1769 the cryptographic handshake. Client addresses can be verified using 1770 an address validation token. This token is delivered during 1771 connection establishment with a Retry packet (see Section 8.1.1) or 1772 in a previous connection using the NEW_TOKEN frame (see 1773 Section 8.1.2). 1775 8.1.1. Address Validation using Retry Packets 1777 QUIC uses token-based address validation during connection 1778 establishment. Any time the server wishes to validate a client 1779 address, it provides the client with a token. As long as it is not 1780 possible for an attacker to generate a valid token for its own 1781 address (see Section 8.1.3) and the client is able to return that 1782 token, it proves to the server that it received the token. 1784 Upon receiving the client's Initial packet, the server can request 1785 address validation by sending a Retry packet (Section 17.7) 1786 containing a token. This token is repeated by the client in an 1787 Initial packet after it receives the Retry packet. In response to 1788 receiving a token in an Initial packet, a server can either abort the 1789 connection or permit it to proceed. 1791 A server can also use a Retry packet to defer the state and 1792 processing costs of connection establishment. By giving the client a 1793 different connection ID to use, a server can cause the connection to 1794 be routed to a server instance with more resources available for new 1795 connections. 1797 A flow showing the use of a Retry packet is shown in Figure 6. 1799 Client Server 1801 Initial[0]: CRYPTO[CH] -> 1803 <- Retry+Token 1805 Initial+Token[0]: CRYPTO[CH] -> 1807 Initial[0]: CRYPTO[SH] ACK[0] 1808 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1809 <- 1-RTT[0]: STREAM[1, "..."] 1811 Figure 6: Example Handshake with Retry 1813 8.1.2. Address Validation for Future Connections 1815 A server MAY provide clients with an address validation token during 1816 one connection that can be used on a subsequent connection. Address 1817 validation is especially important with 0-RTT because a server 1818 potentially sends a significant amount of data to a client in 1819 response to 0-RTT data. 1821 The server uses the NEW_TOKEN frame Section 19.18 to provide the 1822 client with an address validation token that can be used to validate 1823 future connections. The client may then use this token to validate 1824 future connections by including it in the Initial packet's header. 1825 The client MUST NOT use the token provided in a Retry for future 1826 connections. 1828 Unlike the token that is created for a Retry packet, there might be 1829 some time between when the token is created and when the token is 1830 subsequently used. Thus, a resumption token SHOULD include an 1831 expiration time. The server MAY include either an explicit 1832 expiration time or an issued timestamp and dynamically calculate the 1833 expiration time. It is also unlikely that the client port number is 1834 the same on two different connections; validating the port is 1835 therefore unlikely to be successful. 1837 A resumption token SHOULD be constructed to be easily distinguishable 1838 from tokens that are sent in Retry packets as they are carried in the 1839 same field. 1841 If the client has a token received in a NEW_TOKEN frame on a previous 1842 connection to what it believes to be the same server, it can include 1843 that value in the Token field of its Initial packet. 1845 A token allows a server to correlate activity between the connection 1846 where the token was issued and any connection where it is used. 1847 Clients that want to break continuity of identity with a server MAY 1848 discard tokens provided using the NEW_TOKEN frame. Tokens obtained 1849 in Retry packets MUST NOT be discarded. 1851 A client SHOULD NOT reuse a token. Reusing a token allows 1852 connections to be linked by entities on the network path (see 1853 Section 9.5). A client MUST NOT reuse a token if it believes that 1854 its point of network attachment has changed since the token was last 1855 used; that is, if there is a change in its local IP address or 1856 network interface. A client needs to start the connection process 1857 over if it migrates prior to completing the handshake. 1859 When a server receives an Initial packet with an address validation 1860 token, it SHOULD attempt to validate it. If the token is invalid 1861 then the server SHOULD proceed as if the client did not have a 1862 validated address, including potentially sending a Retry. If the 1863 validation succeeds, the server SHOULD then allow the handshake to 1864 proceed. 1866 Note: The rationale for treating the client as unvalidated rather 1867 than discarding the packet is that the client might have received 1868 the token in a previous connection using the NEW_TOKEN frame, and 1869 if the server has lost state, it might be unable to validate the 1870 token at all, leading to connection failure if the packet is 1871 discarded. A server MAY encode tokens provided with NEW_TOKEN 1872 frames and Retry packets differently, and validate the latter more 1873 strictly. 1875 In a stateless design, a server can use encrypted and authenticated 1876 tokens to pass information to clients that the server can later 1877 recover and use to validate a client address. Tokens are not 1878 integrated into the cryptographic handshake and so they are not 1879 authenticated. For instance, a client might be able to reuse a 1880 token. To avoid attacks that exploit this property, a server can 1881 limit its use of tokens to only the information needed validate 1882 client addresses. 1884 8.1.3. Address Validation Token Integrity 1886 An address validation token MUST be difficult to guess. Including a 1887 large enough random value in the token would be sufficient, but this 1888 depends on the server remembering the value it sends to clients. 1890 A token-based scheme allows the server to offload any state 1891 associated with validation to the client. For this design to work, 1892 the token MUST be covered by integrity protection against 1893 modification or falsification by clients. Without integrity 1894 protection, malicious clients could generate or guess values for 1895 tokens that would be accepted by the server. Only the server 1896 requires access to the integrity protection key for tokens. 1898 There is no need for a single well-defined format for the token 1899 because the server that generates the token also consumes it. A 1900 token could include information about the claimed client address (IP 1901 and port), a timestamp, and any other supplementary information the 1902 server will need to validate the token in the future. 1904 8.2. Path Validation 1906 Path validation is used during connection migration (see Section 9 1907 and Section 9.6) by the migrating endpoint to verify reachability of 1908 a peer from a new local address. In path validation, endpoints test 1909 reachability between a specific local address and a specific peer 1910 address, where an address is the two-tuple of IP address and port. 1912 Path validation tests that packets can be both sent to and received 1913 from a peer on the path. Importantly, it validates that the packets 1914 received from the migrating endpoint do not carry a spoofed source 1915 address. 1917 Path validation can be used at any time by either endpoint. For 1918 instance, an endpoint might check that a peer is still in possession 1919 of its address after a period of quiescence. 1921 Path validation is not designed as a NAT traversal mechanism. Though 1922 the mechanism described here might be effective for the creation of 1923 NAT bindings that support NAT traversal, the expectation is that one 1924 or other peer is able to receive packets without first having sent a 1925 packet on that path. Effective NAT traversal needs additional 1926 synchronization mechanisms that are not provided here. 1928 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 1929 are used for path validation with other frames. In particular, an 1930 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 1931 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 1932 PATH_CHALLENGE. 1934 When probing a new path, an endpoint might want to ensure that its 1935 peer has an unused connection ID available for responses. The 1936 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 1937 same packet. This ensures that an unused connection ID will be 1938 available to the peer when sending a response. 1940 8.3. Initiating Path Validation 1942 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 1943 containing a random payload on the path to be validated. 1945 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 1946 packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more 1947 frequently than it would an Initial packet, ensuring that connection 1948 migration is no more load on a new path than establishing a new 1949 connection. 1951 The endpoint MUST use fresh random data in every PATH_CHALLENGE frame 1952 so that it can associate the peer's response with the causative 1953 PATH_CHALLENGE. 1955 8.4. Path Validation Responses 1957 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 1958 immediately by echoing the data contained in the PATH_CHALLENGE frame 1959 in a PATH_RESPONSE frame. However, because a PATH_CHALLENGE might be 1960 sent from a spoofed address, an endpoint MUST limit the rate at which 1961 it sends PATH_RESPONSE frames and MAY silently discard PATH_CHALLENGE 1962 frames that would cause it to respond at a higher rate. 1964 To ensure that packets can be both sent to and received from the 1965 peer, the PATH_RESPONSE MUST be sent on the same path as the 1966 triggering PATH_CHALLENGE. That is, from the same local address on 1967 which the PATH_CHALLENGE was received, to the same remote address 1968 from which the PATH_CHALLENGE was received. 1970 8.5. Successful Path Validation 1972 A new address is considered valid when a PATH_RESPONSE frame is 1973 received containing data that was sent in a previous PATH_CHALLENGE. 1974 Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE 1975 frame is not adequate validation, since the acknowledgment can be 1976 spoofed by a malicious peer. 1978 For path validation to be successful, a PATH_RESPONSE frame MUST be 1979 received from the same remote address to which the corresponding 1980 PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a 1981 different remote address than the one to which the PATH_CHALLENGE was 1982 sent, path validation is considered to have failed, even if the data 1983 matches that sent in the PATH_CHALLENGE. 1985 Additionally, the PATH_RESPONSE frame MUST be received on the same 1986 local address from which the corresponding PATH_CHALLENGE was sent. 1987 If a PATH_RESPONSE frame is received on a different local address 1988 than the one from which the PATH_CHALLENGE was sent, path validation 1989 is considered to have failed, even if the data matches that sent in 1990 the PATH_CHALLENGE. Thus, the endpoint considers the path to be 1991 valid when a PATH_RESPONSE frame is received on the same path with 1992 the same payload as the PATH_CHALLENGE frame. 1994 8.6. Failed Path Validation 1996 Path validation only fails when the endpoint attempting to validate 1997 the path abandons its attempt to validate the path. 1999 Endpoints SHOULD abandon path validation based on a timer. When 2000 setting this timer, implementations are cautioned that the new path 2001 could have a longer round-trip time than the original. 2003 Note that the endpoint might receive packets containing other frames 2004 on the new path, but a PATH_RESPONSE frame with appropriate data is 2005 required for path validation to succeed. 2007 When an endpoint abandons path validation, it determines that the 2008 path is unusable. This does not necessarily imply a failure of the 2009 connection - endpoints can continue sending packets over other paths 2010 as appropriate. If no paths are available, an endpoint can wait for 2011 a new path to become available or close the connection. 2013 A path validation might be abandoned for other reasons besides 2014 failure. Primarily, this happens if a connection migration to a new 2015 path is initiated while a path validation on the old path is in 2016 progress. 2018 9. Connection Migration 2020 The use of a connection ID allows connections to survive changes to 2021 endpoint addresses (that is, IP address and/or port), such as those 2022 caused by an endpoint migrating to a new network. This section 2023 describes the process by which an endpoint migrates to a new address. 2025 An endpoint MUST NOT initiate connection migration before the 2026 handshake is finished and the endpoint has 1-RTT keys. The design of 2027 QUIC relies on endpoints retaining a stable address for the duration 2028 of the handshake. 2030 An endpoint also MUST NOT initiate connection migration if the peer 2031 sent the "disable_migration" transport parameter during the 2032 handshake. An endpoint which has sent this transport parameter, but 2033 detects that a peer has nonetheless migrated to a different network 2034 MAY treat this as a connection error of type INVALID_MIGRATION. 2036 Not all changes of peer address are intentional migrations. The peer 2037 could experience NAT rebinding: a change of address due to a 2038 middlebox, usually a NAT, allocating a new outgoing port or even a 2039 new outgoing IP address for a flow. NAT rebinding is not connection 2040 migration as defined in this section, though an endpoint SHOULD 2041 perform path validation (Section 8.2) if it detects a change in the 2042 IP address of its peer. 2044 This document limits migration of connections to new client 2045 addresses, except as described in Section 9.6. Clients are 2046 responsible for initiating all migrations. Servers do not send non- 2047 probing packets (see Section 9.1) toward a client address until they 2048 see a non-probing packet from that address. If a client receives 2049 packets from an unknown server address, the client MAY discard these 2050 packets. 2052 9.1. Probing a New Path 2054 An endpoint MAY probe for peer reachability from a new local address 2055 using path validation Section 8.2 prior to migrating the connection 2056 to the new local address. Failure of path validation simply means 2057 that the new path is not usable for this connection. Failure to 2058 validate a path does not cause the connection to end unless there are 2059 no valid alternative paths available. 2061 An endpoint uses a new connection ID for probes sent from a new local 2062 address, see Section 9.5 for further discussion. An endpoint that 2063 uses a new local address needs to ensure that at least one new 2064 connection ID is available at the peer. That can be achieved by 2065 including a NEW_CONNECTION_ID frame in the probe. 2067 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2068 is probing for reachability on a path. An endpoint sends a 2069 PATH_RESPONSE in response as per Section 8.2. 2071 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2072 are "probing frames", and all other frames are "non-probing frames". 2073 A packet containing only probing frames is a "probing packet", and a 2074 packet containing any other frame is a "non-probing packet". 2076 9.2. Initiating Connection Migration 2078 An endpoint can migrate a connection to a new local address by 2079 sending packets containing non-probing frames from that address. 2081 Each endpoint validates its peer's address during connection 2082 establishment. Therefore, a migrating endpoint can send to its peer 2083 knowing that the peer is willing to receive at the peer's current 2084 address. Thus an endpoint can migrate to a new local address without 2085 first validating the peer's address. 2087 When migrating, the new path might not support the endpoint's current 2088 sending rate. Therefore, the endpoint resets its congestion 2089 controller, as described in Section 9.4. 2091 The new path might not have the same ECN capability. Therefore, the 2092 endpoint verifies ECN capability as described in Section 13.3. 2094 Receiving acknowledgments for data sent on the new path serves as 2095 proof of the peer's reachability from the new address. Note that 2096 since acknowledgments may be received on any path, return 2097 reachability on the new path is not established. To establish return 2098 reachability on the new path, an endpoint MAY concurrently initiate 2099 path validation Section 8.2 on the new path. 2101 9.3. Responding to Connection Migration 2103 Receiving a packet from a new peer address containing a non-probing 2104 frame indicates that the peer has migrated to that address. 2106 In response to such a packet, an endpoint MUST start sending 2107 subsequent packets to the new peer address and MUST initiate path 2108 validation (Section 8.2) to verify the peer's ownership of the 2109 unvalidated address. 2111 An endpoint MAY send data to an unvalidated peer address, but it MUST 2112 protect against potential attacks as described in Section 9.3.1 and 2113 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2114 that address has been seen recently. 2116 An endpoint only changes the address that it sends packets to in 2117 response to the highest-numbered non-probing packet. This ensures 2118 that an endpoint does not send packets to an old peer address in the 2119 case that it receives reordered packets. 2121 After changing the address to which it sends non-probing packets, an 2122 endpoint could abandon any path validation for other addresses. 2124 Receiving a packet from a new peer address might be the result of a 2125 NAT rebinding at the peer. 2127 After verifying a new client address, the server SHOULD send new 2128 address validation tokens (Section 8) to the client. 2130 9.3.1. Handling Address Spoofing by a Peer 2132 It is possible that a peer is spoofing its source address to cause an 2133 endpoint to send excessive amounts of data to an unwilling host. If 2134 the endpoint sends significantly more data than the spoofing peer, 2135 connection migration might be used to amplify the volume of data that 2136 an attacker can generate toward a victim. 2138 As described in Section 9.3, an endpoint is required to validate a 2139 peer's new address to confirm the peer's possession of the new 2140 address. Until a peer's address is deemed valid, an endpoint MUST 2141 limit the rate at which it sends data to this address. The endpoint 2142 MUST NOT send more than a minimum congestion window's worth of data 2143 per estimated round-trip time (kMinimumWindow, as defined in 2144 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2145 being used for a denial of service attack against an unsuspecting 2146 victim. Note that since the endpoint will not have any round-trip 2147 time measurements to this address, the estimate SHOULD be the default 2148 initial value (see [QUIC-RECOVERY]). 2150 If an endpoint skips validation of a peer address as described in 2151 Section 9.3, it does not need to limit its sending rate. 2153 9.3.2. Handling Address Spoofing by an On-path Attacker 2155 An on-path attacker could cause a spurious connection migration by 2156 copying and forwarding a packet with a spoofed address such that it 2157 arrives before the original packet. The packet with the spoofed 2158 address will be seen to come from a migrating connection, and the 2159 original packet will be seen as a duplicate and dropped. After a 2160 spurious migration, validation of the source address will fail 2161 because the entity at the source address does not have the necessary 2162 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2163 that is sent to it even if it wanted to. 2165 To protect the connection from failing due to such a spurious 2166 migration, an endpoint MUST revert to using the last validated peer 2167 address when validation of a new peer address fails. 2169 If an endpoint has no state about the last validated peer address, it 2170 MUST close the connection silently by discarding all connection 2171 state. This results in new packets on the connection being handled 2172 generically. For instance, an endpoint MAY send a stateless reset in 2173 response to any further incoming packets. 2175 Note that receipt of packets with higher packet numbers from the 2176 legitimate peer address will trigger another connection migration. 2177 This will cause the validation of the address of the spurious 2178 migration to be abandoned. 2180 9.4. Loss Detection and Congestion Control 2182 The capacity available on the new path might not be the same as the 2183 old path. Packets sent on the old path SHOULD NOT contribute to 2184 congestion control or RTT estimation for the new path. 2186 On confirming a peer's ownership of its new address, an endpoint 2187 SHOULD immediately reset the congestion controller and round-trip 2188 time estimator for the new path. 2190 An endpoint MUST NOT return to the send rate used for the previous 2191 path unless it is reasonably sure that the previous send rate is 2192 valid for the new path. For instance, a change in the client's port 2193 number is likely indicative of a rebinding in a middlebox and not a 2194 complete change in path. This determination likely depends on 2195 heuristics, which could be imperfect; if the new path capacity is 2196 significantly reduced, ultimately this relies on the congestion 2197 controller responding to congestion signals and reducing send rates 2198 appropriately. 2200 There may be apparent reordering at the receiver when an endpoint 2201 sends data and probes from/to multiple addresses during the migration 2202 period, since the two resulting paths may have different round-trip 2203 times. A receiver of packets on multiple paths will still send ACK 2204 frames covering all received packets. 2206 While multiple paths might be used during connection migration, a 2207 single congestion control context and a single loss recovery context 2208 (as described in [QUIC-RECOVERY]) may be adequate. A sender can make 2209 exceptions for probe packets so that their loss detection is 2210 independent and does not unduly cause the congestion controller to 2211 reduce its sending rate. An endpoint might set a separate timer when 2212 a PATH_CHALLENGE is sent, which is cancelled when the corresponding 2213 PATH_RESPONSE is received. If the timer fires before the 2214 PATH_RESPONSE is received, the endpoint might send a new 2215 PATH_CHALLENGE, and restart the timer for a longer period of time. 2217 9.5. Privacy Implications of Connection Migration 2219 Using a stable connection ID on multiple network paths allows a 2220 passive observer to correlate activity between those paths. An 2221 endpoint that moves between networks might not wish to have their 2222 activity correlated by any entity other than their peer, so different 2223 connection IDs are used when sending from different local addresses, 2224 as discussed in Section 5.1. For this to be effective endpoints need 2225 to ensure that connections IDs they provide cannot be linked by any 2226 other entity. 2228 This eliminates the use of the connection ID for linking activity 2229 from the same connection on different networks. Protection of packet 2230 numbers ensures that packet numbers cannot be used to correlate 2231 activity. This does not prevent other properties of packets, such as 2232 timing and size, from being used to correlate activity. 2234 Clients MAY move to a new connection ID at any time based on 2235 implementation-specific concerns. For example, after a period of 2236 network inactivity NAT rebinding might occur when the client begins 2237 sending data again. 2239 A client might wish to reduce linkability by employing a new 2240 connection ID and source UDP port when sending traffic after a period 2241 of inactivity. Changing the UDP port from which it sends packets at 2242 the same time might cause the packet to appear as a connection 2243 migration. This ensures that the mechanisms that support migration 2244 are exercised even for clients that don't experience NAT rebindings 2245 or genuine migrations. Changing port number can cause a peer to 2246 reset its congestion state (see Section 9.4), so the port SHOULD only 2247 be changed infrequently. 2249 Endpoints that use connection IDs with length greater than zero could 2250 have their activity correlated if their peers keep using the same 2251 destination connection ID after migration. Endpoints that receive 2252 packets with a previously unused Destination Connection ID SHOULD 2253 change to sending packets with a connection ID that has not been used 2254 on any other network path. The goal here is to ensure that packets 2255 sent on different paths cannot be correlated. To fulfill this 2256 privacy requirement, endpoints that initiate migration and use 2257 connection IDs with length greater than zero SHOULD provide their 2258 peers with new connection IDs before migration. 2260 Caution: If both endpoints change connection ID in response to 2261 seeing a change in connection ID from their peer, then this can 2262 trigger an infinite sequence of changes. 2264 9.6. Server's Preferred Address 2266 QUIC allows servers to accept connections on one IP address and 2267 attempt to transfer these connections to a more preferred address 2268 shortly after the handshake. This is particularly useful when 2269 clients initially connect to an address shared by multiple servers 2270 but would prefer to use a unicast address to ensure connection 2271 stability. This section describes the protocol for migrating a 2272 connection to a preferred server address. 2274 Migrating a connection to a new server address mid-connection is left 2275 for future work. If a client receives packets from a new server 2276 address not indicated by the preferred_address transport parameter, 2277 the client SHOULD discard these packets. 2279 9.6.1. Communicating A Preferred Address 2281 A server conveys a preferred address by including the 2282 preferred_address transport parameter in the TLS handshake. 2284 Once the handshake is finished, the client SHOULD initiate path 2285 validation (see Section 8.2) of the server's preferred address using 2286 the connection ID provided in the preferred_address transport 2287 parameter. 2289 If path validation succeeds, the client SHOULD immediately begin 2290 sending all future packets to the new server address using the new 2291 connection ID and discontinue use of the old server address. If path 2292 validation fails, the client MUST continue sending all future packets 2293 to the server's original IP address. 2295 9.6.2. Responding to Connection Migration 2297 A server might receive a packet addressed to its preferred IP address 2298 at any time after it accepts a connection. If this packet contains a 2299 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2300 Section 8.2. The server MAY send other non-probing frames from its 2301 preferred address, but MUST continue sending all probing packets from 2302 its original IP address. 2304 The server SHOULD also initiate path validation of the client using 2305 its preferred address and the address from which it received the 2306 client probe. This helps to guard against spurious migration 2307 initiated by an attacker. 2309 Once the server has completed its path validation and has received a 2310 non-probing packet with a new largest packet number on its preferred 2311 address, the server begins sending non-probing packets to the client 2312 exclusively from its preferred IP address. It SHOULD drop packets 2313 for this connection received on the old IP address, but MAY continue 2314 to process delayed packets. 2316 9.6.3. Interaction of Client Migration and Preferred Address 2318 A client might need to perform a connection migration before it has 2319 migrated to the server's preferred address. In this case, the client 2320 SHOULD perform path validation to both the original and preferred 2321 server address from the client's new address concurrently. 2323 If path validation of the server's preferred address succeeds, the 2324 client MUST abandon validation of the original address and migrate to 2325 using the server's preferred address. If path validation of the 2326 server's preferred address fails but validation of the server's 2327 original address succeeds, the client MAY migrate to its new address 2328 and continue sending to the server's original address. 2330 If the connection to the server's preferred address is not from the 2331 same client address, the server MUST protect against potential 2332 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2333 to intentional simultaneous migration, this might also occur because 2334 the client's access network used a different NAT binding for the 2335 server's preferred address. 2337 Servers SHOULD initiate path validation to the client's new address 2338 upon receiving a probe packet from a different address. Servers MUST 2339 NOT send more than a minimum congestion window's worth of non-probing 2340 packets to the new address before path validation is complete. 2342 10. Connection Termination 2344 Connections should remain open until they become idle for a pre- 2345 negotiated period of time. A QUIC connection, once established, can 2346 be terminated in one of three ways: 2348 o idle timeout (Section 10.2) 2350 o immediate close (Section 10.3) 2352 o stateless reset (Section 10.4) 2354 10.1. Closing and Draining Connection States 2356 The closing and draining connection states exist to ensure that 2357 connections close cleanly and that delayed or reordered packets are 2358 properly discarded. These states SHOULD persist for three times the 2359 current Retransmission Timeout (RTO) interval as defined in 2360 [QUIC-RECOVERY]. 2362 An endpoint enters a closing period after initiating an immediate 2363 close (Section 10.3). While closing, an endpoint MUST NOT send 2364 packets unless they contain a CONNECTION_CLOSE or APPLICATION_CLOSE 2365 frame (see Section 10.3 for details). An endpoint retains only 2366 enough information to generate a packet containing a closing frame 2367 and to identify packets as belonging to the connection. The 2368 connection ID and QUIC version is sufficient information to identify 2369 packets for a closing connection; an endpoint can discard all other 2370 connection state. An endpoint MAY retain packet protection keys for 2371 incoming packets to allow it to read and process a closing frame. 2373 The draining state is entered once an endpoint receives a signal that 2374 its peer is closing or draining. While otherwise identical to the 2375 closing state, an endpoint in the draining state MUST NOT send any 2376 packets. Retaining packet protection keys is unnecessary once a 2377 connection is in the draining state. 2379 An endpoint MAY transition from the closing period to the draining 2380 period if it can confirm that its peer is also closing or draining. 2381 Receiving a closing frame is sufficient confirmation, as is receiving 2382 a stateless reset. The draining period SHOULD end when the closing 2383 period would have ended. In other words, the endpoint can use the 2384 same end time, but cease retransmission of the closing packet. 2386 Disposing of connection state prior to the end of the closing or 2387 draining period could cause delayed or reordered packets to be 2388 handled poorly. Endpoints that have some alternative means to ensure 2389 that late-arriving packets on the connection do not create QUIC 2390 state, such as those that are able to close the UDP socket, MAY use 2391 an abbreviated draining period which can allow for faster resource 2392 recovery. Servers that retain an open socket for accepting new 2393 connections SHOULD NOT exit the closing or draining period early. 2395 Once the closing or draining period has ended, an endpoint SHOULD 2396 discard all connection state. This results in new packets on the 2397 connection being handled generically. For instance, an endpoint MAY 2398 send a stateless reset in response to any further incoming packets. 2400 The draining and closing periods do not apply when a stateless reset 2401 (Section 10.4) is sent. 2403 An endpoint is not expected to handle key updates when it is closing 2404 or draining. A key update might prevent the endpoint from moving 2405 from the closing state to draining, but it otherwise has no impact. 2407 An endpoint could receive packets from a new source address, 2408 indicating a client connection migration (Section 9), while in the 2409 closing period. An endpoint in the closing state MUST strictly limit 2410 the number of packets it sends to this new address until the address 2411 is validated (see Section 8.2). A server in the closing state MAY 2412 instead choose to discard packets received from a new source address. 2414 10.2. Idle Timeout 2416 If the idle timeout is enabled, a connection that remains idle for 2417 longer than the advertised idle timeout (see Section 18.1) is closed. 2418 A connection enters the draining state when the idle timeout expires. 2420 Each endpoint advertises its own idle timeout to its peer. The idle 2421 timeout starts from the last packet received. In order to ensure 2422 that initiating new activity postpones an idle timeout, an endpoint 2423 restarts this timer when sending a packet. An endpoint does not 2424 postpone the idle timeout if another packet has been sent containing 2425 frames other than ACK or PADDING, and that other packet has not been 2426 acknowledged or declared lost. Packets that contain only ACK or 2427 PADDING frames are not acknowledged until an endpoint has other 2428 frames to send, so they could prevent the timeout from being 2429 refreshed. 2431 The value for an idle timeout can be asymmetric. The value 2432 advertised by an endpoint is only used to determine whether the 2433 connection is live at that endpoint. An endpoint that sends packets 2434 near the end of the idle timeout period of a peer risks having those 2435 packets discarded if its peer enters the draining state before the 2436 packets arrive. If a peer could timeout within an RTO (see 2437 Section 4.3.3 of [QUIC-RECOVERY]), it is advisable to test for 2438 liveness before sending any data that cannot be retried safely. 2440 10.3. Immediate Close 2442 An endpoint sends a closing frame (CONNECTION_CLOSE or 2443 APPLICATION_CLOSE) to terminate the connection immediately. Any 2444 closing frame causes all streams to immediately become closed; open 2445 streams can be assumed to be implicitly reset. 2447 After sending a closing frame, endpoints immediately enter the 2448 closing state. During the closing period, an endpoint that sends a 2449 closing frame SHOULD respond to any packet that it receives with 2450 another packet containing a closing frame. To minimize the state 2451 that an endpoint maintains for a closing connection, endpoints MAY 2452 send the exact same packet. However, endpoints SHOULD limit the 2453 number of packets they generate containing a closing frame. For 2454 instance, an endpoint could progressively increase the number of 2455 packets that it receives before sending additional packets or 2456 increase the time between packets. 2458 Note: Allowing retransmission of a packet contradicts other advice 2459 in this document that recommends the creation of new packet 2460 numbers for every packet. Sending new packet numbers is primarily 2461 of advantage to loss recovery and congestion control, which are 2462 not expected to be relevant for a closed connection. 2463 Retransmitting the final packet requires less state. 2465 After receiving a closing frame, endpoints enter the draining state. 2466 An endpoint that receives a closing frame MAY send a single packet 2467 containing a closing frame before entering the draining state, using 2468 a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An 2469 endpoint MUST NOT send further packets, which could result in a 2470 constant exchange of closing frames until the closing period on 2471 either peer ended. 2473 An immediate close can be used after an application protocol has 2474 arranged to close a connection. This might be after the application 2475 protocols negotiates a graceful shutdown. The application protocol 2476 exchanges whatever messages that are needed to cause both endpoints 2477 to agree to close the connection, after which the application 2478 requests that the connection be closed. The application protocol can 2479 use an APPLICATION_CLOSE message with an appropriate error code to 2480 signal closure. 2482 If the connection has been successfully established, endpoints MUST 2483 send any closing frames in a 1-RTT packet. Prior to connection 2484 establishment a peer might not have 1-RTT keys, so endpoints SHOULD 2485 send closing frames in a Handshake packet. If the endpoint does not 2486 have Handshake keys, or it is not certain that the peer has Handshake 2487 keys, it MAY send closing frames in an Initial packet. If multiple 2488 packets are sent, they can be coalesced (see Section 12.2) to 2489 facilitate retransmission. 2491 10.4. Stateless Reset 2493 A stateless reset is provided as an option of last resort for an 2494 endpoint that does not have access to the state of a connection. A 2495 crash or outage might result in peers continuing to send data to an 2496 endpoint that is unable to properly continue the connection. An 2497 endpoint that wishes to communicate a fatal connection error MUST use 2498 a closing frame if it has sufficient state to do so. 2500 To support this process, a token is sent by endpoints. The token is 2501 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2502 servers can specify the stateless_reset_token transport parameter 2503 during the handshake (clients cannot because their transport 2504 parameters don't have confidentiality protection). This value is 2505 protected by encryption, so only client and server know this value. 2506 Tokens sent via NEW_CONNECTION_ID frames are invalidated when their 2507 associated connection ID is retired via a RETIRE_CONNECTION_ID frame 2508 (Section 19.13). 2510 An endpoint that receives packets that it cannot process sends a 2511 packet in the following layout: 2513 0 1 2 3 2514 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 2515 +-+-+-+-+-+-+-+-+ 2516 |0|K|1|1|0|0|0|0| 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | Random Octets (160..) ... 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | | 2521 + + 2522 | | 2523 + Stateless Reset Token (128) + 2524 | | 2525 + + 2526 | | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 Figure 7: Stateless Reset Packet 2531 This design ensures that a stateless reset packet is - to the extent 2532 possible - indistinguishable from a regular packet with a short 2533 header. 2535 The message consists of a header octet, followed by an arbitrary 2536 number of random octets, followed by a Stateless Reset Token. 2538 A stateless reset will be interpreted by a recipient as a packet with 2539 a short header. For the packet to appear as valid, the Random Octets 2540 field needs to include at least 20 octets of random or unpredictable 2541 values. This is intended to allow for a destination connection ID of 2542 the maximum length permitted, a packet number, and minimal payload. 2543 The Stateless Reset Token corresponds to the minimum expansion of the 2544 packet protection AEAD. More random octets might be necessary if the 2545 endpoint could have negotiated a packet protection scheme with a 2546 larger minimum AEAD expansion. 2548 An endpoint SHOULD NOT send a stateless reset that is significantly 2549 larger than the packet it receives. Endpoints MUST discard packets 2550 that are too small to be valid QUIC packets. With the set of AEAD 2551 functions defined in [QUIC-TLS], packets less than 19 octets long are 2552 never valid. 2554 An endpoint MAY send a stateless reset in response to a packet with a 2555 long header. This would not be effective if the stateless reset 2556 token was not yet available to a peer. In this QUIC version, packets 2557 with a long header are only used during connection establishment. 2558 Because the stateless reset token is not available until connection 2559 establishment is complete or near completion, ignoring an unknown 2560 packet with a long header might be more effective. 2562 An endpoint cannot determine the Source Connection ID from a packet 2563 with a short header, therefore it cannot set the Destination 2564 Connection ID in the stateless reset packet. The Destination 2565 Connection ID will therefore differ from the value used in previous 2566 packets. A random Destination Connection ID makes the connection ID 2567 appear to be the result of moving to a new connection ID that was 2568 provided using a NEW_CONNECTION_ID frame (Section 19.12). 2570 Using a randomized connection ID results in two problems: 2572 o The packet might not reach the peer. If the Destination 2573 Connection ID is critical for routing toward the peer, then this 2574 packet could be incorrectly routed. This might also trigger 2575 another Stateless Reset in response, see Section 10.4.3. A 2576 Stateless Reset that is not correctly routed is ineffective in 2577 causing errors to be quickly detected and recovered. In this 2578 case, endpoints will need to rely on other methods - such as 2579 timers - to detect that the connection has failed. 2581 o The randomly generated connection ID can be used by entities other 2582 than the peer to identify this as a potential stateless reset. An 2583 endpoint that occasionally uses different connection IDs might 2584 introduce some uncertainty about this. 2586 Finally, the last 16 octets of the packet are set to the value of the 2587 Stateless Reset Token. 2589 A stateless reset is not appropriate for signaling error conditions. 2590 An endpoint that wishes to communicate a fatal connection error MUST 2591 use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has 2592 sufficient state to do so. 2594 This stateless reset design is specific to QUIC version 1. An 2595 endpoint that supports multiple versions of QUIC needs to generate a 2596 stateless reset that will be accepted by peers that support any 2597 version that the endpoint might support (or might have supported 2598 prior to losing state). Designers of new versions of QUIC need to be 2599 aware of this and either reuse this design, or use a portion of the 2600 packet other than the last 16 octets for carrying data. 2602 10.4.1. Detecting a Stateless Reset 2604 An endpoint detects a potential stateless reset when a packet with a 2605 short header either cannot be decrypted or is marked as a duplicate 2606 packet. The endpoint then compares the last 16 octets of the packet 2607 with the Stateless Reset Token provided by its peer, either in a 2608 NEW_CONNECTION_ID frame or the server's transport parameters. If 2609 these values are identical, the endpoint MUST enter the draining 2610 period and not send any further packets on this connection. If the 2611 comparison fails, the packet can be discarded. 2613 10.4.2. Calculating a Stateless Reset Token 2615 The stateless reset token MUST be difficult to guess. In order to 2616 create a Stateless Reset Token, an endpoint could randomly generate 2617 [RFC4086] a secret for every connection that it creates. However, 2618 this presents a coordination problem when there are multiple 2619 instances in a cluster or a storage problem for an endpoint that 2620 might lose state. Stateless reset specifically exists to handle the 2621 case where state is lost, so this approach is suboptimal. 2623 A single static key can be used across all connections to the same 2624 endpoint by generating the proof using a second iteration of a 2625 preimage-resistant function that takes a static key and the 2626 connection ID chosen by the endpoint (see Section 5.1) as input. An 2627 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2628 connection_id)) or HKDF [RFC5869] (for example, using the static key 2629 as input keying material, with the connection ID as salt). The 2630 output of this function is truncated to 16 octets to produce the 2631 Stateless Reset Token for that connection. 2633 An endpoint that loses state can use the same method to generate a 2634 valid Stateless Reset Token. The connection ID comes from the packet 2635 that the endpoint receives. 2637 This design relies on the peer always sending a connection ID in its 2638 packets so that the endpoint can use the connection ID from a packet 2639 to reset the connection. An endpoint that uses this design MUST 2640 either use the same connection ID length for all connections or 2641 encode the length of the connection ID such that it can be recovered 2642 without state. In addition, it cannot provide a zero-length 2643 connection ID. 2645 Revealing the Stateless Reset Token allows any entity to terminate 2646 the connection, so a value can only be used once. This method for 2647 choosing the Stateless Reset Token means that the combination of 2648 connection ID and static key cannot occur for another connection. A 2649 denial of service attack is possible if the same connection ID is 2650 used by instances that share a static key, or if an attacker can 2651 cause a packet to be routed to an instance that has no state but the 2652 same static key (see Section 21.8). A connection ID from a 2653 connection that is reset by revealing the Stateless Reset Token 2654 cannot be reused for new connections at nodes that share a static 2655 key. 2657 Note that Stateless Reset packets do not have any cryptographic 2658 protection. 2660 10.4.3. Looping 2662 The design of a Stateless Reset is such that it is indistinguishable 2663 from a valid packet. This means that a Stateless Reset might trigger 2664 the sending of a Stateless Reset in response, which could lead to 2665 infinite exchanges. 2667 An endpoint MUST ensure that every Stateless Reset that it sends is 2668 smaller than the packet which triggered it, unless it maintains state 2669 sufficient to prevent looping. In the event of a loop, this results 2670 in packets eventually being too small to trigger a response. 2672 An endpoint can remember the number of Stateless Reset packets that 2673 it has sent and stop generating new Stateless Reset packets once a 2674 limit is reached. Using separate limits for different remote 2675 addresses will ensure that Stateless Reset packets can be used to 2676 close connections when other peers or connections have exhausted 2677 limits. 2679 Reducing the size of a Stateless Reset below the recommended minimum 2680 size of 37 octets could mean that the packet could reveal to an 2681 observer that it is a Stateless Reset. Conversely, refusing to send 2682 a Stateless Reset in response to a small packet might result in 2683 Stateless Reset not being useful in detecting cases of broken 2684 connections where only very small packets are sent; such failures 2685 might only be detected by other means, such as timers. 2687 An endpoint can increase the odds that a packet will trigger a 2688 Stateless Reset if it cannot be processed by padding it to at least 2689 38 octets. 2691 11. Error Handling 2693 An endpoint that detects an error SHOULD signal the existence of that 2694 error to its peer. Both transport-level and application-level errors 2695 can affect an entire connection (see Section 11.1), while only 2696 application-level errors can be isolated to a single stream (see 2697 Section 11.2). 2699 The most appropriate error code (Section 20) SHOULD be included in 2700 the frame that signals the error. Where this specification 2701 identifies error conditions, it also identifies the error code that 2702 is used. 2704 A stateless reset (Section 10.4) is not suitable for any error that 2705 can be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or 2706 RST_STREAM frame. A stateless reset MUST NOT be used by an endpoint 2707 that has the state necessary to send a frame on the connection. 2709 11.1. Connection Errors 2711 Errors that result in the connection being unusable, such as an 2712 obvious violation of protocol semantics or corruption of state that 2713 affects an entire connection, MUST be signaled using a 2714 CONNECTION_CLOSE or APPLICATION_CLOSE frame (Section 19.3, 2715 Section 19.4). An endpoint MAY close the connection in this manner 2716 even if the error only affects a single stream. 2718 Application protocols can signal application-specific protocol errors 2719 using the APPLICATION_CLOSE frame. Errors that are specific to the 2720 transport, including all those described in this document, are 2721 carried in a CONNECTION_CLOSE frame. Other than the type of error 2722 code they carry, these frames are identical in format and semantics. 2724 A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a 2725 packet that is lost. An endpoint SHOULD be prepared to retransmit a 2726 packet containing either frame type if it receives more packets on a 2727 terminated connection. Limiting the number of retransmissions and 2728 the time over which this final packet is sent limits the effort 2729 expended on terminated connections. 2731 An endpoint that chooses not to retransmit packets containing 2732 CONNECTION_CLOSE or APPLICATION_CLOSE risks a peer missing the first 2733 such packet. The only mechanism available to an endpoint that 2734 continues to receive data for a terminated connection is to use the 2735 stateless reset process (Section 10.4). 2737 An endpoint that receives an invalid CONNECTION_CLOSE or 2738 APPLICATION_CLOSE frame MUST NOT signal the existence of the error to 2739 its peer. 2741 11.2. Stream Errors 2743 If an application-level error affects a single stream, but otherwise 2744 leaves the connection in a recoverable state, the endpoint can send a 2745 RST_STREAM frame (Section 19.2) with an appropriate error code to 2746 terminate just the affected stream. 2748 Other than STOPPING (Section 3.5), RST_STREAM MUST be instigated by 2749 the application and MUST carry an application error code. Resetting 2750 a stream without knowledge of the application protocol could cause 2751 the protocol to enter an unrecoverable state. Application protocols 2752 might require certain streams to be reliably delivered in order to 2753 guarantee consistent state between endpoints. 2755 12. Packets and Frames 2757 QUIC endpoints communicate by exchanging packets. Packets are 2758 carried in UDP datagrams (see Section 12.2) and have confidentiality 2759 and integrity protection (see Section 12.1). 2761 This version of QUIC uses the long packet header (see Section 17.2) 2762 during connection establishment and the short header (see 2763 Section 17.3) once 1-RTT keys have been established. 2765 Packets that carry the long header are Initial Section 17.5, Retry 2766 Section 17.7, Handshake Section 17.6, and 0-RTT Protected packets 2767 Section 12.1. 2769 Packets with the short header are designed for minimal overhead and 2770 are used after a connection is established. 2772 Version negotiation uses a packet with a special format (see 2773 Section 17.4). 2775 12.1. Protected Packets 2777 All QUIC packets except Version Negotiation and Retry packets use 2778 authenticated encryption with additional data (AEAD) [RFC5119] to 2779 provide confidentiality and integrity protection. Details of packet 2780 protection are found in [QUIC-TLS]; this section includes an overview 2781 of the process. 2783 Initial packets are protected using keys that are statically derived. 2784 This packet protection is not effective confidentiality protection, 2785 it only exists to ensure that the sender of the packet is on the 2786 network path. Any entity that receives the Initial packet from a 2787 client can recover the keys necessary to remove packet protection or 2788 to generate packets that will be successfully authenticated. 2790 All other packets are protected with keys derived from the 2791 cryptographic handshake. The type of the packet from the long header 2792 or key phase from the short header are used to identify which 2793 encryption level - and therefore the keys - that are used. Packets 2794 protected with 0-RTT and 1-RTT keys are expected to have 2795 confidentiality and data origin authentication; the cryptographic 2796 handshake ensures that only the communicating endpoints receive the 2797 corresponding keys. 2799 The packet number field contains a packet number, which has 2800 additional confidentiality protection that is applied after packet 2801 protection is applied (see [QUIC-TLS] for details). The underlying 2802 packet number increases with each packet sent, see Section 12.3 for 2803 details. 2805 12.2. Coalescing Packets 2807 A sender can coalesce multiple QUIC packets into one UDP datagram. 2808 This can reduce the number of UDP datagrams needed to complete the 2809 cryptographic handshake and starting sending data. Receivers MUST be 2810 able to process coalesced packets. 2812 Coalescing packets in order of increasing encryption levels (Initial, 2813 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 2814 able to process all the packets in a single pass. A packet with a 2815 short header does not include a length, so it will always be the last 2816 packet included in a UDP datagram. 2818 Senders MUST NOT coalesce QUIC packets for different connections into 2819 a single UDP datagram. Receivers SHOULD ignore any subsequent 2820 packets with a different Destination Connection ID than the first 2821 packet in the datagram. 2823 Every QUIC packet that is coalesced into a single UDP datagram is 2824 separate and complete. Though the values of some fields in the 2825 packet header might be redundant, no fields are omitted. The 2826 receiver of coalesced QUIC packets MUST individually process each 2827 QUIC packet and separately acknowledge them, as if they were received 2828 as the payload of different UDP datagrams. For example, if 2829 decryption fails (because the keys are not available or any other 2830 reason) or the packet is of an unknown type, the receiver MAY either 2831 discard or buffer the packet for later processing and MUST attempt to 2832 process the remaining packets. 2834 Retry packets (Section 17.7), Version Negotiation packets 2835 (Section 17.4), and packets with a short header cannot be followed by 2836 other packets in the same UDP datagram. 2838 12.3. Packet Numbers 2840 The packet number is an integer in the range 0 to 2^62-1. Where 2841 present, packet numbers are encoded as a variable-length integer (see 2842 Section 16). This number is used in determining the cryptographic 2843 nonce for packet protection. Each endpoint maintains a separate 2844 packet number for sending and receiving. 2846 Version Negotiation (Section 17.4) and Retry Section 17.7 packets do 2847 not include a packet number. 2849 Packet numbers are divided into 3 spaces in QUIC: 2851 o Initial space: All Initial packets Section 17.5 are in this space. 2853 o Handshake space: All Handshake packets Section 17.6 are in this 2854 space. 2856 o Application data space: All 0-RTT and 1-RTT encrypted packets 2857 Section 12.1 are in this space. 2859 As described in [QUIC-TLS], each packet type uses different 2860 protection keys. 2862 Conceptually, a packet number space is the context in which a packet 2863 can be processed and acknowledged. Initial packets can only be sent 2864 with Initial packet protection keys and acknowledged in packets which 2865 are also Initial packets. Similarly, Handshake packets are sent at 2866 the Handshake encryption level and can only be acknowledged in 2867 Handshake packets. 2869 This enforces cryptographic separation between the data sent in the 2870 different packet sequence number spaces. Each packet number space 2871 starts at packet number 0. Subsequent packets sent in the same 2872 packet number space MUST increase the packet number by at least one. 2874 0-RTT and 1-RTT data exist in the same packet number space to make 2875 loss recovery algorithms easier to implement between the two packet 2876 types. 2878 A QUIC endpoint MUST NOT reuse a packet number within the same packet 2879 number space in one connection (that is, under the same cryptographic 2880 keys). If the packet number for sending reaches 2^62 - 1, the sender 2881 MUST close the connection without sending a CONNECTION_CLOSE frame or 2882 any further packets; an endpoint MAY send a Stateless Reset 2883 (Section 10.4) in response to further packets that it receives. 2885 A receiver MUST discard a newly unprotected packet unless it is 2886 certain that it has not processed another packet with the same packet 2887 number from the same packet number space. Duplicate suppression MUST 2888 happen after removing packet protection for the reasons described in 2889 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 2890 suppression can be found in Section 3.4.3 of [RFC2406]. 2892 Packet number encoding at a sender and decoding at a receiver are 2893 described in Section 17.1. 2895 12.4. Frames and Frame Types 2897 The payload of QUIC packets, after removing packet protection, 2898 commonly consists of a sequence of frames, as shown in Figure 8. 2899 Version Negotiation, Stateless Reset, and Retry packets do not 2900 contain frames. 2902 0 1 2 3 2903 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 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 | Frame 1 (*) ... 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 | Frame 2 (*) ... 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 ... 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 | Frame N (*) ... 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 Figure 8: QUIC Payload 2916 QUIC payloads MUST contain at least one frame, and MAY contain 2917 multiple frames and multiple frame types. 2919 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 2920 packet boundary. Each frame begins with a Frame Type, indicating its 2921 type, followed by additional type-dependent fields: 2923 0 1 2 3 2924 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 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 | Frame Type (i) ... 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | Type-Dependent Fields (*) ... 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 Figure 9: Generic Frame Layout 2933 The frame types defined in this specification are listed in Table 3. 2934 The Frame Type in STREAM frames is used to carry other frame-specific 2935 flags. For all other frames, the Frame Type field simply identifies 2936 the frame. These frames are explained in more detail in Section 19. 2938 +-------------+----------------------+---------------+ 2939 | Type Value | Frame Type Name | Definition | 2940 +-------------+----------------------+---------------+ 2941 | 0x00 | PADDING | Section 19.1 | 2942 | | | | 2943 | 0x01 | RST_STREAM | Section 19.2 | 2944 | | | | 2945 | 0x02 | CONNECTION_CLOSE | Section 19.3 | 2946 | | | | 2947 | 0x03 | APPLICATION_CLOSE | Section 19.4 | 2948 | | | | 2949 | 0x04 | MAX_DATA | Section 19.5 | 2950 | | | | 2951 | 0x05 | MAX_STREAM_DATA | Section 19.6 | 2952 | | | | 2953 | 0x06 | MAX_STREAM_ID | Section 19.7 | 2954 | | | | 2955 | 0x07 | PING | Section 19.8 | 2956 | | | | 2957 | 0x08 | BLOCKED | Section 19.9 | 2958 | | | | 2959 | 0x09 | STREAM_BLOCKED | Section 19.10 | 2960 | | | | 2961 | 0x0a | STREAM_ID_BLOCKED | Section 19.11 | 2962 | | | | 2963 | 0x0b | NEW_CONNECTION_ID | Section 19.12 | 2964 | | | | 2965 | 0x0c | STOP_SENDING | Section 19.14 | 2966 | | | | 2967 | 0x0d | RETIRE_CONNECTION_ID | Section 19.13 | 2968 | | | | 2969 | 0x0e | PATH_CHALLENGE | Section 19.16 | 2970 | | | | 2971 | 0x0f | PATH_RESPONSE | Section 19.17 | 2972 | | | | 2973 | 0x10 - 0x17 | STREAM | Section 19.19 | 2974 | | | | 2975 | 0x18 | CRYPTO | Section 19.20 | 2976 | | | | 2977 | 0x19 | NEW_TOKEN | Section 19.18 | 2978 | | | | 2979 | 0x1a - 0x1b | ACK | Section 19.15 | 2980 +-------------+----------------------+---------------+ 2982 Table 3: Frame Types 2984 All QUIC frames are idempotent. That is, a valid frame does not 2985 cause undesirable side effects or errors when received more than 2986 once. 2988 The Frame Type field uses a variable length integer encoding (see 2989 Section 16) with one exception. To ensure simple and efficient 2990 implementations of frame parsing, a frame type MUST use the shortest 2991 possible encoding. Though a two-, four- or eight-octet encoding of 2992 the frame types defined in this document is possible, the Frame Type 2993 field for these frames is encoded on a single octet. For instance, 2994 though 0x4007 is a legitimate two-octet encoding for a variable- 2995 length integer with a value of 7, PING frames are always encoded as a 2996 single octet with the value 0x07. An endpoint MUST treat the receipt 2997 of a frame type that uses a longer encoding than necessary as a 2998 connection error of type PROTOCOL_VIOLATION. 3000 13. Packetization and Reliability 3002 A sender bundles one or more frames in a QUIC packet (see 3003 Section 12.4). 3005 A sender can minimize per-packet bandwidth and computational costs by 3006 bundling as many frames as possible within a QUIC packet. A sender 3007 MAY wait for a short period of time to bundle multiple frames before 3008 sending a packet that is not maximally packed, to avoid sending out 3009 large numbers of small packets. An implementation may use knowledge 3010 about application sending behavior or heuristics to determine whether 3011 and for how long to wait. This waiting period is an implementation 3012 decision, and an implementation should be careful to delay 3013 conservatively, since any delay is likely to increase application- 3014 visible latency. 3016 Stream multiplexing is achieved by interleaving STREAM frames from 3017 multiple streams into one or more QUIC packets. A single QUIC packet 3018 can include multiple STREAM frames from one or more streams. 3020 One of the benefits of QUIC is avoidance of head-of-line blocking 3021 across multiple streams. When a packet loss occurs, only streams 3022 with data in that packet are blocked waiting for a retransmission to 3023 be received, while other streams can continue making progress. Note 3024 that when data from multiple streams is bundled into a single QUIC 3025 packet, loss of that packet blocks all those streams from making 3026 progress. Implementations are advised to bundle as few streams as 3027 necessary in outgoing packets without losing transmission efficiency 3028 to underfilled packets. 3030 13.1. Packet Processing and Acknowledgment 3032 A packet MUST NOT be acknowledged until packet protection has been 3033 successfully removed and all frames contained in the packet have been 3034 processed. For STREAM frames, this means the data has been enqueued 3035 in preparation to be received by the application protocol, but it 3036 does not require that data is delivered and consumed. 3038 Once the packet has been fully processed, a receiver acknowledges 3039 receipt by sending one or more ACK frames containing the packet 3040 number of the received packet. 3042 13.1.1. Sending ACK Frames 3044 To avoid creating an indefinite feedback loop, an endpoint MUST NOT 3045 send an ACK frame in response to a packet containing only ACK or 3046 PADDING frames, even if there are packet gaps which precede the 3047 received packet. The endpoint MUST however acknowledge packets 3048 containing only ACK or PADDING frames when sending ACK frames in 3049 response to other packets. 3051 While PADDING frames do not elicit an ACK frame from a receiver, they 3052 are considered to be in flight for congestion control purposes 3053 [QUIC-RECOVERY]. Sending only PADDING frames might cause the sender 3054 to become limited by the congestion controller (as described in 3055 [QUIC-RECOVERY]) with no acknowledgments forthcoming from the 3056 receiver. Therefore, a sender should ensure that other frames are 3057 sent in addition to PADDING frames to elicit acknowledgments from the 3058 receiver. 3060 An endpoint MUST NOT send more than one packet containing only an ACK 3061 frame per received packet that contains frames other than ACK and 3062 PADDING frames. 3064 The receiver's delayed acknowledgment timer SHOULD NOT exceed the 3065 current RTT estimate or the value it indicates in the "max_ack_delay" 3066 transport parameter. This ensures an acknowledgment is sent at least 3067 once per RTT when packets needing acknowledgement are received. The 3068 sender can use the receiver's "max_ack_delay" value in determining 3069 timeouts for timer-based retransmission. 3071 Strategies and implications of the frequency of generating 3072 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 3074 To limit ACK Blocks to those that have not yet been received by the 3075 sender, the receiver SHOULD track which ACK frames have been 3076 acknowledged by its peer. Once an ACK frame has been acknowledged, 3077 the packets it acknowledges SHOULD NOT be acknowledged again. 3079 Because ACK frames are not sent in response to ACK-only packets, a 3080 receiver that is only sending ACK frames will only receive 3081 acknowledgements for its packets if the sender includes them in 3082 packets with non-ACK frames. A sender SHOULD bundle ACK frames with 3083 other frames when possible. 3085 To limit receiver state or the size of ACK frames, a receiver MAY 3086 limit the number of ACK Blocks it sends. A receiver can do this even 3087 without receiving acknowledgment of its ACK frames, with the 3088 knowledge this could cause the sender to unnecessarily retransmit 3089 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 3090 lost after sufficiently newer packets are acknowledged. Therefore, 3091 the receiver SHOULD repeatedly acknowledge newly received packets in 3092 preference to packets received in the past. 3094 13.1.2. ACK Frames and Packet Protection 3096 ACK frames MUST only be carried in a packet that has the same packet 3097 number space as the packet being ACKed (see Section 12.1). For 3098 instance, packets that are protected with 1-RTT keys MUST be 3099 acknowledged in packets that are also protected with 1-RTT keys. 3101 Packets that a client sends with 0-RTT packet protection MUST be 3102 acknowledged by the server in packets protected by 1-RTT keys. This 3103 can mean that the client is unable to use these acknowledgments if 3104 the server cryptographic handshake messages are delayed or lost. 3105 Note that the same limitation applies to other data sent by the 3106 server protected by the 1-RTT keys. 3108 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3109 frames with a reduced delay; see Section 4.3.1 of [QUIC-RECOVERY]. 3111 13.2. Retransmission of Information 3113 QUIC packets that are determined to be lost are not retransmitted 3114 whole. The same applies to the frames that are contained within lost 3115 packets. Instead, the information that might be carried in frames is 3116 sent again in new frames as needed. 3118 New frames and packets are used to carry information that is 3119 determined to have been lost. In general, information is sent again 3120 when a packet containing that information is determined to be lost 3121 and sending ceases when a packet containing that information is 3122 acknowledged. 3124 o Data sent in CRYPTO frames is retransmitted according to the rules 3125 in [QUIC-RECOVERY], until all data has been acknowledged. 3127 o Application data sent in STREAM frames is retransmitted in new 3128 STREAM frames unless the endpoint has sent a RST_STREAM for that 3129 stream. Once an endpoint sends a RST_STREAM frame, no further 3130 STREAM frames are needed. 3132 o The most recent set of acknowledgments are sent in ACK frames. An 3133 ACK frame SHOULD contain all unacknowledged acknowledgments, as 3134 described in Section 13.1.1. 3136 o Cancellation of stream transmission, as carried in a RST_STREAM 3137 frame, is sent until acknowledged or until all stream data is 3138 acknowledged by the peer (that is, either the "Reset Recvd" or 3139 "Data Recvd" state is reached on the send stream). The content of 3140 a RST_STREAM frame MUST NOT change when it is sent again. 3142 o Similarly, a request to cancel stream transmission, as encoded in 3143 a STOP_SENDING frame, is sent until the receive stream enters 3144 either a "Data Recvd" or "Reset Recvd" state, see Section 3.5. 3146 o Connection close signals, including those that use 3147 CONNECTION_CLOSE and APPLICATION_CLOSE frames, are not sent again 3148 when packet loss is detected, but as described in Section 10. 3150 o The current connection maximum data is sent in MAX_DATA frames. 3151 An updated value is sent in a MAX_DATA frame if the packet 3152 containing the most recently sent MAX_DATA frame is declared lost, 3153 or when the endpoint decides to update the limit. Care is 3154 necessary to avoid sending this frame too often as the limit can 3155 increase frequently and cause an unnecessarily large number of 3156 MAX_DATA frames to be sent. 3158 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3159 frames. Like MAX_DATA, an updated value is sent when the packet 3160 containing the most recent MAX_STREAM_DATA frame for a stream is 3161 lost or when the limit is updated, with care taken to prevent the 3162 frame from being sent too often. An endpoint SHOULD stop sending 3163 MAX_STREAM_DATA frames when the receive stream enters a "Size 3164 Known" state. 3166 o The maximum stream ID for a stream of a given type is sent in 3167 MAX_STREAM_ID frames. Like MAX_DATA, an updated value is sent 3168 when a packet containing the most recent MAX_STREAM_ID for a 3169 stream type frame is declared lost or when the limit is updated, 3170 with care taken to prevent the frame from being sent too often. 3172 o Blocked signals are carried in BLOCKED, STREAM_BLOCKED, and 3173 STREAM_ID_BLOCKED frames. BLOCKED streams have connection scope, 3174 STREAM_BLOCKED frames have stream scope, and STREAM_ID_BLOCKED 3175 frames are scoped to a specific stream type. New frames are sent 3176 if packets containing the most recent frame for a scope is lost, 3177 but only while the endpoint is blocked on the corresponding limit. 3178 These frames always include the limit that is causing blocking at 3179 the time that they are transmitted. 3181 o A liveness or path validation check using PATH_CHALLENGE frames is 3182 sent periodically until a matching PATH_RESPONSE frame is received 3183 or until there is no remaining need for liveness or path 3184 validation checking. PATH_CHALLENGE frames include a different 3185 payload each time they are sent. 3187 o Responses to path validation using PATH_RESPONSE frames are sent 3188 just once. A new PATH_CHALLENGE frame will be sent if another 3189 PATH_RESPONSE frame is needed. 3191 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3192 retransmitted if the packet containing them is lost. 3193 Retransmissions of this frame carry the same sequence number 3194 value. Likewise, retired connection IDs are sent in 3195 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3196 containing them is lost. 3198 o PADDING frames contain no information, so lost PADDING frames do 3199 not require repair. 3201 Upon detecting losses, a sender MUST take appropriate congestion 3202 control action. The details of loss detection and congestion control 3203 are described in [QUIC-RECOVERY]. 3205 13.3. Explicit Congestion Notification 3207 QUIC endpoints use Explicit Congestion Notification (ECN) [RFC3168] 3208 to detect and respond to network congestion. ECN allows a network 3209 node to indicate congestion in the network by setting a codepoint in 3210 the IP header of a packet instead of dropping it. Endpoints react to 3211 congestion by reducing their sending rate in response, as described 3212 in [QUIC-RECOVERY]. 3214 To use ECN, QUIC endpoints first determine whether a path supports 3215 ECN marking and the peer is able to access the ECN codepoint in the 3216 IP header. A network path does not support ECN if ECN marked packets 3217 get dropped or ECN markings are rewritten on the path. An endpoint 3218 verifies the path, both during connection establishment and when 3219 migrating to a new path (see Section 9). 3221 13.3.1. ECN Counters 3223 On receiving a packet with an ECT or CE codepoint, an endpoint that 3224 can access the IP ECN codepoints increases the corresponding ECT(0), 3225 ECT(1), or CE count, and includes these counters in subsequent (see 3226 Section 13.1) ACK frames (see Section 19.15). 3228 A packet detected by a receiver as a duplicate does not affect the 3229 receiver's local ECN codepoint counts; see (Section 21.7) for 3230 relevant security concerns. 3232 If an endpoint receives a packet without an ECT or CE codepoint, it 3233 responds per Section 13.1 with an ACK frame. If an endpoint does not 3234 have access to received ECN codepoints, it acknowledges received 3235 packets per Section 13.1 with an ACK frame. 3237 13.3.2. ECN Verification 3239 Each endpoint independently verifies and enables use of ECN by 3240 setting the IP header ECN codepoint to ECN Capable Transport (ECT) 3241 for the path from it to the other peer. Even if ECN is not used on 3242 the path to the peer, the endpoint MUST provide feedback about ECN 3243 markings received (if accessible). 3245 To verify both that a path supports ECN and the peer can provide ECN 3246 feedback, an endpoint MUST set the ECT(0) codepoint in the IP header 3247 of all outgoing packets [RFC8311]. 3249 If an ECT codepoint set in the IP header is not corrupted by a 3250 network device, then a received packet contains either the codepoint 3251 sent by the peer or the Congestion Experienced (CE) codepoint set by 3252 a network device that is experiencing congestion. 3254 If a packet sent with an ECT codepoint is newly acknowledged by the 3255 peer in an ACK frame without ECN feedback, the endpoint stops setting 3256 ECT codepoints in subsequent packets, with the expectation that 3257 either the network or the peer no longer supports ECN. 3259 To protect the connection from arbitrary corruption of ECN codepoints 3260 by the network, an endpoint verifies the following when an ACK frame 3261 is received: 3263 o The increase in ECT(0) and ECT(1) counters MUST be at least the 3264 number of packets newly acknowledged that were sent with the 3265 corresponding codepoint. 3267 o The total increase in ECT(0), ECT(1), and CE counters reported in 3268 the ACK frame MUST be at least the total number of packets newly 3269 acknowledged in this ACK frame. 3271 An endpoint could miss acknowledgements for a packet when ACK frames 3272 are lost. It is therefore possible for the total increase in ECT(0), 3273 ECT(1), and CE counters to be greater than the number of packets 3274 acknowledged in an ACK frame. When this happens, the local reference 3275 counts MUST be increased to match the counters in the ACK frame. 3277 Upon successful verification, an endpoint continues to set ECT 3278 codepoints in subsequent packets with the expectation that the path 3279 is ECN-capable. 3281 If verification fails, then the endpoint ceases setting ECT 3282 codepoints in subsequent packets with the expectation that either the 3283 network or the peer does not support ECN. 3285 If an endpoint sets ECT codepoints on outgoing packets and encounters 3286 a retransmission timeout due to the absence of acknowledgments from 3287 the peer (see [QUIC-RECOVERY]), or if an endpoint has reason to 3288 believe that a network element might be corrupting ECN codepoints, 3289 the endpoint MAY cease setting ECT codepoints in subsequent packets. 3290 Doing so allows the connection to traverse network elements that drop 3291 or corrupt ECN codepoints in the IP header. 3293 14. Packet Size 3295 The QUIC packet size includes the QUIC header and integrity check, 3296 but not the UDP or IP header. 3298 Clients MUST ensure that the first Initial packet they send is sent 3299 in a UDP datagram that is at least 1200 octets. Padding the Initial 3300 packet or including a 0-RTT packet in the same datagram are ways to 3301 meet this requirement. Sending a UDP datagram of this size ensures 3302 that the network path supports a reasonable Maximum Transmission Unit 3303 (MTU), and helps reduce the amplitude of amplification attacks caused 3304 by server responses toward an unverified client address, see 3305 Section 8. 3307 The payload of a UDP datagram carrying the Initial packet MUST be 3308 expanded to at least 1200 octets, by adding PADDING frames to the 3309 Initial packet and/or by combining the Initial packet with a 0-RTT 3310 packet (see Section 12.2). 3312 The datagram containing the first Initial packet from a client MAY 3313 exceed 1200 octets if the client believes that the Path Maximum 3314 Transmission Unit (PMTU) supports the size that it chooses. 3316 A server MAY send a CONNECTION_CLOSE frame with error code 3317 PROTOCOL_VIOLATION in response to the first Initial packet it 3318 receives from a client if the UDP datagram is smaller than 1200 3319 octets. It MUST NOT send any other frame type in response, or 3320 otherwise behave as if any part of the offending packet was processed 3321 as valid. 3323 The server MUST also limit the number of bytes it sends before 3324 validating the address of the client, see Section 8. 3326 14.1. Path Maximum Transmission Unit 3328 The Path Maximum Transmission Unit (PMTU) is the maximum size of the 3329 entire IP header, UDP header, and UDP payload. The UDP payload 3330 includes the QUIC packet header, protected payload, and any 3331 authentication fields. 3333 All QUIC packets SHOULD be sized to fit within the estimated PMTU to 3334 avoid IP fragmentation or packet drops. To optimize bandwidth 3335 efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery 3336 ([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) 3337 for detecting the PMTU, setting the PMTU appropriately, and storing 3338 the result of previous PMTU determinations. 3340 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3341 packets larger than 1280 octets. Assuming the minimum IP header 3342 size, this results in a QUIC packet size of 1232 octets for IPv6 and 3343 1252 octets for IPv4. Some QUIC implementations MAY be more 3344 conservative in computing allowed QUIC packet size given unknown 3345 tunneling overheads or IP header options. 3347 QUIC endpoints that implement any kind of PMTU discovery SHOULD 3348 maintain an estimate for each combination of local and remote IP 3349 addresses. Each pairing of local and remote addresses could have a 3350 different maximum MTU in the path. 3352 QUIC depends on the network path supporting an MTU of at least 1280 3353 octets. This is the IPv6 minimum MTU and therefore also supported by 3354 most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below 3355 this number, even if it receives signals that indicate a smaller 3356 limit might exist. 3358 If a QUIC endpoint determines that the PMTU between any pair of local 3359 and remote IP addresses has fallen below 1280 octets, it MUST 3360 immediately cease sending QUIC packets on the affected path. This 3361 could result in termination of the connection if an alternative path 3362 cannot be found. 3364 14.1.1. IPv4 PMTU Discovery 3366 Traditional ICMP-based path MTU discovery in IPv4 [PMTUDv4] is 3367 potentially vulnerable to off-path attacks that successfully guess 3368 the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient 3369 value. TCP connections mitigate this risk by using the (at minimum) 3370 8 bytes of transport header echoed in the ICMP message to validate 3371 the TCP sequence number as valid for the current connection. 3372 However, as QUIC operates over UDP, in IPv4 the echoed information 3373 could consist only of the IP and UDP headers, which usually has 3374 insufficient entropy to mitigate off-path attacks. 3376 As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps 3377 to mitigate this risk. For instance, an application could: 3379 o Set the IPv4 Don't Fragment (DF) bit on a small proportion of 3380 packets, so that most invalid ICMP messages arrive when there are 3381 no DF packets outstanding, and can therefore be identified as 3382 spurious. 3384 o Store additional information from the IP or UDP headers from DF 3385 packets (for example, the IP ID or UDP checksum) to further 3386 authenticate incoming Datagram Too Big messages. 3388 o Any reduction in PMTU due to a report contained in an ICMP packet 3389 is provisional until QUIC's loss detection algorithm determines 3390 that the packet is actually lost. 3392 14.2. Special Considerations for Packetization Layer PMTU Discovery 3394 The PADDING frame provides a useful option for PMTU probe packets. 3395 PADDING frames generate acknowledgements, but they need not be 3396 delivered reliably. As a result, the loss of PADDING frames in probe 3397 packets does not require delay-inducing retransmission. However, 3398 PADDING frames do consume congestion window, which may delay the 3399 transmission of subsequent application data. 3401 When implementing the algorithm in Section 7.2 of [PLPMTUD], the 3402 initial value of search_low SHOULD be consistent with the IPv6 3403 minimum packet size. Paths that do not support this size cannot 3404 deliver Initial packets, and therefore are not QUIC-compliant. 3406 Section 7.3 of [PLPMTUD] discusses trade-offs between small and large 3407 increases in the size of probe packets. As QUIC probe packets need 3408 not contain application data, aggressive increases in probe size 3409 carry fewer consequences. 3411 15. Versions 3413 QUIC versions are identified using a 32-bit unsigned number. 3415 The version 0x00000000 is reserved to represent version negotiation. 3416 This version of the specification is identified by the number 3417 0x00000001. 3419 Other versions of QUIC might have different properties to this 3420 version. The properties of QUIC that are guaranteed to be consistent 3421 across all versions of the protocol are described in 3422 [QUIC-INVARIANTS]. 3424 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 3425 protocol, as described in [QUIC-TLS]. 3427 Versions with the most significant 16 bits of the version number 3428 cleared are reserved for use in future IETF consensus documents. 3430 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 3431 forcing version negotiation to be exercised. That is, any version 3432 number where the low four bits of all octets is 1010 (in binary). A 3433 client or server MAY advertise support for any of these reserved 3434 versions. 3436 Reserved version numbers will probably never represent a real 3437 protocol; a client MAY use one of these version numbers with the 3438 expectation that the server will initiate version negotiation; a 3439 server MAY advertise support for one of these versions and can expect 3440 that clients ignore the value. 3442 [[RFC editor: please remove the remainder of this section before 3443 publication.]] 3445 The version number for the final version of this specification 3446 (0x00000001), is reserved for the version of the protocol that is 3447 published as an RFC. 3449 Version numbers used to identify IETF drafts are created by adding 3450 the draft number to 0xff000000. For example, draft-ietf-quic- 3451 transport-13 would be identified as 0xff00000D. 3453 Implementors are encouraged to register version numbers of QUIC that 3454 they are using for private experimentation on the GitHub wiki at 3455 . 3457 16. Variable-Length Integer Encoding 3459 QUIC packets and frames commonly use a variable-length encoding for 3460 non-negative integer values. This encoding ensures that smaller 3461 integer values need fewer octets to encode. 3463 The QUIC variable-length integer encoding reserves the two most 3464 significant bits of the first octet to encode the base 2 logarithm of 3465 the integer encoding length in octets. The integer value is encoded 3466 on the remaining bits, in network byte order. 3468 This means that integers are encoded on 1, 2, 4, or 8 octets and can 3469 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3470 the encoding properties. 3472 +------+--------+-------------+-----------------------+ 3473 | 2Bit | Length | Usable Bits | Range | 3474 +------+--------+-------------+-----------------------+ 3475 | 00 | 1 | 6 | 0-63 | 3476 | | | | | 3477 | 01 | 2 | 14 | 0-16383 | 3478 | | | | | 3479 | 10 | 4 | 30 | 0-1073741823 | 3480 | | | | | 3481 | 11 | 8 | 62 | 0-4611686018427387903 | 3482 +------+--------+-------------+-----------------------+ 3484 Table 4: Summary of Integer Encodings 3486 For example, the eight octet sequence c2 19 7c 5e ff 14 e8 8c (in 3487 hexadecimal) decodes to the decimal value 151288809941952652; the 3488 four octet sequence 9d 7f 3e 7d decodes to 494878333; the two octet 3489 sequence 7b bd decodes to 15293; and the single octet 25 decodes to 3490 37 (as does the two octet sequence 40 25). 3492 Error codes (Section 20) and versions Section 15 are described using 3493 integers, but do not use this encoding. 3495 17. Packet Formats 3497 All numeric values are encoded in network byte order (that is, big- 3498 endian) and all field sizes are in bits. Hexadecimal notation is 3499 used for describing the value of fields. 3501 17.1. Packet Number Encoding and Decoding 3503 Packet numbers in long and short packet headers are encoded as 3504 follows. The number of bits required to represent the packet number 3505 is first reduced by including only a variable number of the least 3506 significant bits of the packet number. One or two of the most 3507 significant bits of the first octet are then used to represent how 3508 many bits of the packet number are provided, as shown in Table 5. 3510 +---------------------+----------------+--------------+ 3511 | First octet pattern | Encoded Length | Bits Present | 3512 +---------------------+----------------+--------------+ 3513 | 0b0xxxxxxx | 1 octet | 7 | 3514 | | | | 3515 | 0b10xxxxxx | 2 | 14 | 3516 | | | | 3517 | 0b11xxxxxx | 4 | 30 | 3518 +---------------------+----------------+--------------+ 3520 Table 5: Packet Number Encodings for Packet Headers 3522 Note that these encodings are similar to those in Section 16, but use 3523 different values. 3525 Finally, the encoded packet number is protected as described in 3526 Section 5.3 of [QUIC-TLS]. 3528 The sender MUST use a packet number size able to represent more than 3529 twice as large a range than the difference between the largest 3530 acknowledged packet and packet number being sent. A peer receiving 3531 the packet will then correctly decode the packet number, unless the 3532 packet is delayed in transit such that it arrives after many higher- 3533 numbered packets have been received. An endpoint SHOULD use a large 3534 enough packet number encoding to allow the packet number to be 3535 recovered even if the packet arrives after packets that are sent 3536 afterwards. 3538 As a result, the size of the packet number encoding is at least one 3539 more than the base 2 logarithm of the number of contiguous 3540 unacknowledged packet numbers, including the new packet. 3542 For example, if an endpoint has received an acknowledgment for packet 3543 0x6afa2f, sending a packet with a number of 0x6b2d79 requires a 3544 packet number encoding with 14 bits or more; whereas the 30-bit 3545 packet number encoding is needed to send a packet with a number of 3546 0x6bc107. 3548 At a receiver, protection of the packet number is removed prior to 3549 recovering the full packet number. The full packet number is then 3550 reconstructed based on the number of significant bits present, the 3551 value of those bits, and the largest packet number received on a 3552 successfully authenticated packet. Recovering the full packet number 3553 is necessary to successfully remove packet protection. 3555 Once packet number protection is removed, the packet number is 3556 decoded by finding the packet number value that is closest to the 3557 next expected packet. The next expected packet is the highest 3558 received packet number plus one. For example, if the highest 3559 successfully authenticated packet had a packet number of 0xaa82f30e, 3560 then a packet containing a 14-bit value of 0x9b3 will be decoded as 3561 0xaa8309b3. Example pseudo-code for packet number decoding can be 3562 found in Appendix A. 3564 17.2. Long Header Packet 3566 0 1 2 3 3567 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 3568 +-+-+-+-+-+-+-+-+ 3569 |1| Type (7) | 3570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3571 | Version (32) | 3572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 |DCIL(4)|SCIL(4)| 3574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3575 | Destination Connection ID (0/32..144) ... 3576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3577 | Source Connection ID (0/32..144) ... 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3579 | Length (i) ... 3580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3581 | Packet Number (8/16/32) | 3582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3583 | Payload (*) ... 3584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3586 Figure 10: Long Header Packet Format 3588 Long headers are used for packets that are sent prior to the 3589 completion of version negotiation and establishment of 1-RTT keys. 3590 Once both conditions are met, a sender switches to sending packets 3591 using the short header (Section 17.3). The long form allows for 3592 special packets - such as the Version Negotiation packet - to be 3593 represented in this uniform fixed-length packet format. Packets that 3594 use the long header contain the following fields: 3596 Header Form: The most significant bit (0x80) of octet 0 (the first 3597 octet) is set to 1 for long headers. 3599 Long Packet Type: The remaining seven bits of octet 0 contain the 3600 packet type. This field can indicate one of 128 packet types. 3601 The types specified for this version are listed in Table 6. 3603 Version: The QUIC Version is a 32-bit field that follows the Type. 3604 This field indicates which version of QUIC is in use and 3605 determines how the rest of the protocol fields are interpreted. 3607 DCIL and SCIL: The octet following the version contains the lengths 3608 of the two connection ID fields that follow it. These lengths are 3609 encoded as two 4-bit unsigned integers. The Destination 3610 Connection ID Length (DCIL) field occupies the 4 high bits of the 3611 octet and the Source Connection ID Length (SCIL) field occupies 3612 the 4 low bits of the octet. An encoded length of 0 indicates 3613 that the connection ID is also 0 octets in length. Non-zero 3614 encoded lengths are increased by 3 to get the full length of the 3615 connection ID, producing a length between 4 and 18 octets 3616 inclusive. For example, an octet with the value 0x50 describes an 3617 8-octet Destination Connection ID and a zero-length Source 3618 Connection ID. 3620 Destination Connection ID: The Destination Connection ID field 3621 follows the connection ID lengths and is either 0 octets in length 3622 or between 4 and 18 octets. Section 7.2 describes the use of this 3623 field in more detail. 3625 Source Connection ID: The Source Connection ID field follows the 3626 Destination Connection ID and is either 0 octets in length or 3627 between 4 and 18 octets. Section 7.2 describes the use of this 3628 field in more detail. 3630 Length: The length of the remainder of the packet (that is, the 3631 Packet Number and Payload fields) in octets, encoded as a 3632 variable-length integer (Section 16). 3634 Packet Number: The packet number field is 1, 2, or 4 octets long. 3635 The packet number has confidentiality protection separate from 3636 packet protection, as described in Section 5.3 of [QUIC-TLS]. The 3637 length of the packet number field is encoded in the plaintext 3638 packet number. See Section 17.1 for details. 3640 Payload: The payload of the packet. 3642 The following packet types are defined: 3644 +------+-----------------+--------------+ 3645 | Type | Name | Section | 3646 +------+-----------------+--------------+ 3647 | 0x7F | Initial | Section 17.5 | 3648 | | | | 3649 | 0x7E | Retry | Section 17.7 | 3650 | | | | 3651 | 0x7D | Handshake | Section 17.6 | 3652 | | | | 3653 | 0x7C | 0-RTT Protected | Section 12.1 | 3654 +------+-----------------+--------------+ 3656 Table 6: Long Header Packet Types 3658 The header form, type, connection ID lengths octet, destination and 3659 source connection IDs, and version fields of a long header packet are 3660 version-independent. The packet number and values for packet types 3661 defined in Table 6 are version-specific. See [QUIC-INVARIANTS] for 3662 details on how packets from different versions of QUIC are 3663 interpreted. 3665 The interpretation of the fields and the payload are specific to a 3666 version and packet type. Type-specific semantics for this version 3667 are described in the following sections. 3669 The end of the packet is determined by the Length field. The Length 3670 field covers both the Packet Number and Payload fields, both of which 3671 are confidentiality protected and initially of unknown length. The 3672 size of the Payload field is learned once the packet number 3673 protection is removed. The Length field enables packet coalescing 3674 (Section 12.2). 3676 17.3. Short Header Packet 3678 0 1 2 3 3679 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 3680 +-+-+-+-+-+-+-+-+ 3681 |0|K|1|1|0|R R R| 3682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3683 | Destination Connection ID (0..144) ... 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3685 | Packet Number (8/16/32) ... 3686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3687 | Protected Payload (*) ... 3688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3690 Figure 11: Short Header Packet Format 3692 The short header can be used after the version and 1-RTT keys are 3693 negotiated. Packets that use the short header contain the following 3694 fields: 3696 Header Form: The most significant bit (0x80) of octet 0 is set to 0 3697 for the short header. 3699 Key Phase Bit: The second bit (0x40) of octet 0 indicates the key 3700 phase, which allows a recipient of a packet to identify the packet 3701 protection keys that are used to protect the packet. See 3702 [QUIC-TLS] for details. 3704 [[Editor's Note: this section should be removed and the bit 3705 definitions changed before this draft goes to the IESG.]] 3707 Third Bit: The third bit (0x20) of octet 0 is set to 1. 3709 [[Editor's Note: this section should be removed and the bit 3710 definitions changed before this draft goes to the IESG.]] 3712 Fourth Bit: The fourth bit (0x10) of octet 0 is set to 1. 3714 [[Editor's Note: this section should be removed and the bit 3715 definitions changed before this draft goes to the IESG.]] 3717 Google QUIC Demultiplexing Bit: The fifth bit (0x8) of octet 0 is 3718 set to 0. This allows implementations of Google QUIC to 3719 distinguish Google QUIC packets from short header packets sent by 3720 a client because Google QUIC servers expect the connection ID to 3721 always be present. The special interpretation of this bit SHOULD 3722 be removed from this specification when Google QUIC has finished 3723 transitioning to the new header format. 3725 Reserved: The sixth, seventh, and eighth bits (0x7) of octet 0 are 3726 reserved for experimentation. Endpoints MUST ignore these bits on 3727 packets they receive unless they are participating in an 3728 experiment that uses these bits. An endpoint not actively using 3729 these bits SHOULD set the value randomly on packets they send to 3730 protect against unwanted inference about particular values. 3732 Destination Connection ID: The Destination Connection ID is a 3733 connection ID that is chosen by the intended recipient of the 3734 packet. See Section 5.1 for more details. 3736 Packet Number: The packet number field is 1, 2, or 4 octets long. 3737 The packet number has confidentiality protection separate from 3738 packet protection, as described in Section 5.3 of [QUIC-TLS]. The 3739 length of the packet number field is encoded in the plaintext 3740 packet number. See Section 17.1 for details. 3742 Protected Payload: Packets with a short header always include a 3743 1-RTT protected payload. 3745 The header form and connection ID field of a short header packet are 3746 version-independent. The remaining fields are specific to the 3747 selected QUIC version. See [QUIC-INVARIANTS] for details on how 3748 packets from different versions of QUIC are interpreted. 3750 17.4. Version Negotiation Packet 3752 A Version Negotiation packet is inherently not version-specific, and 3753 does not use the long packet header (see Section 17.2). Upon receipt 3754 by a client, it will appear to be a packet using the long header, but 3755 will be identified as a Version Negotiation packet based on the 3756 Version field having a value of 0. 3758 The Version Negotiation packet is a response to a client packet that 3759 contains a version that is not supported by the server, and is only 3760 sent by servers. 3762 The layout of a Version Negotiation packet is: 3764 0 1 2 3 3765 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 3766 +-+-+-+-+-+-+-+-+ 3767 |1| Unused (7) | 3768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3769 | Version (32) | 3770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 |DCIL(4)|SCIL(4)| 3772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3773 | Destination Connection ID (0/32..144) ... 3774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3775 | Source Connection ID (0/32..144) ... 3776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3777 | Supported Version 1 (32) ... 3778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3779 | [Supported Version 2 (32)] ... 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 ... 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 | [Supported Version N (32)] ... 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 Figure 12: Version Negotiation Packet 3788 The value in the Unused field is selected randomly by the server. 3790 The Version field of a Version Negotiation packet MUST be set to 3791 0x00000000. 3793 The server MUST include the value from the Source Connection ID field 3794 of the packet it receives in the Destination Connection ID field. 3795 The value for Source Connection ID MUST be copied from the 3796 Destination Connection ID of the received packet, which is initially 3797 randomly selected by a client. Echoing both connection IDs gives 3798 clients some assurance that the server received the packet and that 3799 the Version Negotiation packet was not generated by an off-path 3800 attacker. 3802 The remainder of the Version Negotiation packet is a list of 32-bit 3803 versions which the server supports. 3805 A Version Negotiation packet cannot be explicitly acknowledged in an 3806 ACK frame by a client. Receiving another Initial packet implicitly 3807 acknowledges a Version Negotiation packet. 3809 The Version Negotiation packet does not include the Packet Number and 3810 Length fields present in other packets that use the long header form. 3811 Consequently, a Version Negotiation packet consumes an entire UDP 3812 datagram. 3814 See Section 6 for a description of the version negotiation process. 3816 17.5. Initial Packet 3818 An Initial packet uses long headers with a type value of 0x7F. It 3819 carries the first CRYPTO frames sent by the client and server to 3820 perform key exchange, and carries ACKs in either direction. 3822 In order to prevent tampering by version-unaware middleboxes, Initial 3823 packets are protected with connection- and version-specific keys 3824 (Initial keys) as described in [QUIC-TLS]. This protection does not 3825 provide confidentiality or integrity against on-path attackers, but 3826 provides some level of protection against off-path attackers. 3828 An Initial packet (shown in Figure 13) has two additional header 3829 fields that are added to the Long Header before the Length field. 3831 +-+-+-+-+-+-+-+-+ 3832 |1| 0x7f | 3833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3834 | Version (32) | 3835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3836 |DCIL(4)|SCIL(4)| 3837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3838 | Destination Connection ID (0/32..144) ... 3839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3840 | Source Connection ID (0/32..144) ... 3841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3842 | Token Length (i) ... 3843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3844 | Token (*) ... 3845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3846 | Length (i) ... 3847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3848 | Packet Number (8/16/32) | 3849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3850 | Payload (*) ... 3851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3853 Figure 13: Initial Packet 3855 These fields include the token that was previously provided in a 3856 Retry packet or NEW_TOKEN frame: 3858 Token Length: A variable-length integer specifying the length of the 3859 Token field, in bytes. This value is zero if no token is present. 3860 Initial packets sent by the server MUST set the Token Length field 3861 to zero; clients that receive an Initial packet with a non-zero 3862 Token Length field MUST either discard the packet or generate a 3863 connection error of type PROTOCOL_VIOLATION. 3865 Token: The value of the token. 3867 The client and server use the Initial packet type for any packet that 3868 contains an initial cryptographic handshake message. This includes 3869 all cases where a new packet containing the initial cryptographic 3870 message needs to be created, such as the packets sent after receiving 3871 a Version Negotiation (Section 17.4) or Retry packet (Section 17.7). 3873 A server sends its first Initial packet in response to a client 3874 Initial. A server may send multiple Initial packets. The 3875 cryptographic key exchange could require multiple round trips or 3876 retransmissions of this data. 3878 The payload of an Initial packet includes a CRYPTO frame (or frames) 3879 containing a cryptographic handshake message, ACK frames, or both. 3880 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 3881 that receives an Initial packet containing other frames can either 3882 discard the packet as spurious or treat it as a connection error. 3884 The first packet sent by a client always includes a CRYPTO frame that 3885 contains the entirety of the first cryptographic handshake message. 3886 This packet, and the cryptographic handshake message, MUST fit in a 3887 single UDP datagram (see Section 7). The first CRYPTO frame sent 3888 always begins at an offset of 0 (see Section 7). 3890 Note that if the server sends a HelloRetryRequest, the client will 3891 send a second Initial packet. This Initial packet will continue the 3892 cryptographic handshake and will contain a CRYPTO frame with an 3893 offset matching the size of the CRYPTO frame sent in the first 3894 Initial packet. Cryptographic handshake messages subsequent to the 3895 first do not need to fit within a single UDP datagram. 3897 17.5.1. Starting Packet Numbers 3899 The first Initial packet sent by either endpoint contains a packet 3900 number of 0. The packet number MUST increase monotonically 3901 thereafter. Initial packets are in a different packet number space 3902 to other packets (see Section 12.3). 3904 17.5.2. 0-RTT Packet Numbers 3906 Packet numbers for 0-RTT protected packets use the same space as 3907 1-RTT protected packets. 3909 After a client receives a Retry or Version Negotiation packet, 0-RTT 3910 packets are likely to have been lost or discarded by the server. A 3911 client MAY attempt to resend data in 0-RTT packets after it sends a 3912 new Initial packet. 3914 A client MUST NOT reset the packet number it uses for 0-RTT packets. 3915 The keys used to protect 0-RTT packets will not change as a result of 3916 responding to a Retry or Version Negotiation packet unless the client 3917 also regenerates the cryptographic handshake message. Sending 3918 packets with the same packet number in that case is likely to 3919 compromise the packet protection for all 0-RTT packets because the 3920 same key and nonce could be used to protect different content. 3922 Receiving a Retry or Version Negotiation packet, especially a Retry 3923 that changes the connection ID used for subsequent packets, indicates 3924 a strong possibility that 0-RTT packets could be lost. A client only 3925 receives acknowledgments for its 0-RTT packets once the handshake is 3926 complete. Consequently, a server might expect 0-RTT packets to start 3927 with a packet number of 0. Therefore, in determining the length of 3928 the packet number encoding for 0-RTT packets, a client MUST assume 3929 that all packets up to the current packet number are in flight, 3930 starting from a packet number of 0. Thus, 0-RTT packets could need 3931 to use a longer packet number encoding. 3933 A client SHOULD instead generate a fresh cryptographic handshake 3934 message and start packet numbers from 0. This ensures that new 0-RTT 3935 packets will not use the same keys, avoiding any risk of key and 3936 nonce reuse; this also prevents 0-RTT packets from previous handshake 3937 attempts from being accepted as part of the connection. 3939 17.6. Handshake Packet 3941 A Handshake packet uses long headers with a type value of 0x7D. It 3942 is used to carry acknowledgments and cryptographic handshake messages 3943 from the server and client. 3945 Once a client has received a Handshake packet from a server, it uses 3946 Handshake packets to send subsequent cryptographic handshake messages 3947 and acknowledgments to the server. 3949 The Destination Connection ID field in a Handshake packet contains a 3950 connection ID that is chosen by the recipient of the packet; the 3951 Source Connection ID includes the connection ID that the sender of 3952 the packet wishes to use (see Section 7.2). 3954 The first Handshake packet sent by a server contains a packet number 3955 of 0. Handshake packets are their own packet number space. Packet 3956 numbers are incremented normally for other Handshake packets. 3958 The payload of this packet contains CRYPTO frames and could contain 3959 PADDING, or ACK frames. Handshake packets MAY contain 3960 CONNECTION_CLOSE or APPLICATION_CLOSE frames. Endpoints MUST treat 3961 receipt of Handshake packets with other frames as a connection error. 3963 17.7. Retry Packet 3965 A Retry packet uses a long packet header with a type value of 0x7E. 3966 It carries an address validation token created by the server. It is 3967 used by a server that wishes to perform a stateless retry (see 3968 Section 8.1). 3970 0 1 2 3 3971 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 3972 +-+-+-+-+-+-+-+-+ 3973 |1| 0x7e | 3974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3975 | Version (32) | 3976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3977 |DCIL(4)|SCIL(4)| 3978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3979 | Destination Connection ID (0/32..144) ... 3980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3981 | Source Connection ID (0/32..144) ... 3982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3983 | ODCIL(8) | Original Destination Connection ID (*) | 3984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3985 | Retry Token (*) ... 3986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3988 Figure 14: Retry Packet 3990 A Retry packet (shown in Figure 14) only uses the invariant portion 3991 of the long packet header [QUIC-INVARIANTS]; that is, the fields up 3992 to and including the Destination and Source Connection ID fields. A 3993 Retry packet does not contain any protected fields. Like Version 3994 Negotiation, a Retry packet contains the long header including the 3995 connection IDs, but omits the Length, Packet Number, and Payload 3996 fields. These are replaced with: 3998 ODCIL: The length of the Original Destination Connection ID field. 3999 The length is encoded in the least significant 4 bits of the 4000 octet, using the same encoding as the DCIL and SCIL fields. The 4001 most significant 4 bits of this octet are reserved. Unless a use 4002 for these bits has been negotiated, endpoints SHOULD send 4003 randomized values and MUST ignore any value that it receives. 4005 Original Destination Connection ID: The Original Destination 4006 Connection ID contains the value of the Destination Connection ID 4007 from the Initial packet that this Retry is in response to. The 4008 length of this field is given in ODCIL. 4010 Retry Token: An opaque token that the server can use to validate the 4011 client's address. 4013 The server populates the Destination Connection ID with the 4014 connection ID that the client included in the Source Connection ID of 4015 the Initial packet. 4017 The server includes a connection ID of its choice in the Source 4018 Connection ID field. This value MUST not be equal to the Destination 4019 Connection ID field of the packet sent by the client. The client 4020 MUST use this connection ID in the Destination Connection ID of 4021 subsequent packets that it sends. 4023 A server MAY send Retry packets in response to Initial and 0-RTT 4024 packets. A server can either discard or buffer 0-RTT packets that it 4025 receives. A server can send multiple Retry packets as it receives 4026 Initial or 0-RTT packets. 4028 A client MUST accept and process at most one Retry packet for each 4029 connection attempt. After the client has received and processed an 4030 Initial or Retry packet from the server, it MUST discard any 4031 subsequent Retry packets that it receives. 4033 Clients MUST discard Retry packets that contain an Original 4034 Destination Connection ID field that does not match the Destination 4035 Connection ID from its Initial packet. This prevents an off-path 4036 attacker from injecting a Retry packet. 4038 The client responds to a Retry packet with an Initial packet that 4039 includes the provided Retry Token to continue connection 4040 establishment. 4042 A client sets the Destination Connection ID field of this Initial 4043 packet to the value from the Source Connection ID in the Retry 4044 packet. Changing Destination Connection ID also results in a change 4045 to the keys used to protect the Initial packet. It also sets the 4046 Token field to the token provided in the Retry. The client MUST NOT 4047 change the Source Connection ID because the server could include the 4048 connection ID as part of its token validation logic (see 4049 Section 8.1.2). 4051 All subsequent Initial packets from the client MUST use the 4052 connection ID and token values from the Retry packet. Aside from 4053 this, the Initial packet sent by the client is subject to the same 4054 restrictions as the first Initial packet. A client can either reuse 4055 the cryptographic handshake message or construct a new one at its 4056 discretion. 4058 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4059 0-RTT packets to the connection ID provided by the server. A client 4060 that sends additional 0-RTT packets without constructing a new 4061 cryptographic handshake message MUST NOT reset the packet number to 0 4062 after a Retry packet, see Section 17.5.2. 4064 A server acknowledges the use of a Retry packet for a connection 4065 using the original_connection_id transport parameter (see 4066 Section 18.1). If the server sends a Retry packet, it MUST include 4067 the value of the Original Destination Connection ID field of the 4068 Retry packet (that is, the Destination Connection ID field from the 4069 client's first Initial packet) in the transport parameter. 4071 If the client received and processed a Retry packet, it validates 4072 that the original_connection_id transport parameter is present and 4073 correct; otherwise, it validates that the transport parameter is 4074 absent. A client MUST treat a failed validation as a connection 4075 error of type TRANSPORT_PARAMETER_ERROR. 4077 A Retry packet does not include a packet number and cannot be 4078 explicitly acknowledged by a client. 4080 18. Transport Parameter Encoding 4082 The format of the transport parameters is the TransportParameters 4083 struct from Figure 15. This is described using the presentation 4084 language from Section 3 of [TLS13]. 4086 uint32 QuicVersion; 4088 enum { 4089 initial_max_stream_data_bidi_local(0), 4090 initial_max_data(1), 4091 initial_max_bidi_streams(2), 4092 idle_timeout(3), 4093 preferred_address(4), 4094 max_packet_size(5), 4095 stateless_reset_token(6), 4096 ack_delay_exponent(7), 4097 initial_max_uni_streams(8), 4098 disable_migration(9), 4099 initial_max_stream_data_bidi_remote(10), 4100 initial_max_stream_data_uni(11), 4101 max_ack_delay(12), 4102 original_connection_id(13), 4103 (65535) 4104 } TransportParameterId; 4106 struct { 4107 TransportParameterId parameter; 4108 opaque value<0..2^16-1>; 4109 } TransportParameter; 4111 struct { 4112 select (Handshake.msg_type) { 4113 case client_hello: 4114 QuicVersion initial_version; 4116 case encrypted_extensions: 4117 QuicVersion negotiated_version; 4118 QuicVersion supported_versions<4..2^8-4>; 4119 }; 4120 TransportParameter parameters<0..2^16-1>; 4121 } TransportParameters; 4123 struct { 4124 enum { IPv4(4), IPv6(6), (15) } ipVersion; 4125 opaque ipAddress<4..2^8-1>; 4126 uint16 port; 4127 opaque connectionId<0..18>; 4128 opaque statelessResetToken[16]; 4129 } PreferredAddress; 4131 Figure 15: Definition of TransportParameters 4133 The "extension_data" field of the quic_transport_parameters extension 4134 defined in [QUIC-TLS] contains a TransportParameters value. TLS 4135 encoding rules are therefore used to describe the encoding of 4136 transport parameters. 4138 QUIC encodes transport parameters into a sequence of octets, which 4139 are then included in the cryptographic handshake. 4141 18.1. Transport Parameter Definitions 4143 An endpoint MAY use the following transport parameters: 4145 idle_timeout (0x0003): The idle timeout is a value in seconds that 4146 is encoded as an unsigned 16-bit integer. If this parameter is 4147 absent or zero then the idle timeout is disabled. 4149 max_packet_size (0x0005): The maximum packet size parameter places a 4150 limit on the size of packets that the endpoint is willing to 4151 receive, encoded as an unsigned 16-bit integer. This indicates 4152 that packets larger than this limit will be dropped. The default 4153 for this parameter is the maximum permitted UDP payload of 65527. 4154 Values below 1200 are invalid. This limit only applies to 4155 protected packets (Section 12.1). 4157 ack_delay_exponent (0x0007): An 8-bit unsigned integer value 4158 indicating an exponent used to decode the ACK Delay field in the 4159 ACK frame, see Section 19.15. If this value is absent, a default 4160 value of 3 is assumed (indicating a multiplier of 8). The default 4161 value is also used for ACK frames that are sent in Initial and 4162 Handshake packets. Values above 20 are invalid. 4164 disable_migration (0x0009): The endpoint does not support connection 4165 migration (Section 9). Peers MUST NOT send any packets, including 4166 probing packets (Section 9.1), from a local address other than 4167 that used to perform the handshake. This parameter is a zero- 4168 length value. 4170 max_ack_delay (0x000c): An 8 bit unsigned integer value indicating 4171 the maximum amount of time in milliseconds by which the endpoint 4172 will delay sending acknowledgments. If this value is absent, a 4173 default of 25 milliseconds is assumed. 4175 Either peer MAY advertise an initial value for flow control of each 4176 type of stream on which they might receive data. Each of the 4177 following transport parameters is encoded as an unsigned 32-bit 4178 integer in units of octets: 4180 initial_max_stream_data_bidi_local (0x0000): The initial stream 4181 maximum data for bidirectional, locally-initiated streams 4182 parameter contains the initial flow control limit for newly 4183 created bidirectional streams opened by the endpoint that sets the 4184 transport parameter. In client transport parameters, this applies 4185 to streams with an identifier ending in 0x0; in server transport 4186 parameters, this applies to streams ending in 0x1. 4188 initial_max_stream_data_bidi_remote (0x000a): The initial stream 4189 maximum data for bidirectional, peer-initiated streams parameter 4190 contains the initial flow control limit for newly created 4191 bidirectional streams opened by the endpoint that receives the 4192 transport parameter. In client transport parameters, this applies 4193 to streams with an identifier ending in 0x1; in server transport 4194 parameters, this applies to streams ending in 0x0. 4196 initial_max_stream_data_uni (0x000b): The initial stream maximum 4197 data for unidirectional streams parameter contains the initial 4198 flow control limit for newly created unidirectional streams opened 4199 by the endpoint that receives the transport parameter. In client 4200 transport parameters, this applies to streams with an identifier 4201 ending in 0x3; in server transport parameters, this applies to 4202 streams ending in 0x2. 4204 If present, transport parameters that set initial flow control limits 4205 (initial_max_stream_data_bidi_local, 4206 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 4207 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.6) on 4208 every stream of the corresponding type immediately after opening. If 4209 the transport parameter is absent, streams of that type start with a 4210 flow control limit of 0. 4212 initial_max_data (0x0001): The initial maximum data parameter 4213 contains the initial value for the maximum amount of data that can 4214 be sent on the connection. This parameter is encoded as an 4215 unsigned 32-bit integer in units of octets. This is equivalent to 4216 sending a MAX_DATA (Section 19.5) for the connection immediately 4217 after completing the handshake. If the transport parameter is 4218 absent, the connection starts with a flow control limit of 0. 4220 initial_max_bidi_streams (0x0002): The initial maximum bidirectional 4221 streams parameter contains the initial maximum number of 4222 bidirectional streams the peer may initiate, encoded as an 4223 unsigned 16-bit integer. If this parameter is absent or zero, 4224 bidirectional streams cannot be created until a MAX_STREAM_ID 4225 frame is sent. Setting this parameter is equivalent to sending a 4226 MAX_STREAM_ID (Section 19.7) immediately after completing the 4227 handshake containing the corresponding Stream ID. For example, a 4228 value of 0x05 would be equivalent to receiving a MAX_STREAM_ID 4229 containing 16 when received by a client or 17 when received by a 4230 server. 4232 initial_max_uni_streams (0x0008): The initial maximum unidirectional 4233 streams parameter contains the initial maximum number of 4234 unidirectional streams the peer may initiate, encoded as an 4235 unsigned 16-bit integer. If this parameter is absent or zero, 4236 unidirectional streams cannot be created until a MAX_STREAM_ID 4237 frame is sent. Setting this parameter is equivalent to sending a 4238 MAX_STREAM_ID (Section 19.7) immediately after completing the 4239 handshake containing the corresponding Stream ID. For example, a 4240 value of 0x05 would be equivalent to receiving a MAX_STREAM_ID 4241 containing 18 when received by a client or 19 when received by a 4242 server. 4244 A server MUST include the following transport parameter if it sent a 4245 Retry packet: 4247 original_connection_id (0x000d): The value of the Destination 4248 Connection ID field from the first Initial packet sent by the 4249 client. This transport parameter is only sent by the server. 4251 A server MAY include the following transport parameters: 4253 stateless_reset_token (0x0006): The Stateless Reset Token is used in 4254 verifying a stateless reset, see Section 10.4. This parameter is 4255 a sequence of 16 octets. 4257 preferred_address (0x0004): The server's Preferred Address is used 4258 to effect a change in server address at the end of the handshake, 4259 as described in Section 9.6. 4261 A client MUST NOT include an original connection ID, a stateless 4262 reset token, or a preferred address. A server MUST treat receipt of 4263 any of these transport parameters as a connection error of type 4264 TRANSPORT_PARAMETER_ERROR. 4266 19. Frame Types and Formats 4268 As described in Section 12.4, packets contain one or more frames. 4269 This section describes the format and semantics of the core QUIC 4270 frame types. 4272 19.1. PADDING Frame 4274 The PADDING frame (type=0x00) has no semantic value. PADDING frames 4275 can be used to increase the size of a packet. Padding can be used to 4276 increase an initial client packet to the minimum required size, or to 4277 provide protection against traffic analysis for protected packets. 4279 A PADDING frame has no content. That is, a PADDING frame consists of 4280 the single octet that identifies the frame as a PADDING frame. 4282 19.2. RST_STREAM Frame 4284 An endpoint may use a RST_STREAM frame (type=0x01) to abruptly 4285 terminate a stream. 4287 After sending a RST_STREAM, an endpoint ceases transmission and 4288 retransmission of STREAM frames on the identified stream. A receiver 4289 of RST_STREAM can discard any data that it already received on that 4290 stream. 4292 An endpoint that receives a RST_STREAM frame for a send-only stream 4293 MUST terminate the connection with error PROTOCOL_VIOLATION. 4295 The RST_STREAM frame is as follows: 4297 0 1 2 3 4298 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 4299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4300 | Stream ID (i) ... 4301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4302 | Application Error Code (16) | 4303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4304 | Final Offset (i) ... 4305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4307 The fields are: 4309 Stream ID: A variable-length integer encoding of the Stream ID of 4310 the stream being terminated. 4312 Application Protocol Error Code: A 16-bit application protocol error 4313 code (see Section 20.1) which indicates why the stream is being 4314 closed. 4316 Final Offset: A variable-length integer indicating the absolute byte 4317 offset of the end of data written on this stream by the RST_STREAM 4318 sender. 4320 19.3. CONNECTION_CLOSE frame 4322 An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its 4323 peer that the connection is being closed. CONNECTION_CLOSE is used 4324 to signal errors at the QUIC layer, or the absence of errors (with 4325 the NO_ERROR code). 4327 If there are open streams that haven't been explicitly closed, they 4328 are implicitly closed when the connection is closed. 4330 The CONNECTION_CLOSE frame is as follows: 4332 0 1 2 3 4333 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 4334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4335 | Error Code (16) | 4336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4337 | Frame Type (i) ... 4338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4339 | Reason Phrase Length (i) ... 4340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4341 | Reason Phrase (*) ... 4342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4344 The fields of a CONNECTION_CLOSE frame are as follows: 4346 Error Code: A 16-bit error code which indicates the reason for 4347 closing this connection. CONNECTION_CLOSE uses codes from the 4348 space defined in Section 20. 4350 Frame Type: A variable-length integer encoding the type of frame 4351 that triggered the error. A value of 0 (equivalent to the mention 4352 of the PADDING frame) is used when the frame type is unknown. 4354 Reason Phrase Length: A variable-length integer specifying the 4355 length of the reason phrase in bytes. Note that a 4356 CONNECTION_CLOSE frame cannot be split between packets, so in 4357 practice any limits on packet size will also limit the space 4358 available for a reason phrase. 4360 Reason Phrase: A human-readable explanation for why the connection 4361 was closed. This can be zero length if the sender chooses to not 4362 give details beyond the Error Code. This SHOULD be a UTF-8 4363 encoded string [RFC3629]. 4365 19.4. APPLICATION_CLOSE frame 4367 An APPLICATION_CLOSE frame (type=0x03) is used to signal an error 4368 with the protocol that uses QUIC. 4370 The APPLICATION_CLOSE frame is as follows: 4372 0 1 2 3 4373 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 4374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4375 | Error Code (16) | 4376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4377 | Reason Phrase Length (i) ... 4378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4379 | Reason Phrase (*) ... 4380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4382 The fields of an APPLICATION_CLOSE frame are as follows: 4384 Error Code: A 16-bit error code which indicates the reason for 4385 closing this connection. APPLICATION_CLOSE uses codes from the 4386 application protocol error code space, see Section 20.1. 4388 Reason Phrase Length: This field is identical in format and 4389 semantics to the Reason Phrase Length field from CONNECTION_CLOSE. 4391 Reason Phrase: This field is identical in format and semantics to 4392 the Reason Phrase field from CONNECTION_CLOSE. 4394 APPLICATION_CLOSE has similar format and semantics to the 4395 CONNECTION_CLOSE frame (Section 19.3). Aside from the semantics of 4396 the Error Code field and the omission of the Frame Type field, both 4397 frames are used to close the connection. 4399 19.5. MAX_DATA Frame 4401 The MAX_DATA frame (type=0x04) is used in flow control to inform the 4402 peer of the maximum amount of data that can be sent on the connection 4403 as a whole. 4405 The frame is as follows: 4407 0 1 2 3 4408 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 4409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4410 | Maximum Data (i) ... 4411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4412 The fields in the MAX_DATA frame are as follows: 4414 Maximum Data: A variable-length integer indicating the maximum 4415 amount of data that can be sent on the entire connection, in units 4416 of octets. 4418 All data sent in STREAM frames counts toward this limit. The sum of 4419 the largest received offsets on all streams - including streams in 4420 terminal states - MUST NOT exceed the value advertised by a receiver. 4421 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 4422 error if it receives more data than the maximum data value that it 4423 has sent, unless this is a result of a change in the initial limits 4424 (see Section 7.3.1). 4426 19.6. MAX_STREAM_DATA Frame 4428 The MAX_STREAM_DATA frame (type=0x05) is used in flow control to 4429 inform a peer of the maximum amount of data that can be sent on a 4430 stream. 4432 An endpoint that receives a MAX_STREAM_DATA frame for a receive-only 4433 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 4435 An endpoint that receives a MAX_STREAM_DATA frame for a send-only 4436 stream it has not opened MUST terminate the connection with error 4437 PROTOCOL_VIOLATION. 4439 Note that an endpoint may legally receive a MAX_STREAM_DATA frame on 4440 a bidirectional stream it has not opened. 4442 The frame is as follows: 4444 0 1 2 3 4445 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 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4447 | Stream ID (i) ... 4448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4449 | Maximum Stream Data (i) ... 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4452 The fields in the MAX_STREAM_DATA frame are as follows: 4454 Stream ID: The stream ID of the stream that is affected encoded as a 4455 variable-length integer. 4457 Maximum Stream Data: A variable-length integer indicating the 4458 maximum amount of data that can be sent on the identified stream, 4459 in units of octets. 4461 When counting data toward this limit, an endpoint accounts for the 4462 largest received offset of data that is sent or received on the 4463 stream. Loss or reordering can mean that the largest received offset 4464 on a stream can be greater than the total size of data received on 4465 that stream. Receiving STREAM frames might not increase the largest 4466 received offset. 4468 The data sent on a stream MUST NOT exceed the largest maximum stream 4469 data value advertised by the receiver. An endpoint MUST terminate a 4470 connection with a FLOW_CONTROL_ERROR error if it receives more data 4471 than the largest maximum stream data that it has sent for the 4472 affected stream, unless this is a result of a change in the initial 4473 limits (see Section 7.3.1). 4475 19.7. MAX_STREAM_ID Frame 4477 The MAX_STREAM_ID frame (type=0x06) informs the peer of the maximum 4478 stream ID that they are permitted to open. 4480 The frame is as follows: 4482 0 1 2 3 4483 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 4484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4485 | Maximum Stream ID (i) ... 4486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4488 The fields in the MAX_STREAM_ID frame are as follows: 4490 Maximum Stream ID: ID of the maximum unidirectional or bidirectional 4491 peer-initiated stream ID for the connection encoded as a variable- 4492 length integer. The limit applies to unidirectional steams if the 4493 second least signification bit of the stream ID is 1, and applies 4494 to bidirectional streams if it is 0. 4496 Loss or reordering can mean that a MAX_STREAM_ID frame can be 4497 received which states a lower stream limit than the client has 4498 previously received. MAX_STREAM_ID frames which do not increase the 4499 maximum stream ID MUST be ignored. 4501 A peer MUST NOT initiate a stream with a higher stream ID than the 4502 greatest maximum stream ID it has received. An endpoint MUST 4503 terminate a connection with a STREAM_ID_ERROR error if a peer 4504 initiates a stream with a higher stream ID than it has sent, unless 4505 this is a result of a change in the initial limits (see 4506 Section 7.3.1). 4508 19.8. PING Frame 4510 Endpoints can use PING frames (type=0x07) to verify that their peers 4511 are still alive or to check reachability to the peer. The PING frame 4512 contains no additional fields. 4514 The receiver of a PING frame simply needs to acknowledge the packet 4515 containing this frame. 4517 The PING frame can be used to keep a connection alive when an 4518 application or application protocol wishes to prevent the connection 4519 from timing out. An application protocol SHOULD provide guidance 4520 about the conditions under which generating a PING is recommended. 4521 This guidance SHOULD indicate whether it is the client or the server 4522 that is expected to send the PING. Having both endpoints send PING 4523 frames without coordination can produce an excessive number of 4524 packets and poor performance. 4526 A connection will time out if no packets are sent or received for a 4527 period longer than the time specified in the idle_timeout transport 4528 parameter (see Section 10). However, state in middleboxes might time 4529 out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 4530 minute timeout interval, experience shows that sending packets every 4531 15 to 30 seconds is necessary to prevent the majority of middleboxes 4532 from losing state for UDP flows. 4534 19.9. BLOCKED Frame 4536 A sender SHOULD send a BLOCKED frame (type=0x08) when it wishes to 4537 send data, but is unable to due to connection-level flow control (see 4538 Section 4). BLOCKED frames can be used as input to tuning of flow 4539 control algorithms (see Section 4.2). 4541 The BLOCKED frame is as follows: 4543 0 1 2 3 4544 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 4545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4546 | Offset (i) ... 4547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4549 The BLOCKED frame contains a single field. 4551 Offset: A variable-length integer indicating the connection-level 4552 offset at which the blocking occurred. 4554 19.10. STREAM_BLOCKED Frame 4556 A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it 4557 wishes to send data, but is unable to due to stream-level flow 4558 control. This frame is analogous to BLOCKED (Section 19.9). 4560 An endpoint that receives a STREAM_BLOCKED frame for a send-only 4561 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 4563 The STREAM_BLOCKED frame is as follows: 4565 0 1 2 3 4566 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 4567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4568 | Stream ID (i) ... 4569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4570 | Offset (i) ... 4571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4573 The STREAM_BLOCKED frame contains two fields: 4575 Stream ID: A variable-length integer indicating the stream which is 4576 flow control blocked. 4578 Offset: A variable-length integer indicating the offset of the 4579 stream at which the blocking occurred. 4581 19.11. STREAM_ID_BLOCKED Frame 4583 A sender SHOULD send a STREAM_ID_BLOCKED frame (type=0x0a) when it 4584 wishes to open a stream, but is unable to due to the maximum stream 4585 ID limit set by its peer (see Section 19.7). This does not open the 4586 stream, but informs the peer that a new stream was needed, but the 4587 stream limit prevented the creation of the stream. 4589 The STREAM_ID_BLOCKED frame is as follows: 4591 0 1 2 3 4592 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 4593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4594 | Stream ID (i) ... 4595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4597 The STREAM_ID_BLOCKED frame contains a single field. 4599 Stream ID: A variable-length integer indicating the highest stream 4600 ID that the sender was permitted to open. 4602 19.12. NEW_CONNECTION_ID Frame 4604 An endpoint sends a NEW_CONNECTION_ID frame (type=0x0b) to provide 4605 its peer with alternative connection IDs that can be used to break 4606 linkability when migrating connections (see Section 9.5). 4608 The NEW_CONNECTION_ID frame is as follows: 4610 0 1 2 3 4611 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 4612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4613 | Length (8) | Sequence Number (i) ... 4614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4615 | Connection ID (32..144) ... 4616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4617 | | 4618 + + 4619 | | 4620 + Stateless Reset Token (128) + 4621 | | 4622 + + 4623 | | 4624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4626 The fields are: 4628 Length: An 8-bit unsigned integer containing the length of the 4629 connection ID. Values less than 4 and greater than 18 are invalid 4630 and MUST be treated as a connection error of type 4631 PROTOCOL_VIOLATION. 4633 Sequence Number: The sequence number assigned to the connection ID 4634 by the sender. See Section 5.1.1. 4636 Connection ID: A connection ID of the specified length. 4638 Stateless Reset Token: A 128-bit value that will be used for a 4639 stateless reset when the associated connection ID is used (see 4640 Section 10.4). 4642 An endpoint MUST NOT send this frame if it currently requires that 4643 its peer send packets with a zero-length Destination Connection ID. 4644 Changing the length of a connection ID to or from zero-length makes 4645 it difficult to identify when the value of the connection ID changed. 4646 An endpoint that is sending packets with a zero-length Destination 4647 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 4648 connection error of type PROTOCOL_VIOLATION. 4650 Transmission errors, timeouts and retransmissions might cause the 4651 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 4652 of the same frame multiple times MUST NOT be treated as a connection 4653 error. A receiver can use the sequence number supplied in the 4654 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 4656 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 4657 previously issued connection ID with a different Stateless Reset 4658 Token or a different sequence number, the endpoint MAY treat that 4659 receipt as a connection error of type PROTOCOL_VIOLATION. 4661 19.13. RETIRE_CONNECTION_ID Frame 4663 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x1b) to 4664 indicate that it will no longer use a connection ID that was issued 4665 by its peer. This may include the connection ID provided during the 4666 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 4667 request to the peer to send additional connection IDs for future use 4668 (see Section 5.1). New connection IDs can be delivered to a peer 4669 using the NEW_CONNECTION_ID frame (Section 19.12). 4671 Retiring a connection ID invalidates the stateless reset token 4672 associated with that connection ID. 4674 The RETIRE_CONNECTION_ID frame is as follows: 4676 0 1 2 3 4677 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 4678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4679 | Sequence Number (i) ... 4680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4682 The fields are: 4684 Sequence Number: The sequence number of the connection ID being 4685 retired. See Section 5.1.2. 4687 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 4688 greater than any previously sent to the peer MAY be treated as a 4689 connection error of type PROTOCOL_VIOLATION. 4691 An endpoint cannot send this frame if it was provided with a zero- 4692 length connection ID by its peer. An endpoint that provides a zero- 4693 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 4694 frame as a connection error of type PROTOCOL_VIOLATION. 4696 19.14. STOP_SENDING Frame 4698 An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate 4699 that incoming data is being discarded on receipt at application 4700 request. This signals a peer to abruptly terminate transmission on a 4701 stream. 4703 Receipt of a STOP_SENDING frame is only valid for a send stream that 4704 exists and is not in the "Ready" state (see Section 3.1). Receiving 4705 a STOP_SENDING frame for a send stream that is "Ready" or non- 4706 existent MUST be treated as a connection error of type 4707 PROTOCOL_VIOLATION. An endpoint that receives a STOP_SENDING frame 4708 for a receive-only stream MUST terminate the connection with error 4709 PROTOCOL_VIOLATION. 4711 The STOP_SENDING frame is as follows: 4713 0 1 2 3 4714 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 4715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4716 | Stream ID (i) ... 4717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4718 | Application Error Code (16) | 4719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4721 The fields are: 4723 Stream ID: A variable-length integer carrying the Stream ID of the 4724 stream being ignored. 4726 Application Error Code: A 16-bit, application-specified reason the 4727 sender is ignoring the stream (see Section 20.1). 4729 19.15. ACK Frame 4731 Receivers send ACK frames (types 0x1a and 0x1b) to inform senders of 4732 packets they have received and processed. The ACK frame contains one 4733 or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. 4734 If the frame type is 0x1b, ACK frames also contain the sum of ECN 4735 marks received on the connection up until this point. 4737 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 4738 remains acknowledged, even if it does not appear in a future ACK 4739 frame. This is unlike TCP SACKs ([RFC2018]). 4741 It is expected that a sender will reuse the same packet number across 4742 different packet number spaces. ACK frames only acknowledge the 4743 packet numbers that were transmitted by the sender in the same packet 4744 number space of the packet that the ACK was received in. 4746 Version Negotiation and Retry packets cannot be acknowledged because 4747 they do not contain a packet number. Rather than relying on ACK 4748 frames, these packets are implicitly acknowledged by the next Initial 4749 packet sent by the client. 4751 An ACK frame is shown below. 4753 0 1 2 3 4754 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 4755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4756 | Largest Acknowledged (i) ... 4757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4758 | ACK Delay (i) ... 4759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 | ACK Block Count (i) ... 4761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4762 | ACK Blocks (*) ... 4763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4764 | [ECN Section] ... 4765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4767 Figure 16: ACK Frame Format 4769 The fields in the ACK frame are as follows: 4771 Largest Acknowledged: A variable-length integer representing the 4772 largest packet number the peer is acknowledging; this is usually 4773 the largest packet number that the peer has received prior to 4774 generating the ACK frame. Unlike the packet number in the QUIC 4775 long or short header, the value in an ACK frame is not truncated. 4777 ACK Delay: A variable-length integer including the time in 4778 microseconds that the largest acknowledged packet, as indicated in 4779 the Largest Acknowledged field, was received by this peer to when 4780 this ACK was sent. The value of the ACK Delay field is scaled by 4781 multiplying the encoded value by 2 to the power of the value of 4782 the "ack_delay_exponent" transport parameter set by the sender of 4783 the ACK frame. The "ack_delay_exponent" defaults to 3, or a 4784 multiplier of 8 (see Section 18.1). Scaling in this fashion 4785 allows for a larger range of values with a shorter encoding at the 4786 cost of lower resolution. 4788 ACK Block Count: A variable-length integer specifying the number of 4789 Additional ACK Block (and Gap) fields after the First ACK Block. 4791 ACK Blocks: Contains one or more blocks of packet numbers which have 4792 been successfully received, see Section 19.15.1. 4794 19.15.1. ACK Block Section 4796 The ACK Block Section consists of alternating Gap and ACK Block 4797 fields in descending packet number order. A First Ack Block field is 4798 followed by a variable number of alternating Gap and Additional ACK 4799 Blocks. The number of Gap and Additional ACK Block fields is 4800 determined by the ACK Block Count field. 4802 Gap and ACK Block fields use a relative integer encoding for 4803 efficiency. Though each encoded value is positive, the values are 4804 subtracted, so that each ACK Block describes progressively lower- 4805 numbered packets. As long as contiguous ranges of packets are small, 4806 the variable-length integer encoding ensures that each range can be 4807 expressed in a small number of octets. 4809 The ACK frame uses the least significant bit(bit (that is, type 0x1b) 4810 to indicate ECN feedback and report receipt of packets with ECN 4811 codepoints of ECT(0), ECT(1), or CE in the packet's IP header. 4813 0 1 2 3 4814 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 4815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4816 | First ACK Block (i) ... 4817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4818 | Gap (i) ... 4819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4820 | Additional ACK Block (i) ... 4821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4822 | Gap (i) ... 4823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4824 | Additional ACK Block (i) ... 4825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 ... 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4828 | Gap (i) ... 4829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4830 | Additional ACK Block (i) ... 4831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4833 Figure 17: ACK Block Section 4835 Each ACK Block acknowledges a contiguous range of packets by 4836 indicating the number of acknowledged packets that precede the 4837 largest packet number in that block. A value of zero indicates that 4838 only the largest packet number is acknowledged. Larger ACK Block 4839 values indicate a larger range, with corresponding lower values for 4840 the smallest packet number in the range. Thus, given a largest 4841 packet number for the ACK, the smallest value is determined by the 4842 formula: 4844 smallest = largest - ack_block 4846 The range of packets that are acknowledged by the ACK Block include 4847 the range from the smallest packet number to the largest, inclusive. 4849 The largest value for the First ACK Block is determined by the 4850 Largest Acknowledged field; the largest for Additional ACK Blocks is 4851 determined by cumulatively subtracting the size of all preceding ACK 4852 Blocks and Gaps. 4854 Each Gap indicates a range of packets that are not being 4855 acknowledged. The number of packets in the gap is one higher than 4856 the encoded value of the Gap Field. 4858 The value of the Gap field establishes the largest packet number 4859 value for the ACK Block that follows the gap using the following 4860 formula: 4862 largest = previous_smallest - gap - 2 4864 If the calculated value for largest or smallest packet number for any 4865 ACK Block is negative, an endpoint MUST generate a connection error 4866 of type FRAME_ENCODING_ERROR indicating an error in an ACK frame. 4868 The fields in the ACK Block Section are: 4870 First ACK Block: A variable-length integer indicating the number of 4871 contiguous packets preceding the Largest Acknowledged that are 4872 being acknowledged. 4874 Gap (repeated): A variable-length integer indicating the number of 4875 contiguous unacknowledged packets preceding the packet number one 4876 lower than the smallest in the preceding ACK Block. 4878 Additional ACK Block (repeated): A variable-length integer 4879 indicating the number of contiguous acknowledged packets preceding 4880 the largest packet number, as determined by the preceding Gap. 4882 19.15.2. ECN section 4884 The ECN section should only be parsed when the ACK frame type byte is 4885 0x1b. The ECN section consists of 3 ECN counters as shown below. 4887 0 1 2 3 4888 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 4889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4890 | ECT(0) Count (i) ... 4891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4892 | ECT(1) Count (i) ... 4893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4894 | ECN-CE Count (i) ... 4895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4897 ECT(0) Count: A variable-length integer representing the total 4898 number packets received with the ECT(0) codepoint. 4900 ECT(1) Count: A variable-length integer representing the total 4901 number packets received with the ECT(1) codepoint. 4903 CE Count: A variable-length integer representing the total number 4904 packets received with the CE codepoint. 4906 19.16. PATH_CHALLENGE Frame 4908 Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check 4909 reachability to the peer and for path validation during connection 4910 migration. 4912 PATH_CHALLENGE frames contain an 8-byte payload. 4914 0 1 2 3 4915 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 4916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4917 | | 4918 + Data (8) + 4919 | | 4920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4922 Data: This 8-byte field contains arbitrary data. 4924 A PATH_CHALLENGE frame containing 8 octets that are hard to guess is 4925 sufficient to ensure that it is easier to receive the packet than it 4926 is to guess the value correctly. 4928 The recipient of this frame MUST generate a PATH_RESPONSE frame 4929 (Section 19.17) containing the same Data. 4931 19.17. PATH_RESPONSE Frame 4933 The PATH_RESPONSE frame (type=0x0f) is sent in response to a 4934 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 4935 frame (Section 19.16). 4937 If the content of a PATH_RESPONSE frame does not match the content of 4938 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 4939 MAY generate a connection error of type PROTOCOL_VIOLATION. 4941 19.18. NEW_TOKEN frame 4943 A server sends a NEW_TOKEN frame (type=0x19) to provide the client a 4944 token to send in the header of an Initial packet for a future 4945 connection. 4947 The NEW_TOKEN frame is as follows: 4949 0 1 2 3 4950 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 4951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4952 | Token Length (i) ... 4953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4954 | Token (*) ... 4955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4957 The fields of a NEW_TOKEN frame are as follows: 4959 Token Length: A variable-length integer specifying the length of the 4960 token in bytes. 4962 Token: An opaque blob that the client may use with a future Initial 4963 packet. 4965 19.19. STREAM Frames 4967 STREAM frames implicitly create a stream and carry stream data. The 4968 STREAM frame takes the form 0b00010XXX (or the set of values from 4969 0x10 to 0x17). The value of the three low-order bits of the frame 4970 type determine the fields that are present in the frame. 4972 o The OFF bit (0x04) in the frame type is set to indicate that there 4973 is an Offset field present. When set to 1, the Offset field is 4974 present; when set to 0, the Offset field is absent and the Stream 4975 Data starts at an offset of 0 (that is, the frame contains the 4976 first octets of the stream, or the end of a stream that includes 4977 no data). 4979 o The LEN bit (0x02) in the frame type is set to indicate that there 4980 is a Length field present. If this bit is set to 0, the Length 4981 field is absent and the Stream Data field extends to the end of 4982 the packet. If this bit is set to 1, the Length field is present. 4984 o The FIN bit (0x01) of the frame type is set only on frames that 4985 contain the final offset of the stream. Setting this bit 4986 indicates that the frame marks the end of the stream. 4988 An endpoint that receives a STREAM frame for a send-only stream MUST 4989 terminate the connection with error PROTOCOL_VIOLATION. 4991 A STREAM frame is shown below. 4993 0 1 2 3 4994 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 4995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4996 | Stream ID (i) ... 4997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4998 | [Offset (i)] ... 4999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5000 | [Length (i)] ... 5001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5002 | Stream Data (*) ... 5003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5005 Figure 18: STREAM Frame Format 5007 The STREAM frame contains the following fields: 5009 Stream ID: A variable-length integer indicating the stream ID of the 5010 stream (see Section 2.1). 5012 Offset: A variable-length integer specifying the byte offset in the 5013 stream for the data in this STREAM frame. This field is present 5014 when the OFF bit is set to 1. When the Offset field is absent, 5015 the offset is 0. 5017 Length: A variable-length integer specifying the length of the 5018 Stream Data field in this STREAM frame. This field is present 5019 when the LEN bit is set to 1. When the LEN bit is set to 0, the 5020 Stream Data field consumes all the remaining octets in the packet. 5022 Stream Data: The bytes from the designated stream to be delivered. 5024 When a Stream Data field has a length of 0, the offset in the STREAM 5025 frame is the offset of the next byte that would be sent. 5027 The first byte in the stream has an offset of 0. The largest offset 5028 delivered on a stream - the sum of the re-constructed offset and data 5029 length - MUST be less than 2^62. 5031 19.20. CRYPTO Frame 5033 The CRYPTO frame (type=0x18) is used to transmit cryptographic 5034 handshake messages. It can be sent in all packet types. The CRYPTO 5035 frame offers the cryptographic protocol an in-order stream of bytes. 5036 CRYPTO frames are functionally identical to STREAM frames, except 5037 that they do not bear a stream identifier; they are not flow 5038 controlled; and they do not carry markers for optional offset, 5039 optional length, and the end of the stream. 5041 A CRYPTO frame is shown below. 5043 0 1 2 3 5044 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 5045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5046 | Offset (i) ... 5047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5048 | Length (i) ... 5049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5050 | Crypto Data (*) ... 5051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5053 Figure 19: CRYPTO Frame Format 5055 The CRYPTO frame contains the following fields: 5057 Offset: A variable-length integer specifying the byte offset in the 5058 stream for the data in this CRYPTO frame. 5060 Length: A variable-length integer specifying the length of the 5061 Crypto Data field in this CRYPTO frame. 5063 Crypto Data: The cryptographic message data. 5065 There is a separate flow of cryptographic handshake data in each 5066 encryption level, each of which starts at an offset of 0. This 5067 implies that each encryption level is treated as a separate CRYPTO 5068 stream of data. 5070 Unlike STREAM frames, which include a Stream ID indicating to which 5071 stream the data belongs, the CRYPTO frame carries data for a single 5072 stream per encryption level. The stream does not have an explicit 5073 end, so CRYPTO frames do not have a FIN bit. 5075 19.21. Extension Frames 5077 QUIC frames do not use a self-describing encoding. An endpoint 5078 therefore needs to understand the syntax of all frames before it can 5079 successfully process a packet. This allows for efficient encoding of 5080 frames, but it means that an endpoint cannot send a frame of a type 5081 that is unknown to its peer. 5083 An extension to QUIC that wishes to use a new type of frame MUST 5084 first ensure that a peer is able to understand the frame. An 5085 endpoint can use a transport parameter to signal its willingness to 5086 receive one or more extension frame types with the one transport 5087 parameter. 5089 Extension frames MUST be congestion controlled and MUST cause an ACK 5090 frame to be sent. The exception is extension frames that replace or 5091 supplement the ACK frame. Extension frames are not included in flow 5092 control unless specified in the extension. 5094 An IANA registry is used to manage the assignment of frame types, see 5095 Section 22.2. 5097 20. Transport Error Codes 5099 QUIC error codes are 16-bit unsigned integers. 5101 This section lists the defined QUIC transport error codes that may be 5102 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5103 connection. 5105 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5106 signal that the connection is being closed abruptly in the absence 5107 of any error. 5109 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5110 cannot continue with the connection. 5112 SERVER_BUSY (0x2): The server is currently busy and does not accept 5113 any new connections. 5115 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5116 permitted in its advertised data limits (see Section 4). 5118 STREAM_ID_ERROR (0x4): An endpoint received a frame for a stream 5119 identifier that exceeded its advertised maximum stream ID. 5121 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5122 that was not in a state that permitted that frame (see Section 3). 5124 FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame 5125 containing data that exceeded the previously established final 5126 offset. Or an endpoint received a RST_STREAM frame containing a 5127 final offset that was lower than the maximum offset of data that 5128 was already received. Or an endpoint received a RST_STREAM frame 5129 containing a different final offset to the one already 5130 established. 5132 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5133 badly formatted. For instance, a frame of an unknown type, or an 5134 ACK frame that has more acknowledgment ranges than the remainder 5135 of the packet could carry. 5137 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5138 parameters that were badly formatted, included an invalid value, 5139 was absent even though it is mandatory, was present though it is 5140 forbidden, or is otherwise in error. 5142 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 5143 parameters that contained version negotiation parameters that 5144 disagreed with the version negotiation that it performed. This 5145 error code indicates a potential version downgrade attack. 5147 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5148 protocol compliance that was not covered by more specific error 5149 codes. 5151 INVALID_MIGRATION (0xC): A peer has migrated to a different network 5152 when the endpoint had disabled migration. 5154 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5155 of 256 values is reserved for carrying error codes specific to the 5156 cryptographic handshake that is used. Codes for errors occurring 5157 when TLS is used for the crypto handshake are described in 5158 Section 4.8 of [QUIC-TLS]. 5160 See Section 22.3 for details of registering new error codes. 5162 20.1. Application Protocol Error Codes 5164 Application protocol error codes are 16-bit unsigned integers, but 5165 the management of application error codes are left to application 5166 protocols. Application protocol error codes are used for the 5167 RST_STREAM (Section 19.2) and APPLICATION_CLOSE (Section 19.4) 5168 frames. 5170 There is no restriction on the use of the 16-bit error code space for 5171 application protocols. However, QUIC reserves the error code with a 5172 value of 0 to mean STOPPING. The application error code of STOPPING 5173 (0) is used by the transport to cancel a stream in response to 5174 receipt of a STOP_SENDING frame. 5176 21. Security Considerations 5178 21.1. Handshake Denial of Service 5180 As an encrypted and authenticated transport QUIC provides a range of 5181 protections against denial of service. Once the cryptographic 5182 handshake is complete, QUIC endpoints discard most packets that are 5183 not authenticated, greatly limiting the ability of an attacker to 5184 interfere with existing connections. 5186 Once a connection is established QUIC endpoints might accept some 5187 unauthenticated ICMP packets (see Section 14.1.1), but the use of 5188 these packets is extremely limited. The only other type of packet 5189 that an endpoint might accept is a stateless reset (Section 10.4) 5190 which relies on the token being kept secret until it is used. 5192 During the creation of a connection, QUIC only provides protection 5193 against attack from off the network path. All QUIC packets contain 5194 proof that the recipient saw a preceding packet from its peer. 5196 The first mechanism used is the source and destination connection 5197 IDs, which are required to match those set by a peer. Except for an 5198 Initial and stateless reset packets, an endpoint only accepts packets 5199 that include a destination connection that matches a connection ID 5200 the endpoint previously chose. This is the only protection offered 5201 for Version Negotiation packets. 5203 The destination connection ID in an Initial packet is selected by a 5204 client to be unpredictable, which serves an additional purpose. The 5205 packets that carry the cryptographic handshake are protected with a 5206 key that is derived from this connection ID and salt specific to the 5207 QUIC version. This allows endpoints to use the same process for 5208 authenticating packets that they receive as they use after the 5209 cryptographic handshake completes. Packets that cannot be 5210 authenticated are discarded. Protecting packets in this fashion 5211 provides a strong assurance that the sender of the packet saw the 5212 Initial packet and understood it. 5214 These protections are not intended to be effective against an 5215 attacker that is able to receive QUIC packets prior to the connection 5216 being established. Such an attacker can potentially send packets 5217 that will be accepted by QUIC endpoints. This version of QUIC 5218 attempts to detect this sort of attack, but it expects that endpoints 5219 will fail to establish a connection rather than recovering. For the 5220 most part, the cryptographic handshake protocol [QUIC-TLS] is 5221 responsible for detecting tampering during the handshake, though 5222 additional validation is required for version negotiation (see 5223 Section 7.3.3). 5225 Endpoints are permitted to use other methods to detect and attempt to 5226 recover from interference with the handshake. Invalid packets may be 5227 identified and discarded using other methods, but no specific method 5228 is mandated in this document. 5230 21.2. Spoofed ACK Attack 5232 An attacker might be able to receive an address validation token 5233 (Section 8) from the server and then release the IP address it used 5234 to acquire that token. The attacker may, in the future, spoof this 5235 same address (which now presumably addresses a different endpoint), 5236 and initiate a 0-RTT connection with a server on the victim's behalf. 5237 The attacker can then spoof ACK frames to the server which cause the 5238 server to send excessive amounts of data toward the new owner of the 5239 IP address. 5241 There are two possible mitigations to this attack. The simplest one 5242 is that a server can unilaterally create a gap in packet-number 5243 space. In the non-attack scenario, the client will send an ACK frame 5244 with the larger value for largest acknowledged. In the attack 5245 scenario, the attacker could acknowledge a packet in the gap. If the 5246 server sees an acknowledgment for a packet that was never sent, the 5247 connection can be aborted. 5249 The second mitigation is that the server can require that 5250 acknowledgments for sent packets match the encryption level of the 5251 sent packet. This mitigation is useful if the connection has an 5252 ephemeral forward-secure key that is generated and used for every new 5253 connection. If a packet sent is protected with a forward-secure key, 5254 then any acknowledgments that are received for them MUST also be 5255 forward-secure protected. Since the attacker will not have the 5256 forward-secure key, the attacker will not be able to generate 5257 forward-secure protected packets with ACK frames. 5259 21.3. Optimistic ACK Attack 5261 An endpoint that acknowledges packets it has not received might cause 5262 a congestion controller to permit sending at rates beyond what the 5263 network supports. An endpoint MAY skip packet numbers when sending 5264 packets to detect this behavior. An endpoint can then immediately 5265 close the connection with a connection error of type 5266 PROTOCOL_VIOLATION (see Section 10.3). 5268 21.4. Slowloris Attacks 5270 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 5271 connections to the target endpoint open and hold them open as long as 5272 possible. These attacks can be executed against a QUIC endpoint by 5273 generating the minimum amount of activity necessary to avoid being 5274 closed for inactivity. This might involve sending small amounts of 5275 data, gradually opening flow control windows in order to control the 5276 sender rate, or manufacturing ACK frames that simulate a high loss 5277 rate. 5279 QUIC deployments SHOULD provide mitigations for the Slowloris 5280 attacks, such as increasing the maximum number of clients the server 5281 will allow, limiting the number of connections a single IP address is 5282 allowed to make, imposing restrictions on the minimum transfer speed 5283 a connection is allowed to have, and restricting the length of time 5284 an endpoint is allowed to stay connected. 5286 21.5. Stream Fragmentation and Reassembly Attacks 5288 An adversarial sender might intentionally send fragments of stream 5289 data in order to cause disproportionate receive buffer memory 5290 commitment and/or creation of a large and inefficient data structure. 5292 An adversarial receiver might intentionally not acknowledge packets 5293 containing stream data in order to force the sender to store the 5294 unacknowledged stream data for retransmission. 5296 The attack on receivers is mitigated if flow control windows 5297 correspond to available memory. However, some receivers will over- 5298 commit memory and advertise flow control offsets in the aggregate 5299 that exceed actual available memory. The over-commitment strategy 5300 can lead to better performance when endpoints are well behaved, but 5301 renders endpoints vulnerable to the stream fragmentation attack. 5303 QUIC deployments SHOULD provide mitigations against stream 5304 fragmentation attacks. Mitigations could consist of avoiding over- 5305 committing memory, limiting the size of tracking data structures, 5306 delaying reassembly of STREAM frames, implementing heuristics based 5307 on the age and duration of reassembly holes, or some combination. 5309 21.6. Stream Commitment Attack 5311 An adversarial endpoint can open lots of streams, exhausting state on 5312 an endpoint. The adversarial endpoint could repeat the process on a 5313 large number of connections, in a manner similar to SYN flooding 5314 attacks in TCP. 5316 Normally, clients will open streams sequentially, as explained in 5317 Section 2.1. However, when several streams are initiated at short 5318 intervals, transmission error may cause STREAM DATA frames opening 5319 streams to be received out of sequence. A receiver is obligated to 5320 open intervening streams if a higher-numbered stream ID is received. 5321 Thus, on a new connection, opening stream 2000001 opens 1 million 5322 streams, as required by the specification. 5324 The number of active streams is limited by the concurrent stream 5325 limit transport parameter, as explained in Section 2.2. If chosen 5326 judiciously, this limit mitigates the effect of the stream commitment 5327 attack. However, setting the limit too low could affect performance 5328 when applications expect to open large number of streams. 5330 21.7. Explicit Congestion Notification Attacks 5332 An on-path attacker could manipulate the value of ECN codepoints in 5333 the IP header to influence the sender's rate. [RFC3168] discusses 5334 manipulations and their effects in more detail. 5336 An on-the-side attacker can duplicate and send packets with modified 5337 ECN codepoints to affect the sender's rate. If duplicate packets are 5338 discarded by a receiver, an off-path attacker will need to race the 5339 duplicate packet against the original to be successful in this 5340 attack. Therefore, QUIC receivers ignore ECN codepoints set in 5341 duplicate packets (see Section 13.3). 5343 21.8. Stateless Reset Oracle 5345 Stateless resets create a possible denial of service attack analogous 5346 to a TCP reset injection. This attack is possible if an attacker is 5347 able to cause a stateless reset token to be generated for a 5348 connection with a selected connection ID. An attacker that can cause 5349 this token to be generated can reset an active connection with the 5350 same connection ID. 5352 If a packet can be routed to different instances that share a static 5353 key, for example by changing an IP address or port, then an attacker 5354 can cause the server to send a stateless reset. To defend against 5355 this style of denial service, endpoints that share a static key for 5356 stateless reset (see Section 10.4.2) MUST be arranged so that packets 5357 with a given connection ID always arrive at an instance that has 5358 connection state, unless that connection is no longer active. 5360 In the case of a cluster that uses dynamic load balancing, it's 5361 possible that a change in load balancer configuration could happen 5362 while an active instance retains connection state; even if an 5363 instance retains connection state, the change in routing and 5364 resulting stateless reset will result in the connection being 5365 terminated. If there is no chance in the packet being routed to the 5366 correct instance, it is better to send a stateless reset than wait 5367 for connections to time out. However, this is acceptable only if the 5368 routing cannot be influenced by an attacker. 5370 22. IANA Considerations 5372 22.1. QUIC Transport Parameter Registry 5374 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 5375 under a "QUIC Protocol" heading. 5377 The "QUIC Transport Parameters" registry governs a 16-bit space. 5378 This space is split into two spaces that are governed by different 5379 policies. Values with the first byte in the range 0x00 to 0xfe (in 5380 hexadecimal) are assigned via the Specification Required policy 5381 [RFC8126]. Values with the first byte 0xff are reserved for Private 5382 Use [RFC8126]. 5384 Registrations MUST include the following fields: 5386 Value: The numeric value of the assignment (registrations will be 5387 between 0x0000 and 0xfeff). 5389 Parameter Name: A short mnemonic for the parameter. 5391 Specification: A reference to a publicly available specification for 5392 the value. 5394 The nominated expert(s) verify that a specification exists and is 5395 readily accessible. Expert(s) are encouraged to be biased towards 5396 approving registrations unless they are abusive, frivolous, or 5397 actively harmful (not merely aesthetically displeasing, or 5398 architecturally dubious). 5400 The initial contents of this registry are shown in Table 7. 5402 +--------+-------------------------------------+---------------+ 5403 | Value | Parameter Name | Specification | 5404 +--------+-------------------------------------+---------------+ 5405 | 0x0000 | initial_max_stream_data_bidi_local | Section 18.1 | 5406 | | | | 5407 | 0x0001 | initial_max_data | Section 18.1 | 5408 | | | | 5409 | 0x0002 | initial_max_bidi_streams | Section 18.1 | 5410 | | | | 5411 | 0x0003 | idle_timeout | Section 18.1 | 5412 | | | | 5413 | 0x0004 | preferred_address | Section 18.1 | 5414 | | | | 5415 | 0x0005 | max_packet_size | Section 18.1 | 5416 | | | | 5417 | 0x0006 | stateless_reset_token | Section 18.1 | 5418 | | | | 5419 | 0x0007 | ack_delay_exponent | Section 18.1 | 5420 | | | | 5421 | 0x0008 | initial_max_uni_streams | Section 18.1 | 5422 | | | | 5423 | 0x0009 | disable_migration | Section 18.1 | 5424 | | | | 5425 | 0x000a | initial_max_stream_data_bidi_remote | Section 18.1 | 5426 | | | | 5427 | 0x000b | initial_max_stream_data_uni | Section 18.1 | 5428 | | | | 5429 | 0x000c | max_ack_delay | Section 18.1 | 5430 | | | | 5431 | 0x000d | original_connection_id | Section 18.1 | 5432 +--------+-------------------------------------+---------------+ 5434 Table 7: Initial QUIC Transport Parameters Entries 5436 22.2. QUIC Frame Type Registry 5438 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 5439 "QUIC Protocol" heading. 5441 The "QUIC Frame Types" registry governs a 62-bit space. This space 5442 is split into three spaces that are governed by different policies. 5443 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 5444 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 5445 to 0x3fff operate on the Specification Required policy [RFC8126]. 5446 All other values are assigned to Private Use [RFC8126]. 5448 Registrations MUST include the following fields: 5450 Value: The numeric value of the assignment (registrations will be 5451 between 0x00 and 0x3fff). A range of values MAY be assigned. 5453 Frame Name: A short mnemonic for the frame type. 5455 Specification: A reference to a publicly available specification for 5456 the value. 5458 The nominated expert(s) verify that a specification exists and is 5459 readily accessible. Specifications for new registrations need to 5460 describe the means by which an endpoint might determine that it can 5461 send the identified type of frame. An accompanying transport 5462 parameter registration (see Section 22.1) is expected for most 5463 registrations. The specification needs to describe the format and 5464 assigned semantics of any fields in the frame. 5466 Expert(s) are encouraged to be biased towards approving registrations 5467 unless they are abusive, frivolous, or actively harmful (not merely 5468 aesthetically displeasing, or architecturally dubious). 5470 The initial contents of this registry are tabulated in Table 3. 5472 22.3. QUIC Transport Error Codes Registry 5474 IANA [SHALL add/has added] a registry for "QUIC Transport Error 5475 Codes" under a "QUIC Protocol" heading. 5477 The "QUIC Transport Error Codes" registry governs a 16-bit space. 5478 This space is split into two spaces that are governed by different 5479 policies. Values with the first byte in the range 0x00 to 0xfe (in 5480 hexadecimal) are assigned via the Specification Required policy 5481 [RFC8126]. Values with the first byte 0xff are reserved for Private 5482 Use [RFC8126]. 5484 Registrations MUST include the following fields: 5486 Value: The numeric value of the assignment (registrations will be 5487 between 0x0000 and 0xfeff). 5489 Code: A short mnemonic for the parameter. 5491 Description: A brief description of the error code semantics, which 5492 MAY be a summary if a specification reference is provided. 5494 Specification: A reference to a publicly available specification for 5495 the value. 5497 The initial contents of this registry are shown in Table 8. Values 5498 from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. 5500 +------+---------------------------+----------------+---------------+ 5501 | Valu | Error | Description | Specification | 5502 | e | | | | 5503 +------+---------------------------+----------------+---------------+ 5504 | 0x0 | NO_ERROR | No error | Section 20 | 5505 | | | | | 5506 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 5507 | | | error | | 5508 | | | | | 5509 | 0x2 | SERVER_BUSY | Server | Section 20 | 5510 | | | currently busy | | 5511 | | | | | 5512 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 5513 | | | error | | 5514 | | | | | 5515 | 0x4 | STREAM_ID_ERROR | Invalid stream | Section 20 | 5516 | | | ID | | 5517 | | | | | 5518 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 5519 | | | in invalid | | 5520 | | | stream state | | 5521 | | | | | 5522 | 0x6 | FINAL_OFFSET_ERROR | Change to | Section 20 | 5523 | | | final stream | | 5524 | | | offset | | 5525 | | | | | 5526 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 5527 | | | error | | 5528 | | | | | 5529 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 5530 | | | transport | | 5531 | | | parameters | | 5532 | | | | | 5533 | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 20 | 5534 | | | negotiation | | 5535 | | | failure | | 5536 | | | | | 5537 | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | 5538 | | | protocol | | 5539 | | | violation | | 5540 | | | | | 5541 | 0xC | INVALID_MIGRATION | Violated | Section 20 | 5542 | | | disabled | | 5543 | | | migration | | 5544 +------+---------------------------+----------------+---------------+ 5546 Table 8: Initial QUIC Transport Error Codes Entries 5548 23. References 5550 23.1. Normative References 5552 [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 5553 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 5554 . 5556 [PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5557 DOI 10.17487/RFC1191, November 1990, 5558 . 5560 [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5561 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5562 DOI 10.17487/RFC8201, July 2017, 5563 . 5565 [QUIC-RECOVERY] 5566 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5567 and Congestion Control", draft-ietf-quic-recovery-16 (work 5568 in progress), October 2018. 5570 [QUIC-TLS] 5571 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5572 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5573 tls-16 (work in progress), October 2018. 5575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5576 Requirement Levels", BCP 14, RFC 2119, 5577 DOI 10.17487/RFC2119, March 1997, 5578 . 5580 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5581 of Explicit Congestion Notification (ECN) to IP", 5582 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5583 . 5585 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 5586 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 5587 2003, . 5589 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5590 "Randomness Requirements for Security", BCP 106, RFC 4086, 5591 DOI 10.17487/RFC4086, June 2005, 5592 . 5594 [RFC5119] Edwards, T., "A Uniform Resource Name (URN) Namespace for 5595 the Society of Motion Picture and Television Engineers 5596 (SMPTE)", RFC 5119, DOI 10.17487/RFC5119, February 2008, 5597 . 5599 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5600 Writing an IANA Considerations Section in RFCs", BCP 26, 5601 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5602 . 5604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5606 May 2017, . 5608 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 5609 Notification (ECN) Experimentation", RFC 8311, 5610 DOI 10.17487/RFC8311, January 2018, 5611 . 5613 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5614 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5615 . 5617 23.2. Informative References 5619 [EARLY-DESIGN] 5620 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 5621 December 2013, . 5623 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 5624 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 5625 DOI 10.17487/RFC7540, May 2015, 5626 . 5628 [QUIC-INVARIANTS] 5629 Thomson, M., "Version-Independent Properties of QUIC", 5630 draft-ietf-quic-invariants-03 (work in progress), October 5631 2018. 5633 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 5634 Selective Acknowledgment Options", RFC 2018, 5635 DOI 10.17487/RFC2018, October 1996, 5636 . 5638 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5639 Hashing for Message Authentication", RFC 2104, 5640 DOI 10.17487/RFC2104, February 1997, 5641 . 5643 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 5644 RFC 2360, DOI 10.17487/RFC2360, June 1998, 5645 . 5647 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 5648 Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November 5649 1998, . 5651 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 5652 Translation (NAT) Behavioral Requirements for Unicast 5653 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 5654 2007, . 5656 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5657 Key Derivation Function (HKDF)", RFC 5869, 5658 DOI 10.17487/RFC5869, May 2010, 5659 . 5661 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5662 "Transport Layer Security (TLS) Application-Layer Protocol 5663 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5664 July 2014, . 5666 [SLOWLORIS] 5667 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 5668 . 5671 [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer 5672 Communication Review Vol. 37, pp. 361, 5673 DOI 10.1145/1282427.1282421, October 2007. 5675 Appendix A. Sample Packet Number Decoding Algorithm 5677 The following pseudo-code shows how an implementation can decode 5678 packet numbers after packet number protection has been removed. 5680 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 5681 expected_pn = largest_pn + 1 5682 pn_win = 1 << pn_nbits 5683 pn_hwin = pn_win / 2 5684 pn_mask = pn_win - 1 5685 // The incoming packet number should be greater than 5686 // expected_pn - pn_hwin and less than or equal to 5687 // expected_pn + pn_hwin 5688 // 5689 // This means we can't just strip the trailing bits from 5690 // expected_pn and add the truncated_pn because that might 5691 // yield a value outside the window. 5692 // 5693 // The following code calculates a candidate value and 5694 // makes sure it's within the packet number window. 5695 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 5696 if candidate_pn <= expected_pn - pn_hwin: 5697 return candidate_pn + pn_win 5698 // Note the extra check for underflow when candidate_pn 5699 // is near zero. 5700 if candidate_pn > expected_pn + pn_hwin and 5701 candidate_pn > pn_win: 5702 return candidate_pn - pn_win 5703 return candidate_pn 5705 Appendix B. Change Log 5707 *RFC Editor's Note:* Please remove this section prior to 5708 publication of a final version of this document. 5710 Issue and pull request numbers are listed with a leading octothorp. 5712 B.1. Since draft-ietf-quic-transport-15 5714 Substantial editorial reorganization; no technical changes. 5716 B.2. Since draft-ietf-quic-transport-14 5718 o Merge ACK and ACK_ECN (#1778, #1801) 5720 o Explicitly communicate max_ack_delay (#981, #1781) 5722 o Validate original connection ID after Retry packets (#1710, #1486, 5723 #1793) 5725 o Idle timeout is optional and has no specified maximum (#1765) 5726 o Update connection ID handling; add RETIRE_CONNECTION_ID type 5727 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 5728 #1821) 5730 o Include a Token in all Initial packets (#1649, #1794) 5732 o Prevent handshake deadlock (#1764, #1824) 5734 B.3. Since draft-ietf-quic-transport-13 5736 o Streams open when higher-numbered streams of the same type open 5737 (#1342, #1549) 5739 o Split initial stream flow control limit into 3 transport 5740 parameters (#1016, #1542) 5742 o All flow control transport parameters are optional (#1610) 5744 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 5746 o Permit stateless reset in response to any packet (#1348, #1553) 5748 o Recommended defense against stateless reset spoofing (#1386, 5749 #1554) 5751 o Prevent infinite stateless reset exchanges (#1443, #1627) 5753 o Forbid processing of the same packet number twice (#1405, #1624) 5755 o Added a packet number decoding example (#1493) 5757 o More precisely define idle timeout (#1429, #1614, #1652) 5759 o Corrected format of Retry packet and prevented looping (#1492, 5760 #1451, #1448, #1498) 5762 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 5763 #1514, #1621) 5765 o Permit Retry in response to 0-RTT (#1547, #1552) 5767 o Looser verification of ECN counters to account for ACK loss 5768 (#1555, #1481, #1565) 5770 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 5772 B.4. Since draft-ietf-quic-transport-12 5774 o Changes to integration of the TLS handshake (#829, #1018, #1094, 5775 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 5777 * The cryptographic handshake uses CRYPTO frames, not stream 0 5779 * QUIC packet protection is used in place of TLS record 5780 protection 5782 * Separate QUIC packet number spaces are used for the handshake 5784 * Changed Retry to be independent of the cryptographic handshake 5786 * Added NEW_TOKEN frame and Token fields to Initial packet 5788 * Limit the use of HelloRetryRequest to address TLS needs (like 5789 key shares) 5791 o Enable server to transition connections to a preferred address 5792 (#560, #1251, #1373) 5794 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 5795 (#804, #805, #1372) 5797 o Changed rules and recommendations for use of new connection IDs 5798 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 5800 o Added a transport parameter to disable intentional connection 5801 migration (#1271, #1447) 5803 o Packets from different connection ID can't be coalesced (#1287, 5804 #1423) 5806 o Fixed sampling method for packet number encryption; the length 5807 field in long headers includes the packet number field in addition 5808 to the packet payload (#1387, #1389) 5810 o Stateless Reset is now symmetric and subject to size constraints 5811 (#466, #1346) 5813 o Added frame type extension mechanism (#58, #1473) 5815 B.5. Since draft-ietf-quic-transport-11 5817 o Enable server to transition connections to a preferred address 5818 (#560, #1251) 5820 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 5821 #990, #734, #1317, #1267, #1079) 5823 o Packet numbers use a variable-length encoding (#989, #1334) 5825 o STREAM frames can now be empty (#1350) 5827 B.6. Since draft-ietf-quic-transport-10 5829 o Swap payload length and packed number fields in long header 5830 (#1294) 5832 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 5833 (#1274) 5835 o Spin bit reserved (#1283) 5837 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 5839 o A more complete connection migration (#1249) 5841 o Refine opportunistic ACK defense text (#305, #1030, #1185) 5843 o A Stateless Reset Token isn't mandatory (#818, #1191) 5845 o Removed implicit stream opening (#896, #1193) 5847 o An empty STREAM frame can be used to open a stream without sending 5848 data (#901, #1194) 5850 o Define stream counts in transport parameters rather than a maximum 5851 stream ID (#1023, #1065) 5853 o STOP_SENDING is now prohibited before streams are used (#1050) 5855 o Recommend including ACK in Retry packets and allow PADDING (#1067, 5856 #882) 5858 o Endpoints now become closing after an idle timeout (#1178, #1179) 5860 o Remove implication that Version Negotiation is sent when a packet 5861 of the wrong version is received (#1197) 5863 B.7. Since draft-ietf-quic-transport-09 5865 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 5866 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 5867 (#1091, #725, #1086) 5869 o A server can now only send 3 packets without validating the client 5870 address (#38, #1090) 5872 o Delivery order of stream data is no longer strongly specified 5873 (#252, #1070) 5875 o Rework of packet handling and version negotiation (#1038) 5877 o Stream 0 is now exempt from flow control until the handshake 5878 completes (#1074, #725, #825, #1082) 5880 o Improved retransmission rules for all frame types: information is 5881 retransmitted, not packets or frames (#463, #765, #1095, #1053) 5883 o Added an error code for server busy signals (#1137) 5885 o Endpoints now set the connection ID that their peer uses. 5886 Connection IDs are variable length. Removed the 5887 omit_connection_id transport parameter and the corresponding short 5888 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 5890 B.8. Since draft-ietf-quic-transport-08 5892 o Clarified requirements for BLOCKED usage (#65, #924) 5894 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 5895 #928) 5897 o GAP limitation in ACK Frame (#613) 5899 o Improved PMTUD description (#614, #1036) 5901 o Clarified stream state machine (#634, #662, #743, #894) 5903 o Reserved versions don't need to be generated deterministically 5904 (#831, #931) 5906 o You don't always need the draining period (#871) 5908 o Stateless reset clarified as version-specific (#930, #986) 5910 o initial_max_stream_id_x transport parameters are optional (#970, 5911 #971) 5913 o Ack Delay assumes a default value during the handshake (#1007, 5914 #1009) 5916 o Removed transport parameters from NewSessionTicket (#1015) 5918 B.9. Since draft-ietf-quic-transport-07 5920 o The long header now has version before packet number (#926, #939) 5922 o Rename and consolidate packet types (#846, #822, #847) 5924 o Packet types are assigned new codepoints and the Connection ID 5925 Flag is inverted (#426, #956) 5927 o Removed type for Version Negotiation and use Version 0 (#963, 5928 #968) 5930 o Streams are split into unidirectional and bidirectional (#643, 5931 #656, #720, #872, #175, #885) 5933 * Stream limits now have separate uni- and bi-directional 5934 transport parameters (#909, #958) 5936 * Stream limit transport parameters are now optional and default 5937 to 0 (#970, #971) 5939 o The stream state machine has been split into read and write (#634, 5940 #894) 5942 o Employ variable-length integer encodings throughout (#595) 5944 o Improvements to connection close 5946 * Added distinct closing and draining states (#899, #871) 5948 * Draining period can terminate early (#869, #870) 5950 * Clarifications about stateless reset (#889, #890) 5952 o Address validation for connection migration (#161, #732, #878) 5954 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 5956 o negotiated_version is sent in server transport parameters (#710, 5957 #959) 5959 o Increased the range over which packet numbers are randomized 5960 (#864, #850, #964) 5962 B.10. Since draft-ietf-quic-transport-06 5964 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 5966 o Split error code space between application and transport (#485) 5968 o Stateless reset token moved to end (#820) 5970 o 1-RTT-protected long header types removed (#848) 5972 o No acknowledgments during draining period (#852) 5974 o Remove "application close" as a separate close type (#854) 5976 o Remove timestamps from the ACK frame (#841) 5978 o Require transport parameters to only appear once (#792) 5980 B.11. Since draft-ietf-quic-transport-05 5982 o Stateless token is server-only (#726) 5984 o Refactor section on connection termination (#733, #748, #328, 5985 #177) 5987 o Limit size of Version Negotiation packet (#585) 5989 o Clarify when and what to ack (#736) 5991 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 5993 o Clarify Keep-alive requirements (#729) 5995 B.12. Since draft-ietf-quic-transport-04 5997 o Introduce STOP_SENDING frame, RST_STREAM only resets in one 5998 direction (#165) 6000 o Removed GOAWAY; application protocols are responsible for graceful 6001 shutdown (#696) 6003 o Reduced the number of error codes (#96, #177, #184, #211) 6005 o Version validation fields can't move or change (#121) 6007 o Removed versions from the transport parameters in a 6008 NewSessionTicket message (#547) 6010 o Clarify the meaning of "bytes in flight" (#550) 6012 o Public reset is now stateless reset and not visible to the path 6013 (#215) 6015 o Reordered bits and fields in STREAM frame (#620) 6017 o Clarifications to the stream state machine (#572, #571) 6019 o Increased the maximum length of the Largest Acknowledged field in 6020 ACK frames to 64 bits (#629) 6022 o truncate_connection_id is renamed to omit_connection_id (#659) 6024 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 6025 #328) 6027 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 6029 B.13. Since draft-ietf-quic-transport-03 6031 o Change STREAM and RST_STREAM layout 6033 o Add MAX_STREAM_ID settings 6035 B.14. Since draft-ietf-quic-transport-02 6037 o The size of the initial packet payload has a fixed minimum (#267, 6038 #472) 6040 o Define when Version Negotiation packets are ignored (#284, #294, 6041 #241, #143, #474) 6043 o The 64-bit FNV-1a algorithm is used for integrity protection of 6044 unprotected packets (#167, #480, #481, #517) 6046 o Rework initial packet types to change how the connection ID is 6047 chosen (#482, #442, #493) 6049 o No timestamps are forbidden in unprotected packets (#542, #429) 6051 o Cryptographic handshake is now on stream 0 (#456) 6053 o Remove congestion control exemption for cryptographic handshake 6054 (#248, #476) 6056 o Version 1 of QUIC uses TLS; a new version is needed to use a 6057 different handshake protocol (#516) 6059 o STREAM frames have a reduced number of offset lengths (#543, #430) 6061 o Split some frames into separate connection- and stream- level 6062 frames (#443) 6064 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 6066 * BLOCKED split to match WINDOW_UPDATE split (#454) 6068 * Define STREAM_ID_NEEDED frame (#455) 6070 o A NEW_CONNECTION_ID frame supports connection migration without 6071 linkability (#232, #491, #496) 6073 o Transport parameters for 0-RTT are retained from a previous 6074 connection (#405, #513, #512) 6076 * A client in 0-RTT no longer required to reset excess streams 6077 (#425, #479) 6079 o Expanded security considerations (#440, #444, #445, #448) 6081 B.15. Since draft-ietf-quic-transport-01 6083 o Defined short and long packet headers (#40, #148, #361) 6085 o Defined a versioning scheme and stable fields (#51, #361) 6087 o Define reserved version values for "greasing" negotiation (#112, 6088 #278) 6090 o The initial packet number is randomized (#35, #283) 6092 o Narrow the packet number encoding range requirement (#67, #286, 6093 #299, #323, #356) 6095 o Defined client address validation (#52, #118, #120, #275) 6097 o Define transport parameters as a TLS extension (#49, #122) 6099 o SCUP and COPT parameters are no longer valid (#116, #117) 6101 o Transport parameters for 0-RTT are either remembered from before, 6102 or assume default values (#126) 6104 o The server chooses connection IDs in its final flight (#119, #349, 6105 #361) 6107 o The server echoes the Connection ID and packet number fields when 6108 sending a Version Negotiation packet (#133, #295, #244) 6110 o Defined a minimum packet size for the initial handshake packet 6111 from the client (#69, #136, #139, #164) 6113 o Path MTU Discovery (#64, #106) 6115 o The initial handshake packet from the client needs to fit in a 6116 single packet (#338) 6118 o Forbid acknowledgment of packets containing only ACK and PADDING 6119 (#291) 6121 o Require that frames are processed when packets are acknowledged 6122 (#381, #341) 6124 o Removed the STOP_WAITING frame (#66) 6126 o Don't require retransmission of old timestamps for lost ACK frames 6127 (#308) 6129 o Clarified that frames are not retransmitted, but the information 6130 in them can be (#157, #298) 6132 o Error handling definitions (#335) 6134 o Split error codes into four sections (#74) 6136 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 6137 (#289) 6139 o Define packet protection rules (#336) 6141 o Require that stream be entirely delivered or reset, including 6142 acknowledgment of all STREAM frames or the RST_STREAM, before it 6143 closes (#381) 6145 o Remove stream reservation from state machine (#174, #280) 6147 o Only stream 1 does not contribute to connection-level flow control 6148 (#204) 6150 o Stream 1 counts towards the maximum concurrent stream limit (#201, 6151 #282) 6153 o Remove connection-level flow control exclusion for some streams 6154 (except 1) (#246) 6156 o RST_STREAM affects connection-level flow control (#162, #163) 6158 o Flow control accounting uses the maximum data offset on each 6159 stream, rather than bytes received (#378) 6161 o Moved length-determining fields to the start of STREAM and ACK 6162 (#168, #277) 6164 o Added the ability to pad between frames (#158, #276) 6166 o Remove error code and reason phrase from GOAWAY (#352, #355) 6168 o GOAWAY includes a final stream number for both directions (#347) 6170 o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a 6171 consistent offset (#249) 6173 o Defined priority as the responsibility of the application protocol 6174 (#104, #303) 6176 B.16. Since draft-ietf-quic-transport-00 6178 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 6180 o Defined versioning 6182 o Reworked description of packet and frame layout 6184 o Error code space is divided into regions for each component 6186 o Use big endian for all numeric values 6188 B.17. Since draft-hamilton-quic-transport-protocol-01 6190 o Adopted as base for draft-ietf-quic-tls 6192 o Updated authors/editors list 6194 o Added IANA Considerations section 6196 o Moved Contributors and Acknowledgments to appendices 6198 Acknowledgments 6200 Special thanks are due to the following for helping shape pre-IETF 6201 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 6202 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 6204 This document has benefited immensely from various private 6205 discussions and public ones on the quic@ietf.org and proto- 6206 quic@chromium.org mailing lists. Our thanks to all. 6208 Contributors 6210 The original authors of this specification were Ryan Hamilton, Jana 6211 Iyengar, Ian Swett, and Alyssa Wilk. 6213 The original design and rationale behind this protocol draw 6214 significantly from work by Jim Roskind [EARLY-DESIGN]. In 6215 alphabetical order, the contributors to the pre-IETF QUIC project at 6216 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 6217 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 6218 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 6219 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 6220 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 6222 Authors' Addresses 6224 Jana Iyengar (editor) 6225 Fastly 6227 Email: jri.ietf@gmail.com 6229 Martin Thomson (editor) 6230 Mozilla 6232 Email: martin.thomson@gmail.com