idnits 2.17.1 draft-ietf-quic-transport-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([QUIC-TLS], [QUIC-RECOVERY]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (December 18, 2018) is 1949 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 1786 == Missing Reference: 'CH' is mentioned on line 1782, but not defined == Missing Reference: 'SH' is mentioned on line 1784, but not defined == Missing Reference: 'EE' is mentioned on line 1785, but not defined == Missing Reference: 'CERT' is mentioned on line 1785, but not defined == Missing Reference: 'CV' is mentioned on line 1785, but not defined == Missing Reference: 'FIN' is mentioned on line 1785, but not defined -- Looks like a reference, but probably isn't: '1' on line 1476 -- Looks like a reference, but probably isn't: '2' on line 1475 -- Looks like a reference, but probably isn't: '16' on line 4370 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-17 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-17 ** Downref: Normative reference to an Informational RFC: RFC 5119 ** Downref: Normative reference to an Experimental draft: draft-ietf-quic-spin-exp (ref. 'SPIN') -- 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 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Iyengar, Ed. 3 Internet-Draft Fastly 4 Intended status: Standards Track M. Thomson, Ed. 5 Expires: June 21, 2019 Mozilla 6 December 18, 2018 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-17 11 Abstract 13 This document defines the core of the QUIC transport protocol. 14 Accompanying documents describe QUIC's loss detection and congestion 15 control [QUIC-RECOVERY] and the use of TLS for key negotiation 16 [QUIC-TLS]. 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 June 21, 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. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 65 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 66 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 68 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 69 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10 70 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.1. Send Stream States . . . . . . . . . . . . . . . . . . . 11 72 3.2. Receive Stream States . . . . . . . . . . . . . . . . . . 13 73 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 74 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16 75 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 17 76 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 18 77 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 78 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 79 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 80 4.4. Stream Final Offset . . . . . . . . . . . . . . . . . . . 21 81 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 82 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 84 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 85 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 86 5.2. Matching Packets to Connections . . . . . . . . . . . . . 25 87 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26 88 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 26 89 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27 90 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 27 91 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 92 6.2. Handling Version Negotiation Packets . . . . . . . . . . 28 93 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 94 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 29 95 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 30 96 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 97 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 33 98 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 99 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 100 7.3.3. Version Negotiation Validation . . . . . . . . . . . 35 101 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 102 8.1. Address Validation During Connection Establishment . . . 37 103 8.1.1. Address Validation using Retry Packets . . . . . . . 38 104 8.1.2. Address Validation for Future Connections . . . . . . 38 105 8.1.3. Address Validation Token Integrity . . . . . . . . . 40 106 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41 107 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 41 108 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 109 8.5. Successful Path Validation . . . . . . . . . . . . . . . 42 110 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 111 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43 112 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44 113 9.2. Initiating Connection Migration . . . . . . . . . . . . . 44 114 9.3. Responding to Connection Migration . . . . . . . . . . . 45 115 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 45 116 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 46 117 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47 118 9.4. Loss Detection and Congestion Control . . . . . . . . . . 48 119 9.5. Privacy Implications of Connection Migration . . . . . . 49 120 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 121 9.6.1. Communicating A Preferred Address . . . . . . . . . . 50 122 9.6.2. Responding to Connection Migration . . . . . . . . . 50 123 9.6.3. Interaction of Client Migration and Preferred Address 51 124 10. Connection Termination . . . . . . . . . . . . . . . . . . . 51 125 10.1. Closing and Draining Connection States . . . . . . . . . 51 126 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53 127 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 53 128 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55 129 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 57 130 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 57 131 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 58 132 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 59 133 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 59 134 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 60 135 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 60 136 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 60 137 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 61 138 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 62 139 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 63 140 13. Packetization and Reliability . . . . . . . . . . . . . . . . 66 141 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 66 142 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 67 143 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 68 144 13.2. Retransmission of Information . . . . . . . . . . . . . 68 145 13.3. Explicit Congestion Notification . . . . . . . . . . . . 70 146 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 71 147 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 71 148 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 73 149 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 73 150 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 74 151 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 75 152 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 76 153 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 77 154 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 77 155 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 78 156 17.2. Long Header Packet . . . . . . . . . . . . . . . . . . . 79 157 17.3. Short Header Packet . . . . . . . . . . . . . . . . . . 81 158 17.4. Version Negotiation Packet . . . . . . . . . . . . . . . 83 159 17.5. Initial Packet . . . . . . . . . . . . . . . . . . . . . 84 160 17.5.1. Abandoning Initial Packets . . . . . . . . . . . . . 86 161 17.5.2. Starting Packet Numbers . . . . . . . . . . . . . . 86 162 17.5.3. 0-RTT Packet Numbers . . . . . . . . . . . . . . . . 86 163 17.6. Handshake Packet . . . . . . . . . . . . . . . . . . . . 87 164 17.7. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 88 165 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 90 166 18.1. Transport Parameter Definitions . . . . . . . . . . . . 92 167 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 94 168 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 95 169 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 95 170 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 95 171 19.3.1. ACK Block Section . . . . . . . . . . . . . . . . . 97 172 19.3.2. ECN section . . . . . . . . . . . . . . . . . . . . 99 173 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 100 174 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 100 175 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 101 176 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 102 177 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 102 178 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 104 179 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 104 180 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 105 181 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 106 182 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 107 183 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 107 184 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 108 185 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 109 186 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 110 187 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 110 188 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 111 189 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 112 190 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 112 191 20.1. Application Protocol Error Codes . . . . . . . . . . . . 113 192 21. Security Considerations . . . . . . . . . . . . . . . . . . . 114 193 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 114 194 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 115 195 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 115 196 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 115 197 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 116 198 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 116 199 21.7. Explicit Congestion Notification Attacks . . . . . . . . 117 200 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 117 201 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 202 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 117 203 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 119 204 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 120 205 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 123 206 23.1. Normative References . . . . . . . . . . . . . . . . . . 123 207 23.2. Informative References . . . . . . . . . . . . . . . . . 124 208 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 126 209 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 126 210 B.1. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 126 211 B.2. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 128 212 B.3. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 128 213 B.4. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 128 214 B.5. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 129 215 B.6. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 130 216 B.7. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 130 217 B.8. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 131 218 B.9. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 131 219 B.10. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 132 220 B.11. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 133 221 B.12. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 133 222 B.13. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 133 223 B.14. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 134 224 B.15. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 134 225 B.16. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 135 226 B.17. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 137 227 B.18. Since draft-hamilton-quic-transport-protocol-01 . . . . . 137 228 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 138 229 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 138 230 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 232 1. Introduction 234 QUIC is a multiplexed and secure general-purpose transport protocol 235 that provides: 237 o Stream multiplexing 239 o Stream and connection-level flow control 241 o Low-latency connection establishment 243 o Connection migration and resilience to NAT rebinding 245 o Authenticated and encrypted header and payload 247 QUIC uses UDP as a substrate to avoid requiring changes to legacy 248 client operating systems and middleboxes. QUIC authenticates all of 249 its headers and encrypts most of the data it exchanges, including its 250 signaling, to avoid incurring a dependency on middleboxes. 252 1.1. Document Structure 254 This document describes the core QUIC protocol and is structured as 255 follows. 257 o Streams are the basic service abstraction that QUIC provides. 259 * Section 2 describes core concepts related to streams, 261 * Section 3 provides a reference model for stream states, and 263 * Section 4 outlines the operation of flow control. 265 o Connections are the context in which QUIC endpoints communicate. 267 * Section 5 describes core concepts related to connections, 269 * Section 6 describes version negotiation, 271 * Section 7 details the process for establishing connections, 273 * Section 8 specifies critical denial of service mitigation 274 mechanisms, 276 * Section 9 describes how endpoints migrate a connection to a new 277 network path, 279 * Section 10 lists the options for terminating an open 280 connection, and 282 * Section 11 provides general guidance for error handling. 284 o Packets and frames are the basic unit used by QUIC to communicate. 286 * Section 12 describes concepts related to packets and frames, 288 * Section 13 defines models for the transmission, retransmission, 289 and acknowledgement of data, and 291 * Section 14 specifies rules for managing the size of packets. 293 o Finally, encoding details of QUIC protocol elements are described 294 in: 296 * Section 15 (Versions), 298 * Section 16 (Integer Encoding), 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 for key negotiation 310 [QUIC-TLS]. 312 This document defines QUIC version 1, which conforms to the protocol 313 invariants in [QUIC-INVARIANTS]. 315 1.2. Terms and Definitions 317 The keywords "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 Commonly used terms in the document are described below. 325 QUIC: The transport protocol described by this document. QUIC is a 326 name, not an acronym. 328 QUIC packet: The smallest unit of QUIC that can be encapsulated in a 329 UDP datagram. Multiple QUIC packets can be encapsulated in a 330 single UDP datagram. 332 Endpoint: An entity that can participate in a QUIC connection by 333 generating, receiving, and processing QUIC packets. There are 334 only two types of endpoint in QUIC: client and server. 336 Client: The endpoint initiating a QUIC connection. 338 Server: The endpoint accepting incoming QUIC connections. 340 Connection ID: An opaque identifier that is used to identify a QUIC 341 connection at an endpoint. Each endpoint sets a value for its 342 peer to include in packets sent towards the endpoint. 344 Stream: A unidirectional or bidirectional channel of ordered bytes 345 within a QUIC connection. A QUIC connection can carry multiple 346 simultaneous streams. 348 Application: An entity that uses QUIC to send and receive data. 350 1.3. Notational Conventions 352 Packet and frame diagrams in this document use the format described 353 in Section 3.1 of [RFC2360], with the following additional 354 conventions: 356 [x]: Indicates that x is optional 358 x (A): Indicates that x is A bits long 360 x (A/B/C) ...: Indicates that x is one of A, B, or C bits long 362 x (i) ...: Indicates that x uses the variable-length encoding in 363 Section 16 365 x (*) ...: Indicates that x is variable-length 367 2. Streams 369 Streams in QUIC provide a lightweight, ordered byte-stream 370 abstraction to an application. An alternative view of QUIC streams 371 is as an elastic "message" abstraction. 373 Streams can be created by sending data. Other processes associated 374 with stream management - ending, cancelling, and managing flow 375 control - are all designed to impose minimal overheads. For 376 instance, a single STREAM frame (Section 19.8) can open, carry data 377 for, and close a stream. Streams can also be long-lived and can last 378 the entire duration of a connection. 380 Streams can be created by either endpoint, can concurrently send data 381 interleaved with other streams, and can be cancelled. Any stream can 382 be initiated by either endpoint. QUIC does not provide any means of 383 ensuring ordering between bytes on different streams. 385 QUIC allows for an arbitrary number of streams to operate 386 concurrently and for an arbitrary amount of data to be sent on any 387 stream, subject to flow control constraints (see Section 4) and 388 stream limits. 390 2.1. Stream Types and Identifiers 392 Streams can be unidirectional or bidirectional. Unidirectional 393 streams carry data in one direction: from the initiator of the stream 394 to its peer. Bidirectional streams allow for data to be sent in both 395 directions. 397 Streams are identified within a connection by a numeric value, 398 referred to as the stream ID. Stream IDs are unique to a stream. A 399 QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream 400 IDs are encoded as variable-length integers (see Section 16). 402 The least significant bit (0x1) of the stream ID identifies the 403 initiator of the stream. Client-initiated streams have even-numbered 404 stream IDs (with the bit set to 0), and server-initiated streams have 405 odd-numbered stream IDs (with the bit set to 1). 407 The second least significant bit (0x2) of the stream ID distinguishes 408 between bidirectional streams (with the bit set to 0) and 409 unidirectional streams (with the bit set to 1). 411 The least significant two bits from a stream ID therefore identify a 412 stream as one of four types, as summarized in Table 1. 414 +------+----------------------------------+ 415 | Bits | Stream Type | 416 +------+----------------------------------+ 417 | 0x0 | Client-Initiated, Bidirectional | 418 | | | 419 | 0x1 | Server-Initiated, Bidirectional | 420 | | | 421 | 0x2 | Client-Initiated, Unidirectional | 422 | | | 423 | 0x3 | Server-Initiated, Unidirectional | 424 +------+----------------------------------+ 426 Table 1: Stream ID Types 428 Within each type, streams are created with numerically increasing 429 stream IDs. A stream ID that is used out of order results in all 430 streams of that type with lower-numbered stream IDs also being 431 opened. 433 The first bidirectional stream opened by the client has a stream ID 434 of 0. 436 2.2. Sending and Receiving Data 438 STREAM frames (Section 19.8) encapsulate data sent by an application. 439 An endpoint uses the Stream ID and Offset fields in STREAM frames to 440 place data in order. 442 Endpoints MUST be able to deliver stream data to an application as an 443 ordered byte-stream. Delivering an ordered byte-stream requires that 444 an endpoint buffer any data that is received out of order, up to the 445 advertised flow control limit. 447 QUIC makes no specific allowances for delivery of stream data out of 448 order. However, implementations MAY choose to offer the ability to 449 deliver data out of order to a receiving application. 451 An endpoint could receive data for a stream at the same stream offset 452 multiple times. Data that has already been received can be 453 discarded. The data at a given offset MUST NOT change if it is sent 454 multiple times; an endpoint MAY treat receipt of different data at 455 the same offset within a stream as a connection error of type 456 PROTOCOL_VIOLATION. 458 Streams are an ordered byte-stream abstraction with no other 459 structure that is visible to QUIC. STREAM frame boundaries are not 460 expected to be preserved when data is transmitted, when data is 461 retransmitted after packet loss, or when data is delivered to the 462 application at a receiver. 464 An endpoint MUST NOT send data on any stream without ensuring that it 465 is within the flow control limits set by its peer. Flow control is 466 described in detail in Section 4. 468 2.3. Stream Prioritization 470 Stream multiplexing can have a significant effect on application 471 performance if resources allocated to streams are correctly 472 prioritized. 474 QUIC does not provide frames for exchanging prioritization 475 information. Instead it relies on receiving priority information 476 from the application that uses QUIC. 478 A QUIC implementation SHOULD provide ways in which an application can 479 indicate the relative priority of streams. When deciding which 480 streams to dedicate resources to, the implementation SHOULD use the 481 information provided by the application. 483 3. Stream States 485 This section describes streams in terms of their send or receive 486 components. Two state machines are described: one for the streams on 487 which an endpoint transmits data (Section 3.1), and another for 488 streams on which an endpoint receives data (Section 3.2). 490 Unidirectional streams use the applicable state machine directly. 491 Bidirectional streams use both state machines. For the most part, 492 the use of these state machines is the same whether the stream is 493 unidirectional or bidirectional. The conditions for opening a stream 494 are slightly more complex for a bidirectional stream because the 495 opening of either send or receive sides causes the stream to open in 496 both directions. 498 An endpoint MUST open streams of the same type in increasing order of 499 stream ID. 501 Note: These states are largely informative. This document uses 502 stream states to describe rules for when and how different types 503 of frames can be sent and the reactions that are expected when 504 different types of frames are received. Though these state 505 machines are intended to be useful in implementing QUIC, these 506 states aren't intended to constrain implementations. An 507 implementation can define a different state machine as long as its 508 behavior is consistent with an implementation that implements 509 these states. 511 3.1. Send Stream States 513 Figure 1 shows the states for the part of a stream that sends data to 514 a peer. 516 o 517 | Create Stream (Sending) 518 | Peer Creates Bidirectional Stream 519 v 520 +-------+ 521 | Ready | Send RESET_STREAM 522 | |-----------------------. 523 +-------+ | 524 | | 525 | Send STREAM / | 526 | STREAM_DATA_BLOCKED | 527 | | 528 | Peer Creates | 529 | Bidirectional Stream | 530 v | 531 +-------+ | 532 | Send | Send RESET_STREAM | 533 | |---------------------->| 534 +-------+ | 535 | | 536 | Send STREAM + FIN | 537 v v 538 +-------+ +-------+ 539 | Data | Send RESET_STREAM | Reset | 540 | Sent |------------------>| Sent | 541 +-------+ +-------+ 542 | | 543 | Recv All ACKs | Recv ACK 544 v v 545 +-------+ +-------+ 546 | Data | | Reset | 547 | Recvd | | Recvd | 548 +-------+ +-------+ 550 Figure 1: States for Send Streams 552 The sending part of stream that the endpoint initiates (types 0 and 2 553 for clients, 1 and 3 for servers) is opened by the application. The 554 "Ready" state represents a newly created stream that is able to 555 accept data from the application. Stream data might be buffered in 556 this state in preparation for sending. 558 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a send 559 stream to enter the "Send" state. An implementation might choose to 560 defer allocating a stream ID to a send stream until it sends the 561 first frame and enters this state, which can allow for better stream 562 prioritization. 564 The sending part of a bidirectional stream initiated by a peer (type 565 0 for a server, type 1 for a client) enters the "Ready" state then 566 immediately transitions to the "Send" state if the receiving part 567 enters the "Recv" state (Section 3.2). 569 In the "Send" state, an endpoint transmits - and retransmits as 570 necessary - stream data in STREAM frames. The endpoint respects the 571 flow control limits set by its peer, and continues to accept and 572 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 573 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 574 stream or connection flow control limits Section 4.1. 576 After the application indicates that all stream data has been sent 577 and a STREAM frame containing the FIN bit is sent, the send stream 578 enters the "Data Sent" state. From this state, the endpoint only 579 retransmits stream data as necessary. The endpoint does not need to 580 check flow control limits or send STREAM_DATA_BLOCKED frames for a 581 send stream in this state. MAX_STREAM_DATA frames might be received 582 until the peer receives the final stream offset. The endpoint can 583 safely ignore any MAX_STREAM_DATA frames it receives from its peer 584 for a stream in this state. 586 Once all stream data has been successfully acknowledged, the send 587 stream enters the "Data Recvd" state, which is a terminal state. 589 From any of the "Ready", "Send", or "Data Sent" states, an 590 application can signal that it wishes to abandon transmission of 591 stream data. Alternatively, an endpoint might receive a STOP_SENDING 592 frame from its peer. In either case, the endpoint sends a 593 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 594 state. 596 An endpoint MAY send a RESET_STREAM as the first frame on a send 597 stream; this causes the send stream to open and then immediately 598 transition to the "Reset Sent" state. 600 Once a packet containing a RESET_STREAM has been acknowledged, the 601 send stream enters the "Reset Recvd" state, which is a terminal 602 state. 604 3.2. Receive Stream States 606 Figure 2 shows the states for the part of a stream that receives data 607 from a peer. The states for a receive stream mirror only some of the 608 states of the send stream at the peer. A receive stream does not 609 track states on the send stream that cannot be observed, such as the 610 "Ready" state. Instead, receive streams track the delivery of data 611 to the application, some of which cannot be observed by the sender. 613 o 614 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 615 | Create Bidirectional Stream (Sending) 616 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 617 | Create Higher-Numbered Stream 618 v 619 +-------+ 620 | Recv | Recv RESET_STREAM 621 | |-----------------------. 622 +-------+ | 623 | | 624 | Recv STREAM + FIN | 625 v | 626 +-------+ | 627 | Size | Recv RESET_STREAM | 628 | Known |---------------------->| 629 +-------+ | 630 | | 631 | Recv All Data | 632 v v 633 +-------+ Recv RESET_STREAM +-------+ 634 | Data |--- (optional) --->| Reset | 635 | Recvd | Recv All Data | Recvd | 636 +-------+<-- (optional) ----+-------+ 637 | | 638 | App Read All Data | App Read RST 639 v v 640 +-------+ +-------+ 641 | Data | | Reset | 642 | Read | | Read | 643 +-------+ +-------+ 645 Figure 2: States for Receive Streams 647 The receiving part of a stream initiated by a peer (types 1 and 3 for 648 a client, or 0 and 2 for a server) is created when the first STREAM, 649 STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. 650 For bidirectional streams initiated by a peer, receipt of a 651 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 652 stream also creates the receiving part. The initial state for a 653 receive stream is "Recv". 655 The receive stream enters the "Recv" state when the sending part of a 656 bidirectional stream initiated by the endpoint (type 0 for a client, 657 type 1 for a server) enters the "Ready" state. 659 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 660 STOP_SENDING frame is received from the peer for that stream. 662 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 663 that the remote peer has opened the stream and is providing flow 664 control credit. Receiving a STOP_SENDING frame for an unopened 665 stream indicates that the remote peer no longer wishes to receive 666 data on this stream. Either frame might arrive before a STREAM or 667 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 669 Before creating a stream, all streams of the same type with lower- 670 numbered stream IDs MUST be created. This ensures that the creation 671 order for streams is consistent on both endpoints. 673 In the "Recv" state, the endpoint receives STREAM and 674 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 675 reassembled into the correct order for delivery to the application. 676 As data is consumed by the application and buffer space becomes 677 available, the endpoint sends MAX_STREAM_DATA frames to allow the 678 peer to send more data. 680 When a STREAM frame with a FIN bit is received, the final offset is 681 known (see Section 4.4). The receive stream enters the "Size Known" 682 state. In this state, the endpoint no longer needs to send 683 MAX_STREAM_DATA frames, it only receives any retransmissions of 684 stream data. 686 Once all data for the stream has been received, the receive stream 687 enters the "Data Recvd" state. This might happen as a result of 688 receiving the same STREAM frame that causes the transition to "Size 689 Known". In this state, the endpoint has all stream data. Any STREAM 690 or STREAM_DATA_BLOCKED frames it receives for the stream can be 691 discarded. 693 The "Data Recvd" state persists until stream data has been delivered 694 to the application. Once stream data has been delivered, the stream 695 enters the "Data Read" state, which is a terminal state. 697 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 698 causes the stream to enter the "Reset Recvd" state. This might cause 699 the delivery of stream data to the application to be interrupted. 701 It is possible that all stream data is received when a RESET_STREAM 702 is received (that is, from the "Data Recvd" state). Similarly, it is 703 possible for remaining stream data to arrive after receiving a 704 RESET_STREAM frame (the "Reset Recvd" state). An implementation is 705 free to manage this situation as it chooses. Sending RESET_STREAM 706 means that an endpoint cannot guarantee delivery of stream data; 707 however there is no requirement that stream data not be delivered if 708 a RESET_STREAM is received. An implementation MAY interrupt delivery 709 of stream data, discard any data that was not consumed, and signal 710 the receipt of the RESET_STREAM immediately. Alternatively, the 711 RESET_STREAM signal might be suppressed or withheld if stream data is 712 completely received and is buffered to be read by the application. 713 In the latter case, the receive stream transitions from "Reset Recvd" 714 to "Data Recvd". 716 Once the application has been delivered the signal indicating that 717 the receive stream was reset, the receive stream transitions to the 718 "Reset Read" state, which is a terminal state. 720 3.3. Permitted Frame Types 722 The sender of a stream sends just three frame types that affect the 723 state of a stream at either sender or receiver: STREAM 724 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 725 (Section 19.4). 727 A sender MUST NOT send any of these frames from a terminal state 728 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 729 STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the 730 terminal states and in the "Reset Sent" state. A receiver could 731 receive any of these three frames in any state, due to the 732 possibility of delayed delivery of packets carrying them. 734 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 735 STOP_SENDING frames (Section 19.5). 737 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 738 receiver can send STOP_SENDING in any state where it has not received 739 a RESET_STREAM frame; that is states other than "Reset Recvd" or 740 "Reset Read". However there is little value in sending a 741 STOP_SENDING frame in the "Data Recvd" state, since all stream data 742 has been received. A sender could receive either of these two frames 743 in any state as a result of delayed delivery of packets. 745 3.4. Bidirectional Stream States 747 A bidirectional stream is composed of a send stream and a receive 748 stream. Implementations may represent states of the bidirectional 749 stream as composites of send and receive stream states. The simplest 750 model presents the stream as "open" when either send or receive 751 stream is in a non-terminal state and "closed" when both send and 752 receive streams are in a terminal state. 754 Table 2 shows a more complex mapping of bidirectional stream states 755 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 756 shows that multiple states on send or receive streams are mapped to 757 the same composite state. Note that this is just one possibility for 758 such a mapping; this mapping requires that data is acknowledged 759 before the transition to a "closed" or "half-closed" state. 761 +-----------------------+---------------------+---------------------+ 762 | Send Stream | Receive Stream | Composite State | 763 +-----------------------+---------------------+---------------------+ 764 | No Stream/Ready | No Stream/Recv *1 | idle | 765 | | | | 766 | Ready/Send/Data Sent | Recv/Size Known | open | 767 | | | | 768 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 769 | | Read | (remote) | 770 | | | | 771 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 772 | | Read | (remote) | 773 | | | | 774 | Data Recvd | Recv/Size Known | half-closed (local) | 775 | | | | 776 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 777 | Recvd | | | 778 | | | | 779 | Data Recvd | Recv/Size Known | half-closed (local) | 780 | | | | 781 | Reset Sent/Reset | Data Recvd/Data | closed | 782 | Recvd | Read | | 783 | | | | 784 | Reset Sent/Reset | Reset Recvd/Reset | closed | 785 | Recvd | Read | | 786 | | | | 787 | Data Recvd | Data Recvd/Data | closed | 788 | | Read | | 789 | | | | 790 | Data Recvd | Reset Recvd/Reset | closed | 791 | | Read | | 792 +-----------------------+---------------------+---------------------+ 794 Table 2: Possible Mapping of Stream States to HTTP/2 796 Note (*1): A stream is considered "idle" if it has not yet been 797 created, or if the receive stream is in the "Recv" state without 798 yet having received any frames. 800 3.5. Solicited State Transitions 802 If an endpoint is no longer interested in the data it is receiving on 803 a stream, it MAY send a STOP_SENDING frame identifying that stream to 804 prompt closure of the stream in the opposite direction. This 805 typically indicates that the receiving application is no longer 806 reading data it receives from the stream, but it is not a guarantee 807 that incoming data will be ignored. 809 STREAM frames received after sending STOP_SENDING are still counted 810 toward connection and stream flow control, even though these frames 811 will be discarded upon receipt. 813 A STOP_SENDING frame requests that the receiving endpoint send a 814 RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame 815 MUST send a RESET_STREAM frame for that stream. An endpoint SHOULD 816 copy the error code from the STOP_SENDING frame, but MAY use any 817 application error code. The endpoint that sends a STOP_SENDING frame 818 can ignore the error code carried in any RESET_STREAM frame it 819 receives. 821 If the STOP_SENDING frame is received on a send stream that is 822 already in the "Data Sent" state, an endpoint that wishes to cease 823 retransmission of previously-sent STREAM frames on that stream MUST 824 first send a RESET_STREAM frame. 826 STOP_SENDING SHOULD only be sent for a receive stream that has not 827 been reset. STOP_SENDING is most useful for streams in the "Recv" or 828 "Size Known" states. 830 An endpoint is expected to send another STOP_SENDING frame if a 831 packet containing a previous STOP_SENDING is lost. However, once 832 either all stream data or a RESET_STREAM frame has been received for 833 the stream - that is, the stream is in any state other than "Recv" or 834 "Size Known" - sending a STOP_SENDING frame is unnecessary. 836 An endpoint that wishes to terminate both directions of a 837 bidirectional stream can terminate one direction by sending a 838 RESET_STREAM, and it can encourage prompt termination in the opposite 839 direction by sending a STOP_SENDING frame. 841 4. Flow Control 843 It is necessary to limit the amount of data that a receiver could 844 buffer, to prevent a fast sender from overwhelming a slow receiver, 845 or to prevent a malicious sender from consuming a large amount of 846 memory at a receiver. To enable a receiver to limit memory 847 commitment to a connection and to apply back pressure on the sender, 848 streams are flow controlled both individually and as an aggregate. A 849 QUIC receiver controls the maximum amount of data the sender can send 850 on a stream at any time, as described in Section 4.1 and Section 4.2 851 Similarly, to limit concurrency within a connection, a QUIC endpoint 852 controls the maximum cumulative number of streams that its peer can 853 initiate, as described in Section 4.5. 855 Data sent in CRYPTO frames is not flow controlled in the same way as 856 stream data. QUIC relies on the cryptographic protocol 857 implementation to avoid excessive buffering of data, see [QUIC-TLS]. 858 The implementation SHOULD provide an interface to QUIC to tell it 859 about its buffering limits so that there is not excessive buffering 860 at multiple layers. 862 4.1. Data Flow Control 864 QUIC employs a credit-based flow-control scheme similar to that in 865 HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is 866 prepared to receive on a given stream and for the entire connection. 867 This leads to two levels of data flow control in QUIC: 869 o Stream flow control, which prevents a single stream from consuming 870 the entire receive buffer for a connection by limiting the amount 871 of data that can be sent on any stream. 873 o Connection flow control, which prevents senders from exceeding a 874 receiver's buffer capacity for the connection, by limiting the 875 total bytes of stream data sent in STREAM frames on all streams. 877 A receiver sets initial credits for all streams by sending transport 878 parameters during the handshake (Section 7.3). A receiver sends 879 MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to 880 the sender to advertise additional credit. 882 A receiver advertises credit for a stream by sending a 883 MAX_STREAM_DATA frame with the Stream ID field set appropriately. A 884 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 885 stream. A receiver could use the current offset of data consumed to 886 determine the flow control offset to be advertised. A receiver MAY 887 send MAX_STREAM_DATA frames in multiple packets in order to make sure 888 that the sender receives an update before running out of flow control 889 credit, even if one of the packets is lost. 891 A receiver advertises credit for a connection by sending a MAX_DATA 892 frame, which indicates the maximum of the sum of the absolute byte 893 offsets of all streams. A receiver maintains a cumulative sum of 894 bytes received on all streams, which is used to check for flow 895 control violations. A receiver might use a sum of bytes consumed on 896 all streams to determine the maximum data limit to be advertised. 898 A receiver can advertise a larger offset by sending MAX_STREAM_DATA 899 or MAX_DATA frames at any time during the connection. A receiver 900 cannot renege on an advertisement however. That is, once a receiver 901 advertises an offset, it MAY advertise a smaller offset, but this has 902 no effect. 904 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 905 (Section 11) if the sender violates the advertised connection or 906 stream data limits. 908 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 909 not increase flow control limits. 911 If a sender runs out of flow control credit, it will be unable to 912 send new data and is considered blocked. A sender SHOULD send 913 STREAM_DATA_BLOCKED or DATA_BLOCKED frames to indicate it has data to 914 write but is blocked by flow control limits. These frames are 915 expected to be sent infrequently in common cases, but they are 916 considered useful for debugging and monitoring purposes. 918 A sender sends a single STREAM_DATA_BLOCKED or DATA_BLOCKED frame 919 only once when it reaches a data limit. A sender SHOULD NOT send 920 multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames for the same data 921 limit, unless the original frame is determined to be lost. Another 922 STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data 923 limit is increased. 925 4.2. Flow Credit Increments 927 This document leaves when and how many bytes to advertise in a 928 MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a 929 few considerations. These frames contribute to connection overhead. 930 Therefore frequently sending frames with small changes is 931 undesirable. At the same time, larger increments to limits are 932 necessary to avoid blocking if updates are less frequent, requiring 933 larger resource commitments at the receiver. Thus there is a trade- 934 off between resource commitment and overhead when determining how 935 large a limit is advertised. 937 A receiver MAY use an autotuning mechanism to tune the frequency and 938 amount of advertised additional credit based on a round-trip time 939 estimate and the rate at which the receiving application consumes 940 data, similar to common TCP implementations. 942 If a sender runs out of flow control credit, it will be unable to 943 send new data and is considered blocked. It is generally considered 944 best to not let the sender become blocked. To avoid blocking a 945 sender, and to reasonably account for the possibility of loss, a 946 receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two 947 round trips before it expects the sender to get blocked. 949 A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED 950 frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will 951 mean that a sender will be blocked for at least an entire round trip, 952 and potentially for longer if the peer chooses to not send 953 STREAM_DATA_BLOCKED or DATA_BLOCKED frames. 955 4.3. Handling Stream Cancellation 957 Endpoints need to eventually agree on the amount of flow control 958 credit that has been consumed, to avoid either exceeding flow control 959 limits or deadlocking. 961 On receipt of a RESET_STREAM frame, an endpoint will tear down state 962 for the matching stream and ignore further data arriving on that 963 stream. If a RESET_STREAM frame is reordered with stream data for 964 the same stream, the receiver's estimate of the number of bytes 965 received on that stream can be lower than the sender's estimate of 966 the number sent. As a result, the two endpoints could disagree on 967 the number of bytes that count towards connection flow control. 969 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes 970 the final offset of data sent on the stream. On receiving a 971 RESET_STREAM frame, a receiver definitively knows how many bytes were 972 sent on that stream before the RESET_STREAM frame, and the receiver 973 MUST use the final offset to account for all bytes sent on the stream 974 in its connection level flow controller. 976 RESET_STREAM terminates one direction of a stream abruptly. For a 977 bidirectional stream, RESET_STREAM has no effect on data flow in the 978 opposite direction. Both endpoints MUST maintain flow control state 979 for the stream in the unterminated direction until that direction 980 enters a terminal state, or until one of the endpoints sends 981 CONNECTION_CLOSE. 983 4.4. Stream Final Offset 985 The final offset is the count of the number of bytes that are 986 transmitted on a stream. For a stream that is reset, the final 987 offset is carried explicitly in a RESET_STREAM frame. Otherwise, the 988 final offset is the offset of the end of the data carried in a STREAM 989 frame marked with a FIN flag, or 0 in the case of incoming 990 unidirectional streams. 992 An endpoint will know the final offset for a stream when the receive 993 stream enters the "Size Known" or "Reset Recvd" state (Section 3). 995 An endpoint MUST NOT send data on a stream at or beyond the final 996 offset. 998 Once a final offset for a stream is known, it cannot change. If a 999 RESET_STREAM or STREAM frame is received indicating a change in the 1000 final offset for the stream, an endpoint SHOULD respond with a 1001 FINAL_OFFSET_ERROR error (see Section 11). A receiver SHOULD treat 1002 receipt of data at or beyond the final offset as a FINAL_OFFSET_ERROR 1003 error, even after a stream is closed. Generating these errors is not 1004 mandatory, but only because requiring that an endpoint generate these 1005 errors also means that the endpoint needs to maintain the final 1006 offset state for closed streams, which could mean a significant state 1007 commitment. 1009 4.5. Controlling Concurrency 1011 An endpoint limits the cumulative number of incoming streams a peer 1012 can open. Only streams with a stream ID less than (max_stream * 4 + 1013 initial_stream_id_for_type) can be opened (see Table 5). Initial 1014 limits are set in the transport parameters (see Section 18.1) and 1015 subsequently limits are advertised using MAX_STREAMS frames 1016 (Section 19.11). Separate limits apply to unidirectional and 1017 bidirectional streams. 1019 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1020 that receives a STREAM frame with a stream ID exceeding the limit it 1021 has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR 1022 (Section 11). 1024 A receiver cannot renege on an advertisement. That is, once a 1025 receiver advertises a stream limit using the MAX_STREAMS frame, 1026 advertising a smaller limit has no effect. A receiver MUST ignore 1027 any MAX_STREAMS frame that does not increase the stream limit. 1029 As with stream and connection flow control, this document leaves when 1030 and how many streams to advertise to a peer via MAX_STREAMS to 1031 implementations. Implementations might choose to increase limits as 1032 streams close to keep the number of streams available to peers 1033 roughly consistent. 1035 An endpoint that is unable to open a new stream due to the peer's 1036 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1037 signal is considered useful for debugging. An endpoint MUST NOT wait 1038 to receive this signal before advertising additional credit, since 1039 doing so will mean that the peer will be blocked for at least an 1040 entire round trip, and potentially for longer if the peer chooses to 1041 not send STREAMS_BLOCKED frames. 1043 5. Connections 1045 QUIC's connection establishment combines version negotiation with the 1046 cryptographic and transport handshakes to reduce connection 1047 establishment latency, as described in Section 7. Once established, 1048 a connection may migrate to a different IP or port at either endpoint 1049 as described in Section 9. Finally, a connection may be terminated 1050 by either endpoint, as described in Section 10. 1052 5.1. Connection ID 1054 Each connection possesses a set of connection identifiers, or 1055 connection IDs, each of which can identify the connection. 1056 Connection IDs are independently selected by endpoints; each endpoint 1057 selects the connection IDs that its peer uses. 1059 The primary function of a connection ID is to ensure that changes in 1060 addressing at lower protocol layers (UDP, IP) don't cause packets for 1061 a QUIC connection to be delivered to the wrong endpoint. Each 1062 endpoint selects connection IDs using an implementation-specific (and 1063 perhaps deployment-specific) method which will allow packets with 1064 that connection ID to be routed back to the endpoint and identified 1065 by the endpoint upon receipt. 1067 Connection IDs MUST NOT contain any information that can be used by 1068 an external observer to correlate them with other connection IDs for 1069 the same connection. As a trivial example, this means the same 1070 connection ID MUST NOT be issued more than once on the same 1071 connection. 1073 Packets with long headers include Source Connection ID and 1074 Destination Connection ID fields. These fields are used to set the 1075 connection IDs for new connections, see Section 7.2 for details. 1077 Packets with short headers (Section 17.3) only include the 1078 Destination Connection ID and omit the explicit length. The length 1079 of the Destination Connection ID field is expected to be known to 1080 endpoints. Endpoints using a load balancer that routes based on 1081 connection ID could agree with the load balancer on a fixed length 1082 for connection IDs, or agree on an encoding scheme. A fixed portion 1083 could encode an explicit length, which allows the entire connection 1084 ID to vary in length and still be used by the load balancer. 1086 A Version Negotiation (Section 17.4) packet echoes the connection IDs 1087 selected by the client, both to ensure correct routing toward the 1088 client and to allow the client to validate that the packet is in 1089 response to an Initial packet. 1091 A zero-length connection ID MAY be used when the connection ID is not 1092 needed for routing and the address/port tuple of packets is 1093 sufficient to identify a connection. An endpoint whose peer has 1094 selected a zero-length connection ID MUST continue to use a zero- 1095 length connection ID for the lifetime of the connection and MUST NOT 1096 send packets from any other local address. 1098 When an endpoint has requested a non-zero-length connection ID, it 1099 needs to ensure that the peer has a supply of connection IDs from 1100 which to choose for packets sent to the endpoint. These connection 1101 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1102 (Section 19.15). 1104 5.1.1. Issuing Connection IDs 1106 Each Connection ID has an associated sequence number to assist in 1107 deduplicating messages. The initial connection ID issued by an 1108 endpoint is sent in the Source Connection ID field of the long packet 1109 header (Section 17.2) during the handshake. The sequence number of 1110 the initial connection ID is 0. If the preferred_address transport 1111 parameter is sent, the sequence number of the supplied connection ID 1112 is 1. 1114 Additional connection IDs are communicated to the peer using 1115 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1116 each newly-issued connection ID MUST increase by 1. The connection 1117 ID randomly selected by the client in the Initial packet and any 1118 connection ID provided by a Retry packet are not assigned sequence 1119 numbers unless a server opts to retain them as its initial connection 1120 ID. 1122 When an endpoint issues a connection ID, it MUST accept packets that 1123 carry this connection ID for the duration of the connection or until 1124 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1125 frame (Section 19.16). 1127 Endpoints store received connection IDs for future use. An endpoint 1128 that receives excessive connection IDs MAY discard those it cannot 1129 store without sending a RETIRE_CONNECTION_ID frame. An endpoint that 1130 issues connection IDs cannot expect its peer to store and use all 1131 issued connection IDs. 1133 An endpoint SHOULD ensure that its peer has a sufficient number of 1134 available and unused connection IDs. While each endpoint 1135 independently chooses how many connection IDs to issue, endpoints 1136 SHOULD provide and maintain at least eight connection IDs. The 1137 endpoint SHOULD do this by always supplying a new connection ID when 1138 a connection ID is retired by its peer or when the endpoint receives 1139 a packet with a previously unused connection ID. Endpoints that 1140 initiate migration and require non-zero-length connection IDs SHOULD 1141 provide their peers with new connection IDs before migration, or risk 1142 the peer closing the connection. 1144 5.1.2. Consuming and Retiring Connection IDs 1146 An endpoint can change the connection ID it uses for a peer to 1147 another available one at any time during the connection. An endpoint 1148 consumes connection IDs in response to a migrating peer, see 1149 Section 9.5 for more. 1151 An endpoint maintains a set of connection IDs received from its peer, 1152 any of which it can use when sending packets. When the endpoint 1153 wishes to remove a connection ID from use, it sends a 1154 RETIRE_CONNECTION_ID frame to its peer. Sending a 1155 RETIRE_CONNECTION_ID frame indicates that the connection ID won't be 1156 used again and requests that the peer replace it with a new 1157 connection ID using a NEW_CONNECTION_ID frame. 1159 As discussed in Section 9.5, each connection ID MUST be used on 1160 packets sent from only one local address. An endpoint that migrates 1161 away from a local address SHOULD retire all connection IDs used on 1162 that address once it no longer plans to use that address. 1164 5.2. Matching Packets to Connections 1166 Incoming packets are classified on receipt. Packets can either be 1167 associated with an existing connection, or - for servers - 1168 potentially create a new connection. 1170 Hosts try to associate a packet with an existing connection. If the 1171 packet has a Destination Connection ID corresponding to an existing 1172 connection, QUIC processes that packet accordingly. Note that more 1173 than one connection ID can be associated with a connection; see 1174 Section 5.1. 1176 If the Destination Connection ID is zero length and the packet 1177 matches the address/port tuple of a connection where the host did not 1178 require connection IDs, QUIC processes the packet as part of that 1179 connection. Endpoints MUST drop packets with zero-length Destination 1180 Connection ID fields if they do not correspond to a single 1181 connection. 1183 Endpoints can send a Stateless Reset (Section 10.4) for any packets 1184 that cannot be attributed to an existing connection. A stateless 1185 reset allows a peer to more quickly identify when a connection 1186 becomes unusable. 1188 Packets that are matched to an existing connection, but for which the 1189 endpoint cannot remove packet protection, are discarded. 1191 5.2.1. Client Packet Handling 1193 Valid packets sent to clients always include a Destination Connection 1194 ID that matches a value the client selects. Clients that choose to 1195 receive zero-length connection IDs can use the address/port tuple to 1196 identify a connection. Packets that don't match an existing 1197 connection are discarded. 1199 Due to packet reordering or loss, clients might receive packets for a 1200 connection that are encrypted with a key it has not yet computed. 1201 Clients MAY drop these packets, or MAY buffer them in anticipation of 1202 later packets that allow it to compute the key. 1204 If a client receives a packet that has an unsupported version, it 1205 MUST discard that packet. 1207 5.2.2. Server Packet Handling 1209 If a server receives a packet that has an unsupported version, but 1210 the packet is sufficiently large to initiate a new connection for any 1211 version supported by the server, it SHOULD send a Version Negotiation 1212 packet as described in Section 6.1. Servers MAY rate control these 1213 packets to avoid storms of Version Negotiation packets. 1215 The first packet for an unsupported version can use different 1216 semantics and encodings for any version-specific field. In 1217 particular, different packet protection keys might be used for 1218 different versions. Servers that do not support a particular version 1219 are unlikely to be able to decrypt the payload of the packet. 1220 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1221 unknown version, but instead send a Version Negotiation packet, 1222 provided that the packet is sufficiently long. 1224 Servers MUST drop other packets that contain unsupported versions. 1226 Packets with a supported version, or no version field, are matched to 1227 a connection using the connection ID or - for packets with zero- 1228 length connection IDs - the address tuple. If the packet doesn't 1229 match an existing connection, the server continues below. 1231 If the packet is an Initial packet fully conforming with the 1232 specification, the server proceeds with the handshake (Section 7). 1233 This commits the server to the version that the client selected. 1235 If a server isn't currently accepting any new connections, it SHOULD 1236 send an Initial packet containing a CONNECTION_CLOSE frame with error 1237 code SERVER_BUSY. 1239 If the packet is a 0-RTT packet, the server MAY buffer a limited 1240 number of these packets in anticipation of a late-arriving Initial 1241 Packet. Clients are forbidden from sending Handshake packets prior 1242 to receiving a server response, so servers SHOULD ignore any such 1243 packets. 1245 Servers MUST drop incoming packets under all other circumstances. 1247 5.3. Life of a QUIC Connection 1249 TBD. 1251 6. Version Negotiation 1253 Version negotiation ensures that client and server agree to a QUIC 1254 version that is mutually supported. A server sends a Version 1255 Negotiation packet in response to each packet that might initiate a 1256 new connection, see Section 5.2 for details. 1258 The first few messages of an exchange between a client attempting to 1259 create a new connection with server is shown in Figure 3. After 1260 version negotiation completes, connection establishment can proceed, 1261 for example as shown in Section 7.1. 1263 Client Server 1265 Packet (v=X) -> 1267 <- Version Negotiation (supported=Y,Z) 1269 Packet (v=Y) -> 1271 <- Packet(s) (v=Y) 1273 Figure 3: Example Version Negotiation Exchange 1275 The size of the first packet sent by a client will determine whether 1276 a server sends a Version Negotiation packet. Clients that support 1277 multiple QUIC versions SHOULD pad the first packet they send to the 1278 largest of the minimum packet sizes across all versions they support. 1279 This ensures that the server responds if there is a mutually 1280 supported version. 1282 6.1. Sending Version Negotiation Packets 1284 If the version selected by the client is not acceptable to the 1285 server, the server responds with a Version Negotiation packet (see 1286 Section 17.4). This includes a list of versions that the server will 1287 accept. An endpoint MUST NOT send a Version Negotiation packet in 1288 response to receiving a Version Negotiation packet. 1290 This system allows a server to process packets with unsupported 1291 versions without retaining state. Though either the Initial packet 1292 or the Version Negotiation packet that is sent in response could be 1293 lost, the client will send new packets until it successfully receives 1294 a response or it abandons the connection attempt. 1296 A server MAY limit the number of Version Negotiation packets it 1297 sends. For instance, a server that is able to recognize packets as 1298 0-RTT might choose not to send Version Negotiation packets in 1299 response to 0-RTT packets with the expectation that it will 1300 eventually receive an Initial packet. 1302 6.2. Handling Version Negotiation Packets 1304 When the client receives a Version Negotiation packet, it first 1305 checks that the Destination and Source Connection ID fields match the 1306 Source and Destination Connection ID fields in a packet that the 1307 client sent. If this check fails, the packet MUST be discarded. 1309 Once the Version Negotiation packet is determined to be valid, the 1310 client then selects an acceptable protocol version from the list 1311 provided by the server. The client then attempts to create a 1312 connection using that version. Though the content of the Initial 1313 packet the client sends might not change in response to version 1314 negotiation, a client MUST increase the packet number it uses on 1315 every packet it sends. Packets MUST continue to use long headers 1316 (Section 17.2) and MUST include the new negotiated protocol version. 1318 The client MUST use the long header format and include its selected 1319 version on all packets until it has 1-RTT keys and it has received a 1320 packet from the server which is not a Version Negotiation packet. 1322 A client MUST NOT change the version it uses unless it is in response 1323 to a Version Negotiation packet from the server. Once a client 1324 receives a packet from the server which is not a Version Negotiation 1325 packet, it MUST discard other Version Negotiation packets on the same 1326 connection. Similarly, a client MUST ignore a Version Negotiation 1327 packet if it has already received and acted on a Version Negotiation 1328 packet. 1330 A client MUST ignore a Version Negotiation packet that lists the 1331 client's chosen version. 1333 A client MAY attempt 0-RTT after receiving a Version Negotiation 1334 packet. A client that sends additional 0-RTT packets MUST NOT reset 1335 the packet number to 0 as a result, see Section 17.5.3. 1337 Version negotiation packets have no cryptographic protection. The 1338 result of the negotiation MUST be revalidated as part of the 1339 cryptographic handshake (see Section 7.3.3). 1341 6.3. Using Reserved Versions 1343 For a server to use a new version in the future, clients must 1344 correctly handle unsupported versions. To help ensure this, a server 1345 SHOULD include a reserved version (see Section 15) while generating a 1346 Version Negotiation packet. 1348 The design of version negotiation permits a server to avoid 1349 maintaining state for packets that it rejects in this fashion. The 1350 validation of version negotiation (see Section 7.3.3) only validates 1351 the result of version negotiation, which is the same no matter which 1352 reserved version was sent. A server MAY therefore send different 1353 reserved version numbers in the Version Negotiation Packet and in its 1354 transport parameters. 1356 A client MAY send a packet using a reserved version number. This can 1357 be used to solicit a list of supported versions from a server. 1359 7. Cryptographic and Transport Handshake 1361 QUIC relies on a combined cryptographic and transport handshake to 1362 minimize connection establishment latency. QUIC uses the CRYPTO 1363 frame Section 19.6 to transmit the cryptographic handshake. Version 1364 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 1365 QUIC version number could indicate that a different cryptographic 1366 handshake protocol is in use. 1368 QUIC provides reliable, ordered delivery of the cryptographic 1369 handshake data. QUIC packet protection is used to encrypt as much of 1370 the handshake protocol as possible. The cryptographic handshake MUST 1371 provide the following properties: 1373 o authenticated key exchange, where 1375 * a server is always authenticated, 1377 * a client is optionally authenticated, 1378 * every connection produces distinct and unrelated keys, 1380 * keying material is usable for packet protection for both 0-RTT 1381 and 1-RTT packets, and 1383 * 1-RTT keys have forward secrecy 1385 o authenticated values for the transport parameters of the peer (see 1386 Section 7.3) 1388 o authenticated confirmation of version negotiation (see 1389 Section 7.3.3) 1391 o authenticated negotiation of an application protocol (TLS uses 1392 ALPN [RFC7301] for this purpose) 1394 The first CRYPTO frame from a client MUST be sent in a single packet. 1395 Any second attempt that is triggered by address validation (see 1396 Section 8.1) MUST also be sent within a single packet. This avoids 1397 having to reassemble a message from multiple packets. 1399 The first client packet of the cryptographic handshake protocol MUST 1400 fit within a 1232 byte QUIC packet payload. This includes overheads 1401 that reduce the space available to the cryptographic handshake 1402 protocol. 1404 An endpoint can verify support for Explicit Congestion Notification 1405 (ECN) in the first packets it sends, as described in Section 13.3.2. 1407 The CRYPTO frame can be sent in different packet number spaces. The 1408 sequence numbers used by CRYPTO frames to ensure ordered delivery of 1409 cryptographic handshake data start from zero in each packet number 1410 space. 1412 7.1. Example Handshake Flows 1414 Details of how TLS is integrated with QUIC are provided in 1415 [QUIC-TLS], but some examples are provided here. An extension of 1416 this exchange to support client address validation is shown in 1417 Section 8.1.1. 1419 Once any version negotiation and address validation exchanges are 1420 complete, the cryptographic handshake is used to agree on 1421 cryptographic keys. The cryptographic handshake is carried in 1422 Initial (Section 17.5) and Handshake (Section 17.6) packets. 1424 Figure 4 provides an overview of the 1-RTT handshake. Each line 1425 shows a QUIC packet with the packet type and packet number shown 1426 first, followed by the frames that are typically contained in those 1427 packets. So, for instance the first packet is of type Initial, with 1428 packet number 0, and contains a CRYPTO frame carrying the 1429 ClientHello. 1431 Note that multiple QUIC packets - even of different encryption levels 1432 - may be coalesced into a single UDP datagram (see Section 12.2), and 1433 so this handshake may consist of as few as 4 UDP datagrams, or any 1434 number more. For instance, the server's first flight contains 1435 packets from the Initial encryption level (obfuscation), the 1436 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1437 encryption level. 1439 Client Server 1441 Initial[0]: CRYPTO[CH] -> 1443 Initial[0]: CRYPTO[SH] ACK[0] 1444 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1445 <- 1-RTT[0]: STREAM[1, "..."] 1447 Initial[1]: ACK[0] 1448 Handshake[0]: CRYPTO[FIN], ACK[0] 1449 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1451 1-RTT[1]: STREAM[55, "..."], ACK[0] 1452 <- Handshake[1]: ACK[0] 1454 Figure 4: Example 1-RTT Handshake 1456 Figure 5 shows an example of a connection with a 0-RTT handshake and 1457 a single packet of 0-RTT data. Note that as described in 1458 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1459 encryption level, and the client sends 1-RTT packets in the same 1460 packet number space. 1462 Client Server 1464 Initial[0]: CRYPTO[CH] 1465 0-RTT[0]: STREAM[0, "..."] -> 1467 Initial[0]: CRYPTO[SH] ACK[0] 1468 Handshake[0] CRYPTO[EE, CERT, CV, FIN] 1469 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1471 Initial[1]: ACK[0] 1472 Handshake[0]: CRYPTO[FIN], ACK[0] 1473 1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1475 1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1476 <- Handshake[1]: ACK[0] 1478 Figure 5: Example 0-RTT Handshake 1480 7.2. Negotiating Connection IDs 1482 A connection ID is used to ensure consistent routing of packets, as 1483 described in Section 5.1. The long header contains two connection 1484 IDs: the Destination Connection ID is chosen by the recipient of the 1485 packet and is used to provide consistent routing; the Source 1486 Connection ID is used to set the Destination Connection ID used by 1487 the peer. 1489 During the handshake, packets with the long header (Section 17.2) are 1490 used to establish the connection ID that each endpoint uses. Each 1491 endpoint uses the Source Connection ID field to specify the 1492 connection ID that is used in the Destination Connection ID field of 1493 packets being sent to them. Upon receiving a packet, each endpoint 1494 sets the Destination Connection ID it sends to match the value of the 1495 Source Connection ID that they receive. 1497 When an Initial packet is sent by a client which has not previously 1498 received a Retry packet from the server, it populates the Destination 1499 Connection ID field with an unpredictable value. This MUST be at 1500 least 8 bytes in length. Until a packet is received from the server, 1501 the client MUST use the same value unless it abandons the connection 1502 attempt and starts a new one. The initial Destination Connection ID 1503 is used to determine packet protection keys for Initial packets. 1505 The final version used for a connection might be different from the 1506 version of the first Initial from the client. To enable consistent 1507 routing through the handshake, a client SHOULD select an initial 1508 Destination Connection ID length long enough to fulfill the minimum 1509 size for every QUIC version it supports. 1511 The client populates the Source Connection ID field with a value of 1512 its choosing and sets the SCIL field to match. 1514 The Destination Connection ID field in the server's Initial packet 1515 contains a connection ID that is chosen by the recipient of the 1516 packet (i.e., the client); the Source Connection ID includes the 1517 connection ID that the sender of the packet wishes to use (see 1518 Section 5.1). The server MUST use consistent Source Connection IDs 1519 during the handshake. 1521 On first receiving an Initial or Retry packet from the server, the 1522 client uses the Source Connection ID supplied by the server as the 1523 Destination Connection ID for subsequent packets. That means that a 1524 client might change the Destination Connection ID twice during 1525 connection establishment, once in response to a Retry and once in 1526 response to the first Initial packet from the server. Once a client 1527 has received an Initial packet from the server, it MUST discard any 1528 packet it receives with a different Source Connection ID. 1530 A client MUST only change the value it sends in the Destination 1531 Connection ID in response to the first packet of each type it 1532 receives from the server (Retry or Initial); a server MUST set its 1533 value based on the Initial packet. Any additional changes are not 1534 permitted; if subsequent packets of those types include a different 1535 Source Connection ID, they MUST be discarded. This avoids problems 1536 that might arise from stateless processing of multiple Initial 1537 packets producing different connection IDs. 1539 The connection ID can change over the lifetime of a connection, 1540 especially in response to connection migration (Section 9), see 1541 Section 5.1.1 for details. 1543 7.3. Transport Parameters 1545 During connection establishment, both endpoints make authenticated 1546 declarations of their transport parameters. These declarations are 1547 made unilaterally by each endpoint. Endpoints are required to comply 1548 with the restrictions implied by these parameters; the description of 1549 each parameter includes rules for its handling. 1551 The encoding of the transport parameters is detailed in Section 18. 1553 QUIC includes the encoded transport parameters in the cryptographic 1554 handshake. Once the handshake completes, the transport parameters 1555 declared by the peer are available. Each endpoint validates the 1556 value provided by its peer. In particular, version negotiation MUST 1557 be validated (see Section 7.3.3) before the connection establishment 1558 is considered properly complete. 1560 Definitions for each of the defined transport parameters are included 1561 in Section 18.1. Any given parameter MUST appear at most once in a 1562 given transport parameters extension. An endpoint MUST treat receipt 1563 of duplicate transport parameters as a connection error of type 1564 TRANSPORT_PARAMETER_ERROR. 1566 A server MUST include the original_connection_id transport parameter 1567 (Section 18.1) if it sent a Retry packet to enable validation of the 1568 Retry, as described in Section 17.7. 1570 7.3.1. Values of Transport Parameters for 0-RTT 1572 A client that attempts to send 0-RTT data MUST remember the transport 1573 parameters used by the server. The transport parameters that the 1574 server advertises during connection establishment apply to all 1575 connections that are resumed using the keying material established 1576 during that handshake. Remembered transport parameters apply to the 1577 new connection until the handshake completes and new transport 1578 parameters from the server can be provided. 1580 A server can remember the transport parameters that it advertised, or 1581 store an integrity-protected copy of the values in the ticket and 1582 recover the information when accepting 0-RTT data. A server uses the 1583 transport parameters in determining whether to accept 0-RTT data. 1585 A server MAY accept 0-RTT and subsequently provide different values 1586 for transport parameters for use in the new connection. If 0-RTT 1587 data is accepted by the server, the server MUST NOT reduce any limits 1588 or alter any values that might be violated by the client with its 1589 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1590 set values for the following parameters (Section 18.1) that are 1591 smaller than the remembered value of those parameters. 1593 o initial_max_data 1595 o initial_max_stream_data_bidi_local 1597 o initial_max_stream_data_bidi_remote 1599 o initial_max_stream_data_uni 1601 o initial_max_streams_bidi 1603 o initial_max_streams_uni 1605 Omitting or setting a zero value for certain transport parameters can 1606 result in 0-RTT data being enabled, but not usable. The applicable 1607 subset of transport parameters that permit sending of application 1608 data SHOULD be set to non-zero values for 0-RTT. This includes 1609 initial_max_data and either initial_max_streams_bidi and 1610 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 1611 initial_max_stream_data_uni. 1613 The value of the server's previous preferred_address MUST NOT be used 1614 when establishing a new connection; rather, the client should wait to 1615 observe the server's new preferred_address value in the handshake. 1617 A server MUST either reject 0-RTT data or abort a handshake if the 1618 implied values for transport parameters cannot be supported. 1620 7.3.2. New Transport Parameters 1622 New transport parameters can be used to negotiate new protocol 1623 behavior. An endpoint MUST ignore transport parameters that it does 1624 not support. Absence of a transport parameter therefore disables any 1625 optional protocol feature that is negotiated using the parameter. 1627 New transport parameters can be registered according to the rules in 1628 Section 22.1. 1630 7.3.3. Version Negotiation Validation 1632 Though the cryptographic handshake has integrity protection, two 1633 forms of QUIC version downgrade are possible. In the first, an 1634 attacker replaces the QUIC version in the Initial packet. In the 1635 second, a fake Version Negotiation packet is sent by an attacker. To 1636 protect against these attacks, the transport parameters include three 1637 fields that encode version information. These parameters are used to 1638 retroactively authenticate the choice of version (see Section 6). 1640 The cryptographic handshake provides integrity protection for the 1641 negotiated version as part of the transport parameters (see 1642 Section 18.1). As a result, attacks on version negotiation by an 1643 attacker can be detected. 1645 The client includes the initial_version field in its transport 1646 parameters. The initial_version is the version that the client 1647 initially attempted to use. If the server did not send a Version 1648 Negotiation packet Section 17.4, this will be identical to the 1649 negotiated_version field in the server transport parameters. 1651 A server that processes all packets in a stateful fashion can 1652 remember how version negotiation was performed and validate the 1653 initial_version value. 1655 A server that does not maintain state for every packet it receives 1656 (i.e., a stateless server) uses a different process. If the 1657 initial_version matches the version of QUIC that is in use, a 1658 stateless server can accept the value. 1660 If the initial_version is different from the version of QUIC that is 1661 in use, a stateless server MUST check that it would have sent a 1662 Version Negotiation packet if it had received a packet with the 1663 indicated initial_version. If a server would have accepted the 1664 version included in the initial_version and the value differs from 1665 the QUIC version that is in use, the server MUST terminate the 1666 connection with a VERSION_NEGOTIATION_ERROR error. 1668 The server includes both the version of QUIC that is in use and a 1669 list of the QUIC versions that the server supports (see 1670 Section 18.1). 1672 The negotiated_version field is the version that is in use. This 1673 MUST be set by the server to the value that is on the Initial packet 1674 that it accepts (not an Initial packet that triggers a Retry or 1675 Version Negotiation packet). A client that receives a 1676 negotiated_version that does not match the version of QUIC that is in 1677 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 1678 error code. 1680 The server includes a list of versions that it would send in any 1681 version negotiation packet (Section 17.4) in the supported_versions 1682 field. The server populates this field even if it did not send a 1683 version negotiation packet. 1685 The client validates that the negotiated_version is included in the 1686 supported_versions list and - if version negotiation was performed - 1687 that it would have selected the negotiated version. A client MUST 1688 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 1689 if the current QUIC version is not listed in the supported_versions 1690 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 1691 code if version negotiation occurred but it would have selected a 1692 different version based on the value of the supported_versions list. 1694 When an endpoint accepts multiple QUIC versions, it can potentially 1695 interpret transport parameters as they are defined by any of the QUIC 1696 versions it supports. The version field in the QUIC packet header is 1697 authenticated using transport parameters. The position and the 1698 format of the version fields in transport parameters MUST either be 1699 identical across different QUIC versions, or be unambiguously 1700 different to ensure no confusion about their interpretation. One way 1701 that a new format could be introduced is to define a TLS extension 1702 with a different codepoint. 1704 8. Address Validation 1706 Address validation is used by QUIC to avoid being used for a traffic 1707 amplification attack. In such an attack, a packet is sent to a 1708 server with spoofed source address information that identifies a 1709 victim. If a server generates more or larger packets in response to 1710 that packet, the attacker can use the server to send more data toward 1711 the victim than it would be able to send on its own. 1713 The primary defense against amplification attack is verifying that an 1714 endpoint is able to receive packets at the transport address that it 1715 claims. Address validation is performed both during connection 1716 establishment (see Section 8.1) and during connection migration (see 1717 Section 8.2). 1719 8.1. Address Validation During Connection Establishment 1721 Connection establishment implicitly provides address validation for 1722 both endpoints. In particular, receipt of a packet protected with 1723 Handshake keys confirms that the client received the Initial packet 1724 from the server. Once the server has successfully processed a 1725 Handshake packet from the client, it can consider the client address 1726 to have been validated. 1728 Prior to validating the client address, servers MUST NOT send more 1729 than three times as many bytes as the number of bytes they have 1730 received. This limits the magnitude of any amplification attack that 1731 can be mounted using spoofed source addresses. In determining this 1732 limit, servers only count the size of successfully processed packets. 1734 Clients MUST pad UDP datagrams that contain only Initial packets to 1735 at least 1200 bytes. Once a client has received an acknowledgment 1736 for a Handshake packet it MAY send smaller datagrams. Sending padded 1737 datagrams ensures that the server is not overly constrained by the 1738 amplification restriction. 1740 In order to prevent a handshake deadlock as a result of the server 1741 being unable to send, clients SHOULD send a packet upon a handshake 1742 timeout, as described in [QUIC-RECOVERY]. If the client has no data 1743 to retransmit and does not have Handshake keys, it SHOULD send an 1744 Initial packet in a UDP datagram of at least 1200 bytes. If the 1745 client has Handshake keys, it SHOULD send a Handshake packet. 1747 A server might wish to validate the client address before starting 1748 the cryptographic handshake. QUIC uses a token in the Initial packet 1749 to provide address validation prior to completing the handshake. 1750 This token is delivered to the client during connection establishment 1751 with a Retry packet (see Section 8.1.1) or in a previous connection 1752 using the NEW_TOKEN frame (see Section 8.1.2). 1754 8.1.1. Address Validation using Retry Packets 1756 Upon receiving the client's Initial packet, the server can request 1757 address validation by sending a Retry packet (Section 17.7) 1758 containing a token. This token MUST be repeated by the client in all 1759 Initial packets it sends after it receives the Retry packet. In 1760 response to processing an Initial containing a token, a server can 1761 either abort the connection or permit it to proceed. 1763 As long as it is not possible for an attacker to generate a valid 1764 token for its own address (see Section 8.1.3) and the client is able 1765 to return that token, it proves to the server that it received the 1766 token. 1768 A server can also use a Retry packet to defer the state and 1769 processing costs of connection establishment. By giving the client a 1770 different connection ID to use, a server can cause the connection to 1771 be routed to a server instance with more resources available for new 1772 connections. 1774 A flow showing the use of a Retry packet is shown in Figure 6. 1776 Client Server 1778 Initial[0]: CRYPTO[CH] -> 1780 <- Retry+Token 1782 Initial+Token[0]: CRYPTO[CH] -> 1784 Initial[0]: CRYPTO[SH] ACK[0] 1785 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1786 <- 1-RTT[0]: STREAM[1, "..."] 1788 Figure 6: Example Handshake with Retry 1790 8.1.2. Address Validation for Future Connections 1792 A server MAY provide clients with an address validation token during 1793 one connection that can be used on a subsequent connection. Address 1794 validation is especially important with 0-RTT because a server 1795 potentially sends a significant amount of data to a client in 1796 response to 0-RTT data. 1798 The server uses the NEW_TOKEN frame Section 19.7 to provide the 1799 client with an address validation token that can be used to validate 1800 future connections. The client includes this token in Initial 1801 packets to provide address validation in a future connection. The 1802 client MUST include the token in all Initial packets it sends, unless 1803 a Retry replaces the token with a newer token. The client MUST NOT 1804 use the token provided in a Retry for future connections. Servers 1805 MAY discard any Initial packet that does not carry the expected 1806 token. 1808 Unlike the token that is created for a Retry packet, there might be 1809 some time between when the token is created and when the token is 1810 subsequently used. Thus, a resumption token SHOULD include an 1811 expiration time. The server MAY include either an explicit 1812 expiration time or an issued timestamp and dynamically calculate the 1813 expiration time. It is also unlikely that the client port number is 1814 the same on two different connections; validating the port is 1815 therefore unlikely to be successful. 1817 A resumption token SHOULD be constructed to be easily distinguishable 1818 from tokens that are sent in Retry packets as they are carried in the 1819 same field. 1821 If the client has a token received in a NEW_TOKEN frame on a previous 1822 connection to what it believes to be the same server, it can include 1823 that value in the Token field of its Initial packet. 1825 A token allows a server to correlate activity between the connection 1826 where the token was issued and any connection where it is used. 1827 Clients that want to break continuity of identity with a server MAY 1828 discard tokens provided using the NEW_TOKEN frame. Tokens obtained 1829 in Retry packets MUST NOT be discarded. 1831 A client SHOULD NOT reuse a token in different connections. Reusing 1832 a token allows connections to be linked by entities on the network 1833 path (see Section 9.5). A client MUST NOT reuse a token if it 1834 believes that its point of network attachment has changed since the 1835 token was last used; that is, if there is a change in its local IP 1836 address or network interface. A client needs to start the connection 1837 process over if it migrates prior to completing the handshake. 1839 When a server receives an Initial packet with an address validation 1840 token, it SHOULD attempt to validate it, unless it has already 1841 completed address validation. If the token is invalid then the 1842 server SHOULD proceed as if the client did not have a validated 1843 address, including potentially sending a Retry. If the validation 1844 succeeds, the server SHOULD then allow the handshake to proceed. 1846 Note: The rationale for treating the client as unvalidated rather 1847 than discarding the packet is that the client might have received 1848 the token in a previous connection using the NEW_TOKEN frame, and 1849 if the server has lost state, it might be unable to validate the 1850 token at all, leading to connection failure if the packet is 1851 discarded. A server MAY encode tokens provided with NEW_TOKEN 1852 frames and Retry packets differently, and validate the latter more 1853 strictly. 1855 In a stateless design, a server can use encrypted and authenticated 1856 tokens to pass information to clients that the server can later 1857 recover and use to validate a client address. Tokens are not 1858 integrated into the cryptographic handshake and so they are not 1859 authenticated. For instance, a client might be able to reuse a 1860 token. To avoid attacks that exploit this property, a server can 1861 limit its use of tokens to only the information needed validate 1862 client addresses. 1864 Attackers could replay tokens to use servers as amplifiers in DDoS 1865 attacks. To protect against such attacks, servers SHOULD ensure that 1866 tokens sent in Retry packets are only accepted for a short time. 1867 Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need 1868 to be valid for longer, but SHOULD NOT be accepted multiple times in 1869 a short period. Servers are encouraged to allow tokens to be used 1870 only once, if possible. 1872 8.1.3. Address Validation Token Integrity 1874 An address validation token MUST be difficult to guess. Including a 1875 large enough random value in the token would be sufficient, but this 1876 depends on the server remembering the value it sends to clients. 1878 A token-based scheme allows the server to offload any state 1879 associated with validation to the client. For this design to work, 1880 the token MUST be covered by integrity protection against 1881 modification or falsification by clients. Without integrity 1882 protection, malicious clients could generate or guess values for 1883 tokens that would be accepted by the server. Only the server 1884 requires access to the integrity protection key for tokens. 1886 There is no need for a single well-defined format for the token 1887 because the server that generates the token also consumes it. A 1888 token could include information about the claimed client address (IP 1889 and port), a timestamp, and any other supplementary information the 1890 server will need to validate the token in the future. 1892 8.2. Path Validation 1894 Path validation is used during connection migration (see Section 9 1895 and Section 9.6) by the migrating endpoint to verify reachability of 1896 a peer from a new local address. In path validation, endpoints test 1897 reachability between a specific local address and a specific peer 1898 address, where an address is the two-tuple of IP address and port. 1900 Path validation tests that packets can be both sent to and received 1901 from a peer on the path. Importantly, it validates that the packets 1902 received from the migrating endpoint do not carry a spoofed source 1903 address. 1905 Path validation can be used at any time by either endpoint. For 1906 instance, an endpoint might check that a peer is still in possession 1907 of its address after a period of quiescence. 1909 Path validation is not designed as a NAT traversal mechanism. Though 1910 the mechanism described here might be effective for the creation of 1911 NAT bindings that support NAT traversal, the expectation is that one 1912 or other peer is able to receive packets without first having sent a 1913 packet on that path. Effective NAT traversal needs additional 1914 synchronization mechanisms that are not provided here. 1916 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 1917 are used for path validation with other frames. In particular, an 1918 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 1919 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 1920 PATH_CHALLENGE. 1922 When probing a new path, an endpoint might want to ensure that its 1923 peer has an unused connection ID available for responses. The 1924 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 1925 same packet. This ensures that an unused connection ID will be 1926 available to the peer when sending a response. 1928 8.3. Initiating Path Validation 1930 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 1931 containing a random payload on the path to be validated. 1933 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 1934 packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more 1935 frequently than it would an Initial packet, ensuring that connection 1936 migration is no more load on a new path than establishing a new 1937 connection. 1939 The endpoint MUST use fresh random data in every PATH_CHALLENGE frame 1940 so that it can associate the peer's response with the causative 1941 PATH_CHALLENGE. 1943 8.4. Path Validation Responses 1945 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 1946 immediately by echoing the data contained in the PATH_CHALLENGE frame 1947 in a PATH_RESPONSE frame. However, because a PATH_CHALLENGE might be 1948 sent from a spoofed address, an endpoint MUST limit the rate at which 1949 it sends PATH_RESPONSE frames and MAY silently discard PATH_CHALLENGE 1950 frames that would cause it to respond at a higher rate. 1952 To ensure that packets can be both sent to and received from the 1953 peer, the PATH_RESPONSE MUST be sent on the same path as the 1954 triggering PATH_CHALLENGE. That is, from the same local address on 1955 which the PATH_CHALLENGE was received, to the same remote address 1956 from which the PATH_CHALLENGE was received. 1958 8.5. Successful Path Validation 1960 A new address is considered valid when a PATH_RESPONSE frame is 1961 received containing data that was sent in a previous PATH_CHALLENGE. 1962 Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE 1963 frame is not adequate validation, since the acknowledgment can be 1964 spoofed by a malicious peer. 1966 For path validation to be successful, a PATH_RESPONSE frame MUST be 1967 received from the same remote address to which the corresponding 1968 PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a 1969 different remote address than the one to which the PATH_CHALLENGE was 1970 sent, path validation is considered to have failed, even if the data 1971 matches that sent in the PATH_CHALLENGE. 1973 Additionally, the PATH_RESPONSE frame MUST be received on the same 1974 local address from which the corresponding PATH_CHALLENGE was sent. 1975 An endpoint considers the path to be valid when a PATH_RESPONSE frame 1976 is received on the same path with the same payload as the 1977 PATH_CHALLENGE frame. 1979 If a PATH_RESPONSE frame is received on a different local address 1980 than the one from which the PATH_CHALLENGE was sent, path validation 1981 is not considered to be successful, even if the data matches the 1982 PATH_CHALLENGE. This doesn't result in path validation failure, as 1983 it might be a result of a forwarded packet (see Section 9.3.3) or 1984 misrouting. 1986 8.6. Failed Path Validation 1988 Path validation only fails when the endpoint attempting to validate 1989 the path abandons its attempt to validate the path. 1991 Endpoints SHOULD abandon path validation based on a timer. When 1992 setting this timer, implementations are cautioned that the new path 1993 could have a longer round-trip time than the original. A value of 1994 three times the current Retransmittion Timeout (RTO) as defined in 1995 [QUIC-RECOVERY] is RECOMMENDED. 1997 Note that the endpoint might receive packets containing other frames 1998 on the new path, but a PATH_RESPONSE frame with appropriate data is 1999 required for path validation to succeed. 2001 When an endpoint abandons path validation, it determines that the 2002 path is unusable. This does not necessarily imply a failure of the 2003 connection - endpoints can continue sending packets over other paths 2004 as appropriate. If no paths are available, an endpoint can wait for 2005 a new path to become available or close the connection. 2007 A path validation might be abandoned for other reasons besides 2008 failure. Primarily, this happens if a connection migration to a new 2009 path is initiated while a path validation on the old path is in 2010 progress. 2012 9. Connection Migration 2014 The use of a connection ID allows connections to survive changes to 2015 endpoint addresses (that is, IP address and/or port), such as those 2016 caused by an endpoint migrating to a new network. This section 2017 describes the process by which an endpoint migrates to a new address. 2019 An endpoint MUST NOT initiate connection migration before the 2020 handshake is finished and the endpoint has 1-RTT keys. The design of 2021 QUIC relies on endpoints retaining a stable address for the duration 2022 of the handshake. 2024 An endpoint also MUST NOT initiate connection migration if the peer 2025 sent the "disable_migration" transport parameter during the 2026 handshake. An endpoint which has sent this transport parameter, but 2027 detects that a peer has nonetheless migrated to a different network 2028 MAY treat this as a connection error of type INVALID_MIGRATION. 2030 Not all changes of peer address are intentional migrations. The peer 2031 could experience NAT rebinding: a change of address due to a 2032 middlebox, usually a NAT, allocating a new outgoing port or even a 2033 new outgoing IP address for a flow. NAT rebinding is not connection 2034 migration as defined in this section, though an endpoint SHOULD 2035 perform path validation (Section 8.2) if it detects a change in the 2036 IP address of its peer. 2038 This document limits migration of connections to new client 2039 addresses, except as described in Section 9.6. Clients are 2040 responsible for initiating all migrations. Servers do not send non- 2041 probing packets (see Section 9.1) toward a client address until they 2042 see a non-probing packet from that address. If a client receives 2043 packets from an unknown server address, the client MUST discard these 2044 packets. 2046 9.1. Probing a New Path 2048 An endpoint MAY probe for peer reachability from a new local address 2049 using path validation Section 8.2 prior to migrating the connection 2050 to the new local address. Failure of path validation simply means 2051 that the new path is not usable for this connection. Failure to 2052 validate a path does not cause the connection to end unless there are 2053 no valid alternative paths available. 2055 An endpoint uses a new connection ID for probes sent from a new local 2056 address, see Section 9.5 for further discussion. An endpoint that 2057 uses a new local address needs to ensure that at least one new 2058 connection ID is available at the peer. That can be achieved by 2059 including a NEW_CONNECTION_ID frame in the probe. 2061 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2062 is probing for reachability on a path. An endpoint sends a 2063 PATH_RESPONSE in response as per Section 8.2. 2065 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2066 are "probing frames", and all other frames are "non-probing frames". 2067 A packet containing only probing frames is a "probing packet", and a 2068 packet containing any other frame is a "non-probing packet". 2070 9.2. Initiating Connection Migration 2072 An endpoint can migrate a connection to a new local address by 2073 sending packets containing non-probing frames from that address. 2075 Each endpoint validates its peer's address during connection 2076 establishment. Therefore, a migrating endpoint can send to its peer 2077 knowing that the peer is willing to receive at the peer's current 2078 address. Thus an endpoint can migrate to a new local address without 2079 first validating the peer's address. 2081 When migrating, the new path might not support the endpoint's current 2082 sending rate. Therefore, the endpoint resets its congestion 2083 controller, as described in Section 9.4. 2085 The new path might not have the same ECN capability. Therefore, the 2086 endpoint verifies ECN capability as described in Section 13.3. 2088 Receiving acknowledgments for data sent on the new path serves as 2089 proof of the peer's reachability from the new address. Note that 2090 since acknowledgments may be received on any path, return 2091 reachability on the new path is not established. To establish return 2092 reachability on the new path, an endpoint MAY concurrently initiate 2093 path validation Section 8.2 on the new path. 2095 9.3. Responding to Connection Migration 2097 Receiving a packet from a new peer address containing a non-probing 2098 frame indicates that the peer has migrated to that address. 2100 In response to such a packet, an endpoint MUST start sending 2101 subsequent packets to the new peer address and MUST initiate path 2102 validation (Section 8.2) to verify the peer's ownership of the 2103 unvalidated address. 2105 An endpoint MAY send data to an unvalidated peer address, but it MUST 2106 protect against potential attacks as described in Section 9.3.1 and 2107 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2108 that address has been seen recently. 2110 An endpoint only changes the address that it sends packets to in 2111 response to the highest-numbered non-probing packet. This ensures 2112 that an endpoint does not send packets to an old peer address in the 2113 case that it receives reordered packets. 2115 After changing the address to which it sends non-probing packets, an 2116 endpoint could abandon any path validation for other addresses. 2118 Receiving a packet from a new peer address might be the result of a 2119 NAT rebinding at the peer. 2121 After verifying a new client address, the server SHOULD send new 2122 address validation tokens (Section 8) to the client. 2124 9.3.1. Peer Address Spoofing 2126 It is possible that a peer is spoofing its source address to cause an 2127 endpoint to send excessive amounts of data to an unwilling host. If 2128 the endpoint sends significantly more data than the spoofing peer, 2129 connection migration might be used to amplify the volume of data that 2130 an attacker can generate toward a victim. 2132 As described in Section 9.3, an endpoint is required to validate a 2133 peer's new address to confirm the peer's possession of the new 2134 address. Until a peer's address is deemed valid, an endpoint MUST 2135 limit the rate at which it sends data to this address. The endpoint 2136 MUST NOT send more than a minimum congestion window's worth of data 2137 per estimated round-trip time (kMinimumWindow, as defined in 2138 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2139 being used for a denial of service attack against an unsuspecting 2140 victim. Note that since the endpoint will not have any round-trip 2141 time measurements to this address, the estimate SHOULD be the default 2142 initial value (see [QUIC-RECOVERY]). 2144 If an endpoint skips validation of a peer address as described in 2145 Section 9.3, it does not need to limit its sending rate. 2147 9.3.2. On-Path Address Spoofing 2149 An on-path attacker could cause a spurious connection migration by 2150 copying and forwarding a packet with a spoofed address such that it 2151 arrives before the original packet. The packet with the spoofed 2152 address will be seen to come from a migrating connection, and the 2153 original packet will be seen as a duplicate and dropped. After a 2154 spurious migration, validation of the source address will fail 2155 because the entity at the source address does not have the necessary 2156 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2157 that is sent to it even if it wanted to. 2159 To protect the connection from failing due to such a spurious 2160 migration, an endpoint MUST revert to using the last validated peer 2161 address when validation of a new peer address fails. 2163 If an endpoint has no state about the last validated peer address, it 2164 MUST close the connection silently by discarding all connection 2165 state. This results in new packets on the connection being handled 2166 generically. For instance, an endpoint MAY send a stateless reset in 2167 response to any further incoming packets. 2169 Note that receipt of packets with higher packet numbers from the 2170 legitimate peer address will trigger another connection migration. 2171 This will cause the validation of the address of the spurious 2172 migration to be abandoned. 2174 9.3.3. Off-Path Packet Forwarding 2176 An off-path attacker that can observe packets might forward copies of 2177 genuine packets to endpoints. If the copied packet arrives before 2178 the genuine packet, this will appear as a NAT rebinding. Any genuine 2179 packet will be discarded as a duplicate. If the attacker is able to 2180 continue forwarding packets, it might be able to cause migration to a 2181 path via the attacker. This places the attacker on path, giving it 2182 the ability to observe or drop all subsequent packets. 2184 Unlike the attack described in Section 9.3.2, the attacker can ensure 2185 that the new path is successfully validated. 2187 This style of attack relies on the attacker using a path that is 2188 approximately as fast as the direct path between endpoints. The 2189 attack is more reliable if relatively few packets are sent or if 2190 packet loss coincides with the attempted attack. 2192 A non-probing packet received on the original path that increases the 2193 maximum received packet number will cause the endpoint to move back 2194 to that path. Eliciting packets on this path increases the 2195 likelihood that the attack is unsuccessful. Therefore, mitigation of 2196 this attack relies on triggering the exchange of packets. 2198 In response to an apparent migration, endpoints MUST validate the 2199 previously active path using a PATH_CHALLENGE frame. This induces 2200 the sending of new packets on that path. If the path is no longer 2201 viable, the validation attempt will time out and fail; if the path is 2202 viable, but no longer desired, the validation will succeed, but only 2203 results in probing packets being sent on the path. 2205 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2206 send a non-probing packet in response. If the non-probing packet 2207 arrives before any copy made by an attacker, this results in the 2208 connection being migrated back to the original path. Any subsequent 2209 migration to another path restarts this entire process. 2211 This defense is imperfect, but this is not considered a serious 2212 problem. If the path via the attack is reliably faster than the 2213 original path despite multiple attempts to use that original path, it 2214 is not possible to distinguish between attack and an improvement in 2215 routing. 2217 An endpoint could also use heuristics to improve detection of this 2218 style of attack. For instance, NAT rebinding is improbable if 2219 packets were recently received on the old path, similarly rebinding 2220 is rare on IPv6 paths. Endpoints can also look for duplicated 2221 packets. Conversely, a change in connection ID is more likely to 2222 indicate an intentional migration rather than an attack. 2224 9.4. Loss Detection and Congestion Control 2226 The capacity available on the new path might not be the same as the 2227 old path. Packets sent on the old path SHOULD NOT contribute to 2228 congestion control or RTT estimation for the new path. 2230 On confirming a peer's ownership of its new address, an endpoint 2231 SHOULD immediately reset the congestion controller and round-trip 2232 time estimator for the new path. 2234 An endpoint MUST NOT return to the send rate used for the previous 2235 path unless it is reasonably sure that the previous send rate is 2236 valid for the new path. For instance, a change in the client's port 2237 number is likely indicative of a rebinding in a middlebox and not a 2238 complete change in path. This determination likely depends on 2239 heuristics, which could be imperfect; if the new path capacity is 2240 significantly reduced, ultimately this relies on the congestion 2241 controller responding to congestion signals and reducing send rates 2242 appropriately. 2244 There may be apparent reordering at the receiver when an endpoint 2245 sends data and probes from/to multiple addresses during the migration 2246 period, since the two resulting paths may have different round-trip 2247 times. A receiver of packets on multiple paths will still send ACK 2248 frames covering all received packets. 2250 While multiple paths might be used during connection migration, a 2251 single congestion control context and a single loss recovery context 2252 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2253 endpoint might delay switching to a new congestion control context 2254 until it is confirmed that an old path is no longer needed (such as 2255 the case in Section 9.3.3). 2257 A sender can make exceptions for probe packets so that their loss 2258 detection is independent and does not unduly cause the congestion 2259 controller to reduce its sending rate. An endpoint might set a 2260 separate timer when a PATH_CHALLENGE is sent, which is cancelled when 2261 the corresponding PATH_RESPONSE is received. If the timer fires 2262 before the PATH_RESPONSE is received, the endpoint might send a new 2263 PATH_CHALLENGE, and restart the timer for a longer period of time. 2265 9.5. Privacy Implications of Connection Migration 2267 Using a stable connection ID on multiple network paths allows a 2268 passive observer to correlate activity between those paths. An 2269 endpoint that moves between networks might not wish to have their 2270 activity correlated by any entity other than their peer, so different 2271 connection IDs are used when sending from different local addresses, 2272 as discussed in Section 5.1. For this to be effective endpoints need 2273 to ensure that connections IDs they provide cannot be linked by any 2274 other entity. 2276 This eliminates the use of the connection ID for linking activity 2277 from the same connection on different networks. Protection of packet 2278 numbers ensures that packet numbers cannot be used to correlate 2279 activity. This does not prevent other properties of packets, such as 2280 timing and size, from being used to correlate activity. 2282 Clients MAY move to a new connection ID at any time based on 2283 implementation-specific concerns. For example, after a period of 2284 network inactivity NAT rebinding might occur when the client begins 2285 sending data again. 2287 A client might wish to reduce linkability by employing a new 2288 connection ID and source UDP port when sending traffic after a period 2289 of inactivity. Changing the UDP port from which it sends packets at 2290 the same time might cause the packet to appear as a connection 2291 migration. This ensures that the mechanisms that support migration 2292 are exercised even for clients that don't experience NAT rebindings 2293 or genuine migrations. Changing port number can cause a peer to 2294 reset its congestion state (see Section 9.4), so the port SHOULD only 2295 be changed infrequently. 2297 Endpoints that use connection IDs with length greater than zero could 2298 have their activity correlated if their peers keep using the same 2299 destination connection ID after migration. Endpoints that receive 2300 packets with a previously unused Destination Connection ID SHOULD 2301 change to sending packets with a connection ID that has not been used 2302 on any other network path. The goal here is to ensure that packets 2303 sent on different paths cannot be correlated. To fulfill this 2304 privacy requirement, endpoints that initiate migration and use 2305 connection IDs with length greater than zero SHOULD provide their 2306 peers with new connection IDs before migration. 2308 Caution: If both endpoints change connection ID in response to 2309 seeing a change in connection ID from their peer, then this can 2310 trigger an infinite sequence of changes. 2312 9.6. Server's Preferred Address 2314 QUIC allows servers to accept connections on one IP address and 2315 attempt to transfer these connections to a more preferred address 2316 shortly after the handshake. This is particularly useful when 2317 clients initially connect to an address shared by multiple servers 2318 but would prefer to use a unicast address to ensure connection 2319 stability. This section describes the protocol for migrating a 2320 connection to a preferred server address. 2322 Migrating a connection to a new server address mid-connection is left 2323 for future work. If a client receives packets from a new server 2324 address not indicated by the preferred_address transport parameter, 2325 the client SHOULD discard these packets. 2327 9.6.1. Communicating A Preferred Address 2329 A server conveys a preferred address by including the 2330 preferred_address transport parameter in the TLS handshake. 2332 Once the handshake is finished, the client SHOULD initiate path 2333 validation (see Section 8.2) of the server's preferred address using 2334 the connection ID provided in the preferred_address transport 2335 parameter. 2337 If path validation succeeds, the client SHOULD immediately begin 2338 sending all future packets to the new server address using the new 2339 connection ID and discontinue use of the old server address. If path 2340 validation fails, the client MUST continue sending all future packets 2341 to the server's original IP address. 2343 9.6.2. Responding to Connection Migration 2345 A server might receive a packet addressed to its preferred IP address 2346 at any time after it accepts a connection. If this packet contains a 2347 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2348 Section 8.2. The server MAY send other non-probing frames from its 2349 preferred address, but MUST continue sending all probing packets from 2350 its original IP address. 2352 The server SHOULD also initiate path validation of the client using 2353 its preferred address and the address from which it received the 2354 client probe. This helps to guard against spurious migration 2355 initiated by an attacker. 2357 Once the server has completed its path validation and has received a 2358 non-probing packet with a new largest packet number on its preferred 2359 address, the server begins sending non-probing packets to the client 2360 exclusively from its preferred IP address. It SHOULD drop packets 2361 for this connection received on the old IP address, but MAY continue 2362 to process delayed packets. 2364 9.6.3. Interaction of Client Migration and Preferred Address 2366 A client might need to perform a connection migration before it has 2367 migrated to the server's preferred address. In this case, the client 2368 SHOULD perform path validation to both the original and preferred 2369 server address from the client's new address concurrently. 2371 If path validation of the server's preferred address succeeds, the 2372 client MUST abandon validation of the original address and migrate to 2373 using the server's preferred address. If path validation of the 2374 server's preferred address fails but validation of the server's 2375 original address succeeds, the client MAY migrate to its new address 2376 and continue sending to the server's original address. 2378 If the connection to the server's preferred address is not from the 2379 same client address, the server MUST protect against potential 2380 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2381 to intentional simultaneous migration, this might also occur because 2382 the client's access network used a different NAT binding for the 2383 server's preferred address. 2385 Servers SHOULD initiate path validation to the client's new address 2386 upon receiving a probe packet from a different address. Servers MUST 2387 NOT send more than a minimum congestion window's worth of non-probing 2388 packets to the new address before path validation is complete. 2390 10. Connection Termination 2392 Connections should remain open until they become idle for a pre- 2393 negotiated period of time. A QUIC connection, once established, can 2394 be terminated in one of three ways: 2396 o idle timeout (Section 10.2) 2398 o immediate close (Section 10.3) 2400 o stateless reset (Section 10.4) 2402 10.1. Closing and Draining Connection States 2404 The closing and draining connection states exist to ensure that 2405 connections close cleanly and that delayed or reordered packets are 2406 properly discarded. These states SHOULD persist for three times the 2407 current Retransmission Timeout (RTO) interval as defined in 2408 [QUIC-RECOVERY]. 2410 An endpoint enters a closing period after initiating an immediate 2411 close (Section 10.3). While closing, an endpoint MUST NOT send 2412 packets unless they contain a CONNECTION_CLOSE frame (see 2413 Section 10.3 for details). An endpoint retains only enough 2414 information to generate a packet containing a CONNECTION_CLOSE frame 2415 and to identify packets as belonging to the connection. The 2416 connection ID and QUIC version is sufficient information to identify 2417 packets for a closing connection; an endpoint can discard all other 2418 connection state. An endpoint MAY retain packet protection keys for 2419 incoming packets to allow it to read and process a CONNECTION_CLOSE 2420 frame. 2422 The draining state is entered once an endpoint receives a signal that 2423 its peer is closing or draining. While otherwise identical to the 2424 closing state, an endpoint in the draining state MUST NOT send any 2425 packets. Retaining packet protection keys is unnecessary once a 2426 connection is in the draining state. 2428 An endpoint MAY transition from the closing period to the draining 2429 period if it can confirm that its peer is also closing or draining. 2430 Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is 2431 receiving a stateless reset. The draining period SHOULD end when the 2432 closing period would have ended. In other words, the endpoint can 2433 use the same end time, but cease retransmission of the closing 2434 packet. 2436 Disposing of connection state prior to the end of the closing or 2437 draining period could cause delayed or reordered packets to be 2438 handled poorly. Endpoints that have some alternative means to ensure 2439 that late-arriving packets on the connection do not create QUIC 2440 state, such as those that are able to close the UDP socket, MAY use 2441 an abbreviated draining period which can allow for faster resource 2442 recovery. Servers that retain an open socket for accepting new 2443 connections SHOULD NOT exit the closing or draining period early. 2445 Once the closing or draining period has ended, an endpoint SHOULD 2446 discard all connection state. This results in new packets on the 2447 connection being handled generically. For instance, an endpoint MAY 2448 send a stateless reset in response to any further incoming packets. 2450 The draining and closing periods do not apply when a stateless reset 2451 (Section 10.4) is sent. 2453 An endpoint is not expected to handle key updates when it is closing 2454 or draining. A key update might prevent the endpoint from moving 2455 from the closing state to draining, but it otherwise has no impact. 2457 An endpoint could receive packets from a new source address, 2458 indicating a client connection migration (Section 9), while in the 2459 closing period. An endpoint in the closing state MUST strictly limit 2460 the number of packets it sends to this new address until the address 2461 is validated (see Section 8.2). A server in the closing state MAY 2462 instead choose to discard packets received from a new source address. 2464 10.2. Idle Timeout 2466 If the idle timeout is enabled, a connection that remains idle for 2467 longer than the advertised idle timeout (see Section 18.1) is closed. 2468 A connection enters the draining state when the idle timeout expires. 2470 Each endpoint advertises its own idle timeout to its peer. The idle 2471 timeout starts from the last packet received. In order to ensure 2472 that initiating new activity postpones an idle timeout, an endpoint 2473 restarts this timer when sending a packet. An endpoint does not 2474 postpone the idle timeout if another packet has been sent containing 2475 frames other than ACK or PADDING, and that other packet has not been 2476 acknowledged or declared lost. Packets that contain only ACK or 2477 PADDING frames are not acknowledged until an endpoint has other 2478 frames to send, so they could prevent the timeout from being 2479 refreshed. 2481 The value for an idle timeout can be asymmetric. The value 2482 advertised by an endpoint is only used to determine whether the 2483 connection is live at that endpoint. An endpoint that sends packets 2484 near the end of the idle timeout period of a peer risks having those 2485 packets discarded if its peer enters the draining state before the 2486 packets arrive. If a peer could timeout within an RTO (see 2487 Section 5.3.3 of [QUIC-RECOVERY]), it is advisable to test for 2488 liveness before sending any data that cannot be retried safely. 2490 10.3. Immediate Close 2492 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 2493 terminate the connection immediately. A CONNECTION_CLOSE frame 2494 causes all streams to immediately become closed; open streams can be 2495 assumed to be implicitly reset. 2497 After sending a CONNECTION_CLOSE frame, endpoints immediately enter 2498 the closing state. During the closing period, an endpoint that sends 2499 a CONNECTION_CLOSE frame SHOULD respond to any packet that it 2500 receives with another packet containing a CONNECTION_CLOSE frame. To 2501 minimize the state that an endpoint maintains for a closing 2502 connection, endpoints MAY send the exact same packet. However, 2503 endpoints SHOULD limit the number of packets they generate containing 2504 a CONNECTION_CLOSE frame. For instance, an endpoint could 2505 progressively increase the number of packets that it receives before 2506 sending additional packets or increase the time between packets. 2508 Note: Allowing retransmission of a packet contradicts other advice 2509 in this document that recommends the creation of new packet 2510 numbers for every packet. Sending new packet numbers is primarily 2511 of advantage to loss recovery and congestion control, which are 2512 not expected to be relevant for a closed connection. 2513 Retransmitting the final packet requires less state. 2515 New packets from unverified addresses could be used to create an 2516 amplification attack (see Section 8). To avoid this, endpoints MUST 2517 either limit transmission of CONNECTION_CLOSE frames to validated 2518 addresses or drop packets without response if the response would be 2519 more than three times larger than the received packet. 2521 After receiving a CONNECTION_CLOSE frame, endpoints enter the 2522 draining state. An endpoint that receives a CONNECTION_CLOSE frame 2523 MAY send a single packet containing a CONNECTION_CLOSE frame before 2524 entering the draining state, using a CONNECTION_CLOSE frame and a 2525 NO_ERROR code if appropriate. An endpoint MUST NOT send further 2526 packets, which could result in a constant exchange of 2527 CONNECTION_CLOSE frames until the closing period on either peer 2528 ended. 2530 An immediate close can be used after an application protocol has 2531 arranged to close a connection. This might be after the application 2532 protocols negotiates a graceful shutdown. The application protocol 2533 exchanges whatever messages that are needed to cause both endpoints 2534 to agree to close the connection, after which the application 2535 requests that the connection be closed. The application protocol can 2536 use an CONNECTION_CLOSE frame with an appropriate error code to 2537 signal closure. 2539 If the connection has been successfully established, endpoints MUST 2540 send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to 2541 connection establishment a peer might not have 1-RTT keys, so 2542 endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. 2543 If the endpoint does not have Handshake keys, or it is not certain 2544 that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames 2545 in an Initial packet. If multiple packets are sent, they can be 2546 coalesced (see Section 12.2) to facilitate retransmission. 2548 10.4. Stateless Reset 2550 A stateless reset is provided as an option of last resort for an 2551 endpoint that does not have access to the state of a connection. A 2552 crash or outage might result in peers continuing to send data to an 2553 endpoint that is unable to properly continue the connection. A 2554 stateless reset is not appropriate for signaling error conditions. 2555 An endpoint that wishes to communicate a fatal connection error MUST 2556 use a CONNECTION_CLOSE frame if it has sufficient state to do so. 2558 To support this process, a token is sent by endpoints. The token is 2559 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2560 servers can specify the stateless_reset_token transport parameter 2561 during the handshake (clients cannot because their transport 2562 parameters don't have confidentiality protection). This value is 2563 protected by encryption, so only client and server know this value. 2564 Tokens are invalidated when their associated connection ID is retired 2565 via a RETIRE_CONNECTION_ID frame (Section 19.16). 2567 An endpoint that receives packets that it cannot process sends a 2568 packet in the following layout: 2570 0 1 2 3 2571 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 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 |0|1| Random Bits (182..) ... 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | | 2576 + + 2577 | | 2578 + Stateless Reset Token (128) + 2579 | | 2580 + + 2581 | | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 Figure 7: Stateless Reset Packet 2586 This design ensures that a stateless reset packet is - to the extent 2587 possible - indistinguishable from a regular packet with a short 2588 header. 2590 A stateless reset uses an entire UDP datagram, starting with the 2591 first two bits of the packet header. The remainder of the first byte 2592 and an arbitrary number of random bytes following it are set to 2593 unpredictable values. The last 16 bytes of the datagram contain a 2594 Stateless Reset Token. 2596 A stateless reset will be interpreted by a recipient as a packet with 2597 a short header. For the packet to appear as valid, the Random Bits 2598 field needs to include at least 182 bits of random or unpredictable 2599 values (or 24 bytes, less the two fixed bits). This is intended to 2600 allow for a destination connection ID of the maximum length 2601 permitted, with a minimal packet number, and payload. The Stateless 2602 Reset Token corresponds to the minimum expansion of the packet 2603 protection AEAD. More random bytes might be necessary if the 2604 endpoint could have negotiated a packet protection scheme with a 2605 larger minimum AEAD expansion. 2607 An endpoint SHOULD NOT send a stateless reset that is significantly 2608 larger than the packet it receives. Endpoints MUST discard packets 2609 that are too small to be valid QUIC packets. With the set of AEAD 2610 functions defined in [QUIC-TLS], packets that are smaller than 21 2611 bytes are never valid. 2613 An endpoint MAY send a stateless reset in response to a packet with a 2614 long header. This would not be effective if the stateless reset 2615 token was not yet available to a peer. In this QUIC version, packets 2616 with a long header are only used during connection establishment. 2617 Because the stateless reset token is not available until connection 2618 establishment is complete or near completion, ignoring an unknown 2619 packet with a long header might be more effective. 2621 An endpoint cannot determine the Source Connection ID from a packet 2622 with a short header, therefore it cannot set the Destination 2623 Connection ID in the stateless reset packet. The Destination 2624 Connection ID will therefore differ from the value used in previous 2625 packets. A random Destination Connection ID makes the connection ID 2626 appear to be the result of moving to a new connection ID that was 2627 provided using a NEW_CONNECTION_ID frame (Section 19.15). 2629 Using a randomized connection ID results in two problems: 2631 o The packet might not reach the peer. If the Destination 2632 Connection ID is critical for routing toward the peer, then this 2633 packet could be incorrectly routed. This might also trigger 2634 another Stateless Reset in response, see Section 10.4.3. A 2635 Stateless Reset that is not correctly routed is an ineffective 2636 error detection and recovery mechanism. In this case, endpoints 2637 will need to rely on other methods - such as timers - to detect 2638 that the connection has failed. 2640 o The randomly generated connection ID can be used by entities other 2641 than the peer to identify this as a potential stateless reset. An 2642 endpoint that occasionally uses different connection IDs might 2643 introduce some uncertainty about this. 2645 Finally, the last 16 bytes of the packet are set to the value of the 2646 Stateless Reset Token. 2648 This stateless reset design is specific to QUIC version 1. An 2649 endpoint that supports multiple versions of QUIC needs to generate a 2650 stateless reset that will be accepted by peers that support any 2651 version that the endpoint might support (or might have supported 2652 prior to losing state). Designers of new versions of QUIC need to be 2653 aware of this and either reuse this design, or use a portion of the 2654 packet other than the last 16 bytes for carrying data. 2656 10.4.1. Detecting a Stateless Reset 2658 An endpoint detects a potential stateless reset when a packet with a 2659 short header either cannot be decrypted or is marked as a duplicate 2660 packet. The endpoint then compares the last 16 bytes of the packet 2661 with the Stateless Reset Token provided by its peer, either in a 2662 NEW_CONNECTION_ID frame or the server's transport parameters. If 2663 these values are identical, the endpoint MUST enter the draining 2664 period and not send any further packets on this connection. If the 2665 comparison fails, the packet can be discarded. 2667 10.4.2. Calculating a Stateless Reset Token 2669 The stateless reset token MUST be difficult to guess. In order to 2670 create a Stateless Reset Token, an endpoint could randomly generate 2671 [RFC4086] a secret for every connection that it creates. However, 2672 this presents a coordination problem when there are multiple 2673 instances in a cluster or a storage problem for an endpoint that 2674 might lose state. Stateless reset specifically exists to handle the 2675 case where state is lost, so this approach is suboptimal. 2677 A single static key can be used across all connections to the same 2678 endpoint by generating the proof using a second iteration of a 2679 preimage-resistant function that takes a static key and the 2680 connection ID chosen by the endpoint (see Section 5.1) as input. An 2681 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2682 connection_id)) or HKDF [RFC5869] (for example, using the static key 2683 as input keying material, with the connection ID as salt). The 2684 output of this function is truncated to 16 bytes to produce the 2685 Stateless Reset Token for that connection. 2687 An endpoint that loses state can use the same method to generate a 2688 valid Stateless Reset Token. The connection ID comes from the packet 2689 that the endpoint receives. 2691 This design relies on the peer always sending a connection ID in its 2692 packets so that the endpoint can use the connection ID from a packet 2693 to reset the connection. An endpoint that uses this design MUST 2694 either use the same connection ID length for all connections or 2695 encode the length of the connection ID such that it can be recovered 2696 without state. In addition, it cannot provide a zero-length 2697 connection ID. 2699 Revealing the Stateless Reset Token allows any entity to terminate 2700 the connection, so a value can only be used once. This method for 2701 choosing the Stateless Reset Token means that the combination of 2702 connection ID and static key cannot occur for another connection. A 2703 denial of service attack is possible if the same connection ID is 2704 used by instances that share a static key, or if an attacker can 2705 cause a packet to be routed to an instance that has no state but the 2706 same static key (see Section 21.8). A connection ID from a 2707 connection that is reset by revealing the Stateless Reset Token 2708 cannot be reused for new connections at nodes that share a static 2709 key. 2711 Note that Stateless Reset packets do not have any cryptographic 2712 protection. 2714 10.4.3. Looping 2716 The design of a Stateless Reset is such that it is indistinguishable 2717 from a valid packet. This means that a Stateless Reset might trigger 2718 the sending of a Stateless Reset in response, which could lead to 2719 infinite exchanges. 2721 An endpoint MUST ensure that every Stateless Reset that it sends is 2722 smaller than the packet which triggered it, unless it maintains state 2723 sufficient to prevent looping. In the event of a loop, this results 2724 in packets eventually being too small to trigger a response. 2726 An endpoint can remember the number of Stateless Reset packets that 2727 it has sent and stop generating new Stateless Reset packets once a 2728 limit is reached. Using separate limits for different remote 2729 addresses will ensure that Stateless Reset packets can be used to 2730 close connections when other peers or connections have exhausted 2731 limits. 2733 Reducing the size of a Stateless Reset below the recommended minimum 2734 size of 37 bytes could mean that the packet could reveal to an 2735 observer that it is a Stateless Reset. Conversely, refusing to send 2736 a Stateless Reset in response to a small packet might result in 2737 Stateless Reset not being useful in detecting cases of broken 2738 connections where only very small packets are sent; such failures 2739 might only be detected by other means, such as timers. 2741 An endpoint can increase the odds that a packet will trigger a 2742 Stateless Reset if it cannot be processed by padding it to at least 2743 38 bytes. 2745 11. Error Handling 2747 An endpoint that detects an error SHOULD signal the existence of that 2748 error to its peer. Both transport-level and application-level errors 2749 can affect an entire connection (see Section 11.1), while only 2750 application-level errors can be isolated to a single stream (see 2751 Section 11.2). 2753 The most appropriate error code (Section 20) SHOULD be included in 2754 the frame that signals the error. Where this specification 2755 identifies error conditions, it also identifies the error code that 2756 is used. 2758 A stateless reset (Section 10.4) is not suitable for any error that 2759 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 2760 stateless reset MUST NOT be used by an endpoint that has the state 2761 necessary to send a frame on the connection. 2763 11.1. Connection Errors 2765 Errors that result in the connection being unusable, such as an 2766 obvious violation of protocol semantics or corruption of state that 2767 affects an entire connection, MUST be signaled using a 2768 CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the 2769 connection in this manner even if the error only affects a single 2770 stream. 2772 Application protocols can signal application-specific protocol errors 2773 using the application-specific variant of the CONNECTION_CLOSE frame. 2774 Errors that are specific to the transport, including all those 2775 described in this document, are carried the QUIC-specific variant of 2776 the CONNECTION_CLOSE frame. 2778 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 2779 endpoint SHOULD be prepared to retransmit a packet containing 2780 containing a CONNECTION_CLOSE frame if it receives more packets on a 2781 terminated connection. Limiting the number of retransmissions and 2782 the time over which this final packet is sent limits the effort 2783 expended on terminated connections. 2785 An endpoint that chooses not to retransmit packets containing a 2786 CONNECTION_CLOSE frame risks a peer missing the first such packet. 2787 The only mechanism available to an endpoint that continues to receive 2788 data for a terminated connection is to use the stateless reset 2789 process (Section 10.4). 2791 An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT 2792 signal the existence of the error to its peer. 2794 11.2. Stream Errors 2796 If an application-level error affects a single stream, but otherwise 2797 leaves the connection in a recoverable state, the endpoint can send a 2798 RESET_STREAM frame (Section 19.4) with an appropriate error code to 2799 terminate just the affected stream. 2801 RESET_STREAM MUST be instigated by the protocol using QUIC, either 2802 directly or through the receipt of a STOP_SENDING frame from a peer. 2803 RESET_STREAM carries an application error code. Resetting a stream 2804 without knowledge of the application protocol could cause the 2805 protocol to enter an unrecoverable state. Application protocols 2806 might require certain streams to be reliably delivered in order to 2807 guarantee consistent state between endpoints. 2809 12. Packets and Frames 2811 QUIC endpoints communicate by exchanging packets. Packets are 2812 carried in UDP datagrams (see Section 12.2) and have confidentiality 2813 and integrity protection (see Section 12.1). 2815 This version of QUIC uses the long packet header (see Section 17.2) 2816 during connection establishment and the short header (see 2817 Section 17.3) once 1-RTT keys have been established. 2819 Packets that carry the long header are Initial Section 17.5, Retry 2820 Section 17.7, Handshake Section 17.6, and 0-RTT Protected packets 2821 Section 12.1. 2823 Packets with the short header are designed for minimal overhead and 2824 are used after a connection is established. 2826 Version negotiation uses a packet with a special format (see 2827 Section 17.4). 2829 12.1. Protected Packets 2831 All QUIC packets except Version Negotiation and Retry packets use 2832 authenticated encryption with additional data (AEAD) [RFC5119] to 2833 provide confidentiality and integrity protection. Details of packet 2834 protection are found in [QUIC-TLS]; this section includes an overview 2835 of the process. 2837 Initial packets are protected using keys that are statically derived. 2838 This packet protection is not effective confidentiality protection, 2839 it only exists to ensure that the sender of the packet is on the 2840 network path. Any entity that receives the Initial packet from a 2841 client can recover the keys necessary to remove packet protection or 2842 to generate packets that will be successfully authenticated. 2844 All other packets are protected with keys derived from the 2845 cryptographic handshake. The type of the packet from the long header 2846 or key phase from the short header are used to identify which 2847 encryption level - and therefore the keys - that are used. Packets 2848 protected with 0-RTT and 1-RTT keys are expected to have 2849 confidentiality and data origin authentication; the cryptographic 2850 handshake ensures that only the communicating endpoints receive the 2851 corresponding keys. 2853 The packet number field contains a packet number, which has 2854 additional confidentiality protection that is applied after packet 2855 protection is applied (see [QUIC-TLS] for details). The underlying 2856 packet number increases with each packet sent, see Section 12.3 for 2857 details. 2859 12.2. Coalescing Packets 2861 A sender can coalesce multiple QUIC packets into one UDP datagram. 2862 This can reduce the number of UDP datagrams needed to complete the 2863 cryptographic handshake and starting sending data. Receivers MUST be 2864 able to process coalesced packets. 2866 Coalescing packets in order of increasing encryption levels (Initial, 2867 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 2868 able to process all the packets in a single pass. A packet with a 2869 short header does not include a length, so it will always be the last 2870 packet included in a UDP datagram. 2872 Senders MUST NOT coalesce QUIC packets for different connections into 2873 a single UDP datagram. Receivers SHOULD ignore any subsequent 2874 packets with a different Destination Connection ID than the first 2875 packet in the datagram. 2877 Every QUIC packet that is coalesced into a single UDP datagram is 2878 separate and complete. Though the values of some fields in the 2879 packet header might be redundant, no fields are omitted. The 2880 receiver of coalesced QUIC packets MUST individually process each 2881 QUIC packet and separately acknowledge them, as if they were received 2882 as the payload of different UDP datagrams. For example, if 2883 decryption fails (because the keys are not available or any other 2884 reason) or the packet is of an unknown type, the receiver MAY either 2885 discard or buffer the packet for later processing and MUST attempt to 2886 process the remaining packets. 2888 Retry packets (Section 17.7), Version Negotiation packets 2889 (Section 17.4), and packets with a short header cannot be followed by 2890 other packets in the same UDP datagram. 2892 12.3. Packet Numbers 2894 The packet number is an integer in the range 0 to 2^62-1. Where 2895 present, packet numbers are encoded as a variable-length integer (see 2896 Section 16). This number is used in determining the cryptographic 2897 nonce for packet protection. Each endpoint maintains a separate 2898 packet number for sending and receiving. 2900 Version Negotiation (Section 17.4) and Retry Section 17.7 packets do 2901 not include a packet number. 2903 Packet numbers are divided into 3 spaces in QUIC: 2905 o Initial space: All Initial packets Section 17.5 are in this space. 2907 o Handshake space: All Handshake packets Section 17.6 are in this 2908 space. 2910 o Application data space: All 0-RTT and 1-RTT encrypted packets 2911 Section 12.1 are in this space. 2913 As described in [QUIC-TLS], each packet type uses different 2914 protection keys. 2916 Conceptually, a packet number space is the context in which a packet 2917 can be processed and acknowledged. Initial packets can only be sent 2918 with Initial packet protection keys and acknowledged in packets which 2919 are also Initial packets. Similarly, Handshake packets are sent at 2920 the Handshake encryption level and can only be acknowledged in 2921 Handshake packets. 2923 This enforces cryptographic separation between the data sent in the 2924 different packet sequence number spaces. Each packet number space 2925 starts at packet number 0. Subsequent packets sent in the same 2926 packet number space MUST increase the packet number by at least one. 2928 0-RTT and 1-RTT data exist in the same packet number space to make 2929 loss recovery algorithms easier to implement between the two packet 2930 types. 2932 A QUIC endpoint MUST NOT reuse a packet number within the same packet 2933 number space in one connection (that is, under the same cryptographic 2934 keys). If the packet number for sending reaches 2^62 - 1, the sender 2935 MUST close the connection without sending a CONNECTION_CLOSE frame or 2936 any further packets; an endpoint MAY send a Stateless Reset 2937 (Section 10.4) in response to further packets that it receives. 2939 A receiver MUST discard a newly unprotected packet unless it is 2940 certain that it has not processed another packet with the same packet 2941 number from the same packet number space. Duplicate suppression MUST 2942 happen after removing packet protection for the reasons described in 2943 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 2944 suppression can be found in Section 3.4.3 of [RFC4303]. 2946 Packet number encoding at a sender and decoding at a receiver are 2947 described in Section 17.1. 2949 12.4. Frames and Frame Types 2951 The payload of QUIC packets, after removing packet protection, 2952 commonly consists of a sequence of frames, as shown in Figure 8. 2953 Version Negotiation, Stateless Reset, and Retry packets do not 2954 contain frames. 2956 0 1 2 3 2957 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 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 | Frame 1 (*) ... 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2961 | Frame 2 (*) ... 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 ... 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | Frame N (*) ... 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 Figure 8: QUIC Payload 2970 QUIC payloads MUST contain at least one frame, and MAY contain 2971 multiple frames and multiple frame types. 2973 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 2974 packet boundary. Each frame begins with a Frame Type, indicating its 2975 type, followed by additional type-dependent fields: 2977 0 1 2 3 2978 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 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 | Frame Type (i) ... 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | Type-Dependent Fields (*) ... 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 Figure 9: Generic Frame Layout 2987 The frame types defined in this specification are listed in Table 3. 2988 The Frame Type in STREAM frames is used to carry other frame-specific 2989 flags. For all other frames, the Frame Type field simply identifies 2990 the frame. These frames are explained in more detail in Section 19. 2992 +-------------+----------------------+---------------+ 2993 | Type Value | Frame Type Name | Definition | 2994 +-------------+----------------------+---------------+ 2995 | 0x00 | PADDING | Section 19.1 | 2996 | | | | 2997 | 0x01 | PING | Section 19.2 | 2998 | | | | 2999 | 0x02 - 0x03 | ACK | Section 19.3 | 3000 | | | | 3001 | 0x04 | RESET_STREAM | Section 19.4 | 3002 | | | | 3003 | 0x05 | STOP_SENDING | Section 19.5 | 3004 | | | | 3005 | 0x06 | CRYPTO | Section 19.6 | 3006 | | | | 3007 | 0x07 | NEW_TOKEN | Section 19.7 | 3008 | | | | 3009 | 0x08 - 0x0f | STREAM | Section 19.8 | 3010 | | | | 3011 | 0x10 | MAX_DATA | Section 19.9 | 3012 | | | | 3013 | 0x11 | MAX_STREAM_DATA | Section 19.10 | 3014 | | | | 3015 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | 3016 | | | | 3017 | 0x14 | DATA_BLOCKED | Section 19.12 | 3018 | | | | 3019 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | 3020 | | | | 3021 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | 3022 | | | | 3023 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | 3024 | | | | 3025 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | 3026 | | | | 3027 | 0x1a | PATH_CHALLENGE | Section 19.17 | 3028 | | | | 3029 | 0x1b | PATH_RESPONSE | Section 19.18 | 3030 | | | | 3031 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | 3032 +-------------+----------------------+---------------+ 3034 Table 3: Frame Types 3036 All QUIC frames are idempotent. That is, a valid frame does not 3037 cause undesirable side effects or errors when received more than 3038 once. 3040 The Frame Type field uses a variable length integer encoding (see 3041 Section 16) with one exception. To ensure simple and efficient 3042 implementations of frame parsing, a frame type MUST use the shortest 3043 possible encoding. Though a two-, four- or eight-byte encoding of 3044 the frame types defined in this document is possible, the Frame Type 3045 field for these frames is encoded on a single byte. For instance, 3046 though 0x4007 is a legitimate two-byte encoding for a variable-length 3047 integer with a value of 7, PING frames are always encoded as a single 3048 byte with the value 0x07. An endpoint MAY treat the receipt of a 3049 frame type that uses a longer encoding than necessary as a connection 3050 error of type PROTOCOL_VIOLATION. 3052 13. Packetization and Reliability 3054 A sender bundles one or more frames in a QUIC packet (see 3055 Section 12.4). 3057 A sender can minimize per-packet bandwidth and computational costs by 3058 bundling as many frames as possible within a QUIC packet. A sender 3059 MAY wait for a short period of time to bundle multiple frames before 3060 sending a packet that is not maximally packed, to avoid sending out 3061 large numbers of small packets. An implementation may use knowledge 3062 about application sending behavior or heuristics to determine whether 3063 and for how long to wait. This waiting period is an implementation 3064 decision, and an implementation should be careful to delay 3065 conservatively, since any delay is likely to increase application- 3066 visible latency. 3068 Stream multiplexing is achieved by interleaving STREAM frames from 3069 multiple streams into one or more QUIC packets. A single QUIC packet 3070 can include multiple STREAM frames from one or more streams. 3072 One of the benefits of QUIC is avoidance of head-of-line blocking 3073 across multiple streams. When a packet loss occurs, only streams 3074 with data in that packet are blocked waiting for a retransmission to 3075 be received, while other streams can continue making progress. Note 3076 that when data from multiple streams is bundled into a single QUIC 3077 packet, loss of that packet blocks all those streams from making 3078 progress. Implementations are advised to bundle as few streams as 3079 necessary in outgoing packets without losing transmission efficiency 3080 to underfilled packets. 3082 13.1. Packet Processing and Acknowledgment 3084 A packet MUST NOT be acknowledged until packet protection has been 3085 successfully removed and all frames contained in the packet have been 3086 processed. For STREAM frames, this means the data has been enqueued 3087 in preparation to be received by the application protocol, but it 3088 does not require that data is delivered and consumed. 3090 Once the packet has been fully processed, a receiver acknowledges 3091 receipt by sending one or more ACK frames containing the packet 3092 number of the received packet. 3094 13.1.1. Sending ACK Frames 3096 To avoid creating an indefinite feedback loop, an endpoint MUST NOT 3097 send an ACK frame in response to a packet containing only ACK or 3098 PADDING frames, even if there are packet gaps which precede the 3099 received packet. The endpoint MUST however acknowledge packets 3100 containing only ACK or PADDING frames when sending ACK frames in 3101 response to other packets. 3103 Packets containing PADDING frames are considered to be in flight for 3104 congestion control purposes [QUIC-RECOVERY]. Sending only PADDING 3105 frames might cause the sender to become limited by the congestion 3106 controller (as described in [QUIC-RECOVERY]) with no acknowledgments 3107 forthcoming from the receiver. Therefore, a sender should ensure 3108 that other frames are sent in addition to PADDING frames to elicit 3109 acknowledgments from the receiver. 3111 An endpoint MUST NOT send more than one packet containing only an ACK 3112 frame per received packet that contains frames other than ACK and 3113 PADDING frames. 3115 The receiver's delayed acknowledgment timer SHOULD NOT exceed the 3116 current RTT estimate or the value it indicates in the "max_ack_delay" 3117 transport parameter. This ensures an acknowledgment is sent at least 3118 once per RTT when packets needing acknowledgement are received. The 3119 sender can use the receiver's "max_ack_delay" value in determining 3120 timeouts for timer-based retransmission. 3122 Strategies and implications of the frequency of generating 3123 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 3125 To limit ACK Blocks to those that have not yet been received by the 3126 sender, the receiver SHOULD track which ACK frames have been 3127 acknowledged by its peer. Once an ACK frame has been acknowledged, 3128 the packets it acknowledges SHOULD NOT be acknowledged again. 3130 Because ACK frames are not sent in response to ACK-only packets, a 3131 receiver that is only sending ACK frames will only receive 3132 acknowledgements for its packets if the sender includes them in 3133 packets with non-ACK frames. A sender SHOULD bundle ACK frames with 3134 other frames when possible. 3136 To limit receiver state or the size of ACK frames, a receiver MAY 3137 limit the number of ACK Blocks it sends. A receiver can do this even 3138 without receiving acknowledgment of its ACK frames, with the 3139 knowledge this could cause the sender to unnecessarily retransmit 3140 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 3141 lost after sufficiently newer packets are acknowledged. Therefore, 3142 the receiver SHOULD repeatedly acknowledge newly received packets in 3143 preference to packets received in the past. 3145 13.1.2. ACK Frames and Packet Protection 3147 ACK frames MUST only be carried in a packet that has the same packet 3148 number space as the packet being ACKed (see Section 12.1). For 3149 instance, packets that are protected with 1-RTT keys MUST be 3150 acknowledged in packets that are also protected with 1-RTT keys. 3152 Packets that a client sends with 0-RTT packet protection MUST be 3153 acknowledged by the server in packets protected by 1-RTT keys. This 3154 can mean that the client is unable to use these acknowledgments if 3155 the server cryptographic handshake messages are delayed or lost. 3156 Note that the same limitation applies to other data sent by the 3157 server protected by the 1-RTT keys. 3159 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3160 frames with a reduced delay; see Section 5.3.1 of [QUIC-RECOVERY]. 3162 13.2. Retransmission of Information 3164 QUIC packets that are determined to be lost are not retransmitted 3165 whole. The same applies to the frames that are contained within lost 3166 packets. Instead, the information that might be carried in frames is 3167 sent again in new frames as needed. 3169 New frames and packets are used to carry information that is 3170 determined to have been lost. In general, information is sent again 3171 when a packet containing that information is determined to be lost 3172 and sending ceases when a packet containing that information is 3173 acknowledged. 3175 o Data sent in CRYPTO frames is retransmitted according to the rules 3176 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 3177 CRYPTO frames for Initial and Handshake packets is discarded when 3178 keys for the corresponding encryption level are discarded. 3180 o Application data sent in STREAM frames is retransmitted in new 3181 STREAM frames unless the endpoint has sent a RESET_STREAM for that 3182 stream. Once an endpoint sends a RESET_STREAM frame, no further 3183 STREAM frames are needed. 3185 o The most recent set of acknowledgments are sent in ACK frames. An 3186 ACK frame SHOULD contain all unacknowledged acknowledgments, as 3187 described in Section 13.1.1. 3189 o Cancellation of stream transmission, as carried in a RESET_STREAM 3190 frame, is sent until acknowledged or until all stream data is 3191 acknowledged by the peer (that is, either the "Reset Recvd" or 3192 "Data Recvd" state is reached on the send stream). The content of 3193 a RESET_STREAM frame MUST NOT change when it is sent again. 3195 o Similarly, a request to cancel stream transmission, as encoded in 3196 a STOP_SENDING frame, is sent until the receive stream enters 3197 either a "Data Recvd" or "Reset Recvd" state, see Section 3.5. 3199 o Connection close signals, including packets that contain 3200 CONNECTION_CLOSE frames, are not sent again when packet loss is 3201 detected, but as described in Section 10. 3203 o The current connection maximum data is sent in MAX_DATA frames. 3204 An updated value is sent in a MAX_DATA frame if the packet 3205 containing the most recently sent MAX_DATA frame is declared lost, 3206 or when the endpoint decides to update the limit. Care is 3207 necessary to avoid sending this frame too often as the limit can 3208 increase frequently and cause an unnecessarily large number of 3209 MAX_DATA frames to be sent. 3211 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3212 frames. Like MAX_DATA, an updated value is sent when the packet 3213 containing the most recent MAX_STREAM_DATA frame for a stream is 3214 lost or when the limit is updated, with care taken to prevent the 3215 frame from being sent too often. An endpoint SHOULD stop sending 3216 MAX_STREAM_DATA frames when the receive stream enters a "Size 3217 Known" state. 3219 o The limit on streams of a given type is sent in MAX_STREAMS 3220 frames. Like MAX_DATA, an updated value is sent when a packet 3221 containing the most recent MAX_STREAMS for a stream type frame is 3222 declared lost or when the limit is updated, with care taken to 3223 prevent the frame from being sent too often. 3225 o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 3226 and STREAMS_BLOCKED frames. DATA_BLOCKED streams have connection 3227 scope, STREAM_DATA_BLOCKED frames have stream scope, and 3228 STREAMS_BLOCKED frames are scoped to a specific stream type. New 3229 frames are sent if packets containing the most recent frame for a 3230 scope is lost, but only while the endpoint is blocked on the 3231 corresponding limit. These frames always include the limit that 3232 is causing blocking at the time that they are transmitted. 3234 o A liveness or path validation check using PATH_CHALLENGE frames is 3235 sent periodically until a matching PATH_RESPONSE frame is received 3236 or until there is no remaining need for liveness or path 3237 validation checking. PATH_CHALLENGE frames include a different 3238 payload each time they are sent. 3240 o Responses to path validation using PATH_RESPONSE frames are sent 3241 just once. A new PATH_CHALLENGE frame will be sent if another 3242 PATH_RESPONSE frame is needed. 3244 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3245 retransmitted if the packet containing them is lost. 3246 Retransmissions of this frame carry the same sequence number 3247 value. Likewise, retired connection IDs are sent in 3248 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3249 containing them is lost. 3251 o PING and PADDING frames contain no information, so lost PING or 3252 PADDING frames do not require repair. 3254 Endpoints SHOULD prioritize retransmission of data over sending new 3255 data, unless priorities specified by the application indicate 3256 otherwise (see Section 2.3). 3258 Upon detecting losses, a sender MUST take appropriate congestion 3259 control action. The details of loss detection and congestion control 3260 are described in [QUIC-RECOVERY]. 3262 13.3. Explicit Congestion Notification 3264 QUIC endpoints can use Explicit Congestion Notification (ECN) 3265 [RFC3168] to detect and respond to network congestion. ECN allows a 3266 network node to indicate congestion in the network by setting a 3267 codepoint in the IP header of a packet instead of dropping it. 3268 Endpoints react to congestion by reducing their sending rate in 3269 response, as described in [QUIC-RECOVERY]. 3271 To use ECN, QUIC endpoints first determine whether a path supports 3272 ECN marking and the peer is able to access the ECN codepoint in the 3273 IP header. A network path does not support ECN if ECN marked packets 3274 get dropped or ECN markings are rewritten on the path. An endpoint 3275 verifies the path, both during connection establishment and when 3276 migrating to a new path (see Section 9). 3278 13.3.1. ECN Counts 3280 On receiving a QUIC packet with an ECT or CE codepoint, an ECN- 3281 enabled endpoint that can access the ECN codepoints from the 3282 enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE 3283 count, and includes these counts in subsequent ACK frames (see 3284 Section 13.1 and Section 19.3). Note that this requires being able 3285 to read the ECN codepoints from the enclosing IP packet, which is not 3286 possible on all platforms. 3288 A packet detected by a receiver as a duplicate does not affect the 3289 receiver's local ECN codepoint counts; see (Section 21.7) for 3290 relevant security concerns. 3292 If an endpoint receives a QUIC packet without an ECT or CE codepoint 3293 in the IP packet header, it responds per Section 13.1 with an ACK 3294 frame without increasing any ECN counts. if an endpoint does not 3295 implement ECN support or does not have access to received ECN 3296 codepoints, it does not increase ECN counts. 3298 Coalesced packets (see Section 12.2) mean that several packets can 3299 share the same IP header. The ECN counter for the ECN codepoint 3300 received in the associated IP header are incremented once for each 3301 QUIC packet, not per enclosing IP packet or UDP datagram. 3303 Each packet number space maintains separate acknowledgement state and 3304 separate ECN counts. For example, if one each of an Initial, 0-RTT, 3305 Handshake, and 1-RTT QUIC packet are coalesced, the corresponding 3306 counts for the Initial and Handshake packet number space will be 3307 incremented by one and the counts for the 1-RTT packet number space 3308 will be increased by two. 3310 13.3.2. ECN Verification 3312 Each endpoint independently verifies and enables use of ECN by 3313 setting the IP header ECN codepoint to ECN Capable Transport (ECT) 3314 for the path from it to the other peer. Even if not setting ECN 3315 codepoints on packets it transmits, the endpoint SHOULD provide 3316 feedback about ECN markings received (if accessible). 3318 To verify both that a path supports ECN and the peer can provide ECN 3319 feedback, an endpoint sets the ECT(0) codepoint in the IP header of 3320 all outgoing packets [RFC8311]. 3322 If an ECT codepoint set in the IP header is not corrupted by a 3323 network device, then a received packet contains either the codepoint 3324 sent by the peer or the Congestion Experienced (CE) codepoint set by 3325 a network device that is experiencing congestion. 3327 If a QUIC packet sent with an ECT codepoint is newly acknowledged by 3328 the peer in an ACK frame without ECN feedback, the endpoint stops 3329 setting ECT codepoints in subsequent IP packets, with the expectation 3330 that either the network path or the peer no longer supports ECN. 3332 Network devices that corrupt or apply non-standard ECN markings might 3333 result in reduced throughput or other undesirable side-effects. To 3334 reduce this risk, an endpoint uses the following steps to verify the 3335 counts it receives in an ACK frame. Counts MUST NOT be verified if 3336 the ACK frame does not increase the largest received packet number at 3337 the endpoint. 3339 o The total increase in ECT(0), ECT(1), and CE counts MUST be no 3340 smaller than the total number of QUIC packets sent with an ECT 3341 codepoint that are newly acknowledged in this ACK frame. This 3342 step detects any network remarking from ECT(0), ECT(1), or CE 3343 codepoints to Not-ECT. 3345 o Any increase in either ECT(0) or ECT(1) counts, plus any increase 3346 in the CE count, MUST be no smaller than the number of packets 3347 sent with the corresponding ECT codepoint that are newly 3348 acknowledged in this ACK frame. This step detects any erroneous 3349 network remarking from ECT(0) to ECT(1) (or vice versa). 3351 An endpoint could miss acknowledgements for a packet when ACK frames 3352 are lost. It is therefore possible for the total increase in ECT(0), 3353 ECT(1), and CE counts to be greater than the number of packets 3354 acknowledged in an ACK frame. When this happens, and if verification 3355 succeeds, the local reference counts MUST be increased to match the 3356 counts in the ACK frame. 3358 Upon successful verification, an endpoint continues to set ECT 3359 codepoints in subsequent packets with the expectation that the path 3360 is ECN-capable. 3362 If verification fails, then the endpoint ceases setting ECT 3363 codepoints in subsequent IP packets with the expectation that either 3364 the network path or the peer does not support ECN. 3366 If an endpoint sets ECT codepoints on outgoing IP packets and 3367 encounters a retransmission timeout due to the absence of 3368 acknowledgments from the peer (see [QUIC-RECOVERY]), or if an 3369 endpoint has reason to believe that an element on the network path 3370 might be corrupting ECN codepoints, the endpoint MAY cease setting 3371 ECT codepoints in subsequent packets. Doing so allows the connection 3372 to be resilient to network elements that corrupt ECN codepoints in 3373 the IP header or drop packets with ECT or CE codepoints in the IP 3374 header. 3376 14. Packet Size 3378 The QUIC packet size includes the QUIC header and protected payload, 3379 but not the UDP or IP header. 3381 Clients MUST ensure they send the first Initial packet in single IP 3382 packet. Similarly, the first Initial packet sent after receiving a 3383 Retry packet MUST be sent in a single IP packet. 3385 The payload of a UDP datagram carrying the first Initial packet MUST 3386 be expanded to at least 1200 bytes, by adding PADDING frames to the 3387 Initial packet and/or by combining the Initial packet with a 0-RTT 3388 packet (see Section 12.2). Sending a UDP datagram of this size 3389 ensures that the network path supports a reasonable Maximum 3390 Transmission Unit (MTU), and helps reduce the amplitude of 3391 amplification attacks caused by server responses toward an unverified 3392 client address, see Section 8. 3394 The datagram containing the first Initial packet from a client MAY 3395 exceed 1200 bytes if the client believes that the Path Maximum 3396 Transmission Unit (PMTU) supports the size that it chooses. 3398 A server MAY send a CONNECTION_CLOSE frame with error code 3399 PROTOCOL_VIOLATION in response to the first Initial packet it 3400 receives from a client if the UDP datagram is smaller than 1200 3401 bytes. It MUST NOT send any other frame type in response, or 3402 otherwise behave as if any part of the offending packet was processed 3403 as valid. 3405 The server MUST also limit the number of bytes it sends before 3406 validating the address of the client, see Section 8. 3408 14.1. Path Maximum Transmission Unit (PMTU) 3410 The PMTU is the maximum size of the entire IP packet including the IP 3411 header, UDP header, and UDP payload. The UDP payload includes the 3412 QUIC packet header, protected payload, and any authentication fields. 3413 The PMTU can depend upon the current path characteristics. 3414 Therefore, the current largest UDP payload an implementation will 3415 send is referred to as the QUIC maximum packet size. 3417 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 3418 minimum size [RFC8200] and is also supported by most modern IPv4 3419 networks. All QUIC packets (except for PMTU probe packets) SHOULD be 3420 sized to fit within the maximum packet size to avoid the packet being 3421 fragmented or dropped [RFC8085]. 3423 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery 3424 ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] 3425 [RFC8201] to determine whether the path to a destination will support 3426 a desired message size without fragmentation. 3428 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3429 packets larger than 1280 bytes. Assuming the minimum IP header size, 3430 this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 3431 1252 bytes for IPv4. A QUIC implementation MAY be more conservative 3432 in computing the QUIC maximum packet size to allow for unknown tunnel 3433 overheads or IP header options/extensions. 3435 Each pair of local and remote addresses could have a different PMTU. 3436 QUIC implementations that implement any kind of PMTU discovery 3437 therefore SHOULD maintain a maximum packet size for each combination 3438 of local and remote IP addresses. 3440 If a QUIC endpoint determines that the PMTU between any pair of local 3441 and remote IP addresses has fallen below the size needed to support 3442 the smallest allowed maximum packet size, it MUST immediately cease 3443 sending QUIC packets, except for PMTU probe packets, on the affected 3444 path. An endpoint MAY terminate the connection if an alternative 3445 path cannot be found. 3447 14.2. ICMP Packet Too Big Messages 3449 PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP 3450 messages (e.g., IPv6 Packet Too Big messages) that indicate when a 3451 packet is dropped because it is larger than the local router MTU. 3452 DPLPMTUD can also optionally use these messages. This use of ICMP 3453 messages is potentially vulnerable to off-path attacks that 3454 successfully guess the addresses used on the path and reduce the PMTU 3455 to a bandwidth-inefficient value. 3457 An endpoint MUST ignore an ICMP message that claims the PMTU has 3458 decreased below 1280 bytes. 3460 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 3461 that the quoted packet should contain as much of the original packet 3462 as possible without exceeding the minimum MTU for the IP version. 3463 The size of the quoted packet can actually be smaller, or the 3464 information unintelligible, as described in Section 1.1 of 3465 [DPLPMTUD]. 3467 QUIC endpoints SHOULD validate ICMP messages to protect from off-path 3468 injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. 3469 This validation SHOULD use the quoted packet supplied in the payload 3470 of an ICMP message to associate the message with a corresponding 3471 transport connection [DPLPMTUD]. 3473 ICMP message validation MUST include matching IP addresses and UDP 3474 ports [RFC8085] and, when possible, connection IDs to an active QUIC 3475 session. 3477 Further validation can also be provided: 3479 o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small 3480 proportion of packets, so that most invalid ICMP messages arrive 3481 when there are no DF packets outstanding, and can therefore be 3482 identified as spurious. 3484 o An endpoint could store additional information from the IP or UDP 3485 headers to use for validation (for example, the IP ID or UDP 3486 checksum). 3488 The endpoint SHOULD ignore all ICMP messages that fail validation. 3490 An endpoint MUST NOT increase PMTU based on ICMP messages. Any 3491 reduction in the QUIC maximum packet size MAY be provisional until 3492 QUIC's loss detection algorithm determines that the quoted packet has 3493 actually been lost. 3495 14.3. Datagram Packetization Layer PMTU Discovery 3497 Section 6.4 of [DPLPMTUD] provides considerations for implementing 3498 Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. 3500 When implementing the algorithm in Section 5.3 of [DPLPMTUD], the 3501 initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC 3502 packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). 3504 PING and PADDING frames can be used to generate PMTU probe packets. 3505 These frames might not be retransmitted if a probe packet containing 3506 them is lost. However, these frames do consume congestion window, 3507 which could delay the transmission of subsequent application data. 3509 A PING frame can be included in a PMTU probe to ensure that a valid 3510 probe is acknowledged. 3512 The considerations for processing ICMP messages in the previous 3513 section also apply if these messages are used by DPLPMTUD. 3515 15. Versions 3517 QUIC versions are identified using a 32-bit unsigned number. 3519 The version 0x00000000 is reserved to represent version negotiation. 3520 This version of the specification is identified by the number 3521 0x00000001. 3523 Other versions of QUIC might have different properties to this 3524 version. The properties of QUIC that are guaranteed to be consistent 3525 across all versions of the protocol are described in 3526 [QUIC-INVARIANTS]. 3528 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 3529 protocol, as described in [QUIC-TLS]. 3531 Versions with the most significant 16 bits of the version number 3532 cleared are reserved for use in future IETF consensus documents. 3534 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 3535 forcing version negotiation to be exercised. That is, any version 3536 number where the low four bits of all bytes is 1010 (in binary). A 3537 client or server MAY advertise support for any of these reserved 3538 versions. 3540 Reserved version numbers will probably never represent a real 3541 protocol; a client MAY use one of these version numbers with the 3542 expectation that the server will initiate version negotiation; a 3543 server MAY advertise support for one of these versions and can expect 3544 that clients ignore the value. 3546 [[RFC editor: please remove the remainder of this section before 3547 publication.]] 3549 The version number for the final version of this specification 3550 (0x00000001), is reserved for the version of the protocol that is 3551 published as an RFC. 3553 Version numbers used to identify IETF drafts are created by adding 3554 the draft number to 0xff000000. For example, draft-ietf-quic- 3555 transport-13 would be identified as 0xff00000D. 3557 Implementors are encouraged to register version numbers of QUIC that 3558 they are using for private experimentation on the GitHub wiki at 3559 . 3561 16. Variable-Length Integer Encoding 3563 QUIC packets and frames commonly use a variable-length encoding for 3564 non-negative integer values. This encoding ensures that smaller 3565 integer values need fewer bytes to encode. 3567 The QUIC variable-length integer encoding reserves the two most 3568 significant bits of the first byte to encode the base 2 logarithm of 3569 the integer encoding length in bytes. The integer value is encoded 3570 on the remaining bits, in network byte order. 3572 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 3573 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3574 the encoding properties. 3576 +------+--------+-------------+-----------------------+ 3577 | 2Bit | Length | Usable Bits | Range | 3578 +------+--------+-------------+-----------------------+ 3579 | 00 | 1 | 6 | 0-63 | 3580 | | | | | 3581 | 01 | 2 | 14 | 0-16383 | 3582 | | | | | 3583 | 10 | 4 | 30 | 0-1073741823 | 3584 | | | | | 3585 | 11 | 8 | 62 | 0-4611686018427387903 | 3586 +------+--------+-------------+-----------------------+ 3588 Table 4: Summary of Integer Encodings 3590 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 3591 hexadecimal) decodes to the decimal value 151288809941952652; the 3592 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 3593 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 3594 (as does the two byte sequence 40 25). 3596 Error codes (Section 20) and versions Section 15 are described using 3597 integers, but do not use this encoding. 3599 17. Packet Formats 3601 All numeric values are encoded in network byte order (that is, big- 3602 endian) and all field sizes are in bits. Hexadecimal notation is 3603 used for describing the value of fields. 3605 17.1. Packet Number Encoding and Decoding 3607 Packet numbers in long and short packet headers are encoded in 1 to 4 3608 bytes. The number of bits required to represent the packet number is 3609 reduced by including the least significant bits of the packet number. 3611 The encoded packet number is protected as described in Section 5.4 of 3612 [QUIC-TLS]. 3614 The sender MUST use a packet number size able to represent more than 3615 twice as large a range than the difference between the largest 3616 acknowledged packet and packet number being sent. A peer receiving 3617 the packet will then correctly decode the packet number, unless the 3618 packet is delayed in transit such that it arrives after many higher- 3619 numbered packets have been received. An endpoint SHOULD use a large 3620 enough packet number encoding to allow the packet number to be 3621 recovered even if the packet arrives after packets that are sent 3622 afterwards. 3624 As a result, the size of the packet number encoding is at least one 3625 bit more than the base-2 logarithm of the number of contiguous 3626 unacknowledged packet numbers, including the new packet. 3628 For example, if an endpoint has received an acknowledgment for packet 3629 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 3630 packet number encoding with 16 bits or more; whereas the 24-bit 3631 packet number encoding is needed to send a packet with a number of 3632 0xace8fe. 3634 At a receiver, protection of the packet number is removed prior to 3635 recovering the full packet number. The full packet number is then 3636 reconstructed based on the number of significant bits present, the 3637 value of those bits, and the largest packet number received on a 3638 successfully authenticated packet. Recovering the full packet number 3639 is necessary to successfully remove packet protection. 3641 Once header protection is removed, the packet number is decoded by 3642 finding the packet number value that is closest to the next expected 3643 packet. The next expected packet is the highest received packet 3644 number plus one. For example, if the highest successfully 3645 authenticated packet had a packet number of 0xa82f30ea, then a packet 3646 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 3647 Example pseudo-code for packet number decoding can be found in 3648 Appendix A. 3650 17.2. Long Header Packet 3652 0 1 2 3 3653 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 3654 +-+-+-+-+-+-+-+-+ 3655 |1|1|T T|R R|P P| 3656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3657 | Version (32) | 3658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3659 |DCIL(4)|SCIL(4)| 3660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3661 | Destination Connection ID (0/32..144) ... 3662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3663 | Source Connection ID (0/32..144) ... 3664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3665 | Length (i) ... 3666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3667 | Packet Number (8/16/24/32) ... 3668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3669 | Payload (*) ... 3670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3672 Figure 10: Long Header Packet Format 3674 Long headers are used for packets that are sent prior to the 3675 completion of version negotiation and establishment of 1-RTT keys. 3676 Once both conditions are met, a sender switches to sending packets 3677 using the short header (Section 17.3). The long form allows for 3678 special packets - such as the Version Negotiation packet - to be 3679 represented in this uniform fixed-length packet format. Packets that 3680 use the long header contain the following fields: 3682 Header Form: The most significant bit (0x80) of byte 0 (the first 3683 byte) is set to 1 for long headers. 3685 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 3686 containing a zero value for this bit are not valid packets in this 3687 version and MUST be discarded. 3689 Long Packet Type (T): The next two bits (those with a mask of 0x30) 3690 of byte 0 contain a packet type. Packet types are listed in 3691 Table 5. 3693 Reserved Bits (R): The next two bits (those with a mask of 0x0c) of 3694 byte 0 are reserved. These bits are protected using header 3695 protection (see Section 5.4 of [QUIC-TLS]). The value included 3696 prior to protection MUST be set to 0. An endpoint MUST treat 3697 receipt of a packet that has a non-zero value for these bits after 3698 removing protection as a connection error of type 3699 PROTOCOL_VIOLATION. 3701 Packet Number Length (P): The least significant two bits (those with 3702 a mask of 0x03) of byte 0 contain the length of the packet number, 3703 encoded as an unsigned, two-bit integer that is one less than the 3704 length of the packet number field in bytes. That is, the length 3705 of the packet number field is the value of this field, plus one. 3706 These bits are protected using header protection (see Section 5.4 3707 of [QUIC-TLS]). 3709 Version: The QUIC Version is a 32-bit field that follows the first 3710 byte. This field indicates which version of QUIC is in use and 3711 determines how the rest of the protocol fields are interpreted. 3713 DCIL and SCIL: The byte following the version contains the lengths 3714 of the two connection ID fields that follow it. These lengths are 3715 encoded as two 4-bit unsigned integers. The Destination 3716 Connection ID Length (DCIL) field occupies the 4 high bits of the 3717 byte and the Source Connection ID Length (SCIL) field occupies the 3718 4 low bits of the byte. An encoded length of 0 indicates that the 3719 connection ID is also 0 bytes in length. Non-zero encoded lengths 3720 are increased by 3 to get the full length of the connection ID, 3721 producing a length between 4 and 18 bytes inclusive. For example, 3722 an byte with the value 0x50 describes an 8-byte Destination 3723 Connection ID and a zero-length Source Connection ID. 3725 Destination Connection ID: The Destination Connection ID field 3726 follows the connection ID lengths and is either 0 bytes in length 3727 or between 4 and 18 bytes. Section 7.2 describes the use of this 3728 field in more detail. 3730 Source Connection ID: The Source Connection ID field follows the 3731 Destination Connection ID and is either 0 bytes in length or 3732 between 4 and 18 bytes. Section 7.2 describes the use of this 3733 field in more detail. 3735 Length: The length of the remainder of the packet (that is, the 3736 Packet Number and Payload fields) in bytes, encoded as a variable- 3737 length integer (Section 16). 3739 Packet Number: The packet number field is 1 to 4 bytes long. The 3740 packet number has confidentiality protection separate from packet 3741 protection, as described in Section 5.4 of [QUIC-TLS]. The length 3742 of the packet number field is encoded in the plaintext packet 3743 number. See Section 17.1 for details. 3745 Payload: The payload of the packet. 3747 The following packet types are defined: 3749 +------+-----------------+--------------+ 3750 | Type | Name | Section | 3751 +------+-----------------+--------------+ 3752 | 0x0 | Initial | Section 17.5 | 3753 | | | | 3754 | 0x1 | 0-RTT Protected | Section 12.1 | 3755 | | | | 3756 | 0x2 | Handshake | Section 17.6 | 3757 | | | | 3758 | 0x3 | Retry | Section 17.7 | 3759 +------+-----------------+--------------+ 3761 Table 5: Long Header Packet Types 3763 The header form bit, connection ID lengths byte, Destination and 3764 Source Connection ID fields, and Version fields of a long header 3765 packet are version-independent. The other fields in the first byte, 3766 plus the Length and Packet Number fields are version-specific. See 3767 [QUIC-INVARIANTS] for details on how packets from different versions 3768 of QUIC are interpreted. 3770 The interpretation of the fields and the payload are specific to a 3771 version and packet type. Type-specific semantics for this version 3772 are described in the following sections. 3774 The end of the packet is determined by the Length field. The Length 3775 field covers both the Packet Number and Payload fields, both of which 3776 are confidentiality protected and initially of unknown length. The 3777 length of the Payload field is learned once header protection is 3778 removed. The Length field enables packet coalescing (Section 12.2). 3780 17.3. Short Header Packet 3782 0 1 2 3 3783 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 3784 +-+-+-+-+-+-+-+-+ 3785 |0|1|S|R|R|K|P P| 3786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3787 | Destination Connection ID (0..144) ... 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3789 | Packet Number (8/16/24/32) ... 3790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3791 | Protected Payload (*) ... 3792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3794 Figure 11: Short Header Packet Format 3796 The short header can be used after the version and 1-RTT keys are 3797 negotiated. Packets that use the short header contain the following 3798 fields: 3800 Header Form: The most significant bit (0x80) of byte 0 is set to 0 3801 for the short header. 3803 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 3804 containing a zero value for this bit are not valid packets in this 3805 version and MUST be discarded. 3807 Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin 3808 Bit, set as described in [SPIN]. 3810 Reserved Bits (R): The next two bits (those with a mask of 0x18) of 3811 byte 0 are reserved. These bits are protected using header 3812 protection (see Section 5.4 of [QUIC-TLS]). The value included 3813 prior to protection MUST be set to 0. An endpoint MUST treat 3814 receipt of a packet that has a non-zero value for these bits after 3815 removing protection as a connection error of type 3816 PROTOCOL_VIOLATION. 3818 Key Phase (K): The next bit (0x04) of byte 0 indicates the key 3819 phase, which allows a recipient of a packet to identify the packet 3820 protection keys that are used to protect the packet. See 3821 [QUIC-TLS] for details. This bit is protected using header 3822 protection (see Section 5.4 of [QUIC-TLS]). 3824 Packet Number Length (P): The least significant two bits (those with 3825 a mask of 0x03) of byte 0 contain the length of the packet number, 3826 encoded as an unsigned, two-bit integer that is one less than the 3827 length of the packet number field in bytes. That is, the length 3828 of the packet number field is the value of this field, plus one. 3829 These bits are protected using header protection (see Section 5.4 3830 of [QUIC-TLS]). 3832 Destination Connection ID: The Destination Connection ID is a 3833 connection ID that is chosen by the intended recipient of the 3834 packet. See Section 5.1 for more details. 3836 Packet Number: The packet number field is 1 to 4 bytes long. The 3837 packet number has confidentiality protection separate from packet 3838 protection, as described in Section 5.4 of [QUIC-TLS]. The length 3839 of the packet number field is encoded in Packet Number Length 3840 field. See Section 17.1 for details. 3842 Protected Payload: Packets with a short header always include a 3843 1-RTT protected payload. 3845 The header form bit and the connection ID field of a short header 3846 packet are version-independent. The remaining fields are specific to 3847 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 3848 packets from different versions of QUIC are interpreted. 3850 17.4. Version Negotiation Packet 3852 A Version Negotiation packet is inherently not version-specific, and 3853 does not use the long packet header (see Section 17.2). Upon receipt 3854 by a client, it will appear to be a packet using the long header, but 3855 will be identified as a Version Negotiation packet based on the 3856 Version field having a value of 0. 3858 The Version Negotiation packet is a response to a client packet that 3859 contains a version that is not supported by the server, and is only 3860 sent by servers. 3862 The layout of a Version Negotiation packet is: 3864 0 1 2 3 3865 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 3866 +-+-+-+-+-+-+-+-+ 3867 |1| Unused (7) | 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 | Version (32) | 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3871 |DCIL(4)|SCIL(4)| 3872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3873 | Destination Connection ID (0/32..144) ... 3874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3875 | Source Connection ID (0/32..144) ... 3876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 | Supported Version 1 (32) ... 3878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3879 | [Supported Version 2 (32)] ... 3880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3881 ... 3882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3883 | [Supported Version N (32)] ... 3884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3886 Figure 12: Version Negotiation Packet 3888 The value in the Unused field is selected randomly by the server. 3890 The Version field of a Version Negotiation packet MUST be set to 3891 0x00000000. 3893 The server MUST include the value from the Source Connection ID field 3894 of the packet it receives in the Destination Connection ID field. 3895 The value for Source Connection ID MUST be copied from the 3896 Destination Connection ID of the received packet, which is initially 3897 randomly selected by a client. Echoing both connection IDs gives 3898 clients some assurance that the server received the packet and that 3899 the Version Negotiation packet was not generated by an off-path 3900 attacker. 3902 The remainder of the Version Negotiation packet is a list of 32-bit 3903 versions which the server supports. 3905 A Version Negotiation packet cannot be explicitly acknowledged in an 3906 ACK frame by a client. Receiving another Initial packet implicitly 3907 acknowledges a Version Negotiation packet. 3909 The Version Negotiation packet does not include the Packet Number and 3910 Length fields present in other packets that use the long header form. 3911 Consequently, a Version Negotiation packet consumes an entire UDP 3912 datagram. 3914 See Section 6 for a description of the version negotiation process. 3916 17.5. Initial Packet 3918 An Initial packet uses long headers with a type value of 0x0. It 3919 carries the first CRYPTO frames sent by the client and server to 3920 perform key exchange, and carries ACKs in either direction. 3922 In order to prevent tampering by version-unaware middleboxes, Initial 3923 packets are protected with connection- and version-specific keys 3924 (Initial keys) as described in [QUIC-TLS]. This protection does not 3925 provide confidentiality or integrity against on-path attackers, but 3926 provides some level of protection against off-path attackers. 3928 An Initial packet (shown in Figure 13) has two additional header 3929 fields that are added to the Long Header before the Length field. 3931 +-+-+-+-+-+-+-+-+ 3932 |1|1| 0 |R R|P P| 3933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3934 | Version (32) | 3935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3936 |DCIL(4)|SCIL(4)| 3937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3938 | Destination Connection ID (0/32..144) ... 3939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3940 | Source Connection ID (0/32..144) ... 3941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3942 | Token Length (i) ... 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 | Token (*) ... 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3946 | Length (i) ... 3947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3948 | Packet Number (8/16/24/32) ... 3949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3950 | Payload (*) ... 3951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3953 Figure 13: Initial Packet 3955 These fields include the token that was previously provided in a 3956 Retry packet or NEW_TOKEN frame: 3958 Token Length: A variable-length integer specifying the length of the 3959 Token field, in bytes. This value is zero if no token is present. 3960 Initial packets sent by the server MUST set the Token Length field 3961 to zero; clients that receive an Initial packet with a non-zero 3962 Token Length field MUST either discard the packet or generate a 3963 connection error of type PROTOCOL_VIOLATION. 3965 Token: The value of the token. 3967 The client and server use the Initial packet type for any packet that 3968 contains an initial cryptographic handshake message. This includes 3969 all cases where a new packet containing the initial cryptographic 3970 message needs to be created, such as the packets sent after receiving 3971 a Version Negotiation (Section 17.4) or Retry packet (Section 17.7). 3973 A server sends its first Initial packet in response to a client 3974 Initial. A server may send multiple Initial packets. The 3975 cryptographic key exchange could require multiple round trips or 3976 retransmissions of this data. 3978 The payload of an Initial packet includes a CRYPTO frame (or frames) 3979 containing a cryptographic handshake message, ACK frames, or both. 3980 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 3981 that receives an Initial packet containing other frames can either 3982 discard the packet as spurious or treat it as a connection error. 3984 The first packet sent by a client always includes a CRYPTO frame that 3985 contains the entirety of the first cryptographic handshake message. 3986 This packet, and the cryptographic handshake message, MUST fit in a 3987 single UDP datagram (see Section 7). The first CRYPTO frame sent 3988 always begins at an offset of 0 (see Section 7). 3990 Note that if the server sends a HelloRetryRequest, the client will 3991 send a second Initial packet. This Initial packet will continue the 3992 cryptographic handshake and will contain a CRYPTO frame with an 3993 offset matching the size of the CRYPTO frame sent in the first 3994 Initial packet. Cryptographic handshake messages subsequent to the 3995 first do not need to fit within a single UDP datagram. 3997 17.5.1. Abandoning Initial Packets 3999 A client stops both sending and processing Initial packets when it 4000 sends its first Handshake packet. A server stops sending and 4001 processing Initial packets when it receives its first Handshake 4002 packet. Though packets might still be in flight or awaiting 4003 acknowledgment, no further Initial packets need to be exchanged 4004 beyond this point. Initial packet protection keys are discarded (see 4005 Section 4.10 of [QUIC-TLS]) along with any loss recovery and 4006 congestion control state (see Sections 5.3.1.2 and 6.9 of 4007 [QUIC-RECOVERY]). 4009 Any data in CRYPTO frames is discarded - and no longer retransmitted 4010 - when Initial keys are discarded. 4012 17.5.2. Starting Packet Numbers 4014 The first Initial packet sent by either endpoint contains a packet 4015 number of 0. The packet number MUST increase monotonically 4016 thereafter. Initial packets are in a different packet number space 4017 to other packets (see Section 12.3). 4019 17.5.3. 0-RTT Packet Numbers 4021 Packet numbers for 0-RTT protected packets use the same space as 4022 1-RTT protected packets. 4024 After a client receives a Retry or Version Negotiation packet, 0-RTT 4025 packets are likely to have been lost or discarded by the server. A 4026 client MAY attempt to resend data in 0-RTT packets after it sends a 4027 new Initial packet. 4029 A client MUST NOT reset the packet number it uses for 0-RTT packets. 4030 The keys used to protect 0-RTT packets will not change as a result of 4031 responding to a Retry or Version Negotiation packet unless the client 4032 also regenerates the cryptographic handshake message. Sending 4033 packets with the same packet number in that case is likely to 4034 compromise the packet protection for all 0-RTT packets because the 4035 same key and nonce could be used to protect different content. 4037 Receiving a Retry or Version Negotiation packet, especially a Retry 4038 that changes the connection ID used for subsequent packets, indicates 4039 a strong possibility that 0-RTT packets could be lost. A client only 4040 receives acknowledgments for its 0-RTT packets once the handshake is 4041 complete. Consequently, a server might expect 0-RTT packets to start 4042 with a packet number of 0. Therefore, in determining the length of 4043 the packet number encoding for 0-RTT packets, a client MUST assume 4044 that all packets up to the current packet number are in flight, 4045 starting from a packet number of 0. Thus, 0-RTT packets could need 4046 to use a longer packet number encoding. 4048 A client SHOULD instead generate a fresh cryptographic handshake 4049 message and start packet numbers from 0. This ensures that new 0-RTT 4050 packets will not use the same keys, avoiding any risk of key and 4051 nonce reuse; this also prevents 0-RTT packets from previous handshake 4052 attempts from being accepted as part of the connection. 4054 17.6. Handshake Packet 4056 A Handshake packet uses long headers with a type value of 0x2. It is 4057 used to carry acknowledgments and cryptographic handshake messages 4058 from the server and client. 4060 Once a client has received a Handshake packet from a server, it uses 4061 Handshake packets to send subsequent cryptographic handshake messages 4062 and acknowledgments to the server. 4064 The Destination Connection ID field in a Handshake packet contains a 4065 connection ID that is chosen by the recipient of the packet; the 4066 Source Connection ID includes the connection ID that the sender of 4067 the packet wishes to use (see Section 7.2). 4069 The first Handshake packet sent by a server contains a packet number 4070 of 0. Handshake packets are their own packet number space. Packet 4071 numbers are incremented normally for other Handshake packets. 4073 The payload of this packet contains CRYPTO frames and could contain 4074 PADDING, or ACK frames. Handshake packets MAY contain 4075 CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake 4076 packets with other frames as a connection error. 4078 Like Initial packets (see Section 17.5.1), data in CRYPTO frames at 4079 the Handshake encryption level is discarded - and no longer 4080 retransmitted - when Handshake protection keys are discarded. 4082 17.7. Retry Packet 4084 A Retry packet uses a long packet header with a type value of 0x3. 4085 It carries an address validation token created by the server. It is 4086 used by a server that wishes to perform a stateless retry (see 4087 Section 8.1). 4089 0 1 2 3 4090 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 4091 +-+-+-+-+-+-+-+-+ 4092 |1|1| 3 |ODCIL(4| 4093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4094 | Version (32) | 4095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4096 |DCIL(4)|SCIL(4)| 4097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4098 | Destination Connection ID (0/32..144) ... 4099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4100 | Source Connection ID (0/32..144) ... 4101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4102 | Original Destination Connection ID (0/32..144) ... 4103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4104 | Retry Token (*) ... 4105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4107 Figure 14: Retry Packet 4109 A Retry packet (shown in Figure 14) only uses the invariant portion 4110 of the long packet header [QUIC-INVARIANTS]; that is, the fields up 4111 to and including the Destination and Source Connection ID fields. A 4112 Retry packet does not contain any protected fields. Like Version 4113 Negotiation, a Retry packet contains the long header including the 4114 connection IDs, but omits the Length, Packet Number, and Payload 4115 fields. These are replaced with: 4117 ODCIL: The four least-significant bits of the first byte of a Retry 4118 packet are not protected as they are for other packets with the 4119 long header, because Retry packets don't contain a protected 4120 payload. These bits instead encode the length of the Original 4121 Destination Connection ID field. The length uses the same 4122 encoding as the DCIL and SCIL fields. 4124 Original Destination Connection ID: The Original Destination 4125 Connection ID contains the value of the Destination Connection ID 4126 from the Initial packet that this Retry is in response to. The 4127 length of this field is given in ODCIL. 4129 Retry Token: An opaque token that the server can use to validate the 4130 client's address. 4132 The server populates the Destination Connection ID with the 4133 connection ID that the client included in the Source Connection ID of 4134 the Initial packet. 4136 The server includes a connection ID of its choice in the Source 4137 Connection ID field. This value MUST not be equal to the Destination 4138 Connection ID field of the packet sent by the client. The client 4139 MUST use this connection ID in the Destination Connection ID of 4140 subsequent packets that it sends. 4142 A server MAY send Retry packets in response to Initial and 0-RTT 4143 packets. A server can either discard or buffer 0-RTT packets that it 4144 receives. A server can send multiple Retry packets as it receives 4145 Initial or 0-RTT packets. 4147 A client MUST accept and process at most one Retry packet for each 4148 connection attempt. After the client has received and processed an 4149 Initial or Retry packet from the server, it MUST discard any 4150 subsequent Retry packets that it receives. 4152 Clients MUST discard Retry packets that contain an Original 4153 Destination Connection ID field that does not match the Destination 4154 Connection ID from its Initial packet. This prevents an off-path 4155 attacker from injecting a Retry packet. 4157 The client responds to a Retry packet with an Initial packet that 4158 includes the provided Retry Token to continue connection 4159 establishment. 4161 A client sets the Destination Connection ID field of this Initial 4162 packet to the value from the Source Connection ID in the Retry 4163 packet. Changing Destination Connection ID also results in a change 4164 to the keys used to protect the Initial packet. It also sets the 4165 Token field to the token provided in the Retry. The client MUST NOT 4166 change the Source Connection ID because the server could include the 4167 connection ID as part of its token validation logic (see 4168 Section 8.1.2). 4170 The next Initial packet from the client uses the connection ID and 4171 token values from the Retry packet (see Section 7.2). Aside from 4172 this, the Initial packet sent by the client is subject to the same 4173 restrictions as the first Initial packet. A client can either reuse 4174 the cryptographic handshake message or construct a new one at its 4175 discretion. 4177 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4178 0-RTT packets to the connection ID provided by the server. A client 4179 that sends additional 0-RTT packets without constructing a new 4180 cryptographic handshake message MUST NOT reset the packet number to 0 4181 after a Retry packet, see Section 17.5.3. 4183 A server acknowledges the use of a Retry packet for a connection 4184 using the original_connection_id transport parameter (see 4185 Section 18.1). If the server sends a Retry packet, it MUST include 4186 the value of the Original Destination Connection ID field of the 4187 Retry packet (that is, the Destination Connection ID field from the 4188 client's first Initial packet) in the transport parameter. 4190 If the client received and processed a Retry packet, it validates 4191 that the original_connection_id transport parameter is present and 4192 correct; otherwise, it validates that the transport parameter is 4193 absent. A client MUST treat a failed validation as a connection 4194 error of type TRANSPORT_PARAMETER_ERROR. 4196 A Retry packet does not include a packet number and cannot be 4197 explicitly acknowledged by a client. 4199 18. Transport Parameter Encoding 4201 The format of the transport parameters is the TransportParameters 4202 struct from Figure 15. This is described using the presentation 4203 language from Section 3 of [TLS13]. 4205 uint32 QuicVersion; 4207 enum { 4208 original_connection_id(0), 4209 idle_timeout(1), 4210 stateless_reset_token(2), 4211 max_packet_size(3), 4212 initial_max_data(4), 4213 initial_max_stream_data_bidi_local(5), 4214 initial_max_stream_data_bidi_remote(6), 4215 initial_max_stream_data_uni(7), 4216 initial_max_streams_bidi(8), 4217 initial_max_streams_uni(9), 4218 ack_delay_exponent(10), 4219 max_ack_delay(11), 4220 disable_migration(12), 4221 preferred_address(13), 4222 (65535) 4223 } TransportParameterId; 4225 struct { 4226 TransportParameterId parameter; 4227 opaque value<0..2^16-1>; 4228 } TransportParameter; 4230 struct { 4231 select (Handshake.msg_type) { 4232 case client_hello: 4233 QuicVersion initial_version; 4235 case encrypted_extensions: 4236 QuicVersion negotiated_version; 4237 QuicVersion supported_versions<4..2^8-4>; 4238 }; 4239 TransportParameter parameters<0..2^16-1>; 4240 } TransportParameters; 4242 Figure 15: Definition of TransportParameters 4244 The "extension_data" field of the quic_transport_parameters extension 4245 defined in [QUIC-TLS] contains a TransportParameters value. TLS 4246 encoding rules are therefore used to describe the encoding of 4247 transport parameters. 4249 QUIC encodes transport parameters into a sequence of bytes, which are 4250 then included in the cryptographic handshake. 4252 18.1. Transport Parameter Definitions 4254 This section details the transport parameters defined in this 4255 document. 4257 Many transport parameters listed here have integer values. Those 4258 transport parameters that are identified as integers use a variable- 4259 length integer encoding (see Section 16) and have a default value of 4260 0 if the transport parameter is absent, unless otherwise stated. 4262 The following transport parameters are defined: 4264 original_connection_id (0x0000): The value of the Destination 4265 Connection ID field from the first Initial packet sent by the 4266 client. This transport parameter is only sent by a server. A 4267 server MUST include the original_connection_id transport parameter 4268 if it sent a Retry packet. 4270 idle_timeout (0x0001): The idle timeout is a value in seconds that 4271 is encoded as an integer. If this parameter is absent or zero 4272 then the idle timeout is disabled. 4274 stateless_reset_token (0x0002): A stateless reset token is used in 4275 verifying a stateless reset, see Section 10.4. This parameter is 4276 a sequence of 16 bytes. This transport parameter is only sent by 4277 a server. 4279 max_packet_size (0x0003): The maximum packet size parameter is an 4280 integer value that limits the size of packets that the endpoint is 4281 willing to receive. This indicates that packets larger than this 4282 limit will be dropped. The default for this parameter is the 4283 maximum permitted UDP payload of 65527. Values below 1200 are 4284 invalid. This limit only applies to protected packets 4285 (Section 12.1). 4287 initial_max_data (0x0004): The initial maximum data parameter is an 4288 integer value that contains the initial value for the maximum 4289 amount of data that can be sent on the connection. This is 4290 equivalent to sending a MAX_DATA (Section 19.9) for the connection 4291 immediately after completing the handshake. 4293 initial_max_stream_data_bidi_local (0x0005): This parameter is an 4294 integer value specifying the initial flow control limit for 4295 locally-initiated bidirectional streams. This limit applies to 4296 newly created bidirectional streams opened by the endpoint that 4297 sends the transport parameter. In client transport parameters, 4298 this applies to streams with an identifier with the least 4299 significant two bits set to 0x0; in server transport parameters, 4300 this applies to streams with the least significant two bits set to 4301 0x1. 4303 initial_max_stream_data_bidi_remote (0x0006): This parameter is an 4304 integer value specifying the initial flow control limit for peer- 4305 initiated bidirectional streams. This limit applies to newly 4306 created bidirectional streams opened by the endpoint that receives 4307 the transport parameter. In client transport parameters, this 4308 applies to streams with an identifier with the least significant 4309 two bits set to 0x1; in server transport parameters, this applies 4310 to streams with the least significant two bits set to 0x0. 4312 initial_max_stream_data_uni (0x0007): This parameter is an integer 4313 value specifying the initial flow control limit for unidirectional 4314 streams. This limit applies to newly created bidirectional 4315 streams opened by the endpoint that receives the transport 4316 parameter. In client transport parameters, this applies to 4317 streams with an identifier with the least significant two bits set 4318 to 0x3; in server transport parameters, this applies to streams 4319 with the least significant two bits set to 0x2. 4321 initial_max_streams_bidi (0x0008): The initial maximum bidirectional 4322 streams parameter is an integer value that contains the initial 4323 maximum number of bidirectional streams the peer may initiate. If 4324 this parameter is absent or zero, the peer cannot open 4325 bidirectional streams until a MAX_STREAMS frame is sent. Setting 4326 this parameter is equivalent to sending a MAX_STREAMS 4327 (Section 19.11) of the corresponding type with the same value. 4329 initial_max_streams_uni (0x0009): The initial maximum unidirectional 4330 streams parameter is an integer value that contains the initial 4331 maximum number of unidirectional streams the peer may initiate. 4332 If this parameter is absent or zero, the peer cannot open 4333 unidirectional streams until a MAX_STREAMS frame is sent. Setting 4334 this parameter is equivalent to sending a MAX_STREAMS 4335 (Section 19.11) of the corresponding type with the same value. 4337 ack_delay_exponent (0x000a): The ACK delay exponent is an integer 4338 value indicating an exponent used to decode the ACK Delay field in 4339 the ACK frame (Section 19.3). If this value is absent, a default 4340 value of 3 is assumed (indicating a multiplier of 8). The default 4341 value is also used for ACK frames that are sent in Initial and 4342 Handshake packets. Values above 20 are invalid. 4344 max_ack_delay (0x000b): The maximum ACK delay is an integer value 4345 indicating the maximum amount of time in milliseconds by which the 4346 endpoint will delay sending acknowledgments. This value SHOULD 4347 include the receiver's expected delays in alarms firing. For 4348 example, if a receiver sets a timer for 5ms and alarms commonly 4349 fire up to 1ms late, then it should send a max_ack_delay of 6ms. 4350 If this value is absent, a default of 25 milliseconds is assumed. 4352 disable_migration (0x000c): The disable migration transport 4353 parameter is included if the endpoint does not support connection 4354 migration (Section 9). Peers of an endpoint that sets this 4355 transport parameter MUST NOT send any packets, including probing 4356 packets (Section 9.1), from a local address other than that used 4357 to perform the handshake. This parameter is a zero-length value. 4359 preferred_address (0x000d): The server's preferred address is used 4360 to effect a change in server address at the end of the handshake, 4361 as described in Section 9.6. The format of this transport 4362 parameter is the PreferredAddress struct shown in Figure 16. This 4363 transport parameter is only sent by a server. 4365 struct { 4366 enum { IPv4(4), IPv6(6), (15) } ipVersion; 4367 opaque ipAddress<4..2^8-1>; 4368 uint16 port; 4369 opaque connectionId<0..18>; 4370 opaque statelessResetToken[16]; 4371 } PreferredAddress; 4373 Figure 16: Preferred Address format 4375 If present, transport parameters that set initial flow control limits 4376 (initial_max_stream_data_bidi_local, 4377 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 4378 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 4379 every stream of the corresponding type immediately after opening. If 4380 the transport parameter is absent, streams of that type start with a 4381 flow control limit of 0. 4383 A client MUST NOT include an original connection ID, a stateless 4384 reset token, or a preferred address. A server MUST treat receipt of 4385 any of these transport parameters as a connection error of type 4386 TRANSPORT_PARAMETER_ERROR. 4388 19. Frame Types and Formats 4390 As described in Section 12.4, packets contain one or more frames. 4391 This section describes the format and semantics of the core QUIC 4392 frame types. 4394 19.1. PADDING Frame 4396 The PADDING frame (type=0x00) has no semantic value. PADDING frames 4397 can be used to increase the size of a packet. Padding can be used to 4398 increase an initial client packet to the minimum required size, or to 4399 provide protection against traffic analysis for protected packets. 4401 A PADDING frame has no content. That is, a PADDING frame consists of 4402 the single byte that identifies the frame as a PADDING frame. 4404 19.2. PING Frame 4406 Endpoints can use PING frames (type=0x01) to verify that their peers 4407 are still alive or to check reachability to the peer. The PING frame 4408 contains no additional fields. 4410 The receiver of a PING frame simply needs to acknowledge the packet 4411 containing this frame. 4413 The PING frame can be used to keep a connection alive when an 4414 application or application protocol wishes to prevent the connection 4415 from timing out. An application protocol SHOULD provide guidance 4416 about the conditions under which generating a PING is recommended. 4417 This guidance SHOULD indicate whether it is the client or the server 4418 that is expected to send the PING. Having both endpoints send PING 4419 frames without coordination can produce an excessive number of 4420 packets and poor performance. 4422 A connection will time out if no packets are sent or received for a 4423 period longer than the time specified in the idle_timeout transport 4424 parameter (see Section 10). However, state in middleboxes might time 4425 out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 4426 minute timeout interval, experience shows that sending packets every 4427 15 to 30 seconds is necessary to prevent the majority of middleboxes 4428 from losing state for UDP flows. 4430 19.3. ACK Frames 4432 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 4433 packets they have received and processed. The ACK frame contains one 4434 or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. 4435 If the frame type is 0x03, ACK frames also contain the sum of QUIC 4436 packets with associated ECN marks received on the connection up until 4437 this point. QUIC implementations MUST properly handle both types 4438 and, if they have enabled ECN for packets they send, they SHOULD use 4439 the information in the ECN section to manage their congestion state. 4441 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 4442 remains acknowledged, even if it does not appear in a future ACK 4443 frame. This is unlike TCP SACKs ([RFC2018]). 4445 It is expected that a sender will reuse the same packet number across 4446 different packet number spaces. ACK frames only acknowledge the 4447 packet numbers that were transmitted by the sender in the same packet 4448 number space of the packet that the ACK was received in. 4450 Version Negotiation and Retry packets cannot be acknowledged because 4451 they do not contain a packet number. Rather than relying on ACK 4452 frames, these packets are implicitly acknowledged by the next Initial 4453 packet sent by the client. 4455 An ACK frame is as follows: 4457 0 1 2 3 4458 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 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4460 | Largest Acknowledged (i) ... 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 | ACK Delay (i) ... 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4464 | ACK Block Count (i) ... 4465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4466 | ACK Blocks (*) ... 4467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4468 | [ECN Section] ... 4469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4471 Figure 17: ACK Frame Format 4473 ACK frames contain the following fields: 4475 Largest Acknowledged: A variable-length integer representing the 4476 largest packet number the peer is acknowledging; this is usually 4477 the largest packet number that the peer has received prior to 4478 generating the ACK frame. Unlike the packet number in the QUIC 4479 long or short header, the value in an ACK frame is not truncated. 4481 ACK Delay: A variable-length integer including the time in 4482 microseconds that the largest acknowledged packet, as indicated in 4483 the Largest Acknowledged field, was received by this peer to when 4484 this ACK was sent. The value of the ACK Delay field is scaled by 4485 multiplying the encoded value by 2 to the power of the value of 4486 the "ack_delay_exponent" transport parameter set by the sender of 4487 the ACK frame. The "ack_delay_exponent" defaults to 3, or a 4488 multiplier of 8 (see Section 18.1). Scaling in this fashion 4489 allows for a larger range of values with a shorter encoding at the 4490 cost of lower resolution. 4492 ACK Block Count: A variable-length integer specifying the number of 4493 Additional ACK Block (and Gap) fields after the First ACK Block. 4495 ACK Blocks: Contains one or more blocks of packet numbers which have 4496 been successfully received, see Section 19.3.1. 4498 19.3.1. ACK Block Section 4500 The ACK Block Section consists of alternating Gap and ACK Block 4501 fields in descending packet number order. A First Ack Block field is 4502 followed by a variable number of alternating Gap and Additional ACK 4503 Blocks. The number of Gap and Additional ACK Block fields is 4504 determined by the ACK Block Count field. 4506 Gap and ACK Block fields use a relative integer encoding for 4507 efficiency. Though each encoded value is positive, the values are 4508 subtracted, so that each ACK Block describes progressively lower- 4509 numbered packets. As long as contiguous ranges of packets are small, 4510 the variable-length integer encoding ensures that each range can be 4511 expressed in a small number of bytes. 4513 The ACK frame uses the least significant bit (that is, type 0x03) to 4514 indicate ECN feedback and report receipt of QUIC packets with 4515 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 4516 header. 4518 0 1 2 3 4519 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 4520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4521 | First ACK Block (i) ... 4522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4523 | Gap (i) ... 4524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4525 | Additional ACK Block (i) ... 4526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4527 | Gap (i) ... 4528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4529 | Additional ACK Block (i) ... 4530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4531 ... 4532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4533 | Gap (i) ... 4534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4535 | Additional ACK Block (i) ... 4536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4538 Figure 18: ACK Block Section 4540 Each ACK Block acknowledges a contiguous range of packets by 4541 indicating the number of acknowledged packets that precede the 4542 largest packet number in that block. A value of zero indicates that 4543 only the largest packet number is acknowledged. Larger ACK Block 4544 values indicate a larger range, with corresponding lower values for 4545 the smallest packet number in the range. Thus, given a largest 4546 packet number for the ACK, the smallest value is determined by the 4547 formula: 4549 smallest = largest - ack_block 4551 The range of packets that are acknowledged by the ACK Block include 4552 the range from the smallest packet number to the largest, inclusive. 4554 The largest value for the First ACK Block is determined by the 4555 Largest Acknowledged field; the largest for Additional ACK Blocks is 4556 determined by cumulatively subtracting the size of all preceding ACK 4557 Blocks and Gaps. 4559 Each Gap indicates a range of packets that are not being 4560 acknowledged. The number of packets in the gap is one higher than 4561 the encoded value of the Gap Field. 4563 The value of the Gap field establishes the largest packet number 4564 value for the ACK Block that follows the gap using the following 4565 formula: 4567 largest = previous_smallest - gap - 2 4569 If the calculated value for largest or smallest packet number for any 4570 ACK Block is negative, an endpoint MUST generate a connection error 4571 of type FRAME_ENCODING_ERROR indicating an error in an ACK frame. 4573 The fields in the ACK Block Section are: 4575 First ACK Block: A variable-length integer indicating the number of 4576 contiguous packets preceding the Largest Acknowledged that are 4577 being acknowledged. 4579 Gap (repeated): A variable-length integer indicating the number of 4580 contiguous unacknowledged packets preceding the packet number one 4581 lower than the smallest in the preceding ACK Block. 4583 Additional ACK Block (repeated): A variable-length integer 4584 indicating the number of contiguous acknowledged packets preceding 4585 the largest packet number, as determined by the preceding Gap. 4587 19.3.2. ECN section 4589 The ECN section should only be parsed when the ACK frame type is 4590 0x03. The ECN section consists of 3 ECN counts as shown below. 4592 0 1 2 3 4593 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 4594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4595 | ECT(0) Count (i) ... 4596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4597 | ECT(1) Count (i) ... 4598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4599 | ECN-CE Count (i) ... 4600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4602 ECT(0) Count: A variable-length integer representing the total 4603 number packets received with the ECT(0) codepoint. 4605 ECT(1) Count: A variable-length integer representing the total 4606 number packets received with the ECT(1) codepoint. 4608 CE Count: A variable-length integer representing the total number 4609 packets received with the CE codepoint. 4611 ECN counts are maintained separately for each packet number space. 4613 19.4. RESET_STREAM Frame 4615 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 4616 terminate a stream. 4618 After sending a RESET_STREAM, an endpoint ceases transmission and 4619 retransmission of STREAM frames on the identified stream. A receiver 4620 of RESET_STREAM can discard any data that it already received on that 4621 stream. 4623 An endpoint that receives a RESET_STREAM frame for a send-only stream 4624 MUST terminate the connection with error PROTOCOL_VIOLATION. 4626 The RESET_STREAM frame is as follows: 4628 0 1 2 3 4629 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 4630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4631 | Stream ID (i) ... 4632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4633 | Application Error Code (16) | 4634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4635 | Final Offset (i) ... 4636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4638 RESET_STREAM frames contain the following fields: 4640 Stream ID: A variable-length integer encoding of the Stream ID of 4641 the stream being terminated. 4643 Application Protocol Error Code: A 16-bit application protocol error 4644 code (see Section 20.1) which indicates why the stream is being 4645 closed. 4647 Final Offset: A variable-length integer indicating the absolute byte 4648 offset of the end of data written on this stream by the 4649 RESET_STREAM sender. 4651 19.5. STOP_SENDING Frame 4653 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 4654 incoming data is being discarded on receipt at application request. 4655 This signals a peer to abruptly terminate transmission on a stream. 4657 Receipt of a STOP_SENDING frame is invalid for a locally-initiated 4658 stream that has not yet been created or is in the "Ready" state (see 4659 Section 3.1). Receiving a STOP_SENDING frame for a locally-initiated 4660 send stream that is "Ready" or not yet created MUST be treated as a 4661 connection error of type PROTOCOL_VIOLATION. An endpoint that 4662 receives a STOP_SENDING frame for a receive-only stream MUST 4663 terminate the connection with error PROTOCOL_VIOLATION. 4665 The STOP_SENDING frame is as follows: 4667 0 1 2 3 4668 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 4669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4670 | Stream ID (i) ... 4671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4672 | Application Error Code (16) | 4673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4675 STOP_SENDING frames contain the following fields: 4677 Stream ID: A variable-length integer carrying the Stream ID of the 4678 stream being ignored. 4680 Application Error Code: A 16-bit, application-specified reason the 4681 sender is ignoring the stream (see Section 20.1). 4683 19.6. CRYPTO Frame 4685 The CRYPTO frame (type=0x06) is used to transmit cryptographic 4686 handshake messages. It can be sent in all packet types. The CRYPTO 4687 frame offers the cryptographic protocol an in-order stream of bytes. 4688 CRYPTO frames are functionally identical to STREAM frames, except 4689 that they do not bear a stream identifier; they are not flow 4690 controlled; and they do not carry markers for optional offset, 4691 optional length, and the end of the stream. 4693 The CRYPTO frame is as follows: 4695 0 1 2 3 4696 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 4697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4698 | Offset (i) ... 4699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4700 | Length (i) ... 4701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4702 | Crypto Data (*) ... 4703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4705 Figure 19: CRYPTO Frame Format 4707 CRYPTO frames contain the following fields: 4709 Offset: A variable-length integer specifying the byte offset in the 4710 stream for the data in this CRYPTO frame. 4712 Length: A variable-length integer specifying the length of the 4713 Crypto Data field in this CRYPTO frame. 4715 Crypto Data: The cryptographic message data. 4717 There is a separate flow of cryptographic handshake data in each 4718 encryption level, each of which starts at an offset of 0. This 4719 implies that each encryption level is treated as a separate CRYPTO 4720 stream of data. 4722 Unlike STREAM frames, which include a Stream ID indicating to which 4723 stream the data belongs, the CRYPTO frame carries data for a single 4724 stream per encryption level. The stream does not have an explicit 4725 end, so CRYPTO frames do not have a FIN bit. 4727 19.7. NEW_TOKEN Frame 4729 A server sends a NEW_TOKEN frame (type=0x07) to provide the client a 4730 token to send in the header of an Initial packet for a future 4731 connection. 4733 The NEW_TOKEN frame is as follows: 4735 0 1 2 3 4736 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 4737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4738 | Token Length (i) ... 4739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4740 | Token (*) ... 4741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4743 NEW_TOKEN frames contain the following fields: 4745 Token Length: A variable-length integer specifying the length of the 4746 token in bytes. 4748 Token: An opaque blob that the client may use with a future Initial 4749 packet. 4751 19.8. STREAM Frames 4753 STREAM frames implicitly create a stream and carry stream data. The 4754 STREAM frame takes the form 0b00001XXX (or the set of values from 4755 0x08 to 0x0f). The value of the three low-order bits of the frame 4756 type determine the fields that are present in the frame. 4758 o The OFF bit (0x04) in the frame type is set to indicate that there 4759 is an Offset field present. When set to 1, the Offset field is 4760 present. When set to 0, the Offset field is absent and the Stream 4761 Data starts at an offset of 0 (that is, the frame contains the 4762 first bytes of the stream, or the end of a stream that includes no 4763 data). 4765 o The LEN bit (0x02) in the frame type is set to indicate that there 4766 is a Length field present. If this bit is set to 0, the Length 4767 field is absent and the Stream Data field extends to the end of 4768 the packet. If this bit is set to 1, the Length field is present. 4770 o The FIN bit (0x01) of the frame type is set only on frames that 4771 contain the final offset of the stream. Setting this bit 4772 indicates that the frame marks the end of the stream. 4774 An endpoint that receives a STREAM frame for a send-only stream MUST 4775 terminate the connection with error PROTOCOL_VIOLATION. 4777 The STREAM frames are as follows: 4779 0 1 2 3 4780 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 4781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4782 | Stream ID (i) ... 4783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4784 | [Offset (i)] ... 4785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4786 | [Length (i)] ... 4787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4788 | Stream Data (*) ... 4789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4791 Figure 20: STREAM Frame Format 4793 STREAM frames contain the following fields: 4795 Stream ID: A variable-length integer indicating the stream ID of the 4796 stream (see Section 2.1). 4798 Offset: A variable-length integer specifying the byte offset in the 4799 stream for the data in this STREAM frame. This field is present 4800 when the OFF bit is set to 1. When the Offset field is absent, 4801 the offset is 0. 4803 Length: A variable-length integer specifying the length of the 4804 Stream Data field in this STREAM frame. This field is present 4805 when the LEN bit is set to 1. When the LEN bit is set to 0, the 4806 Stream Data field consumes all the remaining bytes in the packet. 4808 Stream Data: The bytes from the designated stream to be delivered. 4810 When a Stream Data field has a length of 0, the offset in the STREAM 4811 frame is the offset of the next byte that would be sent. 4813 The first byte in the stream has an offset of 0. The largest offset 4814 delivered on a stream - the sum of the re-constructed offset and data 4815 length - MUST be less than 2^62. 4817 19.9. MAX_DATA Frame 4819 The MAX_DATA frame (type=0x10) is used in flow control to inform the 4820 peer of the maximum amount of data that can be sent on the connection 4821 as a whole. 4823 The MAX_DATA frame is as follows: 4825 0 1 2 3 4826 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 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4828 | Maximum Data (i) ... 4829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4831 MAX_DATA frames contain the following fields: 4833 Maximum Data: A variable-length integer indicating the maximum 4834 amount of data that can be sent on the entire connection, in units 4835 of bytes. 4837 All data sent in STREAM frames counts toward this limit. The sum of 4838 the largest received offsets on all streams - including streams in 4839 terminal states - MUST NOT exceed the value advertised by a receiver. 4840 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 4841 error if it receives more data than the maximum data value that it 4842 has sent, unless this is a result of a change in the initial limits 4843 (see Section 7.3.1). 4845 19.10. MAX_STREAM_DATA Frame 4847 The MAX_STREAM_DATA frame (type=0x11) is used in flow control to 4848 inform a peer of the maximum amount of data that can be sent on a 4849 stream. 4851 An endpoint that receives a MAX_STREAM_DATA frame for a receive-only 4852 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 4854 An endpoint that receives a MAX_STREAM_DATA frame for a send-only 4855 stream it has not opened MUST terminate the connection with error 4856 PROTOCOL_VIOLATION. 4858 Note that an endpoint may legally receive a MAX_STREAM_DATA frame on 4859 a bidirectional stream it has not opened. 4861 The MAX_STREAM_DATA frame is as follows: 4863 0 1 2 3 4864 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 4865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4866 | Stream ID (i) ... 4867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4868 | Maximum Stream Data (i) ... 4869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4871 MAX_STREAM_DATA frames contain the following fields: 4873 Stream ID: The stream ID of the stream that is affected encoded as a 4874 variable-length integer. 4876 Maximum Stream Data: A variable-length integer indicating the 4877 maximum amount of data that can be sent on the identified stream, 4878 in units of bytes. 4880 When counting data toward this limit, an endpoint accounts for the 4881 largest received offset of data that is sent or received on the 4882 stream. Loss or reordering can mean that the largest received offset 4883 on a stream can be greater than the total size of data received on 4884 that stream. Receiving STREAM frames might not increase the largest 4885 received offset. 4887 The data sent on a stream MUST NOT exceed the largest maximum stream 4888 data value advertised by the receiver. An endpoint MUST terminate a 4889 connection with a FLOW_CONTROL_ERROR error if it receives more data 4890 than the largest maximum stream data that it has sent for the 4891 affected stream, unless this is a result of a change in the initial 4892 limits (see Section 7.3.1). 4894 19.11. MAX_STREAMS Frames 4896 The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the 4897 cumulative number of streams of a given type it is permitted to open. 4898 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 4899 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 4900 unidirectional streams. 4902 The MAX_STREAMS frames are as follows: 4904 0 1 2 3 4905 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 4906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4907 | Maximum Streams (i) ... 4908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4910 MAX_STREAMS frames contain the following fields: 4912 Maximum Streams: A count of the cumulative number of streams of the 4913 corresponding type that can be opened over the lifetime of the 4914 connection. 4916 Loss or reordering can cause a MAX_STREAMS frame to be received which 4917 states a lower stream limit than an endpoint has previously received. 4918 MAX_STREAMS frames which do not increase the stream limit MUST be 4919 ignored. 4921 An endpoint MUST NOT open more streams than permitted by the current 4922 stream limit set by its peer. For instance, a server that receives a 4923 unidirectional stream limit of 3 is permitted to open stream 3, 7, 4924 and 11, but not stream 15. An endpoint MUST terminate a connection 4925 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 4926 permitted. 4928 Note that these frames (and the corresponding transport parameters) 4929 do not describe the number of streams that can be opened 4930 concurrently. The limit includes streams that have been closed as 4931 well as those that are open. 4933 19.12. DATA_BLOCKED Frame 4935 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 4936 to send data, but is unable to due to connection-level flow control 4937 (see Section 4). DATA_BLOCKED frames can be used as input to tuning 4938 of flow control algorithms (see Section 4.2). 4940 The DATA_BLOCKED frame is as follows: 4942 0 1 2 3 4943 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 4944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4945 | Data Limit (i) ... 4946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4948 DATA_BLOCKED frames contain the following fields: 4950 Data Limit: A variable-length integer indicating the connection- 4951 level limit at which blocking occurred. 4953 19.13. STREAM_DATA_BLOCKED Frame 4955 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 4956 wishes to send data, but is unable to due to stream-level flow 4957 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 4959 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 4960 stream MUST terminate the connection with error PROTOCOL_VIOLATION. 4962 The STREAM_DATA_BLOCKED frame is as follows: 4964 0 1 2 3 4965 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 4966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4967 | Stream ID (i) ... 4968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4969 | Stream Data Limit (i) ... 4970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4972 STREAM_DATA_BLOCKED frames contain the following fields: 4974 Stream ID: A variable-length integer indicating the stream which is 4975 flow control blocked. 4977 Stream Data Limit: A variable-length integer indicating the offset 4978 of the stream at which the blocking occurred. 4980 19.14. STREAMS_BLOCKED Frames 4982 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 4983 it wishes to open a stream, but is unable to due to the maximum 4984 stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED 4985 frame of type 0x16 is used to indicate reaching the bidirectional 4986 stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates 4987 reaching the unidirectional stream limit. 4989 A STREAMS_BLOCKED frame does not open the stream, but informs the 4990 peer that a new stream was needed and the stream limit prevented the 4991 creation of the stream. 4993 The STREAMS_BLOCKED frames are as follows: 4995 0 1 2 3 4996 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 4997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4998 | Stream Limit (i) ... 4999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5001 STREAMS_BLOCKED frames contain the following fields: 5003 Stream Limit: A variable-length integer indicating the stream limit 5004 at the time the frame was sent. 5006 19.15. NEW_CONNECTION_ID Frame 5008 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 5009 its peer with alternative connection IDs that can be used to break 5010 linkability when migrating connections (see Section 9.5). 5012 The NEW_CONNECTION_ID frame is as follows: 5014 0 1 2 3 5015 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 5016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5017 | Sequence Number (i) ... 5018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5019 | Length (8) | | 5020 +-+-+-+-+-+-+-+-+ Connection ID (32..144) + 5021 | ... 5022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5023 | | 5024 + + 5025 | | 5026 + Stateless Reset Token (128) + 5027 | | 5028 + + 5029 | | 5030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5032 NEW_CONNECTION_ID frames contain the following fields: 5034 Sequence Number: The sequence number assigned to the connection ID 5035 by the sender. See Section 5.1.1. 5037 Length: An 8-bit unsigned integer containing the length of the 5038 connection ID. Values less than 4 and greater than 18 are invalid 5039 and MUST be treated as a connection error of type 5040 PROTOCOL_VIOLATION. 5042 Connection ID: A connection ID of the specified length. 5044 Stateless Reset Token: A 128-bit value that will be used for a 5045 stateless reset when the associated connection ID is used (see 5046 Section 10.4). 5048 An endpoint MUST NOT send this frame if it currently requires that 5049 its peer send packets with a zero-length Destination Connection ID. 5050 Changing the length of a connection ID to or from zero-length makes 5051 it difficult to identify when the value of the connection ID changed. 5052 An endpoint that is sending packets with a zero-length Destination 5053 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 5054 connection error of type PROTOCOL_VIOLATION. 5056 Transmission errors, timeouts and retransmissions might cause the 5057 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 5058 of the same frame multiple times MUST NOT be treated as a connection 5059 error. A receiver can use the sequence number supplied in the 5060 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 5062 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 5063 previously issued connection ID with a different Stateless Reset 5064 Token or a different sequence number, or if a sequence number is used 5065 for different connection IDs, the endpoint MAY treat that receipt as 5066 a connection error of type PROTOCOL_VIOLATION. 5068 19.16. RETIRE_CONNECTION_ID Frame 5070 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 5071 indicate that it will no longer use a connection ID that was issued 5072 by its peer. This may include the connection ID provided during the 5073 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 5074 request to the peer to send additional connection IDs for future use 5075 (see Section 5.1). New connection IDs can be delivered to a peer 5076 using the NEW_CONNECTION_ID frame (Section 19.15). 5078 Retiring a connection ID invalidates the stateless reset token 5079 associated with that connection ID. 5081 The RETIRE_CONNECTION_ID frame is as follows: 5083 0 1 2 3 5084 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 5085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5086 | Sequence Number (i) ... 5087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5089 RETIRE_CONNECTION_ID frames contain the following fields: 5091 Sequence Number: The sequence number of the connection ID being 5092 retired. See Section 5.1.2. 5094 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 5095 greater than any previously sent to the peer MAY be treated as a 5096 connection error of type PROTOCOL_VIOLATION. 5098 An endpoint cannot send this frame if it was provided with a zero- 5099 length connection ID by its peer. An endpoint that provides a zero- 5100 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 5101 frame as a connection error of type PROTOCOL_VIOLATION. 5103 19.17. PATH_CHALLENGE Frame 5105 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 5106 reachability to the peer and for path validation during connection 5107 migration. 5109 The PATH_CHALLENGE frames are as follows: 5111 0 1 2 3 5112 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 5113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5114 | | 5115 + Data (8) + 5116 | | 5117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5119 PATH_CHALLENGE frames contain the following fields: 5121 Data: This 8-byte field contains arbitrary data. 5123 A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is 5124 sufficient to ensure that it is easier to receive the packet than it 5125 is to guess the value correctly. 5127 The recipient of this frame MUST generate a PATH_RESPONSE frame 5128 (Section 19.18) containing the same Data. 5130 19.18. PATH_RESPONSE Frame 5132 The PATH_RESPONSE frame (type=0x1b) is sent in response to a 5133 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 5134 frame (Section 19.17). 5136 If the content of a PATH_RESPONSE frame does not match the content of 5137 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 5138 MAY generate a connection error of type PROTOCOL_VIOLATION. 5140 19.19. CONNECTION_CLOSE Frames 5142 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 5143 notify its peer that the connection is being closed. The 5144 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 5145 at only the QUIC layer, or the absence of errors (with the NO_ERROR 5146 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 5147 signal an error with the application that uses QUIC. 5149 If there are open streams that haven't been explicitly closed, they 5150 are implicitly closed when the connection is closed. 5152 The CONNECTION_CLOSE frames are as follows: 5154 0 1 2 3 5155 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 5156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5157 | Error Code (16) | [ Frame Type (i) ] ... 5158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5159 | Reason Phrase Length (i) ... 5160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5161 | Reason Phrase (*) ... 5162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5164 CONNECTION_CLOSE frames contain the following fields: 5166 Error Code: A 16-bit error code which indicates the reason for 5167 closing this connection. A CONNECTION_CLOSE frame of type 0x1c 5168 uses codes from the space defined in Section 20. A 5169 CONNECTION_CLOSE frame of type 0x1d uses codes from the 5170 application protocol error code space, see Section 20.1 5172 Frame Type: A variable-length integer encoding the type of frame 5173 that triggered the error. A value of 0 (equivalent to the mention 5174 of the PADDING frame) is used when the frame type is unknown. The 5175 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 5176 not include this field. 5178 Reason Phrase Length: A variable-length integer specifying the 5179 length of the reason phrase in bytes. Note that a 5180 CONNECTION_CLOSE frame cannot be split between packets, so in 5181 practice any limits on packet size will also limit the space 5182 available for a reason phrase. 5184 Reason Phrase: A human-readable explanation for why the connection 5185 was closed. This can be zero length if the sender chooses to not 5186 give details beyond the Error Code. This SHOULD be a UTF-8 5187 encoded string [RFC3629]. 5189 19.20. Extension Frames 5191 QUIC frames do not use a self-describing encoding. An endpoint 5192 therefore needs to understand the syntax of all frames before it can 5193 successfully process a packet. This allows for efficient encoding of 5194 frames, but it means that an endpoint cannot send a frame of a type 5195 that is unknown to its peer. 5197 An extension to QUIC that wishes to use a new type of frame MUST 5198 first ensure that a peer is able to understand the frame. An 5199 endpoint can use a transport parameter to signal its willingness to 5200 receive one or more extension frame types with the one transport 5201 parameter. 5203 Extension frames MUST be congestion controlled and MUST cause an ACK 5204 frame to be sent. The exception is extension frames that replace or 5205 supplement the ACK frame. Extension frames are not included in flow 5206 control unless specified in the extension. 5208 An IANA registry is used to manage the assignment of frame types, see 5209 Section 22.2. 5211 20. Transport Error Codes 5213 QUIC error codes are 16-bit unsigned integers. 5215 This section lists the defined QUIC transport error codes that may be 5216 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5217 connection. 5219 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5220 signal that the connection is being closed abruptly in the absence 5221 of any error. 5223 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5224 cannot continue with the connection. 5226 SERVER_BUSY (0x2): The server is currently busy and does not accept 5227 any new connections. 5229 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5230 permitted in its advertised data limits (see Section 4). 5232 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 5233 identifier that exceeded its advertised stream limit for the 5234 corresponding stream type. 5236 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5237 that was not in a state that permitted that frame (see Section 3). 5239 FINAL_OFFSET_ERROR (0x6): An endpoint received a STREAM frame 5240 containing data that exceeded the previously established final 5241 offset. Or an endpoint received a RESET_STREAM frame containing a 5242 final offset that was lower than the maximum offset of data that 5243 was already received. Or an endpoint received a RESET_STREAM 5244 frame containing a different final offset to the one already 5245 established. 5247 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5248 badly formatted. For instance, a frame of an unknown type, or an 5249 ACK frame that has more acknowledgment ranges than the remainder 5250 of the packet could carry. 5252 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5253 parameters that were badly formatted, included an invalid value, 5254 was absent even though it is mandatory, was present though it is 5255 forbidden, or is otherwise in error. 5257 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 5258 parameters that contained version negotiation parameters that 5259 disagreed with the version negotiation that it performed. This 5260 error code indicates a potential version downgrade attack. 5262 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5263 protocol compliance that was not covered by more specific error 5264 codes. 5266 INVALID_MIGRATION (0xC): A peer has migrated to a different network 5267 when the endpoint had disabled migration. 5269 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5270 of 256 values is reserved for carrying error codes specific to the 5271 cryptographic handshake that is used. Codes for errors occurring 5272 when TLS is used for the crypto handshake are described in 5273 Section 4.8 of [QUIC-TLS]. 5275 See Section 22.3 for details of registering new error codes. 5277 20.1. Application Protocol Error Codes 5279 Application protocol error codes are 16-bit unsigned integers, but 5280 the management of application error codes are left to application 5281 protocols. Application protocol error codes are used for the 5282 RESET_STREAM frame (Section 19.4) and the CONNECTION_CLOSE frame with 5283 a type of 0x1d (Section 19.19). 5285 21. Security Considerations 5287 21.1. Handshake Denial of Service 5289 As an encrypted and authenticated transport QUIC provides a range of 5290 protections against denial of service. Once the cryptographic 5291 handshake is complete, QUIC endpoints discard most packets that are 5292 not authenticated, greatly limiting the ability of an attacker to 5293 interfere with existing connections. 5295 Once a connection is established QUIC endpoints might accept some 5296 unauthenticated ICMP packets (see Section 14.2), but the use of these 5297 packets is extremely limited. The only other type of packet that an 5298 endpoint might accept is a stateless reset (Section 10.4) which 5299 relies on the token being kept secret until it is used. 5301 During the creation of a connection, QUIC only provides protection 5302 against attack from off the network path. All QUIC packets contain 5303 proof that the recipient saw a preceding packet from its peer. 5305 The first mechanism used is the source and destination connection 5306 IDs, which are required to match those set by a peer. Except for an 5307 Initial and stateless reset packets, an endpoint only accepts packets 5308 that include a destination connection that matches a connection ID 5309 the endpoint previously chose. This is the only protection offered 5310 for Version Negotiation packets. 5312 The destination connection ID in an Initial packet is selected by a 5313 client to be unpredictable, which serves an additional purpose. The 5314 packets that carry the cryptographic handshake are protected with a 5315 key that is derived from this connection ID and salt specific to the 5316 QUIC version. This allows endpoints to use the same process for 5317 authenticating packets that they receive as they use after the 5318 cryptographic handshake completes. Packets that cannot be 5319 authenticated are discarded. Protecting packets in this fashion 5320 provides a strong assurance that the sender of the packet saw the 5321 Initial packet and understood it. 5323 These protections are not intended to be effective against an 5324 attacker that is able to receive QUIC packets prior to the connection 5325 being established. Such an attacker can potentially send packets 5326 that will be accepted by QUIC endpoints. This version of QUIC 5327 attempts to detect this sort of attack, but it expects that endpoints 5328 will fail to establish a connection rather than recovering. For the 5329 most part, the cryptographic handshake protocol [QUIC-TLS] is 5330 responsible for detecting tampering during the handshake, though 5331 additional validation is required for version negotiation (see 5332 Section 7.3.3). 5334 Endpoints are permitted to use other methods to detect and attempt to 5335 recover from interference with the handshake. Invalid packets may be 5336 identified and discarded using other methods, but no specific method 5337 is mandated in this document. 5339 21.2. Amplification Attack 5341 An attacker might be able to receive an address validation token 5342 (Section 8) from a server and then release the IP address it used to 5343 acquire that token. At a later time, the attacker may initiate a 5344 0-RTT connection with a server by spoofing this same address, which 5345 might now address a different (victim) endpoint. The attacker can 5346 thus potentially cause the server to send an initial congestion 5347 window's worth of data towards the victim. 5349 Servers SHOULD provide mitigations for this attack by limiting the 5350 usage and lifetime of address validation tokens (see Section 8.1.2). 5352 21.3. Optimistic ACK Attack 5354 An endpoint that acknowledges packets it has not received might cause 5355 a congestion controller to permit sending at rates beyond what the 5356 network supports. An endpoint MAY skip packet numbers when sending 5357 packets to detect this behavior. An endpoint can then immediately 5358 close the connection with a connection error of type 5359 PROTOCOL_VIOLATION (see Section 10.3). 5361 21.4. Slowloris Attacks 5363 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 5364 connections to the target endpoint open and hold them open as long as 5365 possible. These attacks can be executed against a QUIC endpoint by 5366 generating the minimum amount of activity necessary to avoid being 5367 closed for inactivity. This might involve sending small amounts of 5368 data, gradually opening flow control windows in order to control the 5369 sender rate, or manufacturing ACK frames that simulate a high loss 5370 rate. 5372 QUIC deployments SHOULD provide mitigations for the Slowloris 5373 attacks, such as increasing the maximum number of clients the server 5374 will allow, limiting the number of connections a single IP address is 5375 allowed to make, imposing restrictions on the minimum transfer speed 5376 a connection is allowed to have, and restricting the length of time 5377 an endpoint is allowed to stay connected. 5379 21.5. Stream Fragmentation and Reassembly Attacks 5381 An adversarial sender might intentionally send fragments of stream 5382 data in order to cause disproportionate receive buffer memory 5383 commitment and/or creation of a large and inefficient data structure. 5385 An adversarial receiver might intentionally not acknowledge packets 5386 containing stream data in order to force the sender to store the 5387 unacknowledged stream data for retransmission. 5389 The attack on receivers is mitigated if flow control windows 5390 correspond to available memory. However, some receivers will over- 5391 commit memory and advertise flow control offsets in the aggregate 5392 that exceed actual available memory. The over-commitment strategy 5393 can lead to better performance when endpoints are well behaved, but 5394 renders endpoints vulnerable to the stream fragmentation attack. 5396 QUIC deployments SHOULD provide mitigations against stream 5397 fragmentation attacks. Mitigations could consist of avoiding over- 5398 committing memory, limiting the size of tracking data structures, 5399 delaying reassembly of STREAM frames, implementing heuristics based 5400 on the age and duration of reassembly holes, or some combination. 5402 21.6. Stream Commitment Attack 5404 An adversarial endpoint can open lots of streams, exhausting state on 5405 an endpoint. The adversarial endpoint could repeat the process on a 5406 large number of connections, in a manner similar to SYN flooding 5407 attacks in TCP. 5409 Normally, clients will open streams sequentially, as explained in 5410 Section 2.1. However, when several streams are initiated at short 5411 intervals, transmission error may cause STREAM DATA frames opening 5412 streams to be received out of sequence. A receiver is obligated to 5413 open intervening streams if a higher-numbered stream ID is received. 5414 Thus, on a new connection, opening stream 2000001 opens 1 million 5415 streams, as required by the specification. 5417 The number of active streams is limited by the concurrent stream 5418 limit transport parameter, as explained in Section 4.5. If chosen 5419 judiciously, this limit mitigates the effect of the stream commitment 5420 attack. However, setting the limit too low could affect performance 5421 when applications expect to open large number of streams. 5423 21.7. Explicit Congestion Notification Attacks 5425 An on-path attacker could manipulate the value of ECN codepoints in 5426 the IP header to influence the sender's rate. [RFC3168] discusses 5427 manipulations and their effects in more detail. 5429 An on-the-side attacker can duplicate and send packets with modified 5430 ECN codepoints to affect the sender's rate. If duplicate packets are 5431 discarded by a receiver, an off-path attacker will need to race the 5432 duplicate packet against the original to be successful in this 5433 attack. Therefore, QUIC receivers ignore ECN codepoints set in 5434 duplicate packets (see Section 13.3). 5436 21.8. Stateless Reset Oracle 5438 Stateless resets create a possible denial of service attack analogous 5439 to a TCP reset injection. This attack is possible if an attacker is 5440 able to cause a stateless reset token to be generated for a 5441 connection with a selected connection ID. An attacker that can cause 5442 this token to be generated can reset an active connection with the 5443 same connection ID. 5445 If a packet can be routed to different instances that share a static 5446 key, for example by changing an IP address or port, then an attacker 5447 can cause the server to send a stateless reset. To defend against 5448 this style of denial service, endpoints that share a static key for 5449 stateless reset (see Section 10.4.2) MUST be arranged so that packets 5450 with a given connection ID always arrive at an instance that has 5451 connection state, unless that connection is no longer active. 5453 In the case of a cluster that uses dynamic load balancing, it's 5454 possible that a change in load balancer configuration could happen 5455 while an active instance retains connection state; even if an 5456 instance retains connection state, the change in routing and 5457 resulting stateless reset will result in the connection being 5458 terminated. If there is no chance in the packet being routed to the 5459 correct instance, it is better to send a stateless reset than wait 5460 for connections to time out. However, this is acceptable only if the 5461 routing cannot be influenced by an attacker. 5463 22. IANA Considerations 5465 22.1. QUIC Transport Parameter Registry 5467 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 5468 under a "QUIC Protocol" heading. 5470 The "QUIC Transport Parameters" registry governs a 16-bit space. 5471 This space is split into two spaces that are governed by different 5472 policies. Values with the first byte in the range 0x00 to 0xfe (in 5473 hexadecimal) are assigned via the Specification Required policy 5474 [RFC8126]. Values with the first byte 0xff are reserved for Private 5475 Use [RFC8126]. 5477 Registrations MUST include the following fields: 5479 Value: The numeric value of the assignment (registrations will be 5480 between 0x0000 and 0xfeff). 5482 Parameter Name: A short mnemonic for the parameter. 5484 Specification: A reference to a publicly available specification for 5485 the value. 5487 The nominated expert(s) verify that a specification exists and is 5488 readily accessible. Expert(s) are encouraged to be biased towards 5489 approving registrations unless they are abusive, frivolous, or 5490 actively harmful (not merely aesthetically displeasing, or 5491 architecturally dubious). 5493 The initial contents of this registry are shown in Table 6. 5495 +--------+-------------------------------------+---------------+ 5496 | Value | Parameter Name | Specification | 5497 +--------+-------------------------------------+---------------+ 5498 | 0x0000 | original_connection_id | Section 18.1 | 5499 | | | | 5500 | 0x0001 | idle_timeout | Section 18.1 | 5501 | | | | 5502 | 0x0002 | stateless_reset_token | Section 18.1 | 5503 | | | | 5504 | 0x0003 | max_packet_size | Section 18.1 | 5505 | | | | 5506 | 0x0004 | initial_max_data | Section 18.1 | 5507 | | | | 5508 | 0x0005 | initial_max_stream_data_bidi_local | Section 18.1 | 5509 | | | | 5510 | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.1 | 5511 | | | | 5512 | 0x0007 | initial_max_stream_data_uni | Section 18.1 | 5513 | | | | 5514 | 0x0008 | initial_max_streams_bidi | Section 18.1 | 5515 | | | | 5516 | 0x0009 | initial_max_streams_uni | Section 18.1 | 5517 | | | | 5518 | 0x000a | ack_delay_exponent | Section 18.1 | 5519 | | | | 5520 | 0x000b | max_ack_delay | Section 18.1 | 5521 | | | | 5522 | 0x000c | disable_migration | Section 18.1 | 5523 | | | | 5524 | 0x000d | preferred_address | Section 18.1 | 5525 +--------+-------------------------------------+---------------+ 5527 Table 6: Initial QUIC Transport Parameters Entries 5529 22.2. QUIC Frame Type Registry 5531 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 5532 "QUIC Protocol" heading. 5534 The "QUIC Frame Types" registry governs a 62-bit space. This space 5535 is split into three spaces that are governed by different policies. 5536 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 5537 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 5538 to 0x3fff operate on the Specification Required policy [RFC8126]. 5539 All other values are assigned to Private Use [RFC8126]. 5541 Registrations MUST include the following fields: 5543 Value: The numeric value of the assignment (registrations will be 5544 between 0x00 and 0x3fff). A range of values MAY be assigned. 5546 Frame Name: A short mnemonic for the frame type. 5548 Specification: A reference to a publicly available specification for 5549 the value. 5551 The nominated expert(s) verify that a specification exists and is 5552 readily accessible. Specifications for new registrations need to 5553 describe the means by which an endpoint might determine that it can 5554 send the identified type of frame. An accompanying transport 5555 parameter registration (see Section 22.1) is expected for most 5556 registrations. The specification needs to describe the format and 5557 assigned semantics of any fields in the frame. 5559 Expert(s) are encouraged to be biased towards approving registrations 5560 unless they are abusive, frivolous, or actively harmful (not merely 5561 aesthetically displeasing, or architecturally dubious). 5563 The initial contents of this registry are tabulated in Table 3. 5565 22.3. QUIC Transport Error Codes Registry 5567 IANA [SHALL add/has added] a registry for "QUIC Transport Error 5568 Codes" under a "QUIC Protocol" heading. 5570 The "QUIC Transport Error Codes" registry governs a 16-bit space. 5571 This space is split into two spaces that are governed by different 5572 policies. Values with the first byte in the range 0x00 to 0xfe (in 5573 hexadecimal) are assigned via the Specification Required policy 5574 [RFC8126]. Values with the first byte 0xff are reserved for Private 5575 Use [RFC8126]. 5577 Registrations MUST include the following fields: 5579 Value: The numeric value of the assignment (registrations will be 5580 between 0x0000 and 0xfeff). 5582 Code: A short mnemonic for the parameter. 5584 Description: A brief description of the error code semantics, which 5585 MAY be a summary if a specification reference is provided. 5587 Specification: A reference to a publicly available specification for 5588 the value. 5590 The initial contents of this registry are shown in Table 7. Values 5591 from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. 5593 +------+---------------------------+----------------+---------------+ 5594 | Valu | Error | Description | Specification | 5595 | e | | | | 5596 +------+---------------------------+----------------+---------------+ 5597 | 0x0 | NO_ERROR | No error | Section 20 | 5598 | | | | | 5599 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 5600 | | | error | | 5601 | | | | | 5602 | 0x2 | SERVER_BUSY | Server | Section 20 | 5603 | | | currently busy | | 5604 | | | | | 5605 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 5606 | | | error | | 5607 | | | | | 5608 | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | 5609 | | | streams opened | | 5610 | | | | | 5611 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 5612 | | | in invalid | | 5613 | | | stream state | | 5614 | | | | | 5615 | 0x6 | FINAL_OFFSET_ERROR | Change to | Section 20 | 5616 | | | final stream | | 5617 | | | offset | | 5618 | | | | | 5619 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 5620 | | | error | | 5621 | | | | | 5622 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 5623 | | | transport | | 5624 | | | parameters | | 5625 | | | | | 5626 | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 20 | 5627 | | | negotiation | | 5628 | | | failure | | 5629 | | | | | 5630 | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | 5631 | | | protocol | | 5632 | | | violation | | 5633 | | | | | 5634 | 0xC | INVALID_MIGRATION | Violated | Section 20 | 5635 | | | disabled | | 5636 | | | migration | | 5637 +------+---------------------------+----------------+---------------+ 5639 Table 7: Initial QUIC Transport Error Codes Entries 5641 23. References 5643 23.1. Normative References 5645 [DPLPMTUD] 5646 Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, 5647 "Packetization Layer Path MTU Discovery for Datagram 5648 Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in 5649 progress), November 2018. 5651 [QUIC-RECOVERY] 5652 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5653 and Congestion Control", draft-ietf-quic-recovery-17 (work 5654 in progress), December 2018. 5656 [QUIC-TLS] 5657 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5658 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5659 tls-17 (work in progress), December 2018. 5661 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5662 DOI 10.17487/RFC1191, November 1990, 5663 . 5665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5666 Requirement Levels", BCP 14, RFC 2119, 5667 DOI 10.17487/RFC2119, March 1997, 5668 . 5670 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5671 of Explicit Congestion Notification (ECN) to IP", 5672 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5673 . 5675 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 5676 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 5677 2003, . 5679 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5680 "Randomness Requirements for Security", BCP 106, RFC 4086, 5681 DOI 10.17487/RFC4086, June 2005, 5682 . 5684 [RFC5119] Edwards, T., "A Uniform Resource Name (URN) Namespace for 5685 the Society of Motion Picture and Television Engineers 5686 (SMPTE)", RFC 5119, DOI 10.17487/RFC5119, February 2008, 5687 . 5689 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 5690 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 5691 March 2017, . 5693 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5694 Writing an IANA Considerations Section in RFCs", BCP 26, 5695 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5696 . 5698 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5699 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5700 May 2017, . 5702 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5703 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5704 DOI 10.17487/RFC8201, July 2017, 5705 . 5707 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 5708 Notification (ECN) Experimentation", RFC 8311, 5709 DOI 10.17487/RFC8311, January 2018, 5710 . 5712 [SPIN] Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 5713 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 5714 October 2018. 5716 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5717 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5718 . 5720 23.2. Informative References 5722 [EARLY-DESIGN] 5723 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 5724 December 2013, . 5726 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 5727 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 5728 DOI 10.17487/RFC7540, May 2015, 5729 . 5731 [QUIC-INVARIANTS] 5732 Thomson, M., "Version-Independent Properties of QUIC", 5733 draft-ietf-quic-invariants-03 (work in progress), December 5734 2018. 5736 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 5737 RFC 1812, DOI 10.17487/RFC1812, June 1995, 5738 . 5740 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 5741 Selective Acknowledgment Options", RFC 2018, 5742 DOI 10.17487/RFC2018, October 1996, 5743 . 5745 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5746 Hashing for Message Authentication", RFC 2104, 5747 DOI 10.17487/RFC2104, February 1997, 5748 . 5750 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 5751 RFC 2360, DOI 10.17487/RFC2360, June 1998, 5752 . 5754 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 5755 RFC 4303, DOI 10.17487/RFC4303, December 2005, 5756 . 5758 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 5759 Control Message Protocol (ICMPv6) for the Internet 5760 Protocol Version 6 (IPv6) Specification", STD 89, 5761 RFC 4443, DOI 10.17487/RFC4443, March 2006, 5762 . 5764 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 5765 Translation (NAT) Behavioral Requirements for Unicast 5766 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 5767 2007, . 5769 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5770 Key Derivation Function (HKDF)", RFC 5869, 5771 DOI 10.17487/RFC5869, May 2010, 5772 . 5774 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5775 "Transport Layer Security (TLS) Application-Layer Protocol 5776 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5777 July 2014, . 5779 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5780 (IPv6) Specification", STD 86, RFC 8200, 5781 DOI 10.17487/RFC8200, July 2017, 5782 . 5784 [SLOWLORIS] 5785 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 5786 . 5789 Appendix A. Sample Packet Number Decoding Algorithm 5791 The following pseudo-code shows how an implementation can decode 5792 packet numbers after header protection has been removed. 5794 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 5795 expected_pn = largest_pn + 1 5796 pn_win = 1 << pn_nbits 5797 pn_hwin = pn_win / 2 5798 pn_mask = pn_win - 1 5799 // The incoming packet number should be greater than 5800 // expected_pn - pn_hwin and less than or equal to 5801 // expected_pn + pn_hwin 5802 // 5803 // This means we can't just strip the trailing bits from 5804 // expected_pn and add the truncated_pn because that might 5805 // yield a value outside the window. 5806 // 5807 // The following code calculates a candidate value and 5808 // makes sure it's within the packet number window. 5809 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 5810 if candidate_pn <= expected_pn - pn_hwin: 5811 return candidate_pn + pn_win 5812 // Note the extra check for underflow when candidate_pn 5813 // is near zero. 5814 if candidate_pn > expected_pn + pn_hwin and 5815 candidate_pn > pn_win: 5816 return candidate_pn - pn_win 5817 return candidate_pn 5819 Appendix B. Change Log 5821 *RFC Editor's Note:* Please remove this section prior to 5822 publication of a final version of this document. 5824 Issue and pull request numbers are listed with a leading octothorp. 5826 B.1. Since draft-ietf-quic-transport-16 5828 o Stream limits are defined as counts, not maximums (#1850, #1906) 5830 o Require amplification attack defense after closing (#1905, #1911) 5831 o Remove reservation of application error code 0 for STOPPING 5832 (#1804, #1922) 5834 o Renumbered frames (#1945) 5836 o Renumbered transport parameters (#1946) 5838 o Numeric transport parameters are expressed as varints (#1608, 5839 #1947, #1955) 5841 o Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 5843 o Rework the first byte (#2006) 5845 * Fix the 0x40 bit 5847 * Change type values for long header 5849 * Add spin bit to short header (#631, #1988) 5851 * Encrypt the remainder of the first byte (#1322) 5853 * Move packet number length to first byte 5855 * Simplify packet number protection (#1575) 5857 o Allow STOP_SENDING to open a remote bidirectional stream (#1797, 5858 #2013) 5860 o Added mitigation for off-path migration attacks (#1278, #1749, 5861 #2033) 5863 o Don't let the PMTU to drop below 1280 (#2063, #2069) 5865 o Require peers to replace retired connection IDs (#2085) 5867 o Servers are required to ignore Version Negotiation packets (#2088) 5869 o Tokens are repeated in all Initial packets (#2089) 5871 o Clarified how PING frames are sent after loss (#2094) 5873 o Initial keys are discarded once Handshake are avaialble (#1951, 5874 #2045) 5876 o ICMP PTB validation clarifications (#2161, #2109, #2108) 5878 B.2. Since draft-ietf-quic-transport-15 5880 Substantial editorial reorganization; no technical changes. 5882 B.3. Since draft-ietf-quic-transport-14 5884 o Merge ACK and ACK_ECN (#1778, #1801) 5886 o Explicitly communicate max_ack_delay (#981, #1781) 5888 o Validate original connection ID after Retry packets (#1710, #1486, 5889 #1793) 5891 o Idle timeout is optional and has no specified maximum (#1765) 5893 o Update connection ID handling; add RETIRE_CONNECTION_ID type 5894 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 5895 #1821) 5897 o Include a Token in all Initial packets (#1649, #1794) 5899 o Prevent handshake deadlock (#1764, #1824) 5901 B.4. Since draft-ietf-quic-transport-13 5903 o Streams open when higher-numbered streams of the same type open 5904 (#1342, #1549) 5906 o Split initial stream flow control limit into 3 transport 5907 parameters (#1016, #1542) 5909 o All flow control transport parameters are optional (#1610) 5911 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 5913 o Permit stateless reset in response to any packet (#1348, #1553) 5915 o Recommended defense against stateless reset spoofing (#1386, 5916 #1554) 5918 o Prevent infinite stateless reset exchanges (#1443, #1627) 5920 o Forbid processing of the same packet number twice (#1405, #1624) 5922 o Added a packet number decoding example (#1493) 5924 o More precisely define idle timeout (#1429, #1614, #1652) 5925 o Corrected format of Retry packet and prevented looping (#1492, 5926 #1451, #1448, #1498) 5928 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 5929 #1514, #1621) 5931 o Permit Retry in response to 0-RTT (#1547, #1552) 5933 o Looser verification of ECN counters to account for ACK loss 5934 (#1555, #1481, #1565) 5936 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 5938 B.5. Since draft-ietf-quic-transport-12 5940 o Changes to integration of the TLS handshake (#829, #1018, #1094, 5941 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 5943 * The cryptographic handshake uses CRYPTO frames, not stream 0 5945 * QUIC packet protection is used in place of TLS record 5946 protection 5948 * Separate QUIC packet number spaces are used for the handshake 5950 * Changed Retry to be independent of the cryptographic handshake 5952 * Added NEW_TOKEN frame and Token fields to Initial packet 5954 * Limit the use of HelloRetryRequest to address TLS needs (like 5955 key shares) 5957 o Enable server to transition connections to a preferred address 5958 (#560, #1251, #1373) 5960 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 5961 (#804, #805, #1372) 5963 o Changed rules and recommendations for use of new connection IDs 5964 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 5966 o Added a transport parameter to disable intentional connection 5967 migration (#1271, #1447) 5969 o Packets from different connection ID can't be coalesced (#1287, 5970 #1423) 5972 o Fixed sampling method for packet number encryption; the length 5973 field in long headers includes the packet number field in addition 5974 to the packet payload (#1387, #1389) 5976 o Stateless Reset is now symmetric and subject to size constraints 5977 (#466, #1346) 5979 o Added frame type extension mechanism (#58, #1473) 5981 B.6. Since draft-ietf-quic-transport-11 5983 o Enable server to transition connections to a preferred address 5984 (#560, #1251) 5986 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 5987 #990, #734, #1317, #1267, #1079) 5989 o Packet numbers use a variable-length encoding (#989, #1334) 5991 o STREAM frames can now be empty (#1350) 5993 B.7. Since draft-ietf-quic-transport-10 5995 o Swap payload length and packed number fields in long header 5996 (#1294) 5998 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 5999 (#1274) 6001 o Spin bit reserved (#1283) 6003 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 6005 o A more complete connection migration (#1249) 6007 o Refine opportunistic ACK defense text (#305, #1030, #1185) 6009 o A Stateless Reset Token isn't mandatory (#818, #1191) 6011 o Removed implicit stream opening (#896, #1193) 6013 o An empty STREAM frame can be used to open a stream without sending 6014 data (#901, #1194) 6016 o Define stream counts in transport parameters rather than a maximum 6017 stream ID (#1023, #1065) 6019 o STOP_SENDING is now prohibited before streams are used (#1050) 6020 o Recommend including ACK in Retry packets and allow PADDING (#1067, 6021 #882) 6023 o Endpoints now become closing after an idle timeout (#1178, #1179) 6025 o Remove implication that Version Negotiation is sent when a packet 6026 of the wrong version is received (#1197) 6028 B.8. Since draft-ietf-quic-transport-09 6030 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 6031 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 6032 (#1091, #725, #1086) 6034 o A server can now only send 3 packets without validating the client 6035 address (#38, #1090) 6037 o Delivery order of stream data is no longer strongly specified 6038 (#252, #1070) 6040 o Rework of packet handling and version negotiation (#1038) 6042 o Stream 0 is now exempt from flow control until the handshake 6043 completes (#1074, #725, #825, #1082) 6045 o Improved retransmission rules for all frame types: information is 6046 retransmitted, not packets or frames (#463, #765, #1095, #1053) 6048 o Added an error code for server busy signals (#1137) 6050 o Endpoints now set the connection ID that their peer uses. 6051 Connection IDs are variable length. Removed the 6052 omit_connection_id transport parameter and the corresponding short 6053 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 6055 B.9. Since draft-ietf-quic-transport-08 6057 o Clarified requirements for BLOCKED usage (#65, #924) 6059 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 6060 #928) 6062 o GAP limitation in ACK Frame (#613) 6064 o Improved PMTUD description (#614, #1036) 6066 o Clarified stream state machine (#634, #662, #743, #894) 6067 o Reserved versions don't need to be generated deterministically 6068 (#831, #931) 6070 o You don't always need the draining period (#871) 6072 o Stateless reset clarified as version-specific (#930, #986) 6074 o initial_max_stream_id_x transport parameters are optional (#970, 6075 #971) 6077 o Ack Delay assumes a default value during the handshake (#1007, 6078 #1009) 6080 o Removed transport parameters from NewSessionTicket (#1015) 6082 B.10. Since draft-ietf-quic-transport-07 6084 o The long header now has version before packet number (#926, #939) 6086 o Rename and consolidate packet types (#846, #822, #847) 6088 o Packet types are assigned new codepoints and the Connection ID 6089 Flag is inverted (#426, #956) 6091 o Removed type for Version Negotiation and use Version 0 (#963, 6092 #968) 6094 o Streams are split into unidirectional and bidirectional (#643, 6095 #656, #720, #872, #175, #885) 6097 * Stream limits now have separate uni- and bi-directional 6098 transport parameters (#909, #958) 6100 * Stream limit transport parameters are now optional and default 6101 to 0 (#970, #971) 6103 o The stream state machine has been split into read and write (#634, 6104 #894) 6106 o Employ variable-length integer encodings throughout (#595) 6108 o Improvements to connection close 6110 * Added distinct closing and draining states (#899, #871) 6112 * Draining period can terminate early (#869, #870) 6114 * Clarifications about stateless reset (#889, #890) 6116 o Address validation for connection migration (#161, #732, #878) 6118 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 6120 o negotiated_version is sent in server transport parameters (#710, 6121 #959) 6123 o Increased the range over which packet numbers are randomized 6124 (#864, #850, #964) 6126 B.11. Since draft-ietf-quic-transport-06 6128 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 6130 o Split error code space between application and transport (#485) 6132 o Stateless reset token moved to end (#820) 6134 o 1-RTT-protected long header types removed (#848) 6136 o No acknowledgments during draining period (#852) 6138 o Remove "application close" as a separate close type (#854) 6140 o Remove timestamps from the ACK frame (#841) 6142 o Require transport parameters to only appear once (#792) 6144 B.12. Since draft-ietf-quic-transport-05 6146 o Stateless token is server-only (#726) 6148 o Refactor section on connection termination (#733, #748, #328, 6149 #177) 6151 o Limit size of Version Negotiation packet (#585) 6153 o Clarify when and what to ack (#736) 6155 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 6157 o Clarify Keep-alive requirements (#729) 6159 B.13. Since draft-ietf-quic-transport-04 6161 o Introduce STOP_SENDING frame, RESET_STREAM only resets in one 6162 direction (#165) 6164 o Removed GOAWAY; application protocols are responsible for graceful 6165 shutdown (#696) 6167 o Reduced the number of error codes (#96, #177, #184, #211) 6169 o Version validation fields can't move or change (#121) 6171 o Removed versions from the transport parameters in a 6172 NewSessionTicket message (#547) 6174 o Clarify the meaning of "bytes in flight" (#550) 6176 o Public reset is now stateless reset and not visible to the path 6177 (#215) 6179 o Reordered bits and fields in STREAM frame (#620) 6181 o Clarifications to the stream state machine (#572, #571) 6183 o Increased the maximum length of the Largest Acknowledged field in 6184 ACK frames to 64 bits (#629) 6186 o truncate_connection_id is renamed to omit_connection_id (#659) 6188 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 6189 #328) 6191 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 6193 B.14. Since draft-ietf-quic-transport-03 6195 o Change STREAM and RESET_STREAM layout 6197 o Add MAX_STREAM_ID settings 6199 B.15. Since draft-ietf-quic-transport-02 6201 o The size of the initial packet payload has a fixed minimum (#267, 6202 #472) 6204 o Define when Version Negotiation packets are ignored (#284, #294, 6205 #241, #143, #474) 6207 o The 64-bit FNV-1a algorithm is used for integrity protection of 6208 unprotected packets (#167, #480, #481, #517) 6210 o Rework initial packet types to change how the connection ID is 6211 chosen (#482, #442, #493) 6213 o No timestamps are forbidden in unprotected packets (#542, #429) 6215 o Cryptographic handshake is now on stream 0 (#456) 6217 o Remove congestion control exemption for cryptographic handshake 6218 (#248, #476) 6220 o Version 1 of QUIC uses TLS; a new version is needed to use a 6221 different handshake protocol (#516) 6223 o STREAM frames have a reduced number of offset lengths (#543, #430) 6225 o Split some frames into separate connection- and stream- level 6226 frames (#443) 6228 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 6230 * BLOCKED split to match WINDOW_UPDATE split (#454) 6232 * Define STREAM_ID_NEEDED frame (#455) 6234 o A NEW_CONNECTION_ID frame supports connection migration without 6235 linkability (#232, #491, #496) 6237 o Transport parameters for 0-RTT are retained from a previous 6238 connection (#405, #513, #512) 6240 * A client in 0-RTT no longer required to reset excess streams 6241 (#425, #479) 6243 o Expanded security considerations (#440, #444, #445, #448) 6245 B.16. Since draft-ietf-quic-transport-01 6247 o Defined short and long packet headers (#40, #148, #361) 6249 o Defined a versioning scheme and stable fields (#51, #361) 6251 o Define reserved version values for "greasing" negotiation (#112, 6252 #278) 6254 o The initial packet number is randomized (#35, #283) 6256 o Narrow the packet number encoding range requirement (#67, #286, 6257 #299, #323, #356) 6259 o Defined client address validation (#52, #118, #120, #275) 6260 o Define transport parameters as a TLS extension (#49, #122) 6262 o SCUP and COPT parameters are no longer valid (#116, #117) 6264 o Transport parameters for 0-RTT are either remembered from before, 6265 or assume default values (#126) 6267 o The server chooses connection IDs in its final flight (#119, #349, 6268 #361) 6270 o The server echoes the Connection ID and packet number fields when 6271 sending a Version Negotiation packet (#133, #295, #244) 6273 o Defined a minimum packet size for the initial handshake packet 6274 from the client (#69, #136, #139, #164) 6276 o Path MTU Discovery (#64, #106) 6278 o The initial handshake packet from the client needs to fit in a 6279 single packet (#338) 6281 o Forbid acknowledgment of packets containing only ACK and PADDING 6282 (#291) 6284 o Require that frames are processed when packets are acknowledged 6285 (#381, #341) 6287 o Removed the STOP_WAITING frame (#66) 6289 o Don't require retransmission of old timestamps for lost ACK frames 6290 (#308) 6292 o Clarified that frames are not retransmitted, but the information 6293 in them can be (#157, #298) 6295 o Error handling definitions (#335) 6297 o Split error codes into four sections (#74) 6299 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 6300 (#289) 6302 o Define packet protection rules (#336) 6304 o Require that stream be entirely delivered or reset, including 6305 acknowledgment of all STREAM frames or the RESET_STREAM, before it 6306 closes (#381) 6308 o Remove stream reservation from state machine (#174, #280) 6310 o Only stream 1 does not contribute to connection-level flow control 6311 (#204) 6313 o Stream 1 counts towards the maximum concurrent stream limit (#201, 6314 #282) 6316 o Remove connection-level flow control exclusion for some streams 6317 (except 1) (#246) 6319 o RESET_STREAM affects connection-level flow control (#162, #163) 6321 o Flow control accounting uses the maximum data offset on each 6322 stream, rather than bytes received (#378) 6324 o Moved length-determining fields to the start of STREAM and ACK 6325 (#168, #277) 6327 o Added the ability to pad between frames (#158, #276) 6329 o Remove error code and reason phrase from GOAWAY (#352, #355) 6331 o GOAWAY includes a final stream number for both directions (#347) 6333 o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 6334 consistent offset (#249) 6336 o Defined priority as the responsibility of the application protocol 6337 (#104, #303) 6339 B.17. Since draft-ietf-quic-transport-00 6341 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 6343 o Defined versioning 6345 o Reworked description of packet and frame layout 6347 o Error code space is divided into regions for each component 6349 o Use big endian for all numeric values 6351 B.18. Since draft-hamilton-quic-transport-protocol-01 6353 o Adopted as base for draft-ietf-quic-tls 6355 o Updated authors/editors list 6356 o Added IANA Considerations section 6358 o Moved Contributors and Acknowledgments to appendices 6360 Acknowledgments 6362 Special thanks are due to the following for helping shape pre-IETF 6363 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 6364 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 6366 This document has benefited immensely from various private 6367 discussions and public ones on the quic@ietf.org and proto- 6368 quic@chromium.org mailing lists. Our thanks to all. 6370 Contributors 6372 The original authors of this specification were Ryan Hamilton, Jana 6373 Iyengar, Ian Swett, and Alyssa Wilk. 6375 The original design and rationale behind this protocol draw 6376 significantly from work by Jim Roskind [EARLY-DESIGN]. In 6377 alphabetical order, the contributors to the pre-IETF QUIC project at 6378 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 6379 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 6380 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 6381 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 6382 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 6384 Authors' Addresses 6386 Jana Iyengar (editor) 6387 Fastly 6389 Email: jri.ietf@gmail.com 6391 Martin Thomson (editor) 6392 Mozilla 6394 Email: martin.thomson@gmail.com