idnits 2.17.1 draft-ietf-quic-transport-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 11, 2019) is 1867 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 1724 == Missing Reference: 'CH' is mentioned on line 1720, but not defined == Missing Reference: 'SH' is mentioned on line 1722, but not defined == Missing Reference: 'EE' is mentioned on line 1723, but not defined == Missing Reference: 'CERT' is mentioned on line 1723, but not defined == Missing Reference: 'CV' is mentioned on line 1723, but not defined == Missing Reference: 'FIN' is mentioned on line 1723, but not defined -- Looks like a reference, but probably isn't: '1' on line 1722 -- Looks like a reference, but probably isn't: '4' on line 4400 -- Looks like a reference, but probably isn't: '16' on line 4405 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-19 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-19 ** 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: 1 error (**), 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: September 12, 2019 Mozilla 6 March 11, 2019 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-19 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 and the use of TLS for key negotiation. 17 Note to Readers 19 Discussion of this draft takes place on the QUIC working group 20 mailing list (quic@ietf.org), which is archived at 21 . 23 Working Group information can be found at ; source code and issues list for this draft can be found at 25 . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 63 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 64 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 65 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 67 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 68 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10 69 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 11 71 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 13 72 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 73 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16 74 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 75 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 77 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 78 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 79 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 80 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 81 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 83 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 84 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 85 5.2. Matching Packets to Connections . . . . . . . . . . . . . 26 86 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26 87 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27 88 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27 89 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28 90 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 91 6.2. Handling Version Negotiation Packets . . . . . . . . . . 28 92 6.2.1. Version Negotiation Between Draft Versions . . . . . 29 93 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 94 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 29 95 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31 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 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 35 101 8.1. Address Validation During Connection Establishment . . . 35 102 8.1.1. Address Validation using Retry Packets . . . . . . . 36 103 8.1.2. Address Validation for Future Connections . . . . . . 37 104 8.1.3. Address Validation Token Integrity . . . . . . . . . 39 105 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 39 106 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 40 107 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 40 108 8.5. Successful Path Validation . . . . . . . . . . . . . . . 41 109 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 41 110 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 42 111 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 43 112 9.2. Initiating Connection Migration . . . . . . . . . . . . . 43 113 9.3. Responding to Connection Migration . . . . . . . . . . . 44 114 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 44 115 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 45 116 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 45 117 9.4. Loss Detection and Congestion Control . . . . . . . . . . 46 118 9.5. Privacy Implications of Connection Migration . . . . . . 47 119 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 48 120 9.6.1. Communicating A Preferred Address . . . . . . . . . . 48 121 9.6.2. Responding to Connection Migration . . . . . . . . . 49 122 9.6.3. Interaction of Client Migration and Preferred Address 49 123 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 50 124 10. Connection Termination . . . . . . . . . . . . . . . . . . . 50 125 10.1. Closing and Draining Connection States . . . . . . . . . 50 126 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 52 127 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 52 128 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 53 129 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 56 130 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 56 131 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 57 132 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 58 133 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 58 134 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 59 135 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 59 136 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 59 137 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 60 138 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 61 139 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 62 140 13. Packetization and Reliability . . . . . . . . . . . . . . . . 65 141 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 65 142 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 66 143 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 67 144 13.2. Retransmission of Information . . . . . . . . . . . . . 67 145 13.3. Explicit Congestion Notification . . . . . . . . . . . . 69 146 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 70 147 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 70 148 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 72 149 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 73 150 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 73 151 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 74 152 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 75 153 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 76 154 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 77 155 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 77 156 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 78 157 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 80 158 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 82 159 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 84 160 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 85 161 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 86 162 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 89 163 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 90 164 18.1. Transport Parameter Definitions . . . . . . . . . . . . 91 165 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 94 166 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 94 167 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 95 168 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 95 169 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 97 170 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 98 171 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 99 172 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 100 173 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 100 174 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 101 175 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 102 176 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 103 177 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 104 178 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 105 179 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 106 180 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 106 181 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 107 182 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 107 183 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 109 184 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 110 185 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 110 186 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 110 187 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 111 188 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 112 189 20.1. Application Protocol Error Codes . . . . . . . . . . . . 113 190 21. Security Considerations . . . . . . . . . . . . . . . . . . . 113 191 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 113 192 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 114 193 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 115 194 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 115 195 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 115 196 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 116 197 21.7. Explicit Congestion Notification Attacks . . . . . . . . 116 198 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 116 199 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 117 200 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 201 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 117 202 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 119 203 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 119 204 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 205 23.1. Normative References . . . . . . . . . . . . . . . . . . 122 206 23.2. Informative References . . . . . . . . . . . . . . . . . 123 207 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 125 208 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 125 209 B.1. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 126 210 B.2. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 126 211 B.3. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 127 212 B.4. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 128 213 B.5. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 128 214 B.6. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 128 215 B.7. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 129 216 B.8. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 130 217 B.9. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 130 218 B.10. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 131 219 B.11. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 132 220 B.12. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 132 221 B.13. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 133 222 B.14. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 134 223 B.15. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 134 224 B.16. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 135 225 B.17. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 135 226 B.18. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 136 227 B.19. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 138 228 B.20. Since draft-hamilton-quic-transport-protocol-01 . . . . . 138 229 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 138 230 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 138 231 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139 233 1. Introduction 235 QUIC is a multiplexed and secure general-purpose transport protocol 236 that provides: 238 o Stream multiplexing 240 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, 287 * Section 13 defines models for the transmission, retransmission, 288 and acknowledgement of data, and 290 * Section 14 specifies rules for managing the size of packets. 292 o Finally, encoding details of QUIC protocol elements are described 293 in: 295 * Section 15 (Versions), 297 * Section 16 (Integer Encoding), 299 * Section 17 (Packet Headers), 301 * Section 18 (Transport Parameters), 303 * Section 19 (Frames), and 305 * Section 20 (Errors). 307 Accompanying documents describe QUIC's loss detection and congestion 308 control [QUIC-RECOVERY], and the use of TLS for key negotiation 309 [QUIC-TLS]. 311 This document defines QUIC version 1, which conforms to the protocol 312 invariants in [QUIC-INVARIANTS]. 314 1.2. Terms and Definitions 316 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 317 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 318 "OPTIONAL" in this document are to be interpreted as described in BCP 319 14 [RFC2119] [RFC8174] when, and only when, they appear in all 320 capitals, as shown here. 322 Commonly used terms in the document are described below. 324 QUIC: The transport protocol described by this document. QUIC is a 325 name, not an acronym. 327 QUIC packet: The smallest unit of QUIC that can be encapsulated in a 328 UDP datagram. Multiple QUIC packets can be encapsulated in a 329 single UDP datagram. 331 Endpoint: An entity that can participate in a QUIC connection by 332 generating, receiving, and processing QUIC packets. There are 333 only two types of endpoint in QUIC: client and server. 335 Client: The endpoint initiating a QUIC connection. 337 Server: The endpoint accepting incoming QUIC connections. 339 Connection ID: An opaque identifier that is used to identify a QUIC 340 connection at an endpoint. Each endpoint sets a value for its 341 peer to include in packets sent towards the endpoint. 343 Stream: A unidirectional or bidirectional channel of ordered bytes 344 within a QUIC connection. A QUIC connection can carry multiple 345 simultaneous streams. 347 Application: An entity that uses QUIC to send and receive data. 349 1.3. Notational Conventions 351 Packet and frame diagrams in this document use the format described 352 in Section 3.1 of [RFC2360], with the following additional 353 conventions: 355 [x]: Indicates that x is optional 357 x (A): Indicates that x is A bits long 359 x (A/B/C) ...: Indicates that x is one of A, B, or C bits long 361 x (i) ...: Indicates that x uses the variable-length encoding in 362 Section 16 364 x (*) ...: Indicates that x is variable-length 366 2. Streams 368 Streams in QUIC provide a lightweight, ordered byte-stream 369 abstraction to an application. An alternative view of QUIC streams 370 is as an elastic "message" abstraction. 372 Streams can be created by sending data. Other processes associated 373 with stream management - ending, cancelling, and managing flow 374 control - are all designed to impose minimal overheads. For 375 instance, a single STREAM frame (Section 19.8) can open, carry data 376 for, and close a stream. Streams can also be long-lived and can last 377 the entire duration of a connection. 379 Streams can be created by either endpoint, can concurrently send data 380 interleaved with other streams, and can be cancelled. QUIC does not 381 provide any means of ensuring ordering between bytes on different 382 streams. 384 QUIC allows for an arbitrary number of streams to operate 385 concurrently and for an arbitrary amount of data to be sent on any 386 stream, subject to flow control constraints (see Section 4) and 387 stream limits. 389 2.1. Stream Types and Identifiers 391 Streams can be unidirectional or bidirectional. Unidirectional 392 streams carry data in one direction: from the initiator of the stream 393 to its peer. Bidirectional streams allow for data to be sent in both 394 directions. 396 Streams are identified within a connection by a numeric value, 397 referred to as the stream ID. Stream IDs are unique to a stream. A 398 QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream 399 IDs are encoded as variable-length integers (see Section 16). 401 The least significant bit (0x1) of the stream ID identifies the 402 initiator of the stream. Client-initiated streams have even-numbered 403 stream IDs (with the bit set to 0), and server-initiated streams have 404 odd-numbered stream IDs (with the bit set to 1). 406 The second least significant bit (0x2) of the stream ID distinguishes 407 between bidirectional streams (with the bit set to 0) and 408 unidirectional streams (with the bit set to 1). 410 The least significant two bits from a stream ID therefore identify a 411 stream as one of four types, as summarized in Table 1. 413 +------+----------------------------------+ 414 | Bits | Stream Type | 415 +------+----------------------------------+ 416 | 0x0 | Client-Initiated, Bidirectional | 417 | | | 418 | 0x1 | Server-Initiated, Bidirectional | 419 | | | 420 | 0x2 | Client-Initiated, Unidirectional | 421 | | | 422 | 0x3 | Server-Initiated, Unidirectional | 423 +------+----------------------------------+ 425 Table 1: Stream ID Types 427 Within each type, streams are created with numerically increasing 428 stream IDs. A stream ID that is used out of order results in all 429 streams of that type with lower-numbered stream IDs also being 430 opened. 432 The first bidirectional stream opened by the client has a stream ID 433 of 0. 435 2.2. Sending and Receiving Data 437 STREAM frames (Section 19.8) encapsulate data sent by an application. 438 An endpoint uses the Stream ID and Offset fields in STREAM frames to 439 place data in order. 441 Endpoints MUST be able to deliver stream data to an application as an 442 ordered byte-stream. Delivering an ordered byte-stream requires that 443 an endpoint buffer any data that is received out of order, up to the 444 advertised flow control limit. 446 QUIC makes no specific allowances for delivery of stream data out of 447 order. However, implementations MAY choose to offer the ability to 448 deliver data out of order to a receiving application. 450 An endpoint could receive data for a stream at the same stream offset 451 multiple times. Data that has already been received can be 452 discarded. The data at a given offset MUST NOT change if it is sent 453 multiple times; an endpoint MAY treat receipt of different data at 454 the same offset within a stream as a connection error of type 455 PROTOCOL_VIOLATION. 457 Streams are an ordered byte-stream abstraction with no other 458 structure that is visible to QUIC. STREAM frame boundaries are not 459 expected to be preserved when data is transmitted, when data is 460 retransmitted after packet loss, or when data is delivered to the 461 application at a receiver. 463 An endpoint MUST NOT send data on any stream without ensuring that it 464 is within the flow control limits set by its peer. Flow control is 465 described in detail in Section 4. 467 2.3. Stream Prioritization 469 Stream multiplexing can have a significant effect on application 470 performance if resources allocated to streams are correctly 471 prioritized. 473 QUIC does not provide frames for exchanging prioritization 474 information. Instead it relies on receiving priority information 475 from the application that uses QUIC. 477 A QUIC implementation SHOULD provide ways in which an application can 478 indicate the relative priority of streams. When deciding which 479 streams to dedicate resources to, the implementation SHOULD use the 480 information provided by the application. 482 3. Stream States 484 This section describes streams in terms of their send or receive 485 components. Two state machines are described: one for the streams on 486 which an endpoint transmits data (Section 3.1), and another for 487 streams on which an endpoint receives data (Section 3.2). 489 Unidirectional streams use the applicable state machine directly. 490 Bidirectional streams use both state machines. For the most part, 491 the use of these state machines is the same whether the stream is 492 unidirectional or bidirectional. The conditions for opening a stream 493 are slightly more complex for a bidirectional stream because the 494 opening of either send or receive sides causes the stream to open in 495 both directions. 497 An endpoint MUST open streams of the same type in increasing order of 498 stream ID. 500 Note: These states are largely informative. This document uses 501 stream states to describe rules for when and how different types 502 of frames can be sent and the reactions that are expected when 503 different types of frames are received. Though these state 504 machines are intended to be useful in implementing QUIC, these 505 states aren't intended to constrain implementations. An 506 implementation can define a different state machine as long as its 507 behavior is consistent with an implementation that implements 508 these states. 510 3.1. Sending Stream States 512 Figure 1 shows the states for the part of a stream that sends data to 513 a peer. 515 o 516 | Create Stream (Sending) 517 | Peer Creates Bidirectional Stream 518 v 519 +-------+ 520 | Ready | Send RESET_STREAM 521 | |-----------------------. 522 +-------+ | 523 | | 524 | Send STREAM / | 525 | STREAM_DATA_BLOCKED | 526 | | 527 | Peer Creates | 528 | Bidirectional Stream | 529 v | 530 +-------+ | 531 | Send | Send RESET_STREAM | 532 | |---------------------->| 533 +-------+ | 534 | | 535 | Send STREAM + FIN | 536 v v 537 +-------+ +-------+ 538 | Data | Send RESET_STREAM | Reset | 539 | Sent |------------------>| Sent | 540 +-------+ +-------+ 541 | | 542 | Recv All ACKs | Recv ACK 543 v v 544 +-------+ +-------+ 545 | Data | | Reset | 546 | Recvd | | Recvd | 547 +-------+ +-------+ 549 Figure 1: States for Sending Parts of Streams 551 The sending part of stream that the endpoint initiates (types 0 and 2 552 for clients, 1 and 3 for servers) is opened by the application. The 553 "Ready" state represents a newly created stream that is able to 554 accept data from the application. Stream data might be buffered in 555 this state in preparation for sending. 557 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a 558 sending part of a stream to enter the "Send" state. An 559 implementation might choose to defer allocating a stream ID to a 560 stream until it sends the first frame and enters this state, which 561 can allow for better stream prioritization. 563 The sending part of a bidirectional stream initiated by a peer (type 564 0 for a server, type 1 for a client) enters the "Ready" state then 565 immediately transitions to the "Send" state if the receiving part 566 enters the "Recv" state (Section 3.2). 568 In the "Send" state, an endpoint transmits - and retransmits as 569 necessary - stream data in STREAM frames. The endpoint respects the 570 flow control limits set by its peer, and continues to accept and 571 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 572 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 573 stream or connection flow control limits Section 4.1. 575 After the application indicates that all stream data has been sent 576 and a STREAM frame containing the FIN bit is sent, the sending part 577 of the stream enters the "Data Sent" state. From this state, the 578 endpoint only retransmits stream data as necessary. The endpoint 579 does not need to check flow control limits or send 580 STREAM_DATA_BLOCKED frames for a stream in this state. 581 MAX_STREAM_DATA frames might be received until the peer receives the 582 final stream offset. The endpoint can safely ignore any 583 MAX_STREAM_DATA frames it receives from its peer for a stream in this 584 state. 586 Once all stream data has been successfully acknowledged, the sending 587 part of the stream enters the "Data Recvd" state, which is a terminal 588 state. 590 From any of the "Ready", "Send", or "Data Sent" states, an 591 application can signal that it wishes to abandon transmission of 592 stream data. Alternatively, an endpoint might receive a STOP_SENDING 593 frame from its peer. In either case, the endpoint sends a 594 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 595 state. 597 An endpoint MAY send a RESET_STREAM as the first frame that mentions 598 a stream; this causes the sending part of that stream to open and 599 then immediately transition to the "Reset Sent" state. 601 Once a packet containing a RESET_STREAM has been acknowledged, the 602 sending part of the stream enters the "Reset Recvd" state, which is a 603 terminal state. 605 3.2. Receiving Stream States 607 Figure 2 shows the states for the part of a stream that receives data 608 from a peer. The states for a receiving part of a stream mirror only 609 some of the states of the sending part of the stream at the peer. 610 The receiving part of a stream does not track states on the sending 611 part that cannot be observed, such as the "Ready" state. Instead, 612 the receiving part of a stream tracks the delivery of data to the 613 application, some of which cannot be observed by the sender. 615 o 616 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 617 | Create Bidirectional Stream (Sending) 618 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 619 | Create Higher-Numbered Stream 620 v 621 +-------+ 622 | Recv | Recv RESET_STREAM 623 | |-----------------------. 624 +-------+ | 625 | | 626 | Recv STREAM + FIN | 627 v | 628 +-------+ | 629 | Size | Recv RESET_STREAM | 630 | Known |---------------------->| 631 +-------+ | 632 | | 633 | Recv All Data | 634 v v 635 +-------+ Recv RESET_STREAM +-------+ 636 | Data |--- (optional) --->| Reset | 637 | Recvd | Recv All Data | Recvd | 638 +-------+<-- (optional) ----+-------+ 639 | | 640 | App Read All Data | App Read RST 641 v v 642 +-------+ +-------+ 643 | Data | | Reset | 644 | Read | | Read | 645 +-------+ +-------+ 647 Figure 2: States for Receiving Parts of Streams 649 The receiving part of a stream initiated by a peer (types 1 and 3 for 650 a client, or 0 and 2 for a server) is created when the first STREAM, 651 STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. 652 For bidirectional streams initiated by a peer, receipt of a 653 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 654 stream also creates the receiving part. The initial state for the 655 receiving part of stream is "Recv". 657 The receiving part of a stream enters the "Recv" state when the 658 sending part of a bidirectional stream initiated by the endpoint 659 (type 0 for a client, type 1 for a server) enters the "Ready" state. 661 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 662 STOP_SENDING frame is received from the peer for that stream. 663 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 664 that the remote peer has opened the stream and is providing flow 665 control credit. Receiving a STOP_SENDING frame for an unopened 666 stream indicates that the remote peer no longer wishes to receive 667 data on this stream. Either frame might arrive before a STREAM or 668 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 670 Before creating a stream, all streams of the same type with lower- 671 numbered stream IDs MUST be created. This ensures that the creation 672 order for streams is consistent on both endpoints. 674 In the "Recv" state, the endpoint receives STREAM and 675 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 676 reassembled into the correct order for delivery to the application. 677 As data is consumed by the application and buffer space becomes 678 available, the endpoint sends MAX_STREAM_DATA frames to allow the 679 peer to send more data. 681 When a STREAM frame with a FIN bit is received, the final size of the 682 stream is known (see Section 4.4). The receiving part of the stream 683 then enters the "Size Known" state. In this state, the endpoint no 684 longer needs to send MAX_STREAM_DATA frames, it only receives any 685 retransmissions of stream data. 687 Once all data for the stream has been received, the receiving part 688 enters the "Data Recvd" state. This might happen as a result of 689 receiving the same STREAM frame that causes the transition to "Size 690 Known". In this state, the endpoint has all stream data. Any STREAM 691 or STREAM_DATA_BLOCKED frames it receives for the stream can be 692 discarded. 694 The "Data Recvd" state persists until stream data has been delivered 695 to the application. Once stream data has been delivered, the stream 696 enters the "Data Read" state, which is a terminal state. 698 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 699 causes the stream to enter the "Reset Recvd" state. This might cause 700 the delivery of stream data to the application to be interrupted. 702 It is possible that all stream data is received when a RESET_STREAM 703 is received (that is, from the "Data Recvd" state). Similarly, it is 704 possible for remaining stream data to arrive after receiving a 705 RESET_STREAM frame (the "Reset Recvd" state). An implementation is 706 free to manage this situation as it chooses. Sending RESET_STREAM 707 means that an endpoint cannot guarantee delivery of stream data; 708 however there is no requirement that stream data not be delivered if 709 a RESET_STREAM is received. An implementation MAY interrupt delivery 710 of stream data, discard any data that was not consumed, and signal 711 the receipt of the RESET_STREAM immediately. Alternatively, the 712 RESET_STREAM signal might be suppressed or withheld if stream data is 713 completely received and is buffered to be read by the application. 714 In the latter case, the receiving part of the stream transitions from 715 "Reset Recvd" to "Data Recvd". 717 Once the application has been delivered the signal indicating that 718 the stream was reset, the receiving part of the stream transitions to 719 the "Reset Read" state, which is a terminal state. 721 3.3. Permitted Frame Types 723 The sender of a stream sends just three frame types that affect the 724 state of a stream at either sender or receiver: STREAM 725 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 726 (Section 19.4). 728 A sender MUST NOT send any of these frames from a terminal state 729 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 730 STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the 731 terminal states and in the "Reset Sent" state. A receiver could 732 receive any of these three frames in any state, due to the 733 possibility of delayed delivery of packets carrying them. 735 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 736 STOP_SENDING frames (Section 19.5). 738 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 739 receiver can send STOP_SENDING in any state where it has not received 740 a RESET_STREAM frame; that is states other than "Reset Recvd" or 741 "Reset Read". However there is little value in sending a 742 STOP_SENDING frame in the "Data Recvd" state, since all stream data 743 has been received. A sender could receive either of these two frames 744 in any state as a result of delayed delivery of packets. 746 3.4. Bidirectional Stream States 748 A bidirectional stream is composed of sending and receiving parts. 749 Implementations may represent states of the bidirectional stream as 750 composites of sending and receiving stream states. The simplest 751 model presents the stream as "open" when either sending or receiving 752 parts are in a non-terminal state and "closed" when both sending and 753 receiving streams are in terminal states. 755 Table 2 shows a more complex mapping of bidirectional stream states 756 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 757 shows that multiple states on sending or receiving parts of streams 758 are mapped to the same composite state. Note that this is just one 759 possibility for such a mapping; this mapping requires that data is 760 acknowledged before the transition to a "closed" or "half-closed" 761 state. 763 +-----------------------+---------------------+---------------------+ 764 | Sending Part | Receiving Part | Composite State | 765 +-----------------------+---------------------+---------------------+ 766 | No Stream/Ready | No Stream/Recv *1 | idle | 767 | | | | 768 | Ready/Send/Data Sent | Recv/Size Known | open | 769 | | | | 770 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 771 | | Read | (remote) | 772 | | | | 773 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 774 | | Read | (remote) | 775 | | | | 776 | Data Recvd | Recv/Size Known | half-closed (local) | 777 | | | | 778 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 779 | Recvd | | | 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 receiving part of the stream is in the "Recv" 798 state without 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 if the stream is in the Ready or Send 816 state. If the stream is in the Data Sent state and any outstanding 817 data is declared lost, an endpoint SHOULD send a RESET_STREAM frame 818 in lieu of a retransmission. 820 An endpoint SHOULD copy the error code from the STOP_SENDING frame to 821 the RESET_STREAM frame it sends, but MAY use any application error 822 code. The endpoint that sends a STOP_SENDING frame MAY ignore the 823 error code carried in any RESET_STREAM frame it receives. 825 If the STOP_SENDING frame is received on a stream that is already in 826 the "Data Sent" state, an endpoint that wishes to cease 827 retransmission of previously-sent STREAM frames on that stream MUST 828 first send a RESET_STREAM frame. 830 STOP_SENDING SHOULD only be sent for a stream that has not been reset 831 by the peer. STOP_SENDING is most useful for streams in the "Recv" 832 or "Size Known" states. 834 An endpoint is expected to send another STOP_SENDING frame if a 835 packet containing a previous STOP_SENDING is lost. However, once 836 either all stream data or a RESET_STREAM frame has been received for 837 the stream - that is, the stream is in any state other than "Recv" or 838 "Size Known" - sending a STOP_SENDING frame is unnecessary. 840 An endpoint that wishes to terminate both directions of a 841 bidirectional stream can terminate one direction by sending a 842 RESET_STREAM, and it can encourage prompt termination in the opposite 843 direction by sending a STOP_SENDING frame. 845 4. Flow Control 847 It is necessary to limit the amount of data that a receiver could 848 buffer, to prevent a fast sender from overwhelming a slow receiver, 849 or to prevent a malicious sender from consuming a large amount of 850 memory at a receiver. To enable a receiver to limit memory 851 commitment to a connection and to apply back pressure on the sender, 852 streams are flow controlled both individually and as an aggregate. A 853 QUIC receiver controls the maximum amount of data the sender can send 854 on a stream at any time, as described in Section 4.1 and Section 4.2 856 Similarly, to limit concurrency within a connection, a QUIC endpoint 857 controls the maximum cumulative number of streams that its peer can 858 initiate, as described in Section 4.5. 860 Data sent in CRYPTO frames is not flow controlled in the same way as 861 stream data. QUIC relies on the cryptographic protocol 862 implementation to avoid excessive buffering of data, see [QUIC-TLS]. 863 The implementation SHOULD provide an interface to QUIC to tell it 864 about its buffering limits so that there is not excessive buffering 865 at multiple layers. 867 4.1. Data Flow Control 869 QUIC employs a credit-based flow-control scheme similar to that in 870 HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is 871 prepared to receive on a given stream and for the entire connection. 872 This leads to two levels of data flow control in QUIC: 874 o Stream flow control, which prevents a single stream from consuming 875 the entire receive buffer for a connection by limiting the amount 876 of data that can be sent on any stream. 878 o Connection flow control, which prevents senders from exceeding a 879 receiver's buffer capacity for the connection, by limiting the 880 total bytes of stream data sent in STREAM frames on all streams. 882 A receiver sets initial credits for all streams by sending transport 883 parameters during the handshake (Section 7.3). A receiver sends 884 MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to 885 the sender to advertise additional credit. 887 A receiver advertises credit for a stream by sending a 888 MAX_STREAM_DATA frame with the Stream ID field set appropriately. A 889 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 890 stream. A receiver could use the current offset of data consumed to 891 determine the flow control offset to be advertised. A receiver MAY 892 send MAX_STREAM_DATA frames in multiple packets in order to make sure 893 that the sender receives an update before running out of flow control 894 credit, even if one of the packets is lost. 896 A receiver advertises credit for a connection by sending a MAX_DATA 897 frame, which indicates the maximum of the sum of the absolute byte 898 offsets of all streams. A receiver maintains a cumulative sum of 899 bytes received on all streams, which is used to check for flow 900 control violations. A receiver might use a sum of bytes consumed on 901 all streams to determine the maximum data limit to be advertised. 903 A receiver can advertise a larger offset by sending MAX_STREAM_DATA 904 or MAX_DATA frames at any time during the connection. A receiver 905 cannot renege on an advertisement however. That is, once a receiver 906 advertises an offset, it MAY advertise a smaller offset, but this has 907 no effect. 909 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 910 (Section 11) if the sender violates the advertised connection or 911 stream data limits. 913 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 914 not increase flow control limits. 916 If a sender runs out of flow control credit, it will be unable to 917 send new data and is considered blocked. A sender SHOULD send 918 STREAM_DATA_BLOCKED or DATA_BLOCKED frames to indicate it has data to 919 write but is blocked by flow control limits. These frames are 920 expected to be sent infrequently in common cases, but they are 921 considered useful for debugging and monitoring purposes. 923 A sender sends a single STREAM_DATA_BLOCKED or DATA_BLOCKED frame 924 only once when it reaches a data limit. A sender SHOULD NOT send 925 multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames for the same data 926 limit, unless the original frame is determined to be lost. Another 927 STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data 928 limit is increased. 930 4.2. Flow Credit Increments 932 This document leaves when and how many bytes to advertise in a 933 MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a 934 few considerations. These frames contribute to connection overhead. 935 Therefore frequently sending frames with small changes is 936 undesirable. At the same time, larger increments to limits are 937 necessary to avoid blocking if updates are less frequent, requiring 938 larger resource commitments at the receiver. Thus there is a trade- 939 off between resource commitment and overhead when determining how 940 large a limit is advertised. 942 A receiver can use an autotuning mechanism to tune the frequency and 943 amount of advertised additional credit based on a round-trip time 944 estimate and the rate at which the receiving application consumes 945 data, similar to common TCP implementations. As an optimization, 946 sending frames related to flow control only when there are other 947 frames to send or when a peer is blocked ensures that flow control 948 doesn't cause extra packets to be sent. 950 If a sender runs out of flow control credit, it will be unable to 951 send new data and is considered blocked. It is generally considered 952 best to not let the sender become blocked. To avoid blocking a 953 sender, and to reasonably account for the possibility of loss, a 954 receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two 955 round trips before it expects the sender to get blocked. 957 A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED 958 frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will 959 mean that a sender will be blocked for at least an entire round trip, 960 and potentially for longer if the peer chooses to not send 961 STREAM_DATA_BLOCKED or DATA_BLOCKED frames. 963 4.3. Handling Stream Cancellation 965 Endpoints need to eventually agree on the amount of flow control 966 credit that has been consumed, to avoid either exceeding flow control 967 limits or deadlocking. 969 On receipt of a RESET_STREAM frame, an endpoint will tear down state 970 for the matching stream and ignore further data arriving on that 971 stream. If a RESET_STREAM frame is reordered with stream data for 972 the same stream, the receiver's estimate of the number of bytes 973 received on that stream can be lower than the sender's estimate of 974 the number sent. As a result, the two endpoints could disagree on 975 the number of bytes that count towards connection flow control. 977 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes 978 the final size of data sent on the stream. On receiving a 979 RESET_STREAM frame, a receiver definitively knows how many bytes were 980 sent on that stream before the RESET_STREAM frame, and the receiver 981 MUST use the final size of the stream to account for all bytes sent 982 on the stream in its connection level flow controller. 984 RESET_STREAM terminates one direction of a stream abruptly. For a 985 bidirectional stream, RESET_STREAM has no effect on data flow in the 986 opposite direction. Both endpoints MUST maintain flow control state 987 for the stream in the unterminated direction until that direction 988 enters a terminal state, or until one of the endpoints sends 989 CONNECTION_CLOSE. 991 4.4. Stream Final Size 993 The final size is the amount of flow control credit that is consumed 994 by a stream. Assuming that every contiguous byte on the stream was 995 sent once, the final size is the number of bytes sent. More 996 generally, this is one higher than the largest byte offset sent on 997 the stream. 999 For a stream that is reset, the final size is carried explicitly in a 1000 RESET_STREAM frame. Otherwise, the final size is the offset plus the 1001 length of a STREAM frame marked with a FIN flag, or 0 in the case of 1002 incoming unidirectional streams. 1004 An endpoint will know the final size for a stream when the receiving 1005 part of the stream enters the "Size Known" or "Reset Recvd" state 1006 (Section 3). 1008 An endpoint MUST NOT send data on a stream at or beyond the final 1009 size. 1011 Once a final size for a stream is known, it cannot change. If a 1012 RESET_STREAM or STREAM frame is received indicating a change in the 1013 final size for the stream, an endpoint SHOULD respond with a 1014 FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat 1015 receipt of data at or beyond the final size as a FINAL_SIZE_ERROR 1016 error, even after a stream is closed. Generating these errors is not 1017 mandatory, but only because requiring that an endpoint generate these 1018 errors also means that the endpoint needs to maintain the final size 1019 state for closed streams, which could mean a significant state 1020 commitment. 1022 4.5. Controlling Concurrency 1024 An endpoint limits the cumulative number of incoming streams a peer 1025 can open. Only streams with a stream ID less than (max_stream * 4 + 1026 initial_stream_id_for_type) can be opened (see Table 5). Initial 1027 limits are set in the transport parameters (see Section 18.1) and 1028 subsequently limits are advertised using MAX_STREAMS frames 1029 (Section 19.11). Separate limits apply to unidirectional and 1030 bidirectional streams. 1032 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1033 that receives a STREAM frame with a stream ID exceeding the limit it 1034 has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR 1035 (Section 11). 1037 A receiver cannot renege on an advertisement. That is, once a 1038 receiver advertises a stream limit using the MAX_STREAMS frame, 1039 advertising a smaller limit has no effect. A receiver MUST ignore 1040 any MAX_STREAMS frame that does not increase the stream limit. 1042 As with stream and connection flow control, this document leaves when 1043 and how many streams to advertise to a peer via MAX_STREAMS to 1044 implementations. Implementations might choose to increase limits as 1045 streams close to keep the number of streams available to peers 1046 roughly consistent. 1048 An endpoint that is unable to open a new stream due to the peer's 1049 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1050 signal is considered useful for debugging. An endpoint MUST NOT wait 1051 to receive this signal before advertising additional credit, since 1052 doing so will mean that the peer will be blocked for at least an 1053 entire round trip, and potentially for longer if the peer chooses to 1054 not send STREAMS_BLOCKED frames. 1056 5. Connections 1058 QUIC's connection establishment combines version negotiation with the 1059 cryptographic and transport handshakes to reduce connection 1060 establishment latency, as described in Section 7. Once established, 1061 a connection may migrate to a different IP or port at either endpoint 1062 as described in Section 9. Finally, a connection may be terminated 1063 by either endpoint, as described in Section 10. 1065 5.1. Connection ID 1067 Each connection possesses a set of connection identifiers, or 1068 connection IDs, each of which can identify the connection. 1069 Connection IDs are independently selected by endpoints; each endpoint 1070 selects the connection IDs that its peer uses. 1072 The primary function of a connection ID is to ensure that changes in 1073 addressing at lower protocol layers (UDP, IP) don't cause packets for 1074 a QUIC connection to be delivered to the wrong endpoint. Each 1075 endpoint selects connection IDs using an implementation-specific (and 1076 perhaps deployment-specific) method which will allow packets with 1077 that connection ID to be routed back to the endpoint and identified 1078 by the endpoint upon receipt. 1080 Connection IDs MUST NOT contain any information that can be used by 1081 an external observer to correlate them with other connection IDs for 1082 the same connection. As a trivial example, this means the same 1083 connection ID MUST NOT be issued more than once on the same 1084 connection. 1086 Packets with long headers include Source Connection ID and 1087 Destination Connection ID fields. These fields are used to set the 1088 connection IDs for new connections, see Section 7.2 for details. 1090 Packets with short headers (Section 17.3) only include the 1091 Destination Connection ID and omit the explicit length. The length 1092 of the Destination Connection ID field is expected to be known to 1093 endpoints. Endpoints using a load balancer that routes based on 1094 connection ID could agree with the load balancer on a fixed length 1095 for connection IDs, or agree on an encoding scheme. A fixed portion 1096 could encode an explicit length, which allows the entire connection 1097 ID to vary in length and still be used by the load balancer. 1099 A Version Negotiation (Section 17.2.1) packet echoes the connection 1100 IDs selected by the client, both to ensure correct routing toward the 1101 client and to allow the client to validate that the packet is in 1102 response to an Initial packet. 1104 A zero-length connection ID MAY be used when the connection ID is not 1105 needed for routing and the address/port tuple of packets is 1106 sufficient to identify a connection. An endpoint whose peer has 1107 selected a zero-length connection ID MUST continue to use a zero- 1108 length connection ID for the lifetime of the connection and MUST NOT 1109 send packets from any other local address. 1111 When an endpoint has requested a non-zero-length connection ID, it 1112 needs to ensure that the peer has a supply of connection IDs from 1113 which to choose for packets sent to the endpoint. These connection 1114 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1115 (Section 19.15). 1117 5.1.1. Issuing Connection IDs 1119 Each Connection ID has an associated sequence number to assist in 1120 deduplicating messages. The initial connection ID issued by an 1121 endpoint is sent in the Source Connection ID field of the long packet 1122 header (Section 17.2) during the handshake. The sequence number of 1123 the initial connection ID is 0. If the preferred_address transport 1124 parameter is sent, the sequence number of the supplied connection ID 1125 is 1. 1127 Additional connection IDs are communicated to the peer using 1128 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1129 each newly-issued connection ID MUST increase by 1. The connection 1130 ID randomly selected by the client in the Initial packet and any 1131 connection ID provided by a Retry packet are not assigned sequence 1132 numbers unless a server opts to retain them as its initial connection 1133 ID. 1135 When an endpoint issues a connection ID, it MUST accept packets that 1136 carry this connection ID for the duration of the connection or until 1137 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1138 frame (Section 19.16). 1140 Endpoints store received connection IDs for future use. An endpoint 1141 that receives excessive connection IDs MAY discard those it cannot 1142 store without sending a RETIRE_CONNECTION_ID frame. An endpoint that 1143 issues connection IDs cannot expect its peer to store and use all 1144 issued connection IDs. 1146 An endpoint SHOULD ensure that its peer has a sufficient number of 1147 available and unused connection IDs. While each endpoint 1148 independently chooses how many connection IDs to issue, endpoints 1149 SHOULD provide and maintain at least eight connection IDs. The 1150 endpoint SHOULD do this by supplying a new connection ID when a 1151 connection ID is retired by its peer or when the endpoint receives a 1152 packet with a previously unused connection ID. However, it MAY limit 1153 the frequency or the total number of connection IDs issued for each 1154 connection to avoid the risk of running out of connection IDs (see 1155 Section 10.4.2). 1157 An endpoint that initiates migration and requires non-zero-length 1158 connection IDs SHOULD ensure that the pool of connection IDs 1159 available to its peer allows the peer to use a new connection ID on 1160 migration, as the peer will close the connection if the pool is 1161 exhausted. 1163 5.1.2. Consuming and Retiring Connection IDs 1165 An endpoint can change the connection ID it uses for a peer to 1166 another available one at any time during the connection. An endpoint 1167 consumes connection IDs in response to a migrating peer, see 1168 Section 9.5 for more. 1170 An endpoint maintains a set of connection IDs received from its peer, 1171 any of which it can use when sending packets. When the endpoint 1172 wishes to remove a connection ID from use, it sends a 1173 RETIRE_CONNECTION_ID frame to its peer. Sending a 1174 RETIRE_CONNECTION_ID frame indicates that the connection ID won't be 1175 used again and requests that the peer replace it with a new 1176 connection ID using a NEW_CONNECTION_ID frame. 1178 As discussed in Section 9.5, each connection ID MUST be used on 1179 packets sent from only one local address. An endpoint that migrates 1180 away from a local address SHOULD retire all connection IDs used on 1181 that address once it no longer plans to use that address. 1183 5.2. Matching Packets to Connections 1185 Incoming packets are classified on receipt. Packets can either be 1186 associated with an existing connection, or - for servers - 1187 potentially create a new connection. 1189 Hosts try to associate a packet with an existing connection. If the 1190 packet has a Destination Connection ID corresponding to an existing 1191 connection, QUIC processes that packet accordingly. Note that more 1192 than one connection ID can be associated with a connection; see 1193 Section 5.1. 1195 If the Destination Connection ID is zero length and the packet 1196 matches the address/port tuple of a connection where the host did not 1197 require connection IDs, QUIC processes the packet as part of that 1198 connection. Endpoints SHOULD either reject connection attempts that 1199 use the same addresses as existing connections, or use a non-zero- 1200 length Destination Connection ID so that packets can be correctly 1201 attributed to connections. 1203 Endpoints can send a Stateless Reset (Section 10.4) for any packets 1204 that cannot be attributed to an existing connection. A stateless 1205 reset allows a peer to more quickly identify when a connection 1206 becomes unusable. 1208 Packets that are matched to an existing connection are discarded if 1209 the packets are inconsistent with the state of that connection. For 1210 example, packets are discarded if they indicate a different protocol 1211 version than that of the connection, or if the removal of packet 1212 protection is unsuccessful once the expected keys are available. 1214 Invalid packets without packet protection, such as Initial, Retry, or 1215 Version Negotiation, MAY be discarded. An endpoint MUST generate a 1216 connection error if it commits changes to state before discovering an 1217 error. 1219 5.2.1. Client Packet Handling 1221 Valid packets sent to clients always include a Destination Connection 1222 ID that matches a value the client selects. Clients that choose to 1223 receive zero-length connection IDs can use the address/port tuple to 1224 identify a connection. Packets that don't match an existing 1225 connection are discarded. 1227 Due to packet reordering or loss, clients might receive packets for a 1228 connection that are encrypted with a key it has not yet computed. 1229 Clients MAY drop these packets, or MAY buffer them in anticipation of 1230 later packets that allow it to compute the key. 1232 If a client receives a packet that has an unsupported version, it 1233 MUST discard that packet. 1235 5.2.2. Server Packet Handling 1237 If a server receives a packet that has an unsupported version, but 1238 the packet is sufficiently large to initiate a new connection for any 1239 version supported by the server, it SHOULD send a Version Negotiation 1240 packet as described in Section 6.1. Servers MAY rate control these 1241 packets to avoid storms of Version Negotiation packets. 1243 The first packet for an unsupported version can use different 1244 semantics and encodings for any version-specific field. In 1245 particular, different packet protection keys might be used for 1246 different versions. Servers that do not support a particular version 1247 are unlikely to be able to decrypt the payload of the packet. 1248 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1249 unknown version, but instead send a Version Negotiation packet, 1250 provided that the packet is sufficiently long. 1252 Servers MUST drop other packets that contain unsupported versions. 1254 Packets with a supported version, or no version field, are matched to 1255 a connection using the connection ID or - for packets with zero- 1256 length connection IDs - the address tuple. If the packet doesn't 1257 match an existing connection, the server continues below. 1259 If the packet is an Initial packet fully conforming with the 1260 specification, the server proceeds with the handshake (Section 7). 1261 This commits the server to the version that the client selected. 1263 If a server isn't currently accepting any new connections, it SHOULD 1264 send an Initial packet containing a CONNECTION_CLOSE frame with error 1265 code SERVER_BUSY. 1267 If the packet is a 0-RTT packet, the server MAY buffer a limited 1268 number of these packets in anticipation of a late-arriving Initial 1269 Packet. Clients are forbidden from sending Handshake packets prior 1270 to receiving a server response, so servers SHOULD ignore any such 1271 packets. 1273 Servers MUST drop incoming packets under all other circumstances. 1275 5.3. Life of a QUIC Connection 1277 TBD. 1279 6. Version Negotiation 1281 Version negotiation ensures that client and server agree to a QUIC 1282 version that is mutually supported. A server sends a Version 1283 Negotiation packet in response to each packet that might initiate a 1284 new connection, see Section 5.2 for details. 1286 The size of the first packet sent by a client will determine whether 1287 a server sends a Version Negotiation packet. Clients that support 1288 multiple QUIC versions SHOULD pad the first packet they send to the 1289 largest of the minimum packet sizes across all versions they support. 1290 This ensures that the server responds if there is a mutually 1291 supported version. 1293 6.1. Sending Version Negotiation Packets 1295 If the version selected by the client is not acceptable to the 1296 server, the server responds with a Version Negotiation packet (see 1297 Section 17.2.1). This includes a list of versions that the server 1298 will accept. An endpoint MUST NOT send a Version Negotiation packet 1299 in response to receiving a Version Negotiation packet. 1301 This system allows a server to process packets with unsupported 1302 versions without retaining state. Though either the Initial packet 1303 or the Version Negotiation packet that is sent in response could be 1304 lost, the client will send new packets until it successfully receives 1305 a response or it abandons the connection attempt. 1307 A server MAY limit the number of Version Negotiation packets it 1308 sends. For instance, a server that is able to recognize packets as 1309 0-RTT might choose not to send Version Negotiation packets in 1310 response to 0-RTT packets with the expectation that it will 1311 eventually receive an Initial packet. 1313 6.2. Handling Version Negotiation Packets 1315 When a client receives a Version Negotiation packet, it MUST abandon 1316 the current connection attempt. Version Negotiation packets are 1317 designed to allow future versions of QUIC to negotiate the version in 1318 use between endpoints. Future versions of QUIC might change how 1319 implementations that support multiple versions of QUIC react to 1320 Version Negotiation packets when attempting to establish a connection 1321 using this version. How to perform version negotiation is left as 1322 future work defined by future versions of QUIC. In particular, that 1323 future work will need to ensure robustness against version downgrade 1324 attacks Section 21.9. 1326 6.2.1. Version Negotiation Between Draft Versions 1328 [[RFC editor: please remove this section before publication.]] 1330 When a draft implementation receives a Version Negotiation packet, it 1331 MAY use it to attempt a new connection with one of the versions 1332 listed in the packet, instead of abandoning the current connection 1333 attempt Section 6.2. 1335 The client MUST check that the Destination and Source Connection ID 1336 fields match the Source and Destination Connection ID fields in a 1337 packet that the client sent. If this check fails, the packet MUST be 1338 discarded. 1340 Once the Version Negotiation packet is determined to be valid, the 1341 client then selects an acceptable protocol version from the list 1342 provided by the server. The client then attempts to create a new 1343 connection using that version. The new connection MUST use a new 1344 random Destination Connection ID different from the one it had 1345 previously sent. 1347 Note that this mechanism does not protect against downgrade attacks 1348 and MUST NOT be used outside of draft implementations. 1350 6.3. Using Reserved Versions 1352 For a server to use a new version in the future, clients must 1353 correctly handle unsupported versions. To help ensure this, a server 1354 SHOULD include a reserved version (see Section 15) while generating a 1355 Version Negotiation packet. 1357 The design of version negotiation permits a server to avoid 1358 maintaining state for packets that it rejects in this fashion. 1360 A client MAY send a packet using a reserved version number. This can 1361 be used to solicit a list of supported versions from a server. 1363 7. Cryptographic and Transport Handshake 1365 QUIC relies on a combined cryptographic and transport handshake to 1366 minimize connection establishment latency. QUIC uses the CRYPTO 1367 frame Section 19.6 to transmit the cryptographic handshake. Version 1368 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 1369 QUIC version number could indicate that a different cryptographic 1370 handshake protocol is in use. 1372 QUIC provides reliable, ordered delivery of the cryptographic 1373 handshake data. QUIC packet protection is used to encrypt as much of 1374 the handshake protocol as possible. The cryptographic handshake MUST 1375 provide the following properties: 1377 o authenticated key exchange, where 1379 * a server is always authenticated, 1381 * a client is optionally authenticated, 1383 * every connection produces distinct and unrelated keys, 1385 * keying material is usable for packet protection for both 0-RTT 1386 and 1-RTT packets, and 1388 * 1-RTT keys have forward secrecy 1390 o authenticated values for the transport parameters of the peer (see 1391 Section 7.3) 1393 o authenticated negotiation of an application protocol (TLS uses 1394 ALPN [RFC7301] for this purpose) 1396 The first CRYPTO frame from a client MUST be sent in a single packet. 1397 Any second attempt that is triggered by address validation (see 1398 Section 8.1) MUST also be sent within a single packet. This avoids 1399 having to reassemble a message from multiple packets. 1401 The first client packet of the cryptographic handshake protocol MUST 1402 fit within a 1232 byte QUIC packet payload. This includes overheads 1403 that reduce the space available to the cryptographic handshake 1404 protocol. 1406 An endpoint can verify support for Explicit Congestion Notification 1407 (ECN) in the first packets it sends, as described in Section 13.3.2. 1409 The CRYPTO frame can be sent in different packet number spaces. The 1410 sequence numbers used by CRYPTO frames to ensure ordered delivery of 1411 cryptographic handshake data start from zero in each packet number 1412 space. 1414 Endpoints MUST explicitly negotiate an application protocol. This 1415 avoids situations where there is a disagreement about the protocol 1416 that is in use. 1418 7.1. Example Handshake Flows 1420 Details of how TLS is integrated with QUIC are provided in 1421 [QUIC-TLS], but some examples are provided here. An extension of 1422 this exchange to support client address validation is shown in 1423 Section 8.1.1. 1425 Once any address validation exchanges are complete, the cryptographic 1426 handshake is used to agree on cryptographic keys. The cryptographic 1427 handshake is carried in Initial (Section 17.2.2) and Handshake 1428 (Section 17.2.4) packets. 1430 Figure 3 provides an overview of the 1-RTT handshake. Each line 1431 shows a QUIC packet with the packet type and packet number shown 1432 first, followed by the frames that are typically contained in those 1433 packets. So, for instance the first packet is of type Initial, with 1434 packet number 0, and contains a CRYPTO frame carrying the 1435 ClientHello. 1437 Note that multiple QUIC packets - even of different encryption levels 1438 - may be coalesced into a single UDP datagram (see Section 12.2), and 1439 so this handshake may consist of as few as 4 UDP datagrams, or any 1440 number more. For instance, the server's first flight contains 1441 packets from the Initial encryption level (obfuscation), the 1442 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1443 encryption level. 1445 Client Server 1447 Initial[0]: CRYPTO[CH] -> 1449 Initial[0]: CRYPTO[SH] ACK[0] 1450 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1451 <- 1-RTT[0]: STREAM[1, "..."] 1453 Initial[1]: ACK[0] 1454 Handshake[0]: CRYPTO[FIN], ACK[0] 1455 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1457 1-RTT[1]: STREAM[3, "..."], ACK[0] 1458 <- Handshake[1]: ACK[0] 1460 Figure 3: Example 1-RTT Handshake 1462 Figure 4 shows an example of a connection with a 0-RTT handshake and 1463 a single packet of 0-RTT data. Note that as described in 1464 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1465 encryption level, and the client sends 1-RTT packets in the same 1466 packet number space. 1468 Client Server 1470 Initial[0]: CRYPTO[CH] 1471 0-RTT[0]: STREAM[0, "..."] -> 1473 Initial[0]: CRYPTO[SH] ACK[0] 1474 Handshake[0] CRYPTO[EE, FIN] 1475 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1477 Initial[1]: ACK[0] 1478 Handshake[0]: CRYPTO[FIN], ACK[0] 1479 1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1481 1-RTT[1]: STREAM[3, "..."], ACK[1] 1482 <- Handshake[1]: ACK[0] 1484 Figure 4: Example 0-RTT Handshake 1486 7.2. Negotiating Connection IDs 1488 A connection ID is used to ensure consistent routing of packets, as 1489 described in Section 5.1. The long header contains two connection 1490 IDs: the Destination Connection ID is chosen by the recipient of the 1491 packet and is used to provide consistent routing; the Source 1492 Connection ID is used to set the Destination Connection ID used by 1493 the peer. 1495 During the handshake, packets with the long header (Section 17.2) are 1496 used to establish the connection ID that each endpoint uses. Each 1497 endpoint uses the Source Connection ID field to specify the 1498 connection ID that is used in the Destination Connection ID field of 1499 packets being sent to them. Upon receiving a packet, each endpoint 1500 sets the Destination Connection ID it sends to match the value of the 1501 Source Connection ID that they receive. 1503 When an Initial packet is sent by a client which has not previously 1504 received a Retry packet from the server, it populates the Destination 1505 Connection ID field with an unpredictable value. This MUST be at 1506 least 8 bytes in length. Until a packet is received from the server, 1507 the client MUST use the same value unless it abandons the connection 1508 attempt and starts a new one. The initial Destination Connection ID 1509 is used to determine packet protection keys for Initial packets. 1511 The client populates the Source Connection ID field with a value of 1512 its choosing and sets the SCIL field to indicate the length. 1514 The first flight of 0-RTT packets use the same Destination and Source 1515 Connection ID values as the client's first Initial. 1517 The Destination Connection ID field in the server's Initial packet 1518 contains a connection ID that is chosen by the recipient of the 1519 packet (i.e., the client); the Source Connection ID includes the 1520 connection ID that the sender of the packet wishes to use (see 1521 Section 5.1). The server MUST use consistent Source Connection IDs 1522 during the handshake. 1524 On first receiving an Initial or Retry packet from the server, the 1525 client uses the Source Connection ID supplied by the server as the 1526 Destination Connection ID for subsequent packets, including any 1527 subsequent 0-RTT packets. That means that a client might change the 1528 Destination Connection ID twice during connection establishment, once 1529 in response to a Retry and once in response to the first Initial 1530 packet from the server. Once a client has received an Initial packet 1531 from the server, it MUST discard any packet it receives with a 1532 different Source Connection ID. 1534 A client MUST only change the value it sends in the Destination 1535 Connection ID in response to the first packet of each type it 1536 receives from the server (Retry or Initial); a server MUST set its 1537 value based on the Initial packet. Any additional changes are not 1538 permitted; if subsequent packets of those types include a different 1539 Source Connection ID, they MUST be discarded. This avoids problems 1540 that might arise from stateless processing of multiple Initial 1541 packets producing different connection IDs. 1543 The connection ID can change over the lifetime of a connection, 1544 especially in response to connection migration (Section 9), see 1545 Section 5.1.1 for details. 1547 7.3. Transport Parameters 1549 During connection establishment, both endpoints make authenticated 1550 declarations of their transport parameters. These declarations are 1551 made unilaterally by each endpoint. Endpoints are required to comply 1552 with the restrictions implied by these parameters; the description of 1553 each parameter includes rules for its handling. 1555 The encoding of the transport parameters is detailed in Section 18. 1557 QUIC includes the encoded transport parameters in the cryptographic 1558 handshake. Once the handshake completes, the transport parameters 1559 declared by the peer are available. Each endpoint validates the 1560 value provided by its peer. 1562 Definitions for each of the defined transport parameters are included 1563 in Section 18.1. An endpoint MUST treat receipt of a transport 1564 parameter with an invalid value as a connection error of type 1565 TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most 1566 once in a given transport parameters extension. An endpoint MUST 1567 treat receipt of duplicate transport parameters as a connection error 1568 of type TRANSPORT_PARAMETER_ERROR. 1570 A server MUST include the original_connection_id transport parameter 1571 (Section 18.1) if it sent a Retry packet to enable validation of the 1572 Retry, as described in Section 17.2.5. 1574 7.3.1. Values of Transport Parameters for 0-RTT 1576 A client that attempts to send 0-RTT data MUST remember the transport 1577 parameters used by the server. The transport parameters that the 1578 server advertises during connection establishment apply to all 1579 connections that are resumed using the keying material established 1580 during that handshake. Remembered transport parameters apply to the 1581 new connection until the handshake completes and new transport 1582 parameters from the server can be provided. 1584 A server can remember the transport parameters that it advertised, or 1585 store an integrity-protected copy of the values in the ticket and 1586 recover the information when accepting 0-RTT data. A server uses the 1587 transport parameters in determining whether to accept 0-RTT data. 1589 A server MAY accept 0-RTT and subsequently provide different values 1590 for transport parameters for use in the new connection. If 0-RTT 1591 data is accepted by the server, the server MUST NOT reduce any limits 1592 or alter any values that might be violated by the client with its 1593 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1594 set values for the following parameters (Section 18.1) that are 1595 smaller than the remembered value of those parameters. 1597 o initial_max_data 1599 o initial_max_stream_data_bidi_local 1601 o initial_max_stream_data_bidi_remote 1603 o initial_max_stream_data_uni 1605 o initial_max_streams_bidi 1607 o initial_max_streams_uni 1608 Omitting or setting a zero value for certain transport parameters can 1609 result in 0-RTT data being enabled, but not usable. The applicable 1610 subset of transport parameters that permit sending of application 1611 data SHOULD be set to non-zero values for 0-RTT. This includes 1612 initial_max_data and either initial_max_streams_bidi and 1613 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 1614 initial_max_stream_data_uni. 1616 The value of the server's previous preferred_address MUST NOT be used 1617 when establishing a new connection; rather, the client should wait to 1618 observe the server's new preferred_address value in the handshake. 1620 A server MUST either reject 0-RTT data or abort a handshake if the 1621 implied values for transport parameters cannot be supported. 1623 7.3.2. New Transport Parameters 1625 New transport parameters can be used to negotiate new protocol 1626 behavior. An endpoint MUST ignore transport parameters that it does 1627 not support. Absence of a transport parameter therefore disables any 1628 optional protocol feature that is negotiated using the parameter. 1630 New transport parameters can be registered according to the rules in 1631 Section 22.1. 1633 8. Address Validation 1635 Address validation is used by QUIC to avoid being used for a traffic 1636 amplification attack. In such an attack, a packet is sent to a 1637 server with spoofed source address information that identifies a 1638 victim. If a server generates more or larger packets in response to 1639 that packet, the attacker can use the server to send more data toward 1640 the victim than it would be able to send on its own. 1642 The primary defense against amplification attack is verifying that an 1643 endpoint is able to receive packets at the transport address that it 1644 claims. Address validation is performed both during connection 1645 establishment (see Section 8.1) and during connection migration (see 1646 Section 8.2). 1648 8.1. Address Validation During Connection Establishment 1650 Connection establishment implicitly provides address validation for 1651 both endpoints. In particular, receipt of a packet protected with 1652 Handshake keys confirms that the client received the Initial packet 1653 from the server. Once the server has successfully processed a 1654 Handshake packet from the client, it can consider the client address 1655 to have been validated. 1657 Prior to validating the client address, servers MUST NOT send more 1658 than three times as many bytes as the number of bytes they have 1659 received. This limits the magnitude of any amplification attack that 1660 can be mounted using spoofed source addresses. In determining this 1661 limit, servers only count the size of successfully processed packets. 1663 Clients MUST pad UDP datagrams that contain only Initial packets to 1664 at least 1200 bytes. Once a client has received an acknowledgment 1665 for a Handshake packet it MAY send smaller datagrams. Sending padded 1666 datagrams ensures that the server is not overly constrained by the 1667 amplification restriction. 1669 Packet loss, in particular loss of a Handshake packet from the 1670 server, can cause a situation in which the server cannot send when 1671 the client has no data to send and the anti-amplification limit is 1672 reached. In order to avoid this causing a handshake deadlock, 1673 clients SHOULD send a packet upon a crypto retransmission timeout, as 1674 described in [QUIC-RECOVERY]. If the client has no data to 1675 retransmit and does not have Handshake keys, it SHOULD send an 1676 Initial packet in a UDP datagram of at least 1200 bytes. If the 1677 client has Handshake keys, it SHOULD send a Handshake packet. 1679 A server might wish to validate the client address before starting 1680 the cryptographic handshake. QUIC uses a token in the Initial packet 1681 to provide address validation prior to completing the handshake. 1682 This token is delivered to the client during connection establishment 1683 with a Retry packet (see Section 8.1.1) or in a previous connection 1684 using the NEW_TOKEN frame (see Section 8.1.2). 1686 In addition to sending limits imposed prior to address validation, 1687 servers are also constrained in what they can send by the limits set 1688 by the congestion controller. Clients are only constrained by the 1689 congestion controller. 1691 8.1.1. Address Validation using Retry Packets 1693 Upon receiving the client's Initial packet, the server can request 1694 address validation by sending a Retry packet (Section 17.2.5) 1695 containing a token. This token MUST be repeated by the client in all 1696 Initial packets it sends for that connection after it receives the 1697 Retry packet. In response to processing an Initial containing a 1698 token, a server can either abort the connection or permit it to 1699 proceed. 1701 As long as it is not possible for an attacker to generate a valid 1702 token for its own address (see Section 8.1.3) and the client is able 1703 to return that token, it proves to the server that it received the 1704 token. 1706 A server can also use a Retry packet to defer the state and 1707 processing costs of connection establishment. By giving the client a 1708 different connection ID to use, a server can cause the connection to 1709 be routed to a server instance with more resources available for new 1710 connections. 1712 A flow showing the use of a Retry packet is shown in Figure 5. 1714 Client Server 1716 Initial[0]: CRYPTO[CH] -> 1718 <- Retry+Token 1720 Initial+Token[1]: CRYPTO[CH] -> 1722 Initial[0]: CRYPTO[SH] ACK[1] 1723 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1724 <- 1-RTT[0]: STREAM[1, "..."] 1726 Figure 5: Example Handshake with Retry 1728 8.1.2. Address Validation for Future Connections 1730 A server MAY provide clients with an address validation token during 1731 one connection that can be used on a subsequent connection. Address 1732 validation is especially important with 0-RTT because a server 1733 potentially sends a significant amount of data to a client in 1734 response to 0-RTT data. 1736 The server uses the NEW_TOKEN frame Section 19.7 to provide the 1737 client with an address validation token that can be used to validate 1738 future connections. The client includes this token in Initial 1739 packets to provide address validation in a future connection. The 1740 client MUST include the token in all Initial packets it sends, unless 1741 a Retry or NEW_TOKEN frame replaces the token with a newer one. The 1742 client MUST NOT use the token provided in a Retry for future 1743 connections. Servers MAY discard any Initial packet that does not 1744 carry the expected token. 1746 Unlike the token that is created for a Retry packet, there might be 1747 some time between when the token is created and when the token is 1748 subsequently used. Thus, a token SHOULD include an expiration time. 1749 The server MAY include either an explicit expiration time or an 1750 issued timestamp and dynamically calculate the expiration time. It 1751 is also unlikely that the client port number is the same on two 1752 different connections; validating the port is therefore unlikely to 1753 be successful. 1755 A token SHOULD be constructed for the server to easily distinguish it 1756 from tokens that are sent in Retry packets as they are carried in the 1757 same field. 1759 If the client has a token received in a NEW_TOKEN frame on a previous 1760 connection to what it believes to be the same server, it SHOULD 1761 include that value in the Token field of its Initial packet. 1762 Including a token might allow the server to validate the client 1763 address without an additional round trip. 1765 A token allows a server to correlate activity between the connection 1766 where the token was issued and any connection where it is used. 1767 Clients that want to break continuity of identity with a server MAY 1768 discard tokens provided using the NEW_TOKEN frame. A token obtained 1769 in a Retry packet MUST be used immediately during the connection 1770 attempt and cannot be used in subsequent connection attempts. 1772 A client SHOULD NOT reuse a token in different connections. Reusing 1773 a token allows connections to be linked by entities on the network 1774 path (see Section 9.5). A client MUST NOT reuse a token if it 1775 believes that its point of network attachment has changed since the 1776 token was last used; that is, if there is a change in its local IP 1777 address or network interface. A client needs to start the connection 1778 process over if it migrates prior to completing the handshake. 1780 When a server receives an Initial packet with an address validation 1781 token, it MUST attempt to validate the token, unless it has already 1782 completed address validation. If the token is invalid then the 1783 server SHOULD proceed as if the client did not have a validated 1784 address, including potentially sending a Retry. If the validation 1785 succeeds, the server SHOULD then allow the handshake to proceed. 1787 Note: The rationale for treating the client as unvalidated rather 1788 than discarding the packet is that the client might have received 1789 the token in a previous connection using the NEW_TOKEN frame, and 1790 if the server has lost state, it might be unable to validate the 1791 token at all, leading to connection failure if the packet is 1792 discarded. A server SHOULD encode tokens provided with NEW_TOKEN 1793 frames and Retry packets differently, and validate the latter more 1794 strictly. 1796 In a stateless design, a server can use encrypted and authenticated 1797 tokens to pass information to clients that the server can later 1798 recover and use to validate a client address. Tokens are not 1799 integrated into the cryptographic handshake and so they are not 1800 authenticated. For instance, a client might be able to reuse a 1801 token. To avoid attacks that exploit this property, a server can 1802 limit its use of tokens to only the information needed to validate 1803 client addresses. 1805 Attackers could replay tokens to use servers as amplifiers in DDoS 1806 attacks. To protect against such attacks, servers SHOULD ensure that 1807 tokens sent in Retry packets are only accepted for a short time. 1808 Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need 1809 to be valid for longer, but SHOULD NOT be accepted multiple times in 1810 a short period. Servers are encouraged to allow tokens to be used 1811 only once, if possible. 1813 8.1.3. Address Validation Token Integrity 1815 An address validation token MUST be difficult to guess. Including a 1816 large enough random value in the token would be sufficient, but this 1817 depends on the server remembering the value it sends to clients. 1819 A token-based scheme allows the server to offload any state 1820 associated with validation to the client. For this design to work, 1821 the token MUST be covered by integrity protection against 1822 modification or falsification by clients. Without integrity 1823 protection, malicious clients could generate or guess values for 1824 tokens that would be accepted by the server. Only the server 1825 requires access to the integrity protection key for tokens. 1827 There is no need for a single well-defined format for the token 1828 because the server that generates the token also consumes it. A 1829 token could include information about the claimed client address (IP 1830 and port), a timestamp, and any other supplementary information the 1831 server will need to validate the token in the future. 1833 8.2. Path Validation 1835 Path validation is used during connection migration (see Section 9 1836 and Section 9.6) by the migrating endpoint to verify reachability of 1837 a peer from a new local address. In path validation, endpoints test 1838 reachability between a specific local address and a specific peer 1839 address, where an address is the two-tuple of IP address and port. 1841 Path validation tests that packets (PATH_CHALLENGE) can be both sent 1842 to and received (PATH_RESPONSE) from a peer on the path. 1843 Importantly, it validates that the packets received from the 1844 migrating endpoint do not carry a spoofed source address. 1846 Path validation can be used at any time by either endpoint. For 1847 instance, an endpoint might check that a peer is still in possession 1848 of its address after a period of quiescence. 1850 Path validation is not designed as a NAT traversal mechanism. Though 1851 the mechanism described here might be effective for the creation of 1852 NAT bindings that support NAT traversal, the expectation is that one 1853 or other peer is able to receive packets without first having sent a 1854 packet on that path. Effective NAT traversal needs additional 1855 synchronization mechanisms that are not provided here. 1857 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 1858 are used for path validation with other frames. In particular, an 1859 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 1860 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 1861 PATH_CHALLENGE. 1863 When probing a new path, an endpoint might want to ensure that its 1864 peer has an unused connection ID available for responses. The 1865 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 1866 same packet. This ensures that an unused connection ID will be 1867 available to the peer when sending a response. 1869 8.3. Initiating Path Validation 1871 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 1872 containing a random payload on the path to be validated. 1874 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 1875 packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more 1876 frequently than it would an Initial packet, ensuring that connection 1877 migration is no more load on a new path than establishing a new 1878 connection. 1880 The endpoint MUST use unpredictable data in every PATH_CHALLENGE 1881 frame so that it can associate the peer's response with the 1882 corresponding PATH_CHALLENGE. 1884 8.4. Path Validation Responses 1886 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 1887 immediately by echoing the data contained in the PATH_CHALLENGE frame 1888 in a PATH_RESPONSE frame. 1890 To ensure that packets can be both sent to and received from the 1891 peer, the PATH_RESPONSE MUST be sent on the same path as the 1892 triggering PATH_CHALLENGE. That is, from the same local address on 1893 which the PATH_CHALLENGE was received, to the same remote address 1894 from which the PATH_CHALLENGE was received. 1896 8.5. Successful Path Validation 1898 A new address is considered valid when a PATH_RESPONSE frame is 1899 received that meets the following criteria: 1901 o It contains the data that was sent in a previous PATH_CHALLENGE. 1902 Receipt of an acknowledgment for a packet containing a 1903 PATH_CHALLENGE frame is not adequate validation, since the 1904 acknowledgment can be spoofed by a malicious peer. 1906 o It was sent from the same remote address to which the 1907 corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame 1908 is received from a different remote address than the one to which 1909 the PATH_CHALLENGE was sent, path validation is considered to have 1910 failed, even if the data matches that sent in the PATH_CHALLENGE. 1912 o It was received on the same local address from which the 1913 corresponding PATH_CHALLENGE was sent. 1915 Note that receipt on a different local address does not result in 1916 path validation failure, as it might be a result of a forwarded 1917 packet (see Section 9.3.3) or misrouting. It is possible that a 1918 valid PATH_RESPONSE might be received in the future. 1920 8.6. Failed Path Validation 1922 Path validation only fails when the endpoint attempting to validate 1923 the path abandons its attempt to validate the path. 1925 Endpoints SHOULD abandon path validation based on a timer. When 1926 setting this timer, implementations are cautioned that the new path 1927 could have a longer round-trip time than the original. A value of 1928 three times the larger of the current Probe Timeout (PTO) or the 1929 initial timeout (that is, 2*kInitialRtt) as defined in 1930 [QUIC-RECOVERY] is RECOMMENDED. That is: 1932 validation_timeout = max(3*PTO, 6*kInitialRtt) 1934 Note that the endpoint might receive packets containing other frames 1935 on the new path, but a PATH_RESPONSE frame with appropriate data is 1936 required for path validation to succeed. 1938 When an endpoint abandons path validation, it determines that the 1939 path is unusable. This does not necessarily imply a failure of the 1940 connection - endpoints can continue sending packets over other paths 1941 as appropriate. If no paths are available, an endpoint can wait for 1942 a new path to become available or close the connection. 1944 A path validation might be abandoned for other reasons besides 1945 failure. Primarily, this happens if a connection migration to a new 1946 path is initiated while a path validation on the old path is in 1947 progress. 1949 9. Connection Migration 1951 The use of a connection ID allows connections to survive changes to 1952 endpoint addresses (that is, IP address and/or port), such as those 1953 caused by an endpoint migrating to a new network. This section 1954 describes the process by which an endpoint migrates to a new address. 1956 An endpoint MUST NOT initiate connection migration before the 1957 handshake is finished and the endpoint has 1-RTT keys. The design of 1958 QUIC relies on endpoints retaining a stable address for the duration 1959 of the handshake. 1961 An endpoint also MUST NOT initiate connection migration if the peer 1962 sent the "disable_migration" transport parameter during the 1963 handshake. An endpoint which has sent this transport parameter, but 1964 detects that a peer has nonetheless migrated to a different network 1965 MAY treat this as a connection error of type INVALID_MIGRATION. 1966 Similarly, an endpoint MUST NOT initiate migration if its peer 1967 supplies a zero-length connection ID as packets without a Destination 1968 Connection ID cannot be attributed to a connection based on address 1969 tuple. 1971 Not all changes of peer address are intentional migrations. The peer 1972 could experience NAT rebinding: a change of address due to a 1973 middlebox, usually a NAT, allocating a new outgoing port or even a 1974 new outgoing IP address for a flow. NAT rebinding is not connection 1975 migration as defined in this section, though an endpoint SHOULD 1976 perform path validation (Section 8.2) if it detects a change in the 1977 IP address of its peer. 1979 When an endpoint has no validated path on which to send packets, it 1980 MAY discard connection state. An endpoint capable of connection 1981 migration MAY wait for a new path to become available before 1982 discarding connection state. 1984 This document limits migration of connections to new client 1985 addresses, except as described in Section 9.6. Clients are 1986 responsible for initiating all migrations. Servers do not send non- 1987 probing packets (see Section 9.1) toward a client address until they 1988 see a non-probing packet from that address. If a client receives 1989 packets from an unknown server address, the client MUST discard these 1990 packets. 1992 9.1. Probing a New Path 1994 An endpoint MAY probe for peer reachability from a new local address 1995 using path validation Section 8.2 prior to migrating the connection 1996 to the new local address. Failure of path validation simply means 1997 that the new path is not usable for this connection. Failure to 1998 validate a path does not cause the connection to end unless there are 1999 no valid alternative paths available. 2001 An endpoint uses a new connection ID for probes sent from a new local 2002 address, see Section 9.5 for further discussion. An endpoint that 2003 uses a new local address needs to ensure that at least one new 2004 connection ID is available at the peer. That can be achieved by 2005 including a NEW_CONNECTION_ID frame in the probe. 2007 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2008 is probing for reachability on a path. An endpoint sends a 2009 PATH_RESPONSE in response as per Section 8.2. 2011 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2012 are "probing frames", and all other frames are "non-probing frames". 2013 A packet containing only probing frames is a "probing packet", and a 2014 packet containing any other frame is a "non-probing packet". 2016 9.2. Initiating Connection Migration 2018 An endpoint can migrate a connection to a new local address by 2019 sending packets containing non-probing frames from that address. 2021 Each endpoint validates its peer's address during connection 2022 establishment. Therefore, a migrating endpoint can send to its peer 2023 knowing that the peer is willing to receive at the peer's current 2024 address. Thus an endpoint can migrate to a new local address without 2025 first validating the peer's address. 2027 When migrating, the new path might not support the endpoint's current 2028 sending rate. Therefore, the endpoint resets its congestion 2029 controller, as described in Section 9.4. 2031 The new path might not have the same ECN capability. Therefore, the 2032 endpoint verifies ECN capability as described in Section 13.3. 2034 Receiving acknowledgments for data sent on the new path serves as 2035 proof of the peer's reachability from the new address. Note that 2036 since acknowledgments may be received on any path, return 2037 reachability on the new path is not established. To establish return 2038 reachability on the new path, an endpoint MAY concurrently initiate 2039 path validation Section 8.2 on the new path. 2041 9.3. Responding to Connection Migration 2043 Receiving a packet from a new peer address containing a non-probing 2044 frame indicates that the peer has migrated to that address. 2046 In response to such a packet, an endpoint MUST start sending 2047 subsequent packets to the new peer address and MUST initiate path 2048 validation (Section 8.2) to verify the peer's ownership of the 2049 unvalidated address. 2051 An endpoint MAY send data to an unvalidated peer address, but it MUST 2052 protect against potential attacks as described in Section 9.3.1 and 2053 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2054 that address has been seen recently. 2056 An endpoint only changes the address that it sends packets to in 2057 response to the highest-numbered non-probing packet. This ensures 2058 that an endpoint does not send packets to an old peer address in the 2059 case that it receives reordered packets. 2061 After changing the address to which it sends non-probing packets, an 2062 endpoint could abandon any path validation for other addresses. 2064 Receiving a packet from a new peer address might be the result of a 2065 NAT rebinding at the peer. 2067 After verifying a new client address, the server SHOULD send new 2068 address validation tokens (Section 8) to the client. 2070 9.3.1. Peer Address Spoofing 2072 It is possible that a peer is spoofing its source address to cause an 2073 endpoint to send excessive amounts of data to an unwilling host. If 2074 the endpoint sends significantly more data than the spoofing peer, 2075 connection migration might be used to amplify the volume of data that 2076 an attacker can generate toward a victim. 2078 As described in Section 9.3, an endpoint is required to validate a 2079 peer's new address to confirm the peer's possession of the new 2080 address. Until a peer's address is deemed valid, an endpoint MUST 2081 limit the rate at which it sends data to this address. The endpoint 2082 MUST NOT send more than a minimum congestion window's worth of data 2083 per estimated round-trip time (kMinimumWindow, as defined in 2084 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2085 being used for a denial of service attack against an unsuspecting 2086 victim. Note that since the endpoint will not have any round-trip 2087 time measurements to this address, the estimate SHOULD be the default 2088 initial value (see [QUIC-RECOVERY]). 2090 If an endpoint skips validation of a peer address as described in 2091 Section 9.3, it does not need to limit its sending rate. 2093 9.3.2. On-Path Address Spoofing 2095 An on-path attacker could cause a spurious connection migration by 2096 copying and forwarding a packet with a spoofed address such that it 2097 arrives before the original packet. The packet with the spoofed 2098 address will be seen to come from a migrating connection, and the 2099 original packet will be seen as a duplicate and dropped. After a 2100 spurious migration, validation of the source address will fail 2101 because the entity at the source address does not have the necessary 2102 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2103 that is sent to it even if it wanted to. 2105 To protect the connection from failing due to such a spurious 2106 migration, an endpoint MUST revert to using the last validated peer 2107 address when validation of a new peer address fails. 2109 If an endpoint has no state about the last validated peer address, it 2110 MUST close the connection silently by discarding all connection 2111 state. This results in new packets on the connection being handled 2112 generically. For instance, an endpoint MAY send a stateless reset in 2113 response to any further incoming packets. 2115 Note that receipt of packets with higher packet numbers from the 2116 legitimate peer address will trigger another connection migration. 2117 This will cause the validation of the address of the spurious 2118 migration to be abandoned. 2120 9.3.3. Off-Path Packet Forwarding 2122 An off-path attacker that can observe packets might forward copies of 2123 genuine packets to endpoints. If the copied packet arrives before 2124 the genuine packet, this will appear as a NAT rebinding. Any genuine 2125 packet will be discarded as a duplicate. If the attacker is able to 2126 continue forwarding packets, it might be able to cause migration to a 2127 path via the attacker. This places the attacker on path, giving it 2128 the ability to observe or drop all subsequent packets. 2130 Unlike the attack described in Section 9.3.2, the attacker can ensure 2131 that the new path is successfully validated. 2133 This style of attack relies on the attacker using a path that is 2134 approximately as fast as the direct path between endpoints. The 2135 attack is more reliable if relatively few packets are sent or if 2136 packet loss coincides with the attempted attack. 2138 A non-probing packet received on the original path that increases the 2139 maximum received packet number will cause the endpoint to move back 2140 to that path. Eliciting packets on this path increases the 2141 likelihood that the attack is unsuccessful. Therefore, mitigation of 2142 this attack relies on triggering the exchange of packets. 2144 In response to an apparent migration, endpoints MUST validate the 2145 previously active path using a PATH_CHALLENGE frame. This induces 2146 the sending of new packets on that path. If the path is no longer 2147 viable, the validation attempt will time out and fail; if the path is 2148 viable, but no longer desired, the validation will succeed, but only 2149 results in probing packets being sent on the path. 2151 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2152 send a non-probing packet in response. If the non-probing packet 2153 arrives before any copy made by an attacker, this results in the 2154 connection being migrated back to the original path. Any subsequent 2155 migration to another path restarts this entire process. 2157 This defense is imperfect, but this is not considered a serious 2158 problem. If the path via the attack is reliably faster than the 2159 original path despite multiple attempts to use that original path, it 2160 is not possible to distinguish between attack and an improvement in 2161 routing. 2163 An endpoint could also use heuristics to improve detection of this 2164 style of attack. For instance, NAT rebinding is improbable if 2165 packets were recently received on the old path, similarly rebinding 2166 is rare on IPv6 paths. Endpoints can also look for duplicated 2167 packets. Conversely, a change in connection ID is more likely to 2168 indicate an intentional migration rather than an attack. 2170 9.4. Loss Detection and Congestion Control 2172 The capacity available on the new path might not be the same as the 2173 old path. Packets sent on the old path SHOULD NOT contribute to 2174 congestion control or RTT estimation for the new path. 2176 On confirming a peer's ownership of its new address, an endpoint 2177 SHOULD immediately reset the congestion controller and round-trip 2178 time estimator for the new path. 2180 An endpoint MUST NOT return to the send rate used for the previous 2181 path unless it is reasonably sure that the previous send rate is 2182 valid for the new path. For instance, a change in the client's port 2183 number is likely indicative of a rebinding in a middlebox and not a 2184 complete change in path. This determination likely depends on 2185 heuristics, which could be imperfect; if the new path capacity is 2186 significantly reduced, ultimately this relies on the congestion 2187 controller responding to congestion signals and reducing send rates 2188 appropriately. 2190 There may be apparent reordering at the receiver when an endpoint 2191 sends data and probes from/to multiple addresses during the migration 2192 period, since the two resulting paths may have different round-trip 2193 times. A receiver of packets on multiple paths will still send ACK 2194 frames covering all received packets. 2196 While multiple paths might be used during connection migration, a 2197 single congestion control context and a single loss recovery context 2198 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2199 endpoint might delay switching to a new congestion control context 2200 until it is confirmed that an old path is no longer needed (such as 2201 the case in Section 9.3.3). 2203 A sender can make exceptions for probe packets so that their loss 2204 detection is independent and does not unduly cause the congestion 2205 controller to reduce its sending rate. An endpoint might set a 2206 separate timer when a PATH_CHALLENGE is sent, which is cancelled when 2207 the corresponding PATH_RESPONSE is received. If the timer fires 2208 before the PATH_RESPONSE is received, the endpoint might send a new 2209 PATH_CHALLENGE, and restart the timer for a longer period of time. 2211 9.5. Privacy Implications of Connection Migration 2213 Using a stable connection ID on multiple network paths allows a 2214 passive observer to correlate activity between those paths. An 2215 endpoint that moves between networks might not wish to have their 2216 activity correlated by any entity other than their peer, so different 2217 connection IDs are used when sending from different local addresses, 2218 as discussed in Section 5.1. For this to be effective endpoints need 2219 to ensure that connections IDs they provide cannot be linked by any 2220 other entity. 2222 At any time, endpoints MAY change the Destination Connection ID they 2223 send to a value that has not been used on another path. 2225 An endpoint MUST use a new connection ID if it initiates connection 2226 migration. Using a new connection ID eliminates the use of the 2227 connection ID for linking activity from the same connection on 2228 different networks. Header protection ensures that packet numbers 2229 cannot be used to correlate activity. This does not prevent other 2230 properties of packets, such as timing and size, from being used to 2231 correlate activity. 2233 Unintentional changes in path without a change in connection ID are 2234 possible. For example, after a period of network inactivity, NAT 2235 rebinding might cause packets to be sent on a new path when the 2236 client resumes sending. 2238 A client might wish to reduce linkability by employing a new 2239 connection ID and source UDP port when sending traffic after a period 2240 of inactivity. Changing the UDP port from which it sends packets at 2241 the same time might cause the packet to appear as a connection 2242 migration. This ensures that the mechanisms that support migration 2243 are exercised even for clients that don't experience NAT rebindings 2244 or genuine migrations. Changing port number can cause a peer to 2245 reset its congestion state (see Section 9.4), so the port SHOULD only 2246 be changed infrequently. 2248 An endpoint that exhausts available connection IDs cannot migrate. 2249 To ensure that migration is possible and packets sent on different 2250 paths cannot be correlated, endpoints SHOULD provide new connection 2251 IDs before peers migrate. 2253 9.6. Server's Preferred Address 2255 QUIC allows servers to accept connections on one IP address and 2256 attempt to transfer these connections to a more preferred address 2257 shortly after the handshake. This is particularly useful when 2258 clients initially connect to an address shared by multiple servers 2259 but would prefer to use a unicast address to ensure connection 2260 stability. This section describes the protocol for migrating a 2261 connection to a preferred server address. 2263 Migrating a connection to a new server address mid-connection is left 2264 for future work. If a client receives packets from a new server 2265 address not indicated by the preferred_address transport parameter, 2266 the client SHOULD discard these packets. 2268 9.6.1. Communicating A Preferred Address 2270 A server conveys a preferred address by including the 2271 preferred_address transport parameter in the TLS handshake. 2273 Servers MAY communicate a preferred address of each address family 2274 (IPv4 and IPv6) to allow clients to pick the one most suited to their 2275 network attachment. 2277 Once the handshake is finished, the client SHOULD select one of the 2278 two server's preferred addresses and initiate path validation (see 2279 Section 8.2) of that address using the connection ID provided in the 2280 preferred_address transport parameter. 2282 If path validation succeeds, the client SHOULD immediately begin 2283 sending all future packets to the new server address using the new 2284 connection ID and discontinue use of the old server address. If path 2285 validation fails, the client MUST continue sending all future packets 2286 to the server's original IP address. 2288 9.6.2. Responding to Connection Migration 2290 A server might receive a packet addressed to its preferred IP address 2291 at any time after it accepts a connection. If this packet contains a 2292 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2293 Section 8.2. The server MUST send other non-probing frames from its 2294 original address until it receives a non-probing packet from the 2295 client at its preferred address and until the server has validated 2296 the new path. 2298 The server MUST probe on the path toward the client from its 2299 preferred address. This helps to guard against spurious migration 2300 initiated by an attacker. 2302 Once the server has completed its path validation and has received a 2303 non-probing packet with a new largest packet number on its preferred 2304 address, the server begins sending non-probing packets to the client 2305 exclusively from its preferred IP address. It SHOULD drop packets 2306 for this connection received on the old IP address, but MAY continue 2307 to process delayed packets. 2309 9.6.3. Interaction of Client Migration and Preferred Address 2311 A client might need to perform a connection migration before it has 2312 migrated to the server's preferred address. In this case, the client 2313 SHOULD perform path validation to both the original and preferred 2314 server address from the client's new address concurrently. 2316 If path validation of the server's preferred address succeeds, the 2317 client MUST abandon validation of the original address and migrate to 2318 using the server's preferred address. If path validation of the 2319 server's preferred address fails but validation of the server's 2320 original address succeeds, the client MAY migrate to its new address 2321 and continue sending to the server's original address. 2323 If the connection to the server's preferred address is not from the 2324 same client address, the server MUST protect against potential 2325 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2326 to intentional simultaneous migration, this might also occur because 2327 the client's access network used a different NAT binding for the 2328 server's preferred address. 2330 Servers SHOULD initiate path validation to the client's new address 2331 upon receiving a probe packet from a different address. Servers MUST 2332 NOT send more than a minimum congestion window's worth of non-probing 2333 packets to the new address before path validation is complete. 2335 A client that migrates to a new address SHOULD use a preferred 2336 address from the same address family for the server. 2338 9.7. Use of IPv6 Flow-Label and Migration 2340 Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label 2341 in compliance with [RFC6437], unless the local API does not allow 2342 setting IPv6 flow labels. 2344 The IPv6 flow label SHOULD be a pseudo-random function of the source 2345 and destination addresses, source and destination UDP ports, and the 2346 destination CID. The flow label generation MUST be designed to 2347 minimize the chances of linkability with a previously used flow 2348 label, as this would enable correlating activity on multiple paths 2349 (see Section 9.5). 2351 A possible implementation is to compute the flow label as a 2352 cryptographic hash function of the source and destination addresses, 2353 source and destination UDP ports, destination CID, and a local 2354 secret. 2356 10. Connection Termination 2358 An established QUIC connection can be terminated in one of three 2359 ways: 2361 o idle timeout (Section 10.2) 2363 o immediate close (Section 10.3) 2365 o stateless reset (Section 10.4) 2367 An endpoint MAY discard connection state if it does not have a 2368 validated path on which it can send packets (see Section 8.2). 2370 10.1. Closing and Draining Connection States 2372 The closing and draining connection states exist to ensure that 2373 connections close cleanly and that delayed or reordered packets are 2374 properly discarded. These states SHOULD persist for at least three 2375 times the current Probe Timeout (PTO) interval as defined in 2376 [QUIC-RECOVERY]. 2378 An endpoint enters a closing period after initiating an immediate 2379 close (Section 10.3). While closing, an endpoint MUST NOT send 2380 packets unless they contain a CONNECTION_CLOSE frame (see 2381 Section 10.3 for details). An endpoint retains only enough 2382 information to generate a packet containing a CONNECTION_CLOSE frame 2383 and to identify packets as belonging to the connection. The 2384 endpoint's selected connection ID and the QUIC version are sufficient 2385 information to identify packets for a closing connection; an endpoint 2386 can discard all other connection state. An endpoint MAY retain 2387 packet protection keys for incoming packets to allow it to read and 2388 process a CONNECTION_CLOSE frame. 2390 The draining state is entered once an endpoint receives a signal that 2391 its peer is closing or draining. While otherwise identical to the 2392 closing state, an endpoint in the draining state MUST NOT send any 2393 packets. Retaining packet protection keys is unnecessary once a 2394 connection is in the draining state. 2396 An endpoint MAY transition from the closing period to the draining 2397 period if it receives a CONNECTION_CLOSE frame or stateless reset, 2398 both of which indicate that the peer is also closing or draining. 2399 The draining period SHOULD end when the closing period would have 2400 ended. In other words, the endpoint can use the same end time, but 2401 cease retransmission of the closing packet. 2403 Disposing of connection state prior to the end of the closing or 2404 draining period could cause delayed or reordered packets to be 2405 handled poorly. Endpoints that have some alternative means to ensure 2406 that late-arriving packets on the connection do not create QUIC 2407 state, such as those that are able to close the UDP socket, MAY use 2408 an abbreviated draining period which can allow for faster resource 2409 recovery. Servers that retain an open socket for accepting new 2410 connections SHOULD NOT exit the closing or draining period early. 2412 Once the closing or draining period has ended, an endpoint SHOULD 2413 discard all connection state. This results in new packets on the 2414 connection being handled generically. For instance, an endpoint MAY 2415 send a stateless reset in response to any further incoming packets. 2417 The draining and closing periods do not apply when a stateless reset 2418 (Section 10.4) is sent. 2420 An endpoint is not expected to handle key updates when it is closing 2421 or draining. A key update might prevent the endpoint from moving 2422 from the closing state to draining, but it otherwise has no impact. 2424 While in the closing period, an endpoint could receive packets from a 2425 new source address, indicating a connection migration (Section 9). 2427 An endpoint in the closing state MUST strictly limit the number of 2428 packets it sends to this new address until the address is validated 2429 (see Section 8.2). A server in the closing state MAY instead choose 2430 to discard packets received from a new source address. 2432 10.2. Idle Timeout 2434 If the idle timeout is enabled, a connection is silently closed and 2435 the state is discarded when it remains idle for longer than both the 2436 advertised idle timeout (see Section 18.1) and three times the 2437 current Probe Timeout (PTO). 2439 Each endpoint advertises its own idle timeout to its peer. An 2440 endpoint restarts any timer it maintains when a packet from its peer 2441 is received and processed successfully. The timer is also restarted 2442 when sending a packet containing frames other than ACK or PADDING (an 2443 ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK- 2444 eliciting packets have been sent since last receiving a packet. 2445 Restarting when sending packets ensures that connections do not 2446 prematurely time out when initiating new activity. 2448 The value for an idle timeout can be asymmetric. The value 2449 advertised by an endpoint is only used to determine whether the 2450 connection is live at that endpoint. An endpoint that sends packets 2451 near the end of the idle timeout period of a peer risks having those 2452 packets discarded if its peer enters the draining state before the 2453 packets arrive. If a peer could timeout within an Probe Timeout 2454 (PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test 2455 for liveness before sending any data that cannot be retried safely. 2456 Note that it is likely that only applications or application 2457 protocols will know what information can be retried. 2459 10.3. Immediate Close 2461 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 2462 terminate the connection immediately. A CONNECTION_CLOSE frame 2463 causes all streams to immediately become closed; open streams can be 2464 assumed to be implicitly reset. 2466 After sending a CONNECTION_CLOSE frame, endpoints immediately enter 2467 the closing state. During the closing period, an endpoint that sends 2468 a CONNECTION_CLOSE frame SHOULD respond to any packet that it 2469 receives with another packet containing a CONNECTION_CLOSE frame. To 2470 minimize the state that an endpoint maintains for a closing 2471 connection, endpoints MAY send the exact same packet. However, 2472 endpoints SHOULD limit the number of packets they generate containing 2473 a CONNECTION_CLOSE frame. For instance, an endpoint could 2474 progressively increase the number of packets that it receives before 2475 sending additional packets or increase the time between packets. 2477 Note: Allowing retransmission of a closing packet contradicts other 2478 advice in this document that recommends the creation of new packet 2479 numbers for every packet. Sending new packet numbers is primarily 2480 of advantage to loss recovery and congestion control, which are 2481 not expected to be relevant for a closed connection. 2482 Retransmitting the final packet requires less state. 2484 New packets from unverified addresses could be used to create an 2485 amplification attack (see Section 8). To avoid this, endpoints MUST 2486 either limit transmission of CONNECTION_CLOSE frames to validated 2487 addresses or drop packets without response if the response would be 2488 more than three times larger than the received packet. 2490 After receiving a CONNECTION_CLOSE frame, endpoints enter the 2491 draining state. An endpoint that receives a CONNECTION_CLOSE frame 2492 MAY send a single packet containing a CONNECTION_CLOSE frame before 2493 entering the draining state, using a CONNECTION_CLOSE frame and a 2494 NO_ERROR code if appropriate. An endpoint MUST NOT send further 2495 packets, which could result in a constant exchange of 2496 CONNECTION_CLOSE frames until the closing period on either peer 2497 ended. 2499 An immediate close can be used after an application protocol has 2500 arranged to close a connection. This might be after the application 2501 protocols negotiates a graceful shutdown. The application protocol 2502 exchanges whatever messages that are needed to cause both endpoints 2503 to agree to close the connection, after which the application 2504 requests that the connection be closed. The application protocol can 2505 use an CONNECTION_CLOSE frame with an appropriate error code to 2506 signal closure. 2508 If the connection has been successfully established, endpoints MUST 2509 send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to 2510 connection establishment a peer might not have 1-RTT keys, so 2511 endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. 2512 If the endpoint does not have Handshake keys, or it is not certain 2513 that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames 2514 in an Initial packet. If multiple packets are sent, they can be 2515 coalesced (see Section 12.2) to facilitate retransmission. 2517 10.4. Stateless Reset 2519 A stateless reset is provided as an option of last resort for an 2520 endpoint that does not have access to the state of a connection. A 2521 crash or outage might result in peers continuing to send data to an 2522 endpoint that is unable to properly continue the connection. A 2523 stateless reset is not appropriate for signaling error conditions. 2524 An endpoint that wishes to communicate a fatal connection error MUST 2525 use a CONNECTION_CLOSE frame if it has sufficient state to do so. 2527 To support this process, a token is sent by endpoints. The token is 2528 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2529 servers can specify the stateless_reset_token transport parameter 2530 during the handshake (clients cannot because their transport 2531 parameters don't have confidentiality protection). This value is 2532 protected by encryption, so only client and server know this value. 2533 Tokens are invalidated when their associated connection ID is retired 2534 via a RETIRE_CONNECTION_ID frame (Section 19.16). 2536 An endpoint that receives packets that it cannot process sends a 2537 packet in the following layout: 2539 0 1 2 3 2540 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 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 |0|1| Unpredictable Bits (182..) ... 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 | | 2545 + + 2546 | | 2547 + Stateless Reset Token (128) + 2548 | | 2549 + + 2550 | | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 Figure 6: Stateless Reset Packet 2555 This design ensures that a stateless reset packet is - to the extent 2556 possible - indistinguishable from a regular packet with a short 2557 header. 2559 A stateless reset uses an entire UDP datagram, starting with the 2560 first two bits of the packet header. The remainder of the first byte 2561 and an arbitrary number of bytes following it that are set to 2562 unpredictable values. The last 16 bytes of the datagram contain a 2563 Stateless Reset Token. 2565 A stateless reset will be interpreted by a recipient as a packet with 2566 a short header. For the packet to appear as valid, the Unpredictable 2567 Bits field needs to include at least 182 bits of data (or 23 bytes, 2568 less the two fixed bits). This is intended to allow for a 2569 Destination Connection ID of the maximum length permitted, with a 2570 minimal packet number, and payload. The Stateless Reset Token 2571 corresponds to the minimum expansion of the packet protection AEAD. 2572 More unpredictable bytes might be necessary if the endpoint could 2573 have negotiated a packet protection scheme with a larger minimum AEAD 2574 expansion. 2576 An endpoint SHOULD NOT send a stateless reset that is significantly 2577 larger than the packet it receives. Endpoints MUST discard packets 2578 that are too small to be valid QUIC packets. With the set of AEAD 2579 functions defined in [QUIC-TLS], packets that are smaller than 21 2580 bytes are never valid. 2582 An endpoint MAY send a stateless reset in response to a packet with a 2583 long header. This would not be effective if the stateless reset 2584 token was not yet available to a peer. In this QUIC version, packets 2585 with a long header are only used during connection establishment. 2586 Because the stateless reset token is not available until connection 2587 establishment is complete or near completion, ignoring an unknown 2588 packet with a long header might be more effective. 2590 An endpoint cannot determine the Source Connection ID from a packet 2591 with a short header, therefore it cannot set the Destination 2592 Connection ID in the stateless reset packet. The Destination 2593 Connection ID will therefore differ from the value used in previous 2594 packets. A random Destination Connection ID makes the connection ID 2595 appear to be the result of moving to a new connection ID that was 2596 provided using a NEW_CONNECTION_ID frame (Section 19.15). 2598 Using a randomized connection ID results in two problems: 2600 o The packet might not reach the peer. If the Destination 2601 Connection ID is critical for routing toward the peer, then this 2602 packet could be incorrectly routed. This might also trigger 2603 another Stateless Reset in response, see Section 10.4.3. A 2604 Stateless Reset that is not correctly routed is an ineffective 2605 error detection and recovery mechanism. In this case, endpoints 2606 will need to rely on other methods - such as timers - to detect 2607 that the connection has failed. 2609 o The randomly generated connection ID can be used by entities other 2610 than the peer to identify this as a potential stateless reset. An 2611 endpoint that occasionally uses different connection IDs might 2612 introduce some uncertainty about this. 2614 Finally, the last 16 bytes of the packet are set to the value of the 2615 Stateless Reset Token. 2617 This stateless reset design is specific to QUIC version 1. An 2618 endpoint that supports multiple versions of QUIC needs to generate a 2619 stateless reset that will be accepted by peers that support any 2620 version that the endpoint might support (or might have supported 2621 prior to losing state). Designers of new versions of QUIC need to be 2622 aware of this and either reuse this design, or use a portion of the 2623 packet other than the last 16 bytes for carrying data. 2625 10.4.1. Detecting a Stateless Reset 2627 An endpoint detects a potential stateless reset when a incoming 2628 packet with a short header either cannot be associated with a 2629 connection, cannot be decrypted, or is marked as a duplicate packet. 2630 The endpoint then compares the last 16 bytes of the packet with the 2631 Stateless Reset Token provided by its peer, either in a 2632 NEW_CONNECTION_ID frame or the server's transport parameters. If 2633 these values are identical, the endpoint MUST enter the draining 2634 period and not send any further packets on this connection. If the 2635 comparison fails, the packet can be discarded. 2637 10.4.2. Calculating a Stateless Reset Token 2639 The stateless reset token MUST be difficult to guess. In order to 2640 create a Stateless Reset Token, an endpoint could randomly generate 2641 [RFC4086] a secret for every connection that it creates. However, 2642 this presents a coordination problem when there are multiple 2643 instances in a cluster or a storage problem for an endpoint that 2644 might lose state. Stateless reset specifically exists to handle the 2645 case where state is lost, so this approach is suboptimal. 2647 A single static key can be used across all connections to the same 2648 endpoint by generating the proof using a second iteration of a 2649 preimage-resistant function that takes a static key and the 2650 connection ID chosen by the endpoint (see Section 5.1) as input. An 2651 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2652 connection_id)) or HKDF [RFC5869] (for example, using the static key 2653 as input keying material, with the connection ID as salt). The 2654 output of this function is truncated to 16 bytes to produce the 2655 Stateless Reset Token for that connection. 2657 An endpoint that loses state can use the same method to generate a 2658 valid Stateless Reset Token. The connection ID comes from the packet 2659 that the endpoint receives. 2661 This design relies on the peer always sending a connection ID in its 2662 packets so that the endpoint can use the connection ID from a packet 2663 to reset the connection. An endpoint that uses this design MUST 2664 either use the same connection ID length for all connections or 2665 encode the length of the connection ID such that it can be recovered 2666 without state. In addition, it cannot provide a zero-length 2667 connection ID. 2669 Revealing the Stateless Reset Token allows any entity to terminate 2670 the connection, so a value can only be used once. This method for 2671 choosing the Stateless Reset Token means that the combination of 2672 connection ID and static key cannot occur for another connection. A 2673 denial of service attack is possible if the same connection ID is 2674 used by instances that share a static key, or if an attacker can 2675 cause a packet to be routed to an instance that has no state but the 2676 same static key (see Section 21.8). A connection ID from a 2677 connection that is reset by revealing the Stateless Reset Token 2678 cannot be reused for new connections at nodes that share a static 2679 key. 2681 Note that Stateless Reset packets do not have any cryptographic 2682 protection. 2684 10.4.3. Looping 2686 The design of a Stateless Reset is such that without knowing the 2687 stateless reset token it is indistinguishable from a valid packet. 2688 For instance, if a server sends a Stateless Reset to another server 2689 it might receive another Stateless Reset in response, which could 2690 lead to an infinite exchange. 2692 An endpoint MUST ensure that every Stateless Reset that it sends is 2693 smaller than the packet which triggered it, unless it maintains state 2694 sufficient to prevent looping. In the event of a loop, this results 2695 in packets eventually being too small to trigger a response. 2697 An endpoint can remember the number of Stateless Reset packets that 2698 it has sent and stop generating new Stateless Reset packets once a 2699 limit is reached. Using separate limits for different remote 2700 addresses will ensure that Stateless Reset packets can be used to 2701 close connections when other peers or connections have exhausted 2702 limits. 2704 Reducing the size of a Stateless Reset below the recommended minimum 2705 size of 39 bytes could mean that the packet could reveal to an 2706 observer that it is a Stateless Reset. Conversely, refusing to send 2707 a Stateless Reset in response to a small packet might result in 2708 Stateless Reset not being useful in detecting cases of broken 2709 connections where only very small packets are sent; such failures 2710 might only be detected by other means, such as timers. 2712 An endpoint can increase the odds that a packet will trigger a 2713 Stateless Reset if it cannot be processed by padding it to at least 2714 40 bytes. 2716 11. Error Handling 2718 An endpoint that detects an error SHOULD signal the existence of that 2719 error to its peer. Both transport-level and application-level errors 2720 can affect an entire connection (see Section 11.1), while only 2721 application-level errors can be isolated to a single stream (see 2722 Section 11.2). 2724 The most appropriate error code (Section 20) SHOULD be included in 2725 the frame that signals the error. Where this specification 2726 identifies error conditions, it also identifies the error code that 2727 is used. 2729 A stateless reset (Section 10.4) is not suitable for any error that 2730 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 2731 stateless reset MUST NOT be used by an endpoint that has the state 2732 necessary to send a frame on the connection. 2734 11.1. Connection Errors 2736 Errors that result in the connection being unusable, such as an 2737 obvious violation of protocol semantics or corruption of state that 2738 affects an entire connection, MUST be signaled using a 2739 CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the 2740 connection in this manner even if the error only affects a single 2741 stream. 2743 Application protocols can signal application-specific protocol errors 2744 using the application-specific variant of the CONNECTION_CLOSE frame. 2745 Errors that are specific to the transport, including all those 2746 described in this document, are carried the QUIC-specific variant of 2747 the CONNECTION_CLOSE frame. 2749 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 2750 endpoint SHOULD be prepared to retransmit a packet containing a 2751 CONNECTION_CLOSE frame if it receives more packets on a terminated 2752 connection. Limiting the number of retransmissions and the time over 2753 which this final packet is sent limits the effort expended on 2754 terminated connections. 2756 An endpoint that chooses not to retransmit packets containing a 2757 CONNECTION_CLOSE frame risks a peer missing the first such packet. 2758 The only mechanism available to an endpoint that continues to receive 2759 data for a terminated connection is to use the stateless reset 2760 process (Section 10.4). 2762 An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT 2763 signal the existence of the error to its peer. 2765 11.2. Stream Errors 2767 If an application-level error affects a single stream, but otherwise 2768 leaves the connection in a recoverable state, the endpoint can send a 2769 RESET_STREAM frame (Section 19.4) with an appropriate error code to 2770 terminate just the affected stream. 2772 RESET_STREAM MUST be instigated by the protocol using QUIC, either 2773 directly or through the receipt of a STOP_SENDING frame from a peer. 2774 RESET_STREAM carries an application error code. Resetting a stream 2775 without knowledge of the application protocol could cause the 2776 protocol to enter an unrecoverable state. Application protocols 2777 might require certain streams to be reliably delivered in order to 2778 guarantee consistent state between endpoints. 2780 12. Packets and Frames 2782 QUIC endpoints communicate by exchanging packets. Packets have 2783 confidentiality and integrity protection (see Section 12.1) and are 2784 carried in UDP datagrams (see Section 12.2). 2786 This version of QUIC uses the long packet header (see Section 17.2) 2787 during connection establishment. Packets with the long header are 2788 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake 2789 (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation 2790 uses a version-independent packet with a long header (see 2791 Section 17.2.1). 2793 Packets with the short header (Section 17.3) are designed for minimal 2794 overhead and are used after a connection is established and 1-RTT 2795 keys are available. 2797 12.1. Protected Packets 2799 All QUIC packets except Version Negotiation and Retry packets use 2800 authenticated encryption with additional data (AEAD) [RFC5116] to 2801 provide confidentiality and integrity protection. Details of packet 2802 protection are found in [QUIC-TLS]; this section includes an overview 2803 of the process. 2805 Initial packets are protected using keys that are statically derived. 2806 This packet protection is not effective confidentiality protection. 2808 Initial protection only exists to ensure that the sender of the 2809 packet is on the network path. Any entity that receives the Initial 2810 packet from a client can recover the keys necessary to remove packet 2811 protection or to generate packets that will be successfully 2812 authenticated. 2814 All other packets are protected with keys derived from the 2815 cryptographic handshake. The type of the packet from the long header 2816 or key phase from the short header are used to identify which 2817 encryption level - and therefore the keys - that are used. Packets 2818 protected with 0-RTT and 1-RTT keys are expected to have 2819 confidentiality and data origin authentication; the cryptographic 2820 handshake ensures that only the communicating endpoints receive the 2821 corresponding keys. 2823 The packet number field contains a packet number, which has 2824 additional confidentiality protection that is applied after packet 2825 protection is applied (see [QUIC-TLS] for details). The underlying 2826 packet number increases with each packet sent in a given packet 2827 number space, see Section 12.3 for details. 2829 12.2. Coalescing Packets 2831 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake 2832 (Section 17.2.4) packets contain a Length field, which determines the 2833 end of the packet. The length includes both the Packet Number and 2834 Payload fields, both of which are confidentiality protected and 2835 initially of unknown length. The length of the Payload field is 2836 learned once header protection is removed. 2838 Using the Length field, a sender can coalesce multiple QUIC packets 2839 into one UDP datagram. This can reduce the number of UDP datagrams 2840 needed to complete the cryptographic handshake and starting sending 2841 data. Receivers MUST be able to process coalesced packets. 2843 Coalescing packets in order of increasing encryption levels (Initial, 2844 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 2845 able to process all the packets in a single pass. A packet with a 2846 short header does not include a length, so it can only be the last 2847 packet included in a UDP datagram. 2849 Senders MUST NOT coalesce QUIC packets for different connections into 2850 a single UDP datagram. Receivers SHOULD ignore any subsequent 2851 packets with a different Destination Connection ID than the first 2852 packet in the datagram. 2854 Every QUIC packet that is coalesced into a single UDP datagram is 2855 separate and complete. Though the values of some fields in the 2856 packet header might be redundant, no fields are omitted. The 2857 receiver of coalesced QUIC packets MUST individually process each 2858 QUIC packet and separately acknowledge them, as if they were received 2859 as the payload of different UDP datagrams. For example, if 2860 decryption fails (because the keys are not available or any other 2861 reason), the receiver MAY either discard or buffer the packet for 2862 later processing and MUST attempt to process the remaining packets. 2864 Retry packets (Section 17.2.5), Version Negotiation packets 2865 (Section 17.2.1), and packets with a short header (Section 17.3) do 2866 not contain a Length field and so cannot be followed by other packets 2867 in the same UDP datagram. 2869 12.3. Packet Numbers 2871 The packet number is an integer in the range 0 to 2^62-1. This 2872 number is used in determining the cryptographic nonce for packet 2873 protection. Each endpoint maintains a separate packet number for 2874 sending and receiving. 2876 Packet numbers are limited to this range because they need to be 2877 representable in whole in the Largest Acknowledged field of an ACK 2878 frame (Section 19.3). When present in a long or short header 2879 however, packet numbers are reduced and encoded in 1 to 4 bytes (see 2880 Section 17.1). 2882 Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) 2883 packets do not include a packet number. 2885 Packet numbers are divided into 3 spaces in QUIC: 2887 o Initial space: All Initial packets (Section 17.2.2) are in this 2888 space. 2890 o Handshake space: All Handshake packets (Section 17.2.4) are in 2891 this space. 2893 o Application data space: All 0-RTT and 1-RTT encrypted packets 2894 (Section 12.1) are in this space. 2896 As described in [QUIC-TLS], each packet type uses different 2897 protection keys. 2899 Conceptually, a packet number space is the context in which a packet 2900 can be processed and acknowledged. Initial packets can only be sent 2901 with Initial packet protection keys and acknowledged in packets which 2902 are also Initial packets. Similarly, Handshake packets are sent at 2903 the Handshake encryption level and can only be acknowledged in 2904 Handshake packets. 2906 This enforces cryptographic separation between the data sent in the 2907 different packet sequence number spaces. Packet numbers in each 2908 space start at packet number 0. Subsequent packets sent in the same 2909 packet number space MUST increase the packet number by at least one. 2911 0-RTT and 1-RTT data exist in the same packet number space to make 2912 loss recovery algorithms easier to implement between the two packet 2913 types. 2915 A QUIC endpoint MUST NOT reuse a packet number within the same packet 2916 number space in one connection. If the packet number for sending 2917 reaches 2^62 - 1, the sender MUST close the connection without 2918 sending a CONNECTION_CLOSE frame or any further packets; an endpoint 2919 MAY send a Stateless Reset (Section 10.4) in response to further 2920 packets that it receives. 2922 A receiver MUST discard a newly unprotected packet unless it is 2923 certain that it has not processed another packet with the same packet 2924 number from the same packet number space. Duplicate suppression MUST 2925 happen after removing packet protection for the reasons described in 2926 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 2927 suppression can be found in Section 3.4.3 of [RFC4303]. 2929 Packet number encoding at a sender and decoding at a receiver are 2930 described in Section 17.1. 2932 12.4. Frames and Frame Types 2934 The payload of QUIC packets, after removing packet protection, 2935 commonly consists of a sequence of frames, as shown in Figure 7. 2936 Version Negotiation, Stateless Reset, and Retry packets do not 2937 contain frames. 2939 0 1 2 3 2940 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 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | Frame 1 (*) ... 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 | Frame 2 (*) ... 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 ... 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 | Frame N (*) ... 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 Figure 7: QUIC Payload 2953 QUIC payloads MUST contain at least one frame, and MAY contain 2954 multiple frames and multiple frame types. 2956 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 2957 packet boundary. Each frame begins with a Frame Type, indicating its 2958 type, followed by additional type-dependent fields: 2960 0 1 2 3 2961 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 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 | Frame Type (i) ... 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | Type-Dependent Fields (*) ... 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 Figure 8: Generic Frame Layout 2970 The frame types defined in this specification are listed in Table 3. 2971 The Frame Type in STREAM frames is used to carry other frame-specific 2972 flags. For all other frames, the Frame Type field simply identifies 2973 the frame. These frames are explained in more detail in Section 19. 2975 +-------------+----------------------+---------------+ 2976 | Type Value | Frame Type Name | Definition | 2977 +-------------+----------------------+---------------+ 2978 | 0x00 | PADDING | Section 19.1 | 2979 | | | | 2980 | 0x01 | PING | Section 19.2 | 2981 | | | | 2982 | 0x02 - 0x03 | ACK | Section 19.3 | 2983 | | | | 2984 | 0x04 | RESET_STREAM | Section 19.4 | 2985 | | | | 2986 | 0x05 | STOP_SENDING | Section 19.5 | 2987 | | | | 2988 | 0x06 | CRYPTO | Section 19.6 | 2989 | | | | 2990 | 0x07 | NEW_TOKEN | Section 19.7 | 2991 | | | | 2992 | 0x08 - 0x0f | STREAM | Section 19.8 | 2993 | | | | 2994 | 0x10 | MAX_DATA | Section 19.9 | 2995 | | | | 2996 | 0x11 | MAX_STREAM_DATA | Section 19.10 | 2997 | | | | 2998 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | 2999 | | | | 3000 | 0x14 | DATA_BLOCKED | Section 19.12 | 3001 | | | | 3002 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | 3003 | | | | 3004 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | 3005 | | | | 3006 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | 3007 | | | | 3008 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | 3009 | | | | 3010 | 0x1a | PATH_CHALLENGE | Section 19.17 | 3011 | | | | 3012 | 0x1b | PATH_RESPONSE | Section 19.18 | 3013 | | | | 3014 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | 3015 +-------------+----------------------+---------------+ 3017 Table 3: Frame Types 3019 All QUIC frames are idempotent in this version of QUIC. That is, a 3020 valid frame does not cause undesirable side effects or errors when 3021 received more than once. 3023 The Frame Type field uses a variable length integer encoding (see 3024 Section 16) with one exception. To ensure simple and efficient 3025 implementations of frame parsing, a frame type MUST use the shortest 3026 possible encoding. Though a two-, four- or eight-byte encoding of 3027 the frame types defined in this document is possible, the Frame Type 3028 field for these frames is encoded on a single byte. For instance, 3029 though 0x4001 is a legitimate two-byte encoding for a variable-length 3030 integer with a value of 1, PING frames are always encoded as a single 3031 byte with the value 0x01. An endpoint MAY treat the receipt of a 3032 frame type that uses a longer encoding than necessary as a connection 3033 error of type PROTOCOL_VIOLATION. 3035 13. Packetization and Reliability 3037 A sender bundles one or more frames in a QUIC packet (see 3038 Section 12.4). 3040 A sender can minimize per-packet bandwidth and computational costs by 3041 bundling as many frames as possible within a QUIC packet. A sender 3042 MAY wait for a short period of time to bundle multiple frames before 3043 sending a packet that is not maximally packed, to avoid sending out 3044 large numbers of small packets. An implementation MAY use knowledge 3045 about application sending behavior or heuristics to determine whether 3046 and for how long to wait. This waiting period is an implementation 3047 decision, and an implementation should be careful to delay 3048 conservatively, since any delay is likely to increase application- 3049 visible latency. 3051 Stream multiplexing is achieved by interleaving STREAM frames from 3052 multiple streams into one or more QUIC packets. A single QUIC packet 3053 can include multiple STREAM frames from one or more streams. 3055 One of the benefits of QUIC is avoidance of head-of-line blocking 3056 across multiple streams. When a packet loss occurs, only streams 3057 with data in that packet are blocked waiting for a retransmission to 3058 be received, while other streams can continue making progress. Note 3059 that when data from multiple streams is bundled into a single QUIC 3060 packet, loss of that packet blocks all those streams from making 3061 progress. Implementations are advised to bundle as few streams as 3062 necessary in outgoing packets without losing transmission efficiency 3063 to underfilled packets. 3065 13.1. Packet Processing and Acknowledgment 3067 A packet MUST NOT be acknowledged until packet protection has been 3068 successfully removed and all frames contained in the packet have been 3069 processed. For STREAM frames, this means the data has been enqueued 3070 in preparation to be received by the application protocol, but it 3071 does not require that data is delivered and consumed. 3073 Once the packet has been fully processed, a receiver acknowledges 3074 receipt by sending one or more ACK frames containing the packet 3075 number of the received packet. 3077 13.1.1. Sending ACK Frames 3079 An endpoint MUST NOT send more than one packet containing only an ACK 3080 frame per received packet that contains frames other than ACK and 3081 PADDING frames. An endpoint MUST NOT send a packet containing only 3082 an ACK frame in response to a packet containing only ACK or PADDING 3083 frames, even if there are packet gaps which precede the received 3084 packet. This prevents an indefinite feedback loop of ACKs. The 3085 endpoint MUST however acknowledge packets containing only ACK or 3086 PADDING frames when sending ACK frames in response to other packets. 3088 Packets containing PADDING frames are considered to be in flight for 3089 congestion control purposes [QUIC-RECOVERY]. Sending only PADDING 3090 frames might cause the sender to become limited by the congestion 3091 controller (as described in [QUIC-RECOVERY]) with no acknowledgments 3092 forthcoming from the receiver. Therefore, a sender SHOULD ensure 3093 that other frames are sent in addition to PADDING frames to elicit 3094 acknowledgments from the receiver. 3096 The receiver's delayed acknowledgment timer SHOULD NOT exceed the 3097 current RTT estimate or the value it indicates in the "max_ack_delay" 3098 transport parameter. This ensures an acknowledgment is sent at least 3099 once per RTT when packets needing acknowledgement are received. The 3100 sender can use the receiver's "max_ack_delay" value in determining 3101 timeouts for timer-based retransmission. 3103 Strategies and implications of the frequency of generating 3104 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 3106 To limit ACK Ranges (see Section 19.3.1) to those that have not yet 3107 been received by the sender, the receiver SHOULD track which ACK 3108 frames have been acknowledged by its peer. The receiver SHOULD 3109 exclude already acknowledged packets from future ACK frames whenever 3110 these packets would unnecessarily contribute to the ACK frame size. 3112 Because ACK frames are not sent in response to ACK-only packets, a 3113 receiver that is only sending ACK frames will only receive 3114 acknowledgements for its packets if the sender includes them in 3115 packets with non-ACK frames. A sender SHOULD bundle ACK frames with 3116 other frames when possible. 3118 To limit receiver state or the size of ACK frames, a receiver MAY 3119 limit the number of ACK Ranges it sends. A receiver can do this even 3120 without receiving acknowledgment of its ACK frames, with the 3121 knowledge this could cause the sender to unnecessarily retransmit 3122 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 3123 lost after sufficiently newer packets are acknowledged. Therefore, 3124 the receiver SHOULD repeatedly acknowledge newly received packets in 3125 preference to packets received in the past. 3127 An endpoint SHOULD treat receipt of an acknowledgment for a packet it 3128 did not send as a connection error of type PROTOCOL_VIOLATION, if it 3129 is able to detect the condition. 3131 13.1.2. ACK Frames and Packet Protection 3133 ACK frames MUST only be carried in a packet that has the same packet 3134 number space as the packet being ACKed (see Section 12.1). For 3135 instance, packets that are protected with 1-RTT keys MUST be 3136 acknowledged in packets that are also protected with 1-RTT keys. 3138 Packets that a client sends with 0-RTT packet protection MUST be 3139 acknowledged by the server in packets protected by 1-RTT keys. This 3140 can mean that the client is unable to use these acknowledgments if 3141 the server cryptographic handshake messages are delayed or lost. 3142 Note that the same limitation applies to other data sent by the 3143 server protected by the 1-RTT keys. 3145 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3146 frames with a reduced delay; see Section 6.2.1 of [QUIC-RECOVERY]. 3148 13.2. Retransmission of Information 3150 QUIC packets that are determined to be lost are not retransmitted 3151 whole. The same applies to the frames that are contained within lost 3152 packets. Instead, the information that might be carried in frames is 3153 sent again in new frames as needed. 3155 New frames and packets are used to carry information that is 3156 determined to have been lost. In general, information is sent again 3157 when a packet containing that information is determined to be lost 3158 and sending ceases when a packet containing that information is 3159 acknowledged. 3161 o Data sent in CRYPTO frames is retransmitted according to the rules 3162 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 3163 CRYPTO frames for Initial and Handshake packets is discarded when 3164 keys for the corresponding encryption level are discarded. 3166 o Application data sent in STREAM frames is retransmitted in new 3167 STREAM frames unless the endpoint has sent a RESET_STREAM for that 3168 stream. Once an endpoint sends a RESET_STREAM frame, no further 3169 STREAM frames are needed. 3171 o The most recent set of acknowledgments are sent in ACK frames. An 3172 ACK frame SHOULD contain all unacknowledged acknowledgments, as 3173 described in Section 13.1.1. 3175 o Cancellation of stream transmission, as carried in a RESET_STREAM 3176 frame, is sent until acknowledged or until all stream data is 3177 acknowledged by the peer (that is, either the "Reset Recvd" or 3178 "Data Recvd" state is reached on the sending part of the stream). 3179 The content of a RESET_STREAM frame MUST NOT change when it is 3180 sent again. 3182 o Similarly, a request to cancel stream transmission, as encoded in 3183 a STOP_SENDING frame, is sent until the receiving part of the 3184 stream enters either a "Data Recvd" or "Reset Recvd" state, see 3185 Section 3.5. 3187 o Connection close signals, including packets that contain 3188 CONNECTION_CLOSE frames, are not sent again when packet loss is 3189 detected, but as described in Section 10. 3191 o The current connection maximum data is sent in MAX_DATA frames. 3192 An updated value is sent in a MAX_DATA frame if the packet 3193 containing the most recently sent MAX_DATA frame is declared lost, 3194 or when the endpoint decides to update the limit. Care is 3195 necessary to avoid sending this frame too often as the limit can 3196 increase frequently and cause an unnecessarily large number of 3197 MAX_DATA frames to be sent. 3199 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3200 frames. Like MAX_DATA, an updated value is sent when the packet 3201 containing the most recent MAX_STREAM_DATA frame for a stream is 3202 lost or when the limit is updated, with care taken to prevent the 3203 frame from being sent too often. An endpoint SHOULD stop sending 3204 MAX_STREAM_DATA frames when the receiving part of the stream 3205 enters a "Size Known" state. 3207 o The limit on streams of a given type is sent in MAX_STREAMS 3208 frames. Like MAX_DATA, an updated value is sent when a packet 3209 containing the most recent MAX_STREAMS for a stream type frame is 3210 declared lost or when the limit is updated, with care taken to 3211 prevent the frame from being sent too often. 3213 o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 3214 and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection 3215 scope, STREAM_DATA_BLOCKED frames have stream scope, and 3216 STREAMS_BLOCKED frames are scoped to a specific stream type. New 3217 frames are sent if packets containing the most recent frame for a 3218 scope is lost, but only while the endpoint is blocked on the 3219 corresponding limit. These frames always include the limit that 3220 is causing blocking at the time that they are transmitted. 3222 o A liveness or path validation check using PATH_CHALLENGE frames is 3223 sent periodically until a matching PATH_RESPONSE frame is received 3224 or until there is no remaining need for liveness or path 3225 validation checking. PATH_CHALLENGE frames include a different 3226 payload each time they are sent. 3228 o Responses to path validation using PATH_RESPONSE frames are sent 3229 just once. A new PATH_CHALLENGE frame will be sent if another 3230 PATH_RESPONSE frame is needed. 3232 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3233 retransmitted if the packet containing them is lost. 3234 Retransmissions of this frame carry the same sequence number 3235 value. Likewise, retired connection IDs are sent in 3236 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3237 containing them is lost. 3239 o PING and PADDING frames contain no information, so lost PING or 3240 PADDING frames do not require repair. 3242 Endpoints SHOULD prioritize retransmission of data over sending new 3243 data, unless priorities specified by the application indicate 3244 otherwise (see Section 2.3). 3246 Even though a sender is encouraged to assemble frames containing up- 3247 to-date information every time it sends a packet, it is not forbidden 3248 to retransmit copies of frames from lost packets. A receiver MUST 3249 accept packets containing an outdated frame, such as a MAX_DATA frame 3250 carrying a smaller maximum data than one found in an older packet. 3252 Upon detecting losses, a sender MUST take appropriate congestion 3253 control action. The details of loss detection and congestion control 3254 are described in [QUIC-RECOVERY]. 3256 13.3. Explicit Congestion Notification 3258 QUIC endpoints can use Explicit Congestion Notification (ECN) 3259 [RFC3168] to detect and respond to network congestion. ECN allows a 3260 network node to indicate congestion in the network by setting a 3261 codepoint in the IP header of a packet instead of dropping it. 3262 Endpoints react to congestion by reducing their sending rate in 3263 response, as described in [QUIC-RECOVERY]. 3265 To use ECN, QUIC endpoints first determine whether a path supports 3266 ECN marking and the peer is able to access the ECN codepoint in the 3267 IP header. A network path does not support ECN if ECN marked packets 3268 get dropped or ECN markings are rewritten on the path. An endpoint 3269 verifies the path, both during connection establishment and when 3270 migrating to a new path (see Section 9). 3272 13.3.1. ECN Counts 3274 On receiving a QUIC packet with an ECT or CE codepoint, an ECN- 3275 enabled endpoint that can access the ECN codepoints from the 3276 enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE 3277 count, and includes these counts in subsequent ACK frames (see 3278 Section 13.1 and Section 19.3). Note that this requires being able 3279 to read the ECN codepoints from the enclosing IP packet, which is not 3280 possible on all platforms. 3282 A packet detected by a receiver as a duplicate does not affect the 3283 receiver's local ECN codepoint counts; see (Section 21.7) for 3284 relevant security concerns. 3286 If an endpoint receives a QUIC packet without an ECT or CE codepoint 3287 in the IP packet header, it responds per Section 13.1 with an ACK 3288 frame without increasing any ECN counts. If an endpoint does not 3289 implement ECN support or does not have access to received ECN 3290 codepoints, it does not increase ECN counts. 3292 Coalesced packets (see Section 12.2) mean that several packets can 3293 share the same IP header. The ECN counter for the ECN codepoint 3294 received in the associated IP header are incremented once for each 3295 QUIC packet, not per enclosing IP packet or UDP datagram. 3297 Each packet number space maintains separate acknowledgement state and 3298 separate ECN counts. For example, if one each of an Initial, 0-RTT, 3299 Handshake, and 1-RTT QUIC packet are coalesced, the corresponding 3300 counts for the Initial and Handshake packet number space will be 3301 incremented by one and the counts for the 1-RTT packet number space 3302 will be increased by two. 3304 13.3.2. ECN Verification 3306 Each endpoint independently verifies and enables use of ECN by 3307 setting the IP header ECN codepoint to ECN Capable Transport (ECT) 3308 for the path from it to the other peer. Even if not setting ECN 3309 codepoints on packets it transmits, the endpoint SHOULD provide 3310 feedback about ECN markings received (if accessible). 3312 To verify both that a path supports ECN and the peer can provide ECN 3313 feedback, an endpoint sets the ECT(0) codepoint in the IP header of 3314 all outgoing packets [RFC8311]. 3316 If an ECT codepoint set in the IP header is not corrupted by a 3317 network device, then a received packet contains either the codepoint 3318 sent by the peer or the Congestion Experienced (CE) codepoint set by 3319 a network device that is experiencing congestion. 3321 If a QUIC packet sent with an ECT codepoint is newly acknowledged by 3322 the peer in an ACK frame without ECN feedback, the endpoint stops 3323 setting ECT codepoints in subsequent IP packets, with the expectation 3324 that either the network path or the peer no longer supports ECN. 3326 Network devices that corrupt or apply non-standard ECN markings might 3327 result in reduced throughput or other undesirable side-effects. To 3328 reduce this risk, an endpoint uses the following steps to verify the 3329 counts it receives in an ACK frame. 3331 o The total increase in ECT(0), ECT(1), and CE counts MUST be no 3332 smaller than the total number of QUIC packets sent with an ECT 3333 codepoint that are newly acknowledged in this ACK frame. This 3334 step detects any network remarking from ECT(0), ECT(1), or CE 3335 codepoints to Not-ECT. 3337 o Any increase in either ECT(0) or ECT(1) counts, plus any increase 3338 in the CE count, MUST be no smaller than the number of packets 3339 sent with the corresponding ECT codepoint that are newly 3340 acknowledged in this ACK frame. This step detects any erroneous 3341 network remarking from ECT(0) to ECT(1) (or vice versa). 3343 An endpoint could miss acknowledgements for a packet when ACK frames 3344 are lost. It is therefore possible for the total increase in ECT(0), 3345 ECT(1), and CE counts to be greater than the number of packets 3346 acknowledged in an ACK frame. When this happens, and if verification 3347 succeeds, the local reference counts MUST be increased to match the 3348 counts in the ACK frame. 3350 Processing counts out of order can result in verification failure. 3351 An endpoint SHOULD NOT perform this verification if the ACK frame is 3352 received in a packet with packet number lower than a previously 3353 received ACK frame. Verifying based on ACK frames that arrive out of 3354 order can result in disabling ECN unnecessarily. 3356 Upon successful verification, an endpoint continues to set ECT 3357 codepoints in subsequent packets with the expectation that the path 3358 is ECN-capable. 3360 If verification fails, then the endpoint ceases setting ECT 3361 codepoints in subsequent IP packets with the expectation that either 3362 the network path or the peer does not support ECN. 3364 If an endpoint sets ECT codepoints on outgoing IP packets and 3365 encounters a retransmission timeout due to the absence of 3366 acknowledgments from the peer (see [QUIC-RECOVERY]), or if an 3367 endpoint has reason to believe that an element on the network path 3368 might be corrupting ECN codepoints, the endpoint MAY cease setting 3369 ECT codepoints in subsequent packets. Doing so allows the connection 3370 to be resilient to network elements that corrupt ECN codepoints in 3371 the IP header or drop packets with ECT or CE codepoints in the IP 3372 header. 3374 14. Packet Size 3376 The QUIC packet size includes the QUIC header and protected payload, 3377 but not the UDP or IP header. 3379 Clients MUST ensure they send the first Initial packet in a single IP 3380 packet. Similarly, the first Initial packet sent after receiving a 3381 Retry packet MUST be sent in a single IP packet. 3383 The payload of a UDP datagram carrying the first Initial packet MUST 3384 be expanded to at least 1200 bytes, by adding PADDING frames to the 3385 Initial packet and/or by combining the Initial packet with a 0-RTT 3386 packet (see Section 12.2). Sending a UDP datagram of this size 3387 ensures that the network path supports a reasonable Maximum 3388 Transmission Unit (MTU), and helps reduce the amplitude of 3389 amplification attacks caused by server responses toward an unverified 3390 client address, see Section 8. 3392 The datagram containing the first Initial packet from a client MAY 3393 exceed 1200 bytes if the client believes that the Path Maximum 3394 Transmission Unit (PMTU) supports the size that it chooses. 3396 A server MAY send a CONNECTION_CLOSE frame with error code 3397 PROTOCOL_VIOLATION in response to the first Initial packet it 3398 receives from a client if the UDP datagram is smaller than 1200 3399 bytes. It MUST NOT send any other frame type in response, or 3400 otherwise behave as if any part of the offending packet was processed 3401 as valid. 3403 The server MUST also limit the number of bytes it sends before 3404 validating the address of the client, see Section 8. 3406 14.1. Path Maximum Transmission Unit (PMTU) 3408 The PMTU is the maximum size of the entire IP packet including the IP 3409 header, UDP header, and UDP payload. The UDP payload includes the 3410 QUIC packet header, protected payload, and any authentication fields. 3411 The PMTU can depend upon the current path characteristics. 3412 Therefore, the current largest UDP payload an implementation will 3413 send is referred to as the QUIC maximum packet size. 3415 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 3416 minimum size [RFC8200] and is also supported by most modern IPv4 3417 networks. All QUIC packets (except for PMTU probe packets) SHOULD be 3418 sized to fit within the maximum packet size to avoid the packet being 3419 fragmented or dropped [RFC8085]. 3421 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery 3422 ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] 3423 [RFC8201] to determine whether the path to a destination will support 3424 a desired message size without fragmentation. 3426 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3427 packets larger than 1280 bytes. Assuming the minimum IP header size, 3428 this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 3429 1252 bytes for IPv4. A QUIC implementation MAY be more conservative 3430 in computing the QUIC maximum packet size to allow for unknown tunnel 3431 overheads or IP header options/extensions. 3433 Each pair of local and remote addresses could have a different PMTU. 3434 QUIC implementations that implement any kind of PMTU discovery 3435 therefore SHOULD maintain a maximum packet size for each combination 3436 of local and remote IP addresses. 3438 If a QUIC endpoint determines that the PMTU between any pair of local 3439 and remote IP addresses has fallen below the size needed to support 3440 the smallest allowed maximum packet size, it MUST immediately cease 3441 sending QUIC packets, except for PMTU probe packets, on the affected 3442 path. An endpoint MAY terminate the connection if an alternative 3443 path cannot be found. 3445 14.2. ICMP Packet Too Big Messages 3447 PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP 3448 messages (e.g., IPv6 Packet Too Big messages) that indicate when a 3449 packet is dropped because it is larger than the local router MTU. 3450 DPLPMTUD can also optionally use these messages. This use of ICMP 3451 messages is potentially vulnerable to off-path attacks that 3452 successfully guess the addresses used on the path and reduce the PMTU 3453 to a bandwidth-inefficient value. 3455 An endpoint MUST ignore an ICMP message that claims the PMTU has 3456 decreased below 1280 bytes. 3458 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 3459 that the quoted packet should contain as much of the original packet 3460 as possible without exceeding the minimum MTU for the IP version. 3461 The size of the quoted packet can actually be smaller, or the 3462 information unintelligible, as described in Section 1.1 of 3463 [DPLPMTUD]. 3465 QUIC endpoints SHOULD validate ICMP messages to protect from off-path 3466 injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. 3467 This validation SHOULD use the quoted packet supplied in the payload 3468 of an ICMP message to associate the message with a corresponding 3469 transport connection [DPLPMTUD]. 3471 ICMP message validation MUST include matching IP addresses and UDP 3472 ports [RFC8085] and, when possible, connection IDs to an active QUIC 3473 session. 3475 Further validation can also be provided: 3477 o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small 3478 proportion of packets, so that most invalid ICMP messages arrive 3479 when there are no DF packets outstanding, and can therefore be 3480 identified as spurious. 3482 o An endpoint could store additional information from the IP or UDP 3483 headers to use for validation (for example, the IP ID or UDP 3484 checksum). 3486 The endpoint SHOULD ignore all ICMP messages that fail validation. 3488 An endpoint MUST NOT increase PMTU based on ICMP messages. Any 3489 reduction in the QUIC maximum packet size MAY be provisional until 3490 QUIC's loss detection algorithm determines that the quoted packet has 3491 actually been lost. 3493 14.3. Datagram Packetization Layer PMTU Discovery 3495 Section 6.4 of [DPLPMTUD] provides considerations for implementing 3496 Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. 3498 When implementing the algorithm in Section 5.3 of [DPLPMTUD], the 3499 initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC 3500 packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). 3502 PING and PADDING frames can be used to generate PMTU probe packets. 3503 These frames might not be retransmitted if a probe packet containing 3504 them is lost. However, these frames do consume congestion window, 3505 which could delay the transmission of subsequent application data. 3507 A PING frame can be included in a PMTU probe to ensure that a valid 3508 probe is acknowledged. 3510 The considerations for processing ICMP messages in the previous 3511 section also apply if these messages are used by DPLPMTUD. 3513 15. Versions 3515 QUIC versions are identified using a 32-bit unsigned number. 3517 The version 0x00000000 is reserved to represent version negotiation. 3518 This version of the specification is identified by the number 3519 0x00000001. 3521 Other versions of QUIC might have different properties to this 3522 version. The properties of QUIC that are guaranteed to be consistent 3523 across all versions of the protocol are described in 3524 [QUIC-INVARIANTS]. 3526 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 3527 protocol, as described in [QUIC-TLS]. 3529 Versions with the most significant 16 bits of the version number 3530 cleared are reserved for use in future IETF consensus documents. 3532 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 3533 forcing version negotiation to be exercised. That is, any version 3534 number where the low four bits of all bytes is 1010 (in binary). A 3535 client or server MAY advertise support for any of these reserved 3536 versions. 3538 Reserved version numbers will probably never represent a real 3539 protocol; a client MAY use one of these version numbers with the 3540 expectation that the server will initiate version negotiation; a 3541 server MAY advertise support for one of these versions and can expect 3542 that clients ignore the value. 3544 [[RFC editor: please remove the remainder of this section before 3545 publication.]] 3546 The version number for the final version of this specification 3547 (0x00000001), is reserved for the version of the protocol that is 3548 published as an RFC. 3550 Version numbers used to identify IETF drafts are created by adding 3551 the draft number to 0xff000000. For example, draft-ietf-quic- 3552 transport-13 would be identified as 0xff00000D. 3554 Implementors are encouraged to register version numbers of QUIC that 3555 they are using for private experimentation on the GitHub wiki at 3556 . 3558 16. Variable-Length Integer Encoding 3560 QUIC packets and frames commonly use a variable-length encoding for 3561 non-negative integer values. This encoding ensures that smaller 3562 integer values need fewer bytes to encode. 3564 The QUIC variable-length integer encoding reserves the two most 3565 significant bits of the first byte to encode the base 2 logarithm of 3566 the integer encoding length in bytes. The integer value is encoded 3567 on the remaining bits, in network byte order. 3569 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 3570 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3571 the encoding properties. 3573 +------+--------+-------------+-----------------------+ 3574 | 2Bit | Length | Usable Bits | Range | 3575 +------+--------+-------------+-----------------------+ 3576 | 00 | 1 | 6 | 0-63 | 3577 | | | | | 3578 | 01 | 2 | 14 | 0-16383 | 3579 | | | | | 3580 | 10 | 4 | 30 | 0-1073741823 | 3581 | | | | | 3582 | 11 | 8 | 62 | 0-4611686018427387903 | 3583 +------+--------+-------------+-----------------------+ 3585 Table 4: Summary of Integer Encodings 3587 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 3588 hexadecimal) decodes to the decimal value 151288809941952652; the 3589 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 3590 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 3591 (as does the two byte sequence 40 25). 3593 Error codes (Section 20) and versions Section 15 are described using 3594 integers, but do not use this encoding. 3596 17. Packet Formats 3598 All numeric values are encoded in network byte order (that is, big- 3599 endian) and all field sizes are in bits. Hexadecimal notation is 3600 used for describing the value of fields. 3602 17.1. Packet Number Encoding and Decoding 3604 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). 3605 When present in long or short packet headers, they are encoded in 1 3606 to 4 bytes. The number of bits required to represent the packet 3607 number is reduced by including the least significant bits of the 3608 packet number. 3610 The encoded packet number is protected as described in Section 5.4 of 3611 [QUIC-TLS]. 3613 The sender MUST use a packet number size able to represent more than 3614 twice as large a range than the difference between the largest 3615 acknowledged packet and packet number being sent. A peer receiving 3616 the packet will then correctly decode the packet number, unless the 3617 packet is delayed in transit such that it arrives after many higher- 3618 numbered packets have been received. An endpoint SHOULD use a large 3619 enough packet number encoding to allow the packet number to be 3620 recovered even if the packet arrives after packets that are sent 3621 afterwards. 3623 As a result, the size of the packet number encoding is at least one 3624 bit more than the base-2 logarithm of the number of contiguous 3625 unacknowledged packet numbers, including the new packet. 3627 For example, if an endpoint has received an acknowledgment for packet 3628 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 3629 packet number encoding with 16 bits or more; whereas the 24-bit 3630 packet number encoding is needed to send a packet with a number of 3631 0xace8fe. 3633 At a receiver, protection of the packet number is removed prior to 3634 recovering the full packet number. The full packet number is then 3635 reconstructed based on the number of significant bits present, the 3636 value of those bits, and the largest packet number received on a 3637 successfully authenticated packet. Recovering the full packet number 3638 is necessary to successfully remove packet protection. 3640 Once header protection is removed, the packet number is decoded by 3641 finding the packet number value that is closest to the next expected 3642 packet. The next expected packet is the highest received packet 3643 number plus one. For example, if the highest successfully 3644 authenticated packet had a packet number of 0xa82f30ea, then a packet 3645 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 3646 Example pseudo-code for packet number decoding can be found in 3647 Appendix A. 3649 17.2. Long Header Packets 3651 0 1 2 3 3652 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 3653 +-+-+-+-+-+-+-+-+ 3654 |1|1|T T|X X X X| 3655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 | Version (32) | 3657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3658 |DCIL(4)|SCIL(4)| 3659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 | Destination Connection ID (0/32..144) ... 3661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3662 | Source Connection ID (0/32..144) ... 3663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3665 Figure 9: Long Header Packet Format 3667 Long headers are used for packets that are sent prior to the 3668 establishment of 1-RTT keys. Once both conditions are met, a sender 3669 switches to sending packets using the short header (Section 17.3). 3670 The long form allows for special packets - such as the Version 3671 Negotiation packet - to be represented in this uniform fixed-length 3672 packet format. Packets that use the long header contain the 3673 following fields: 3675 Header Form: The most significant bit (0x80) of byte 0 (the first 3676 byte) is set to 1 for long headers. 3678 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 3679 containing a zero value for this bit are not valid packets in this 3680 version and MUST be discarded. 3682 Long Packet Type (T): The next two bits (those with a mask of 0x30) 3683 of byte 0 contain a packet type. Packet types are listed in 3684 Table 5. 3686 Type-Specific Bits (X): The lower four bits (those with a mask of 3687 0x0f) of byte 0 are type-specific. 3689 Version: The QUIC Version is a 32-bit field that follows the first 3690 byte. This field indicates which version of QUIC is in use and 3691 determines how the rest of the protocol fields are interpreted. 3693 DCIL and SCIL: The byte following the version contains the lengths 3694 of the two connection ID fields that follow it. These lengths are 3695 encoded as two 4-bit unsigned integers. The Destination 3696 Connection ID Length (DCIL) field occupies the 4 high bits of the 3697 byte and the Source Connection ID Length (SCIL) field occupies the 3698 4 low bits of the byte. An encoded length of 0 indicates that the 3699 connection ID is also 0 bytes in length. Non-zero encoded lengths 3700 are increased by 3 to get the full length of the connection ID, 3701 producing a length between 4 and 18 bytes inclusive. For example, 3702 an byte with the value 0x50 describes an 8-byte Destination 3703 Connection ID and a zero-length Source Connection ID. 3705 Destination Connection ID: The Destination Connection ID field 3706 follows the connection ID lengths and is either 0 bytes in length 3707 or between 4 and 18 bytes. Section 7.2 describes the use of this 3708 field in more detail. 3710 Source Connection ID: The Source Connection ID field follows the 3711 Destination Connection ID and is either 0 bytes in length or 3712 between 4 and 18 bytes. Section 7.2 describes the use of this 3713 field in more detail. 3715 In this version of QUIC, the following packet types with the long 3716 header are defined: 3718 +------+-----------+----------------+ 3719 | Type | Name | Section | 3720 +------+-----------+----------------+ 3721 | 0x0 | Initial | Section 17.2.2 | 3722 | | | | 3723 | 0x1 | 0-RTT | Section 17.2.3 | 3724 | | | | 3725 | 0x2 | Handshake | Section 17.2.4 | 3726 | | | | 3727 | 0x3 | Retry | Section 17.2.5 | 3728 +------+-----------+----------------+ 3730 Table 5: Long Header Packet Types 3732 The header form bit, connection ID lengths byte, Destination and 3733 Source Connection ID fields, and Version fields of a long header 3734 packet are version-independent. The other fields in the first byte 3735 are version-specific. See [QUIC-INVARIANTS] for details on how 3736 packets from different versions of QUIC are interpreted. 3738 The interpretation of the fields and the payload are specific to a 3739 version and packet type. While type-specific semantics for this 3740 version are described in the following sections, several long-header 3741 packets in this version of QUIC contain these additional fields: 3743 Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 3744 are reserved across multiple packet types. These bits are 3745 protected using header protection (see Section 5.4 of [QUIC-TLS]). 3746 The value included prior to protection MUST be set to 0. An 3747 endpoint MUST treat receipt of a packet that has a non-zero value 3748 for these bits, after removing both packet and header protection, 3749 as a connection error of type PROTOCOL_VIOLATION. Discarding such 3750 a packet after only removing header protection can expose the 3751 endpoint to attacks (see Section 9.3 of [QUIC-TLS]). 3753 Packet Number Length (P): In packet types which contain a Packet 3754 Number field, the least significant two bits (those with a mask of 3755 0x03) of byte 0 contain the length of the packet number, encoded 3756 as an unsigned, two-bit integer that is one less than the length 3757 of the packet number field in bytes. That is, the length of the 3758 packet number field is the value of this field, plus one. These 3759 bits are protected using header protection (see Section 5.4 of 3760 [QUIC-TLS]). 3762 Length: The length of the remainder of the packet (that is, the 3763 Packet Number and Payload fields) in bytes, encoded as a variable- 3764 length integer (Section 16). 3766 Packet Number: The packet number field is 1 to 4 bytes long. The 3767 packet number has confidentiality protection separate from packet 3768 protection, as described in Section 5.4 of [QUIC-TLS]. The length 3769 of the packet number field is encoded in the Packet Number Length 3770 bits of byte 0 (see above). 3772 17.2.1. Version Negotiation Packet 3774 A Version Negotiation packet is inherently not version-specific. 3775 Upon receipt by a client, it will be identified as a Version 3776 Negotiation packet based on the Version field having a value of 0. 3778 The Version Negotiation packet is a response to a client packet that 3779 contains a version that is not supported by the server, and is only 3780 sent by servers. 3782 The layout of a Version Negotiation packet is: 3784 0 1 2 3 3785 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 3786 +-+-+-+-+-+-+-+-+ 3787 |1| Unused (7) | 3788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3789 | Version (32) | 3790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3791 |DCIL(4)|SCIL(4)| 3792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3793 | Destination Connection ID (0/32..144) ... 3794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3795 | Source Connection ID (0/32..144) ... 3796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3797 | Supported Version 1 (32) ... 3798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3799 | [Supported Version 2 (32)] ... 3800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3801 ... 3802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3803 | [Supported Version N (32)] ... 3804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3806 Figure 10: Version Negotiation Packet 3808 The value in the Unused field is selected randomly by the server. 3810 The Version field of a Version Negotiation packet MUST be set to 3811 0x00000000. 3813 The server MUST include the value from the Source Connection ID field 3814 of the packet it receives in the Destination Connection ID field. 3815 The value for Source Connection ID MUST be copied from the 3816 Destination Connection ID of the received packet, which is initially 3817 randomly selected by a client. Echoing both connection IDs gives 3818 clients some assurance that the server received the packet and that 3819 the Version Negotiation packet was not generated by an off-path 3820 attacker. 3822 The remainder of the Version Negotiation packet is a list of 32-bit 3823 versions which the server supports. 3825 A Version Negotiation packet cannot be explicitly acknowledged in an 3826 ACK frame by a client. Receiving another Initial packet implicitly 3827 acknowledges a Version Negotiation packet. 3829 The Version Negotiation packet does not include the Packet Number and 3830 Length fields present in other packets that use the long header form. 3832 Consequently, a Version Negotiation packet consumes an entire UDP 3833 datagram. 3835 A server MUST NOT send more than one Version Negotiation packet in 3836 response to a single UDP datagram. 3838 See Section 6 for a description of the version negotiation process. 3840 17.2.2. Initial Packet 3842 An Initial packet uses long headers with a type value of 0x0. It 3843 carries the first CRYPTO frames sent by the client and server to 3844 perform key exchange, and carries ACKs in either direction. 3846 +-+-+-+-+-+-+-+-+ 3847 |1|1| 0 |R R|P P| 3848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3849 | Version (32) | 3850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3851 |DCIL(4)|SCIL(4)| 3852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3853 | Destination Connection ID (0/32..144) ... 3854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3855 | Source Connection ID (0/32..144) ... 3856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3857 | Token Length (i) ... 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 | Token (*) ... 3860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3861 | Length (i) ... 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | Packet Number (8/16/24/32) ... 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 | Payload (*) ... 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3868 Figure 11: Initial Packet 3870 The Initial packet contains a long header as well as the Length and 3871 Packet Number fields. The first byte contains the Reserved and 3872 Packet Number Length bits. Between the SCID and Length fields, there 3873 are two additional field specific to the Initial packet. 3875 Token Length: A variable-length integer specifying the length of the 3876 Token field, in bytes. This value is zero if no token is present. 3877 Initial packets sent by the server MUST set the Token Length field 3878 to zero; clients that receive an Initial packet with a non-zero 3879 Token Length field MUST either discard the packet or generate a 3880 connection error of type PROTOCOL_VIOLATION. 3882 Token: The value of the token that was previously provided in a 3883 Retry packet or NEW_TOKEN frame. 3885 Payload: The payload of the packet. 3887 In order to prevent tampering by version-unaware middleboxes, Initial 3888 packets are protected with connection- and version-specific keys 3889 (Initial keys) as described in [QUIC-TLS]. This protection does not 3890 provide confidentiality or integrity against on-path attackers, but 3891 provides some level of protection against off-path attackers. 3893 The client and server use the Initial packet type for any packet that 3894 contains an initial cryptographic handshake message. This includes 3895 all cases where a new packet containing the initial cryptographic 3896 message needs to be created, such as the packets sent after receiving 3897 a Retry packet (Section 17.2.5). 3899 A server sends its first Initial packet in response to a client 3900 Initial. A server may send multiple Initial packets. The 3901 cryptographic key exchange could require multiple round trips or 3902 retransmissions of this data. 3904 The payload of an Initial packet includes a CRYPTO frame (or frames) 3905 containing a cryptographic handshake message, ACK frames, or both. 3906 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 3907 that receives an Initial packet containing other frames can either 3908 discard the packet as spurious or treat it as a connection error. 3910 The first packet sent by a client always includes a CRYPTO frame that 3911 contains the entirety of the first cryptographic handshake message. 3912 This packet, and the cryptographic handshake message, MUST fit in a 3913 single UDP datagram (see Section 7). The first CRYPTO frame sent 3914 always begins at an offset of 0 (see Section 7). 3916 Note that if the server sends a HelloRetryRequest, the client will 3917 send a second Initial packet. This Initial packet will continue the 3918 cryptographic handshake and will contain a CRYPTO frame with an 3919 offset matching the size of the CRYPTO frame sent in the first 3920 Initial packet. Cryptographic handshake messages subsequent to the 3921 first do not need to fit within a single UDP datagram. 3923 17.2.2.1. Abandoning Initial Packets 3925 A client stops both sending and processing Initial packets when it 3926 sends its first Handshake packet. A server stops sending and 3927 processing Initial packets when it receives its first Handshake 3928 packet. Though packets might still be in flight or awaiting 3929 acknowledgment, no further Initial packets need to be exchanged 3930 beyond this point. Initial packet protection keys are discarded (see 3931 Section 4.10 of [QUIC-TLS]) along with any loss recovery and 3932 congestion control state (see Sections 5.3.1.2 and 6.9 of 3933 [QUIC-RECOVERY]). 3935 Any data in CRYPTO frames is discarded - and no longer retransmitted 3936 - when Initial keys are discarded. 3938 17.2.3. 0-RTT 3940 A 0-RTT packet uses long headers with a type value of 0x1, followed 3941 by the Length and Packet Number fields. The first byte contains the 3942 Reserved and Packet Number Length bits. It is used to carry "early" 3943 data from the client to the server as part of the first flight, prior 3944 to handshake completion. As part of the TLS handshake, the server 3945 can accept or reject this early data. 3947 See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its 3948 limitations. 3950 +-+-+-+-+-+-+-+-+ 3951 |1|1| 1 |R R|P P| 3952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3953 | Version (32) | 3954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3955 |DCIL(4)|SCIL(4)| 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3957 | Destination Connection ID (0/32..144) ... 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 | Source Connection ID (0/32..144) ... 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3961 | Length (i) ... 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3963 | Packet Number (8/16/24/32) ... 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3965 | Payload (*) ... 3966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3968 0-RTT Packet 3970 Packet numbers for 0-RTT protected packets use the same space as 3971 1-RTT protected packets. 3973 After a client receives a Retry packet, 0-RTT packets are likely to 3974 have been lost or discarded by the server. A client MAY attempt to 3975 resend data in 0-RTT packets after it sends a new Initial packet. 3977 A client MUST NOT reset the packet number it uses for 0-RTT packets. 3978 The keys used to protect 0-RTT packets will not change as a result of 3979 responding to a Retry packet unless the client also regenerates the 3980 cryptographic handshake message. Sending packets with the same 3981 packet number in that case is likely to compromise the packet 3982 protection for all 0-RTT packets because the same key and nonce could 3983 be used to protect different content. 3985 Receiving a Retry packet, especially a Retry that changes the 3986 connection ID used for subsequent packets, indicates a strong 3987 possibility that 0-RTT packets could be lost. A client only receives 3988 acknowledgments for its 0-RTT packets once the handshake is complete. 3989 Consequently, a server might expect 0-RTT packets to start with a 3990 packet number of 0. Therefore, in determining the length of the 3991 packet number encoding for 0-RTT packets, a client MUST assume that 3992 all packets up to the current packet number are in flight, starting 3993 from a packet number of 0. Thus, 0-RTT packets could need to use a 3994 longer packet number encoding. 3996 A client SHOULD instead generate a fresh cryptographic handshake 3997 message and start packet numbers from 0. This ensures that new 0-RTT 3998 packets will not use the same keys, avoiding any risk of key and 3999 nonce reuse; this also prevents 0-RTT packets from previous handshake 4000 attempts from being accepted as part of the connection. 4002 17.2.4. Handshake Packet 4004 A Handshake packet uses long headers with a type value of 0x2, 4005 followed by the Length and Packet Number fields. The first byte 4006 contains the Reserved and Packet Number Length bits. It is used to 4007 carry acknowledgments and cryptographic handshake messages from the 4008 server and client. 4010 +-+-+-+-+-+-+-+-+ 4011 |1|1| 2 |R R|P P| 4012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4013 | Version (32) | 4014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4015 |DCIL(4)|SCIL(4)| 4016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4017 | Destination Connection ID (0/32..144) ... 4018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4019 | Source Connection ID (0/32..144) ... 4020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4021 | Length (i) ... 4022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4023 | Packet Number (8/16/24/32) ... 4024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4025 | Payload (*) ... 4026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4028 Figure 12: Handshake Protected Packet 4030 Once a client has received a Handshake packet from a server, it uses 4031 Handshake packets to send subsequent cryptographic handshake messages 4032 and acknowledgments to the server. 4034 The Destination Connection ID field in a Handshake packet contains a 4035 connection ID that is chosen by the recipient of the packet; the 4036 Source Connection ID includes the connection ID that the sender of 4037 the packet wishes to use (see Section 7.2). 4039 Handshake packets are their own packet number space, and thus the 4040 first Handshake packet sent by a server contains a packet number of 4041 0. 4043 The payload of this packet contains CRYPTO frames and could contain 4044 PADDING, or ACK frames. Handshake packets MAY contain 4045 CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake 4046 packets with other frames as a connection error. 4048 Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at 4049 the Handshake encryption level is discarded - and no longer 4050 retransmitted - when Handshake protection keys are discarded. 4052 17.2.5. Retry Packet 4054 A Retry packet uses a long packet header with a type value of 0x3. 4055 It carries an address validation token created by the server. It is 4056 used by a server that wishes to perform a stateless retry (see 4057 Section 8.1). 4059 0 1 2 3 4060 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 4061 +-+-+-+-+-+-+-+-+ 4062 |1|1| 3 | ODCIL | 4063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4064 | Version (32) | 4065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 |DCIL(4)|SCIL(4)| 4067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4068 | Destination Connection ID (0/32..144) ... 4069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4070 | Source Connection ID (0/32..144) ... 4071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4072 | Original Destination Connection ID (0/32..144) ... 4073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4074 | Retry Token (*) ... 4075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4077 Figure 13: Retry Packet 4079 A Retry packet (shown in Figure 13) does not contain any protected 4080 fields. In addition to the long header, it contains these additional 4081 fields: 4083 ODCIL: The four least-significant bits of the first byte of a Retry 4084 packet are not protected as they are for other packets with the 4085 long header, because Retry packets don't contain a protected 4086 payload. These bits instead encode the length of the Original 4087 Destination Connection ID field. The length uses the same 4088 encoding as the DCIL and SCIL fields. 4090 Original Destination Connection ID: The Original Destination 4091 Connection ID contains the value of the Destination Connection ID 4092 from the Initial packet that this Retry is in response to. The 4093 length of this field is given in ODCIL. 4095 Retry Token: An opaque token that the server can use to validate the 4096 client's address. 4098 The server populates the Destination Connection ID with the 4099 connection ID that the client included in the Source Connection ID of 4100 the Initial packet. 4102 The server includes a connection ID of its choice in the Source 4103 Connection ID field. This value MUST not be equal to the Destination 4104 Connection ID field of the packet sent by the client. The client 4105 MUST use this connection ID in the Destination Connection ID of 4106 subsequent packets that it sends. 4108 A server MAY send Retry packets in response to Initial and 0-RTT 4109 packets. A server can either discard or buffer 0-RTT packets that it 4110 receives. A server can send multiple Retry packets as it receives 4111 Initial or 0-RTT packets. A server MUST NOT send more than one Retry 4112 packet in response to a single UDP datagram. 4114 A client MUST accept and process at most one Retry packet for each 4115 connection attempt. After the client has received and processed an 4116 Initial or Retry packet from the server, it MUST discard any 4117 subsequent Retry packets that it receives. 4119 Clients MUST discard Retry packets that contain an Original 4120 Destination Connection ID field that does not match the Destination 4121 Connection ID from its Initial packet. This prevents an off-path 4122 attacker from injecting a Retry packet. 4124 The client responds to a Retry packet with an Initial packet that 4125 includes the provided Retry Token to continue connection 4126 establishment. 4128 A client sets the Destination Connection ID field of this Initial 4129 packet to the value from the Source Connection ID in the Retry 4130 packet. Changing Destination Connection ID also results in a change 4131 to the keys used to protect the Initial packet. It also sets the 4132 Token field to the token provided in the Retry. The client MUST NOT 4133 change the Source Connection ID because the server could include the 4134 connection ID as part of its token validation logic (see 4135 Section 8.1.3). 4137 The next Initial packet from the client uses the connection ID and 4138 token values from the Retry packet (see Section 7.2). Aside from 4139 this, the Initial packet sent by the client is subject to the same 4140 restrictions as the first Initial packet. A client can either reuse 4141 the cryptographic handshake message or construct a new one at its 4142 discretion. 4144 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4145 0-RTT packets to the connection ID provided by the server. A client 4146 that sends additional 0-RTT packets without constructing a new 4147 cryptographic handshake message MUST NOT reset the packet number to 0 4148 after a Retry packet, see Section 17.2.3. 4150 A server acknowledges the use of a Retry packet for a connection 4151 using the original_connection_id transport parameter (see 4152 Section 18.1). If the server sends a Retry packet, it MUST include 4153 the value of the Original Destination Connection ID field of the 4154 Retry packet (that is, the Destination Connection ID field from the 4155 client's first Initial packet) in the transport parameter. 4157 If the client received and processed a Retry packet, it MUST validate 4158 that the original_connection_id transport parameter is present and 4159 correct; otherwise, it MUST validate that the transport parameter is 4160 absent. A client MUST treat a failed validation as a connection 4161 error of type TRANSPORT_PARAMETER_ERROR. 4163 A Retry packet does not include a packet number and cannot be 4164 explicitly acknowledged by a client. 4166 17.3. Short Header Packets 4168 This version of QUIC defines a single packet type which uses the 4169 short packet header. 4171 0 1 2 3 4172 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 4173 +-+-+-+-+-+-+-+-+ 4174 |0|1|S|R|R|K|P P| 4175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4176 | Destination Connection ID (0..144) ... 4177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4178 | Packet Number (8/16/24/32) ... 4179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 | Protected Payload (*) ... 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4183 Figure 14: Short Header Packet Format 4185 The short header can be used after the version and 1-RTT keys are 4186 negotiated. Packets that use the short header contain the following 4187 fields: 4189 Header Form: The most significant bit (0x80) of byte 0 is set to 0 4190 for the short header. 4192 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4193 containing a zero value for this bit are not valid packets in this 4194 version and MUST be discarded. 4196 Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin 4197 Bit, set as described in [SPIN]. 4199 Reserved Bits (R): The next two bits (those with a mask of 0x18) of 4200 byte 0 are reserved. These bits are protected using header 4201 protection (see Section 5.4 of [QUIC-TLS]). The value included 4202 prior to protection MUST be set to 0. An endpoint MUST treat 4203 receipt of a packet that has a non-zero value for these bits, 4204 after removing both packet and header protection, as a connection 4205 error of type PROTOCOL_VIOLATION. Discarding such a packet after 4206 only removing header protection can expose the endpoint to attacks 4207 (see Section 9.3 of [QUIC-TLS]). 4209 Key Phase (K): The next bit (0x04) of byte 0 indicates the key 4210 phase, which allows a recipient of a packet to identify the packet 4211 protection keys that are used to protect the packet. See 4212 [QUIC-TLS] for details. This bit is protected using header 4213 protection (see Section 5.4 of [QUIC-TLS]). 4215 Packet Number Length (P): The least significant two bits (those with 4216 a mask of 0x03) of byte 0 contain the length of the packet number, 4217 encoded as an unsigned, two-bit integer that is one less than the 4218 length of the packet number field in bytes. That is, the length 4219 of the packet number field is the value of this field, plus one. 4220 These bits are protected using header protection (see Section 5.4 4221 of [QUIC-TLS]). 4223 Destination Connection ID: The Destination Connection ID is a 4224 connection ID that is chosen by the intended recipient of the 4225 packet. See Section 5.1 for more details. 4227 Packet Number: The packet number field is 1 to 4 bytes long. The 4228 packet number has confidentiality protection separate from packet 4229 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4230 of the packet number field is encoded in Packet Number Length 4231 field. See Section 17.1 for details. 4233 Protected Payload: Packets with a short header always include a 4234 1-RTT protected payload. 4236 The header form bit and the connection ID field of a short header 4237 packet are version-independent. The remaining fields are specific to 4238 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 4239 packets from different versions of QUIC are interpreted. 4241 18. Transport Parameter Encoding 4243 The format of the transport parameters is the TransportParameters 4244 struct from Figure 15. This is described using the presentation 4245 language from Section 3 of [TLS13]. 4247 enum { 4248 original_connection_id(0), 4249 idle_timeout(1), 4250 stateless_reset_token(2), 4251 max_packet_size(3), 4252 initial_max_data(4), 4253 initial_max_stream_data_bidi_local(5), 4254 initial_max_stream_data_bidi_remote(6), 4255 initial_max_stream_data_uni(7), 4256 initial_max_streams_bidi(8), 4257 initial_max_streams_uni(9), 4258 ack_delay_exponent(10), 4259 max_ack_delay(11), 4260 disable_migration(12), 4261 preferred_address(13), 4262 (65535) 4263 } TransportParameterId; 4265 struct { 4266 TransportParameterId parameter; 4267 opaque value<0..2^16-1>; 4268 } TransportParameter; 4270 TransportParameter TransportParameters<0..2^16-1>; 4272 Figure 15: Definition of TransportParameters 4274 The "extension_data" field of the quic_transport_parameters extension 4275 defined in [QUIC-TLS] contains a TransportParameters value. TLS 4276 encoding rules are therefore used to describe the encoding of 4277 transport parameters. 4279 QUIC encodes transport parameters into a sequence of bytes, which are 4280 then included in the cryptographic handshake. 4282 18.1. Transport Parameter Definitions 4284 This section details the transport parameters defined in this 4285 document. 4287 Many transport parameters listed here have integer values. Those 4288 transport parameters that are identified as integers use a variable- 4289 length integer encoding (see Section 16) and have a default value of 4290 0 if the transport parameter is absent, unless otherwise stated. 4292 The following transport parameters are defined: 4294 original_connection_id (0x0000): The value of the Destination 4295 Connection ID field from the first Initial packet sent by the 4296 client. This transport parameter is only sent by a server. A 4297 server MUST include the original_connection_id transport parameter 4298 if it sent a Retry packet. 4300 idle_timeout (0x0001): The idle timeout is a value in milliseconds 4301 that is encoded as an integer, see (Section 10.2). If this 4302 parameter is absent or zero then the idle timeout is disabled. 4304 stateless_reset_token (0x0002): A stateless reset token is used in 4305 verifying a stateless reset, see Section 10.4. This parameter is 4306 a sequence of 16 bytes. This transport parameter is only sent by 4307 a server. 4309 max_packet_size (0x0003): The maximum packet size parameter is an 4310 integer value that limits the size of packets that the endpoint is 4311 willing to receive. This indicates that packets larger than this 4312 limit will be dropped. The default for this parameter is the 4313 maximum permitted UDP payload of 65527. Values below 1200 are 4314 invalid. This limit only applies to protected packets 4315 (Section 12.1). 4317 initial_max_data (0x0004): The initial maximum data parameter is an 4318 integer value that contains the initial value for the maximum 4319 amount of data that can be sent on the connection. This is 4320 equivalent to sending a MAX_DATA (Section 19.9) for the connection 4321 immediately after completing the handshake. 4323 initial_max_stream_data_bidi_local (0x0005): This parameter is an 4324 integer value specifying the initial flow control limit for 4325 locally-initiated bidirectional streams. This limit applies to 4326 newly created bidirectional streams opened by the endpoint that 4327 sends the transport parameter. In client transport parameters, 4328 this applies to streams with an identifier with the least 4329 significant two bits set to 0x0; in server transport parameters, 4330 this applies to streams with the least significant two bits set to 4331 0x1. 4333 initial_max_stream_data_bidi_remote (0x0006): This parameter is an 4334 integer value specifying the initial flow control limit for peer- 4335 initiated bidirectional streams. This limit applies to newly 4336 created bidirectional streams opened by the endpoint that receives 4337 the transport parameter. In client transport parameters, this 4338 applies to streams with an identifier with the least significant 4339 two bits set to 0x1; in server transport parameters, this applies 4340 to streams with the least significant two bits set to 0x0. 4342 initial_max_stream_data_uni (0x0007): This parameter is an integer 4343 value specifying the initial flow control limit for unidirectional 4344 streams. This limit applies to newly created unidirectional 4345 streams opened by the endpoint that receives the transport 4346 parameter. In client transport parameters, this applies to 4347 streams with an identifier with the least significant two bits set 4348 to 0x3; in server transport parameters, this applies to streams 4349 with the least significant two bits set to 0x2. 4351 initial_max_streams_bidi (0x0008): The initial maximum bidirectional 4352 streams parameter is an integer value that contains the initial 4353 maximum number of bidirectional streams the peer may initiate. If 4354 this parameter is absent or zero, the peer cannot open 4355 bidirectional streams until a MAX_STREAMS frame is sent. Setting 4356 this parameter is equivalent to sending a MAX_STREAMS 4357 (Section 19.11) of the corresponding type with the same value. 4359 initial_max_streams_uni (0x0009): The initial maximum unidirectional 4360 streams parameter is an integer value that contains the initial 4361 maximum number of unidirectional streams the peer may initiate. 4362 If this parameter is absent or zero, the peer cannot open 4363 unidirectional streams until a MAX_STREAMS frame is sent. Setting 4364 this parameter is equivalent to sending a MAX_STREAMS 4365 (Section 19.11) of the corresponding type with the same value. 4367 ack_delay_exponent (0x000a): The ACK delay exponent is an integer 4368 value indicating an exponent used to decode the ACK Delay field in 4369 the ACK frame (Section 19.3). If this value is absent, a default 4370 value of 3 is assumed (indicating a multiplier of 8). The default 4371 value is also used for ACK frames that are sent in Initial and 4372 Handshake packets. Values above 20 are invalid. 4374 max_ack_delay (0x000b): The maximum ACK delay is an integer value 4375 indicating the maximum amount of time in milliseconds by which the 4376 endpoint will delay sending acknowledgments. This value SHOULD 4377 include the receiver's expected delays in alarms firing. For 4378 example, if a receiver sets a timer for 5ms and alarms commonly 4379 fire up to 1ms late, then it should send a max_ack_delay of 6ms. 4380 If this value is absent, a default of 25 milliseconds is assumed. 4381 Values of 2^14 or greater are invalid. 4383 disable_migration (0x000c): The disable migration transport 4384 parameter is included if the endpoint does not support connection 4385 migration (Section 9). Peers of an endpoint that sets this 4386 transport parameter MUST NOT send any packets, including probing 4387 packets (Section 9.1), from a local address other than that used 4388 to perform the handshake. This parameter is a zero-length value. 4390 preferred_address (0x000d): The server's preferred address is used 4391 to effect a change in server address at the end of the handshake, 4392 as described in Section 9.6. The format of this transport 4393 parameter is the PreferredAddress struct shown in Figure 16. This 4394 transport parameter is only sent by a server. Servers MAY choose 4395 to only send a preferred address of one address family by sending 4396 an all-zero address and port (0.0.0.0:0 or ::.0) for the other 4397 family. 4399 struct { 4400 opaque ipv4Address[4]; 4401 uint16 ipv4Port; 4402 opaque ipv6Address[16]; 4403 uint16 ipv6Port; 4404 opaque connectionId<0..18>; 4405 opaque statelessResetToken[16]; 4406 } PreferredAddress; 4408 Figure 16: Preferred Address format 4410 If present, transport parameters that set initial flow control limits 4411 (initial_max_stream_data_bidi_local, 4412 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 4413 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 4414 every stream of the corresponding type immediately after opening. If 4415 the transport parameter is absent, streams of that type start with a 4416 flow control limit of 0. 4418 A client MUST NOT include an original connection ID, a stateless 4419 reset token, or a preferred address. A server MUST treat receipt of 4420 any of these transport parameters as a connection error of type 4421 TRANSPORT_PARAMETER_ERROR. 4423 19. Frame Types and Formats 4425 As described in Section 12.4, packets contain one or more frames. 4426 This section describes the format and semantics of the core QUIC 4427 frame types. 4429 19.1. PADDING Frame 4431 The PADDING frame (type=0x00) has no semantic value. PADDING frames 4432 can be used to increase the size of a packet. Padding can be used to 4433 increase an initial client packet to the minimum required size, or to 4434 provide protection against traffic analysis for protected packets. 4436 A PADDING frame has no content. That is, a PADDING frame consists of 4437 the single byte that identifies the frame as a PADDING frame. 4439 19.2. PING Frame 4441 Endpoints can use PING frames (type=0x01) to verify that their peers 4442 are still alive or to check reachability to the peer. The PING frame 4443 contains no additional fields. 4445 The receiver of a PING frame simply needs to acknowledge the packet 4446 containing this frame. 4448 The PING frame can be used to keep a connection alive when an 4449 application or application protocol wishes to prevent the connection 4450 from timing out. An application protocol SHOULD provide guidance 4451 about the conditions under which generating a PING is recommended. 4452 This guidance SHOULD indicate whether it is the client or the server 4453 that is expected to send the PING. Having both endpoints send PING 4454 frames without coordination can produce an excessive number of 4455 packets and poor performance. 4457 A connection will time out if no packets are sent or received for a 4458 period longer than the time specified in the idle_timeout transport 4459 parameter (see Section 10). However, state in middleboxes might time 4460 out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 4461 minute timeout interval, experience shows that sending packets every 4462 15 to 30 seconds is necessary to prevent the majority of middleboxes 4463 from losing state for UDP flows. 4465 19.3. ACK Frames 4467 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 4468 packets they have received and processed. The ACK frame contains one 4469 or more ACK Ranges. ACK Ranges identify acknowledged packets. If 4470 the frame type is 0x03, ACK frames also contain the sum of QUIC 4471 packets with associated ECN marks received on the connection up until 4472 this point. QUIC implementations MUST properly handle both types 4473 and, if they have enabled ECN for packets they send, they SHOULD use 4474 the information in the ECN section to manage their congestion state. 4476 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 4477 remains acknowledged, even if it does not appear in a future ACK 4478 frame. This is unlike TCP SACKs ([RFC2018]). 4480 It is expected that a sender will reuse the same packet number across 4481 different packet number spaces. ACK frames only acknowledge the 4482 packet numbers that were transmitted by the sender in the same packet 4483 number space of the packet that the ACK was received in. 4485 Version Negotiation and Retry packets cannot be acknowledged because 4486 they do not contain a packet number. Rather than relying on ACK 4487 frames, these packets are implicitly acknowledged by the next Initial 4488 packet sent by the client. 4490 An ACK frame is as follows: 4492 0 1 2 3 4493 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 4494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4495 | Largest Acknowledged (i) ... 4496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4497 | ACK Delay (i) ... 4498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4499 | ACK Range Count (i) ... 4500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4501 | First ACK Range (i) ... 4502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4503 | ACK Ranges (*) ... 4504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4505 | [ECN Counts] ... 4506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 Figure 17: ACK Frame Format 4510 ACK frames contain the following fields: 4512 Largest Acknowledged: A variable-length integer representing the 4513 largest packet number the peer is acknowledging; this is usually 4514 the largest packet number that the peer has received prior to 4515 generating the ACK frame. Unlike the packet number in the QUIC 4516 long or short header, the value in an ACK frame is not truncated. 4518 ACK Delay: A variable-length integer including the time in 4519 microseconds that the largest acknowledged packet, as indicated in 4520 the Largest Acknowledged field, was received by this peer to when 4521 this ACK was sent. The value of the ACK Delay field is scaled by 4522 multiplying the encoded value by 2 to the power of the value of 4523 the "ack_delay_exponent" transport parameter set by the sender of 4524 the ACK frame. The "ack_delay_exponent" defaults to 3, or a 4525 multiplier of 8 (see Section 18.1). Scaling in this fashion 4526 allows for a larger range of values with a shorter encoding at the 4527 cost of lower resolution. 4529 ACK Range Count: A variable-length integer specifying the number of 4530 Gap and ACK Range fields in the frame. 4532 First ACK Range: A variable-length integer indicating the number of 4533 contiguous packets preceding the Largest Acknowledged that are 4534 being acknowledged. The First ACK Range is encoded as an ACK 4535 Range (see Section 19.3.1) starting from the Largest Acknowledged. 4536 That is, the smallest packet acknowledged in the range is 4537 determined by subtracting the First ACK Range value from the 4538 Largest Acknowledged. 4540 ACK Ranges: Contains additional ranges of packets which are 4541 alternately not acknowledged (Gap) and acknowledged (ACK Range), 4542 see Section 19.3.1. 4544 ECN Counts: The three ECN Counts, see Section 19.3.2. 4546 19.3.1. ACK Ranges 4548 The ACK Ranges field consists of alternating Gap and ACK Range values 4549 in descending packet number order. The number of Gap and ACK Range 4550 values is determined by the ACK Range Count field; one of each value 4551 is present for each value in the ACK Range Count field. 4553 ACK Ranges are structured as follows: 4555 0 1 2 3 4556 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 4557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4558 | [Gap (i)] ... 4559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4560 | [ACK Range (i)] ... 4561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4562 | [Gap (i)] ... 4563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4564 | [ACK Range (i)] ... 4565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4566 ... 4567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4568 | [Gap (i)] ... 4569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4570 | [ACK Range (i)] ... 4571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4573 Figure 18: ACK Ranges 4575 The fields that form the ACK Ranges are: 4577 Gap (repeated): A variable-length integer indicating the number of 4578 contiguous unacknowledged packets preceding the packet number one 4579 lower than the smallest in the preceding ACK Range. 4581 ACK Range (repeated): A variable-length integer indicating the 4582 number of contiguous acknowledged packets preceding the largest 4583 packet number, as determined by the preceding Gap. 4585 Gap and ACK Range value use a relative integer encoding for 4586 efficiency. Though each encoded value is positive, the values are 4587 subtracted, so that each ACK Range describes progressively lower- 4588 numbered packets. 4590 Each ACK Range acknowledges a contiguous range of packets by 4591 indicating the number of acknowledged packets that precede the 4592 largest packet number in that range. A value of zero indicates that 4593 only the largest packet number is acknowledged. Larger ACK Range 4594 values indicate a larger range, with corresponding lower values for 4595 the smallest packet number in the range. Thus, given a largest 4596 packet number for the range, the smallest value is determined by the 4597 formula: 4599 smallest = largest - ack_range 4601 An ACK Range acknowledges all packets between the smallest packet 4602 number and the largest, inclusive. 4604 The largest value for an ACK Range is determined by cumulatively 4605 subtracting the size of all preceding ACK Ranges and Gaps. 4607 Each Gap indicates a range of packets that are not being 4608 acknowledged. The number of packets in the gap is one higher than 4609 the encoded value of the Gap field. 4611 The value of the Gap field establishes the largest packet number 4612 value for the subsequent ACK Range using the following formula: 4614 largest = previous_smallest - gap - 2 4616 If any computed packet number is negative, an endpoint MUST generate 4617 a connection error of type FRAME_ENCODING_ERROR indicating an error 4618 in an ACK frame. 4620 19.3.2. ECN Counts 4622 The ACK frame uses the least significant bit (that is, type 0x03) to 4623 indicate ECN feedback and report receipt of QUIC packets with 4624 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 4625 header. ECN Counts are only present when the ACK frame type is 0x03. 4627 ECN Counts are only parsed when the ACK frame type is 0x03. There 4628 are 3 ECN counts, as follows: 4630 0 1 2 3 4631 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 4632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4633 | ECT(0) Count (i) ... 4634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4635 | ECT(1) Count (i) ... 4636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4637 | ECN-CE Count (i) ... 4638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4640 The three ECN Counts are: 4642 ECT(0) Count: A variable-length integer representing the total 4643 number packets received with the ECT(0) codepoint. 4645 ECT(1) Count: A variable-length integer representing the total 4646 number packets received with the ECT(1) codepoint. 4648 CE Count: A variable-length integer representing the total number 4649 packets received with the CE codepoint. 4651 ECN counts are maintained separately for each packet number space. 4653 19.4. RESET_STREAM Frame 4655 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 4656 terminate a stream. 4658 After sending a RESET_STREAM, an endpoint ceases transmission and 4659 retransmission of STREAM frames on the identified stream. A receiver 4660 of RESET_STREAM can discard any data that it already received on that 4661 stream. 4663 An endpoint that receives a RESET_STREAM frame for a send-only stream 4664 MUST terminate the connection with error STREAM_STATE_ERROR. 4666 The RESET_STREAM frame is as follows: 4668 0 1 2 3 4669 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 4670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4671 | Stream ID (i) ... 4672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4673 | Application Error Code (16) | 4674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4675 | Final Size (i) ... 4676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4677 RESET_STREAM frames contain the following fields: 4679 Stream ID: A variable-length integer encoding of the Stream ID of 4680 the stream being terminated. 4682 Application Protocol Error Code: A 16-bit application protocol error 4683 code (see Section 20.1) which indicates why the stream is being 4684 closed. 4686 Final Size: A variable-length integer indicating the final size of 4687 the stream by the RESET_STREAM sender, in unit of bytes. 4689 19.5. STOP_SENDING Frame 4691 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 4692 incoming data is being discarded on receipt at application request. 4693 STOP_SENDING requests that a peer cease transmission on a stream. 4695 A STOP_SENDING frame can be sent for streams in the Recv or Size 4696 Known states (see Section 3.1). Receiving a STOP_SENDING frame for a 4697 locally-initiated stream that has not yet been created MUST be 4698 treated as a connection error of type STREAM_STATE_ERROR. An 4699 endpoint that receives a STOP_SENDING frame for a receive-only stream 4700 MUST terminate the connection with error STREAM_STATE_ERROR. 4702 The STOP_SENDING frame is as follows: 4704 0 1 2 3 4705 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 4706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4707 | Stream ID (i) ... 4708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4709 | Application Error Code (16) | 4710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4712 STOP_SENDING frames contain the following fields: 4714 Stream ID: A variable-length integer carrying the Stream ID of the 4715 stream being ignored. 4717 Application Error Code: A 16-bit, application-specified reason the 4718 sender is ignoring the stream (see Section 20.1). 4720 19.6. CRYPTO Frame 4722 The CRYPTO frame (type=0x06) is used to transmit cryptographic 4723 handshake messages. It can be sent in all packet types. The CRYPTO 4724 frame offers the cryptographic protocol an in-order stream of bytes. 4726 CRYPTO frames are functionally identical to STREAM frames, except 4727 that they do not bear a stream identifier; they are not flow 4728 controlled; and they do not carry markers for optional offset, 4729 optional length, and the end of the stream. 4731 The CRYPTO frame is as follows: 4733 0 1 2 3 4734 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 4735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4736 | Offset (i) ... 4737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4738 | Length (i) ... 4739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4740 | Crypto Data (*) ... 4741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4743 Figure 19: CRYPTO Frame Format 4745 CRYPTO frames contain the following fields: 4747 Offset: A variable-length integer specifying the byte offset in the 4748 stream for the data in this CRYPTO frame. 4750 Length: A variable-length integer specifying the length of the 4751 Crypto Data field in this CRYPTO frame. 4753 Crypto Data: The cryptographic message data. 4755 There is a separate flow of cryptographic handshake data in each 4756 encryption level, each of which starts at an offset of 0. This 4757 implies that each encryption level is treated as a separate CRYPTO 4758 stream of data. 4760 Unlike STREAM frames, which include a Stream ID indicating to which 4761 stream the data belongs, the CRYPTO frame carries data for a single 4762 stream per encryption level. The stream does not have an explicit 4763 end, so CRYPTO frames do not have a FIN bit. 4765 19.7. NEW_TOKEN Frame 4767 A server sends a NEW_TOKEN frame (type=0x07) to provide the client 4768 with a token to send in the header of an Initial packet for a future 4769 connection. 4771 The NEW_TOKEN frame is as follows: 4773 0 1 2 3 4774 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 4775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4776 | Token Length (i) ... 4777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4778 | Token (*) ... 4779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4781 NEW_TOKEN frames contain the following fields: 4783 Token Length: A variable-length integer specifying the length of the 4784 token in bytes. 4786 Token: An opaque blob that the client may use with a future Initial 4787 packet. 4789 19.8. STREAM Frames 4791 STREAM frames implicitly create a stream and carry stream data. The 4792 STREAM frame takes the form 0b00001XXX (or the set of values from 4793 0x08 to 0x0f). The value of the three low-order bits of the frame 4794 type determine the fields that are present in the frame. 4796 o The OFF bit (0x04) in the frame type is set to indicate that there 4797 is an Offset field present. When set to 1, the Offset field is 4798 present. When set to 0, the Offset field is absent and the Stream 4799 Data starts at an offset of 0 (that is, the frame contains the 4800 first bytes of the stream, or the end of a stream that includes no 4801 data). 4803 o The LEN bit (0x02) in the frame type is set to indicate that there 4804 is a Length field present. If this bit is set to 0, the Length 4805 field is absent and the Stream Data field extends to the end of 4806 the packet. If this bit is set to 1, the Length field is present. 4808 o The FIN bit (0x01) of the frame type is set only on frames that 4809 contain the final size of the stream. Setting this bit indicates 4810 that the frame marks the end of the stream. 4812 An endpoint that receives a STREAM frame for a send-only stream MUST 4813 terminate the connection with error STREAM_STATE_ERROR. 4815 The STREAM frames are as follows: 4817 0 1 2 3 4818 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 4819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4820 | Stream ID (i) ... 4821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4822 | [Offset (i)] ... 4823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4824 | [Length (i)] ... 4825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 | Stream Data (*) ... 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4829 Figure 20: STREAM Frame Format 4831 STREAM frames contain the following fields: 4833 Stream ID: A variable-length integer indicating the stream ID of the 4834 stream (see Section 2.1). 4836 Offset: A variable-length integer specifying the byte offset in the 4837 stream for the data in this STREAM frame. This field is present 4838 when the OFF bit is set to 1. When the Offset field is absent, 4839 the offset is 0. 4841 Length: A variable-length integer specifying the length of the 4842 Stream Data field in this STREAM frame. This field is present 4843 when the LEN bit is set to 1. When the LEN bit is set to 0, the 4844 Stream Data field consumes all the remaining bytes in the packet. 4846 Stream Data: The bytes from the designated stream to be delivered. 4848 When a Stream Data field has a length of 0, the offset in the STREAM 4849 frame is the offset of the next byte that would be sent. 4851 The first byte in the stream has an offset of 0. The largest offset 4852 delivered on a stream - the sum of the offset and data length - MUST 4853 be less than 2^62. 4855 19.9. MAX_DATA Frame 4857 The MAX_DATA frame (type=0x10) is used in flow control to inform the 4858 peer of the maximum amount of data that can be sent on the connection 4859 as a whole. 4861 The MAX_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 | Maximum Data (i) ... 4867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4869 MAX_DATA frames contain the following fields: 4871 Maximum Data: A variable-length integer indicating the maximum 4872 amount of data that can be sent on the entire connection, in units 4873 of bytes. 4875 All data sent in STREAM frames counts toward this limit. The sum of 4876 the largest received offsets on all streams - including streams in 4877 terminal states - MUST NOT exceed the value advertised by a receiver. 4878 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 4879 error if it receives more data than the maximum data value that it 4880 has sent, unless this is a result of a change in the initial limits 4881 (see Section 7.3.1). 4883 19.10. MAX_STREAM_DATA Frame 4885 The MAX_STREAM_DATA frame (type=0x11) is used in flow control to 4886 inform a peer of the maximum amount of data that can be sent on a 4887 stream. 4889 A MAX_STREAM_DATA frame can be sent for streams in the Recv state 4890 (see Section 3.1). Receiving a MAX_STREAM_DATA frame for a locally- 4891 initiated stream that has not yet been created MUST be treated as a 4892 connection error of type STREAM_STATE_ERROR. An endpoint that 4893 receives a MAX_STREAM_DATA frame for a receive-only stream MUST 4894 terminate the connection with error STREAM_STATE_ERROR. 4896 The MAX_STREAM_DATA frame is as follows: 4898 0 1 2 3 4899 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 4900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4901 | Stream ID (i) ... 4902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4903 | Maximum Stream Data (i) ... 4904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4906 MAX_STREAM_DATA frames contain the following fields: 4908 Stream ID: The stream ID of the stream that is affected encoded as a 4909 variable-length integer. 4911 Maximum Stream Data: A variable-length integer indicating the 4912 maximum amount of data that can be sent on the identified stream, 4913 in units of bytes. 4915 When counting data toward this limit, an endpoint accounts for the 4916 largest received offset of data that is sent or received on the 4917 stream. Loss or reordering can mean that the largest received offset 4918 on a stream can be greater than the total size of data received on 4919 that stream. Receiving STREAM frames might not increase the largest 4920 received offset. 4922 The data sent on a stream MUST NOT exceed the largest maximum stream 4923 data value advertised by the receiver. An endpoint MUST terminate a 4924 connection with a FLOW_CONTROL_ERROR error if it receives more data 4925 than the largest maximum stream data that it has sent for the 4926 affected stream, unless this is a result of a change in the initial 4927 limits (see Section 7.3.1). 4929 19.11. MAX_STREAMS Frames 4931 The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the 4932 cumulative number of streams of a given type it is permitted to open. 4933 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 4934 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 4935 unidirectional streams. 4937 The MAX_STREAMS frames are as follows: 4939 0 1 2 3 4940 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 4941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4942 | Maximum Streams (i) ... 4943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4945 MAX_STREAMS frames contain the following fields: 4947 Maximum Streams: A count of the cumulative number of streams of the 4948 corresponding type that can be opened over the lifetime of the 4949 connection. 4951 Loss or reordering can cause a MAX_STREAMS frame to be received which 4952 states a lower stream limit than an endpoint has previously received. 4953 MAX_STREAMS frames which do not increase the stream limit MUST be 4954 ignored. 4956 An endpoint MUST NOT open more streams than permitted by the current 4957 stream limit set by its peer. For instance, a server that receives a 4958 unidirectional stream limit of 3 is permitted to open stream 3, 7, 4959 and 11, but not stream 15. An endpoint MUST terminate a connection 4960 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 4961 permitted. 4963 Note that these frames (and the corresponding transport parameters) 4964 do not describe the number of streams that can be opened 4965 concurrently. The limit includes streams that have been closed as 4966 well as those that are open. 4968 19.12. DATA_BLOCKED Frame 4970 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 4971 to send data, but is unable to due to connection-level flow control 4972 (see Section 4). DATA_BLOCKED frames can be used as input to tuning 4973 of flow control algorithms (see Section 4.2). 4975 The DATA_BLOCKED frame is as follows: 4977 0 1 2 3 4978 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 4979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4980 | Data Limit (i) ... 4981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4983 DATA_BLOCKED frames contain the following fields: 4985 Data Limit: A variable-length integer indicating the connection- 4986 level limit at which blocking occurred. 4988 19.13. STREAM_DATA_BLOCKED Frame 4990 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 4991 wishes to send data, but is unable to due to stream-level flow 4992 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 4994 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 4995 stream MUST terminate the connection with error STREAM_STATE_ERROR. 4997 The STREAM_DATA_BLOCKED frame is as follows: 4999 0 1 2 3 5000 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 5001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5002 | Stream ID (i) ... 5003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5004 | Stream Data Limit (i) ... 5005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5006 STREAM_DATA_BLOCKED frames contain the following fields: 5008 Stream ID: A variable-length integer indicating the stream which is 5009 flow control blocked. 5011 Stream Data Limit: A variable-length integer indicating the offset 5012 of the stream at which the blocking occurred. 5014 19.14. STREAMS_BLOCKED Frames 5016 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 5017 it wishes to open a stream, but is unable to due to the maximum 5018 stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED 5019 frame of type 0x16 is used to indicate reaching the bidirectional 5020 stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates 5021 reaching the unidirectional stream limit. 5023 A STREAMS_BLOCKED frame does not open the stream, but informs the 5024 peer that a new stream was needed and the stream limit prevented the 5025 creation of the stream. 5027 The STREAMS_BLOCKED frames are as follows: 5029 0 1 2 3 5030 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 5031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5032 | Stream Limit (i) ... 5033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5035 STREAMS_BLOCKED frames contain the following fields: 5037 Stream Limit: A variable-length integer indicating the stream limit 5038 at the time the frame was sent. 5040 19.15. NEW_CONNECTION_ID Frame 5042 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 5043 its peer with alternative connection IDs that can be used to break 5044 linkability when migrating connections (see Section 9.5). 5046 The NEW_CONNECTION_ID frame is as follows: 5048 0 1 2 3 5049 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 5050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5051 | Sequence Number (i) ... 5052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5053 | Length (8) | | 5054 +-+-+-+-+-+-+-+-+ Connection ID (32..144) + 5055 | ... 5056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5057 | | 5058 + + 5059 | | 5060 + Stateless Reset Token (128) + 5061 | | 5062 + + 5063 | | 5064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5066 NEW_CONNECTION_ID frames contain the following fields: 5068 Sequence Number: The sequence number assigned to the connection ID 5069 by the sender. See Section 5.1.1. 5071 Length: An 8-bit unsigned integer containing the length of the 5072 connection ID. Values less than 4 and greater than 18 are invalid 5073 and MUST be treated as a connection error of type 5074 PROTOCOL_VIOLATION. 5076 Connection ID: A connection ID of the specified length. 5078 Stateless Reset Token: A 128-bit value that will be used for a 5079 stateless reset when the associated connection ID is used (see 5080 Section 10.4). 5082 An endpoint MUST NOT send this frame if it currently requires that 5083 its peer send packets with a zero-length Destination Connection ID. 5084 Changing the length of a connection ID to or from zero-length makes 5085 it difficult to identify when the value of the connection ID changed. 5086 An endpoint that is sending packets with a zero-length Destination 5087 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 5088 connection error of type PROTOCOL_VIOLATION. 5090 Transmission errors, timeouts and retransmissions might cause the 5091 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 5092 of the same frame multiple times MUST NOT be treated as a connection 5093 error. A receiver can use the sequence number supplied in the 5094 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 5096 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 5097 previously issued connection ID with a different Stateless Reset 5098 Token or a different sequence number, or if a sequence number is used 5099 for different connection IDs, the endpoint MAY treat that receipt as 5100 a connection error of type PROTOCOL_VIOLATION. 5102 19.16. RETIRE_CONNECTION_ID Frame 5104 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 5105 indicate that it will no longer use a connection ID that was issued 5106 by its peer. This may include the connection ID provided during the 5107 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 5108 request to the peer to send additional connection IDs for future use 5109 (see Section 5.1). New connection IDs can be delivered to a peer 5110 using the NEW_CONNECTION_ID frame (Section 19.15). 5112 Retiring a connection ID invalidates the stateless reset token 5113 associated with that connection ID. 5115 The RETIRE_CONNECTION_ID frame is as follows: 5117 0 1 2 3 5118 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 5119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5120 | Sequence Number (i) ... 5121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5123 RETIRE_CONNECTION_ID frames contain the following fields: 5125 Sequence Number: The sequence number of the connection ID being 5126 retired. See Section 5.1.2. 5128 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 5129 greater than any previously sent to the peer MAY be treated as a 5130 connection error of type PROTOCOL_VIOLATION. 5132 The sequence number specified in a RETIRE_CONNECTION_ID frame MUST 5133 NOT refer to the Destination Connection ID field of the packet in 5134 which the frame is contained. The peer MAY treat this as a 5135 connection error of type PROTOCOL_VIOLATION. 5137 An endpoint cannot send this frame if it was provided with a zero- 5138 length connection ID by its peer. An endpoint that provides a zero- 5139 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 5140 frame as a connection error of type PROTOCOL_VIOLATION. 5142 19.17. PATH_CHALLENGE Frame 5144 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 5145 reachability to the peer and for path validation during connection 5146 migration. 5148 The PATH_CHALLENGE frames are as follows: 5150 0 1 2 3 5151 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 5152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5153 | | 5154 + Data (64) + 5155 | | 5156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5158 PATH_CHALLENGE frames contain the following fields: 5160 Data: This 8-byte field contains arbitrary data. 5162 A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is 5163 sufficient to ensure that it is easier to receive the packet than it 5164 is to guess the value correctly. 5166 The recipient of this frame MUST generate a PATH_RESPONSE frame 5167 (Section 19.18) containing the same Data. 5169 19.18. PATH_RESPONSE Frame 5171 The PATH_RESPONSE frame (type=0x1b) is sent in response to a 5172 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 5173 frame (Section 19.17). 5175 If the content of a PATH_RESPONSE frame does not match the content of 5176 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 5177 MAY generate a connection error of type PROTOCOL_VIOLATION. 5179 19.19. CONNECTION_CLOSE Frames 5181 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 5182 notify its peer that the connection is being closed. The 5183 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 5184 at only the QUIC layer, or the absence of errors (with the NO_ERROR 5185 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 5186 signal an error with the application that uses QUIC. 5188 If there are open streams that haven't been explicitly closed, they 5189 are implicitly closed when the connection is closed. 5191 The CONNECTION_CLOSE frames are as follows: 5193 0 1 2 3 5194 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 5195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5196 | Error Code (16) | [ Frame Type (i) ] ... 5197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5198 | Reason Phrase Length (i) ... 5199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5200 | Reason Phrase (*) ... 5201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5203 CONNECTION_CLOSE frames contain the following fields: 5205 Error Code: A 16-bit error code which indicates the reason for 5206 closing this connection. A CONNECTION_CLOSE frame of type 0x1c 5207 uses codes from the space defined in Section 20. A 5208 CONNECTION_CLOSE frame of type 0x1d uses codes from the 5209 application protocol error code space, see Section 20.1 5211 Frame Type: A variable-length integer encoding the type of frame 5212 that triggered the error. A value of 0 (equivalent to the mention 5213 of the PADDING frame) is used when the frame type is unknown. The 5214 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 5215 not include this field. 5217 Reason Phrase Length: A variable-length integer specifying the 5218 length of the reason phrase in bytes. Because a CONNECTION_CLOSE 5219 frame cannot be split between packets, any limits on packet size 5220 will also limit the space available for a reason phrase. 5222 Reason Phrase: A human-readable explanation for why the connection 5223 was closed. This can be zero length if the sender chooses to not 5224 give details beyond the Error Code. This SHOULD be a UTF-8 5225 encoded string [RFC3629]. 5227 19.20. Extension Frames 5229 QUIC frames do not use a self-describing encoding. An endpoint 5230 therefore needs to understand the syntax of all frames before it can 5231 successfully process a packet. This allows for efficient encoding of 5232 frames, but it means that an endpoint cannot send a frame of a type 5233 that is unknown to its peer. 5235 An extension to QUIC that wishes to use a new type of frame MUST 5236 first ensure that a peer is able to understand the frame. An 5237 endpoint can use a transport parameter to signal its willingness to 5238 receive one or more extension frame types with the one transport 5239 parameter. 5241 Extension frames MUST be congestion controlled and MUST cause an ACK 5242 frame to be sent. The exception is extension frames that replace or 5243 supplement the ACK frame. Extension frames are not included in flow 5244 control unless specified in the extension. 5246 An IANA registry is used to manage the assignment of frame types, see 5247 Section 22.2. 5249 20. Transport Error Codes 5251 QUIC error codes are 16-bit unsigned integers. 5253 This section lists the defined QUIC transport error codes that may be 5254 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5255 connection. 5257 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5258 signal that the connection is being closed abruptly in the absence 5259 of any error. 5261 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5262 cannot continue with the connection. 5264 SERVER_BUSY (0x2): The server is currently busy and does not accept 5265 any new connections. 5267 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5268 permitted in its advertised data limits (see Section 4). 5270 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 5271 identifier that exceeded its advertised stream limit for the 5272 corresponding stream type. 5274 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5275 that was not in a state that permitted that frame (see Section 3). 5277 FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame 5278 containing data that exceeded the previously established final 5279 size. Or an endpoint received a STREAM frame or a RESET_STREAM 5280 frame containing a final size that was lower than the size of 5281 stream data that was already received. Or an endpoint received a 5282 STREAM frame or a RESET_STREAM frame containing a different final 5283 size to the one already established. 5285 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5286 badly formatted. For instance, a frame of an unknown type, or an 5287 ACK frame that has more acknowledgment ranges than the remainder 5288 of the packet could carry. 5290 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5291 parameters that were badly formatted, included an invalid value, 5292 was absent even though it is mandatory, was present though it is 5293 forbidden, or is otherwise in error. 5295 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5296 protocol compliance that was not covered by more specific error 5297 codes. 5299 INVALID_MIGRATION (0xC): A peer has migrated to a different network 5300 when the endpoint had disabled migration. 5302 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5303 of 256 values is reserved for carrying error codes specific to the 5304 cryptographic handshake that is used. Codes for errors occurring 5305 when TLS is used for the crypto handshake are described in 5306 Section 4.8 of [QUIC-TLS]. 5308 See Section 22.3 for details of registering new error codes. 5310 20.1. Application Protocol Error Codes 5312 Application protocol error codes are 16-bit unsigned integers, but 5313 the management of application error codes are left to application 5314 protocols. Application protocol error codes are used for the 5315 RESET_STREAM frame (Section 19.4), the STOP_SENDING frame 5316 (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d 5317 (Section 19.19). 5319 21. Security Considerations 5321 21.1. Handshake Denial of Service 5323 As an encrypted and authenticated transport QUIC provides a range of 5324 protections against denial of service. Once the cryptographic 5325 handshake is complete, QUIC endpoints discard most packets that are 5326 not authenticated, greatly limiting the ability of an attacker to 5327 interfere with existing connections. 5329 Once a connection is established QUIC endpoints might accept some 5330 unauthenticated ICMP packets (see Section 14.2), but the use of these 5331 packets is extremely limited. The only other type of packet that an 5332 endpoint might accept is a stateless reset (Section 10.4) which 5333 relies on the token being kept secret until it is used. 5335 During the creation of a connection, QUIC only provides protection 5336 against attack from off the network path. All QUIC packets contain 5337 proof that the recipient saw a preceding packet from its peer. 5339 The first mechanism used is the source and destination connection 5340 IDs, which are required to match those set by a peer. Except for an 5341 Initial and stateless reset packets, an endpoint only accepts packets 5342 that include a destination connection that matches a connection ID 5343 the endpoint previously chose. This is the only protection offered 5344 for Version Negotiation packets. 5346 The destination connection ID in an Initial packet is selected by a 5347 client to be unpredictable, which serves an additional purpose. The 5348 packets that carry the cryptographic handshake are protected with a 5349 key that is derived from this connection ID and salt specific to the 5350 QUIC version. This allows endpoints to use the same process for 5351 authenticating packets that they receive as they use after the 5352 cryptographic handshake completes. Packets that cannot be 5353 authenticated are discarded. Protecting packets in this fashion 5354 provides a strong assurance that the sender of the packet saw the 5355 Initial packet and understood it. 5357 These protections are not intended to be effective against an 5358 attacker that is able to receive QUIC packets prior to the connection 5359 being established. Such an attacker can potentially send packets 5360 that will be accepted by QUIC endpoints. This version of QUIC 5361 attempts to detect this sort of attack, but it expects that endpoints 5362 will fail to establish a connection rather than recovering. For the 5363 most part, the cryptographic handshake protocol [QUIC-TLS] is 5364 responsible for detecting tampering during the handshake. 5366 Endpoints are permitted to use other methods to detect and attempt to 5367 recover from interference with the handshake. Invalid packets may be 5368 identified and discarded using other methods, but no specific method 5369 is mandated in this document. 5371 21.2. Amplification Attack 5373 An attacker might be able to receive an address validation token 5374 (Section 8) from a server and then release the IP address it used to 5375 acquire that token. At a later time, the attacker may initiate a 5376 0-RTT connection with a server by spoofing this same address, which 5377 might now address a different (victim) endpoint. The attacker can 5378 thus potentially cause the server to send an initial congestion 5379 window's worth of data towards the victim. 5381 Servers SHOULD provide mitigations for this attack by limiting the 5382 usage and lifetime of address validation tokens (see Section 8.1.2). 5384 21.3. Optimistic ACK Attack 5386 An endpoint that acknowledges packets it has not received might cause 5387 a congestion controller to permit sending at rates beyond what the 5388 network supports. An endpoint MAY skip packet numbers when sending 5389 packets to detect this behavior. An endpoint can then immediately 5390 close the connection with a connection error of type 5391 PROTOCOL_VIOLATION (see Section 10.3). 5393 21.4. Slowloris Attacks 5395 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 5396 connections to the target endpoint open and hold them open as long as 5397 possible. These attacks can be executed against a QUIC endpoint by 5398 generating the minimum amount of activity necessary to avoid being 5399 closed for inactivity. This might involve sending small amounts of 5400 data, gradually opening flow control windows in order to control the 5401 sender rate, or manufacturing ACK frames that simulate a high loss 5402 rate. 5404 QUIC deployments SHOULD provide mitigations for the Slowloris 5405 attacks, such as increasing the maximum number of clients the server 5406 will allow, limiting the number of connections a single IP address is 5407 allowed to make, imposing restrictions on the minimum transfer speed 5408 a connection is allowed to have, and restricting the length of time 5409 an endpoint is allowed to stay connected. 5411 21.5. Stream Fragmentation and Reassembly Attacks 5413 An adversarial sender might intentionally send fragments of stream 5414 data in order to cause disproportionate receive buffer memory 5415 commitment and/or creation of a large and inefficient data structure. 5417 An adversarial receiver might intentionally not acknowledge packets 5418 containing stream data in order to force the sender to store the 5419 unacknowledged stream data for retransmission. 5421 The attack on receivers is mitigated if flow control windows 5422 correspond to available memory. However, some receivers will over- 5423 commit memory and advertise flow control offsets in the aggregate 5424 that exceed actual available memory. The over-commitment strategy 5425 can lead to better performance when endpoints are well behaved, but 5426 renders endpoints vulnerable to the stream fragmentation attack. 5428 QUIC deployments SHOULD provide mitigations against stream 5429 fragmentation attacks. Mitigations could consist of avoiding over- 5430 committing memory, limiting the size of tracking data structures, 5431 delaying reassembly of STREAM frames, implementing heuristics based 5432 on the age and duration of reassembly holes, or some combination. 5434 21.6. Stream Commitment Attack 5436 An adversarial endpoint can open lots of streams, exhausting state on 5437 an endpoint. The adversarial endpoint could repeat the process on a 5438 large number of connections, in a manner similar to SYN flooding 5439 attacks in TCP. 5441 Normally, clients will open streams sequentially, as explained in 5442 Section 2.1. However, when several streams are initiated at short 5443 intervals, transmission error may cause STREAM DATA frames opening 5444 streams to be received out of sequence. A receiver is obligated to 5445 open intervening streams if a higher-numbered stream ID is received. 5446 Thus, on a new connection, opening stream 2000001 opens 1 million 5447 streams, as required by the specification. 5449 The number of active streams is limited by the concurrent stream 5450 limit transport parameter, as explained in Section 4.5. If chosen 5451 judiciously, this limit mitigates the effect of the stream commitment 5452 attack. However, setting the limit too low could affect performance 5453 when applications expect to open large number of streams. 5455 21.7. Explicit Congestion Notification Attacks 5457 An on-path attacker could manipulate the value of ECN codepoints in 5458 the IP header to influence the sender's rate. [RFC3168] discusses 5459 manipulations and their effects in more detail. 5461 An on-the-side attacker can duplicate and send packets with modified 5462 ECN codepoints to affect the sender's rate. If duplicate packets are 5463 discarded by a receiver, an off-path attacker will need to race the 5464 duplicate packet against the original to be successful in this 5465 attack. Therefore, QUIC receivers ignore ECN codepoints set in 5466 duplicate packets (see Section 13.3). 5468 21.8. Stateless Reset Oracle 5470 Stateless resets create a possible denial of service attack analogous 5471 to a TCP reset injection. This attack is possible if an attacker is 5472 able to cause a stateless reset token to be generated for a 5473 connection with a selected connection ID. An attacker that can cause 5474 this token to be generated can reset an active connection with the 5475 same connection ID. 5477 If a packet can be routed to different instances that share a static 5478 key, for example by changing an IP address or port, then an attacker 5479 can cause the server to send a stateless reset. To defend against 5480 this style of denial service, endpoints that share a static key for 5481 stateless reset (see Section 10.4.2) MUST be arranged so that packets 5482 with a given connection ID always arrive at an instance that has 5483 connection state, unless that connection is no longer active. 5485 In the case of a cluster that uses dynamic load balancing, it's 5486 possible that a change in load balancer configuration could happen 5487 while an active instance retains connection state; even if an 5488 instance retains connection state, the change in routing and 5489 resulting stateless reset will result in the connection being 5490 terminated. If there is no chance in the packet being routed to the 5491 correct instance, it is better to send a stateless reset than wait 5492 for connections to time out. However, this is acceptable only if the 5493 routing cannot be influenced by an attacker. 5495 21.9. Version Downgrade 5497 This document defines QUIC Version Negotiation packets Section 6, 5498 which can be used to negotiate the QUIC version used between two 5499 endpoints. However, this document does not specify how this 5500 negotiation will be performed between this version and subsequent 5501 future versions. In particular, Version Negotiation packets do not 5502 contain any mechanism to prevent version downgrade attacks. Future 5503 versions of QUIC that use Version Negotiation packets MUST define a 5504 mechanism that is robust against version downgrade attacks. 5506 22. IANA Considerations 5508 22.1. QUIC Transport Parameter Registry 5510 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 5511 under a "QUIC Protocol" heading. 5513 The "QUIC Transport Parameters" registry governs a 16-bit space. 5514 This space is split into two spaces that are governed by different 5515 policies. Values with the first byte in the range 0x00 to 0xfe (in 5516 hexadecimal) are assigned via the Specification Required policy 5517 [RFC8126]. Values with the first byte 0xff are reserved for Private 5518 Use [RFC8126]. 5520 Registrations MUST include the following fields: 5522 Value: The numeric value of the assignment (registrations will be 5523 between 0x0000 and 0xfeff). 5525 Parameter Name: A short mnemonic for the parameter. 5527 Specification: A reference to a publicly available specification for 5528 the value. 5530 The nominated expert(s) verify that a specification exists and is 5531 readily accessible. Expert(s) are encouraged to be biased towards 5532 approving registrations unless they are abusive, frivolous, or 5533 actively harmful (not merely aesthetically displeasing, or 5534 architecturally dubious). 5536 The initial contents of this registry are shown in Table 6. 5538 +--------+-------------------------------------+---------------+ 5539 | Value | Parameter Name | Specification | 5540 +--------+-------------------------------------+---------------+ 5541 | 0x0000 | original_connection_id | Section 18.1 | 5542 | | | | 5543 | 0x0001 | idle_timeout | Section 18.1 | 5544 | | | | 5545 | 0x0002 | stateless_reset_token | Section 18.1 | 5546 | | | | 5547 | 0x0003 | max_packet_size | Section 18.1 | 5548 | | | | 5549 | 0x0004 | initial_max_data | Section 18.1 | 5550 | | | | 5551 | 0x0005 | initial_max_stream_data_bidi_local | Section 18.1 | 5552 | | | | 5553 | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.1 | 5554 | | | | 5555 | 0x0007 | initial_max_stream_data_uni | Section 18.1 | 5556 | | | | 5557 | 0x0008 | initial_max_streams_bidi | Section 18.1 | 5558 | | | | 5559 | 0x0009 | initial_max_streams_uni | Section 18.1 | 5560 | | | | 5561 | 0x000a | ack_delay_exponent | Section 18.1 | 5562 | | | | 5563 | 0x000b | max_ack_delay | Section 18.1 | 5564 | | | | 5565 | 0x000c | disable_migration | Section 18.1 | 5566 | | | | 5567 | 0x000d | preferred_address | Section 18.1 | 5568 +--------+-------------------------------------+---------------+ 5570 Table 6: Initial QUIC Transport Parameters Entries 5572 22.2. QUIC Frame Type Registry 5574 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 5575 "QUIC Protocol" heading. 5577 The "QUIC Frame Types" registry governs a 62-bit space. This space 5578 is split into three spaces that are governed by different policies. 5579 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 5580 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 5581 to 0x3fff operate on the Specification Required policy [RFC8126]. 5582 All other values are assigned to Private Use [RFC8126]. 5584 Registrations MUST include the following fields: 5586 Value: The numeric value of the assignment (registrations will be 5587 between 0x00 and 0x3fff). A range of values MAY be assigned. 5589 Frame Name: A short mnemonic for the frame type. 5591 Specification: A reference to a publicly available specification for 5592 the value. 5594 The nominated expert(s) verify that a specification exists and is 5595 readily accessible. Specifications for new registrations need to 5596 describe the means by which an endpoint might determine that it can 5597 send the identified type of frame. An accompanying transport 5598 parameter registration (see Section 22.1) is expected for most 5599 registrations. The specification needs to describe the format and 5600 assigned semantics of any fields in the frame. 5602 Expert(s) are encouraged to be biased towards approving registrations 5603 unless they are abusive, frivolous, or actively harmful (not merely 5604 aesthetically displeasing, or architecturally dubious). 5606 The initial contents of this registry are tabulated in Table 3. 5608 22.3. QUIC Transport Error Codes Registry 5610 IANA [SHALL add/has added] a registry for "QUIC Transport Error 5611 Codes" under a "QUIC Protocol" heading. 5613 The "QUIC Transport Error Codes" registry governs a 16-bit space. 5614 This space is split into two spaces that are governed by different 5615 policies. Values with the first byte in the range 0x00 to 0xfe (in 5616 hexadecimal) are assigned via the Specification Required policy 5617 [RFC8126]. Values with the first byte 0xff are reserved for Private 5618 Use [RFC8126]. 5620 Registrations MUST include the following fields: 5622 Value: The numeric value of the assignment (registrations will be 5623 between 0x0000 and 0xfeff). 5625 Code: A short mnemonic for the parameter. 5627 Description: A brief description of the error code semantics, which 5628 MAY be a summary if a specification reference is provided. 5630 Specification: A reference to a publicly available specification for 5631 the value. 5633 The initial contents of this registry are shown in Table 7. Values 5634 from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. 5636 +------+---------------------------+----------------+---------------+ 5637 | Valu | Error | Description | Specification | 5638 | e | | | | 5639 +------+---------------------------+----------------+---------------+ 5640 | 0x0 | NO_ERROR | No error | Section 20 | 5641 | | | | | 5642 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 5643 | | | error | | 5644 | | | | | 5645 | 0x2 | SERVER_BUSY | Server | Section 20 | 5646 | | | currently busy | | 5647 | | | | | 5648 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 5649 | | | error | | 5650 | | | | | 5651 | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | 5652 | | | streams opened | | 5653 | | | | | 5654 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 5655 | | | in invalid | | 5656 | | | stream state | | 5657 | | | | | 5658 | 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 | 5659 | | | final size | | 5660 | | | | | 5661 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 5662 | | | error | | 5663 | | | | | 5664 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 5665 | | | transport | | 5666 | | | parameters | | 5667 | | | | | 5668 | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | 5669 | | | protocol | | 5670 | | | violation | | 5671 | | | | | 5672 | 0xC | INVALID_MIGRATION | Violated | Section 20 | 5673 | | | disabled | | 5674 | | | migration | | 5675 +------+---------------------------+----------------+---------------+ 5677 Table 7: Initial QUIC Transport Error Codes Entries 5679 23. References 5680 23.1. Normative References 5682 [DPLPMTUD] 5683 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 5684 T. Voelker, "Packetization Layer Path MTU Discovery for 5685 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07 5686 (work in progress), February 2019. 5688 [QUIC-RECOVERY] 5689 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5690 and Congestion Control", draft-ietf-quic-recovery-19 (work 5691 in progress), March 2019. 5693 [QUIC-TLS] 5694 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5695 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5696 tls-19 (work in progress), March 2019. 5698 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5699 DOI 10.17487/RFC1191, November 1990, 5700 . 5702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5703 Requirement Levels", BCP 14, RFC 2119, 5704 DOI 10.17487/RFC2119, March 1997, 5705 . 5707 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5708 of Explicit Congestion Notification (ECN) to IP", 5709 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5710 . 5712 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 5713 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 5714 2003, . 5716 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5717 "Randomness Requirements for Security", BCP 106, RFC 4086, 5718 DOI 10.17487/RFC4086, June 2005, 5719 . 5721 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 5722 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 5723 . 5725 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 5726 "IPv6 Flow Label Specification", RFC 6437, 5727 DOI 10.17487/RFC6437, November 2011, 5728 . 5730 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 5731 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 5732 March 2017, . 5734 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5735 Writing an IANA Considerations Section in RFCs", BCP 26, 5736 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5737 . 5739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5741 May 2017, . 5743 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5744 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5745 DOI 10.17487/RFC8201, July 2017, 5746 . 5748 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 5749 Notification (ECN) Experimentation", RFC 8311, 5750 DOI 10.17487/RFC8311, January 2018, 5751 . 5753 [SPIN] Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 5754 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 5755 October 2018. 5757 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5758 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5759 . 5761 23.2. Informative References 5763 [EARLY-DESIGN] 5764 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 5765 December 2013, . 5767 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 5768 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 5769 DOI 10.17487/RFC7540, May 2015, 5770 . 5772 [QUIC-INVARIANTS] 5773 Thomson, M., "Version-Independent Properties of QUIC", 5774 draft-ietf-quic-invariants-03 (work in progress), March 5775 2019. 5777 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 5778 RFC 1812, DOI 10.17487/RFC1812, June 1995, 5779 . 5781 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 5782 Selective Acknowledgment Options", RFC 2018, 5783 DOI 10.17487/RFC2018, October 1996, 5784 . 5786 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5787 Hashing for Message Authentication", RFC 2104, 5788 DOI 10.17487/RFC2104, February 1997, 5789 . 5791 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 5792 RFC 2360, DOI 10.17487/RFC2360, June 1998, 5793 . 5795 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 5796 RFC 4303, DOI 10.17487/RFC4303, December 2005, 5797 . 5799 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 5800 Control Message Protocol (ICMPv6) for the Internet 5801 Protocol Version 6 (IPv6) Specification", STD 89, 5802 RFC 4443, DOI 10.17487/RFC4443, March 2006, 5803 . 5805 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 5806 Translation (NAT) Behavioral Requirements for Unicast 5807 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 5808 2007, . 5810 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5811 Key Derivation Function (HKDF)", RFC 5869, 5812 DOI 10.17487/RFC5869, May 2010, 5813 . 5815 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5816 "Transport Layer Security (TLS) Application-Layer Protocol 5817 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5818 July 2014, . 5820 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5821 (IPv6) Specification", STD 86, RFC 8200, 5822 DOI 10.17487/RFC8200, July 2017, 5823 . 5825 [SLOWLORIS] 5826 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 5827 . 5830 Appendix A. Sample Packet Number Decoding Algorithm 5832 The following pseudo-code shows how an implementation can decode 5833 packet numbers after header protection has been removed. 5835 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 5836 expected_pn = largest_pn + 1 5837 pn_win = 1 << pn_nbits 5838 pn_hwin = pn_win / 2 5839 pn_mask = pn_win - 1 5840 // The incoming packet number should be greater than 5841 // expected_pn - pn_hwin and less than or equal to 5842 // expected_pn + pn_hwin 5843 // 5844 // This means we can't just strip the trailing bits from 5845 // expected_pn and add the truncated_pn because that might 5846 // yield a value outside the window. 5847 // 5848 // The following code calculates a candidate value and 5849 // makes sure it's within the packet number window. 5850 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 5851 if candidate_pn <= expected_pn - pn_hwin: 5852 return candidate_pn + pn_win 5853 // Note the extra check for underflow when candidate_pn 5854 // is near zero. 5855 if candidate_pn > expected_pn + pn_hwin and 5856 candidate_pn > pn_win: 5857 return candidate_pn - pn_win 5858 return candidate_pn 5860 Appendix B. Change Log 5862 *RFC Editor's Note:* Please remove this section prior to 5863 publication of a final version of this document. 5865 Issue and pull request numbers are listed with a leading octothorp. 5867 B.1. Since draft-ietf-quic-transport-18 5869 o Removed version negotation; version negotiation, including 5870 authentication of the result, will be addressed in the next 5871 version of QUIC (#1773, #2313) 5873 o Added discussion of the use of IPv6 flow labels (#2348, #2399) 5875 o A connection ID can't be retired in a packet that uses that 5876 connection ID (#2101, #2420) 5878 o Idle timeout transport parameter is in milliseconds (from seconds) 5879 (#2453, #2454) 5881 o Endpoints are required to use new connnection IDs when they use 5882 new network paths (#2413, #2414) 5884 o Increased the set of permissible frames in 0-RTT (#2344, #2355) 5886 B.2. Since draft-ietf-quic-transport-17 5888 o Stream-related errors now use STREAM_STATE_ERROR (#2305) 5890 o Endpoints discard initial keys as soon as handshake keys are 5891 available (#1951, #2045) 5893 o Expanded conditions for ignoring ICMP packet too big messages 5894 (#2108, #2161) 5896 o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, 5897 #2241) 5899 o Endpoints are permitted to discard malformed initial packets 5900 (#2141) 5902 o Clarified ECN implementation and usage requirements (#2156, #2201) 5904 o Disable ECN count verification for packets that arrive out of 5905 order (#2198, #2215) 5907 o Use Probe Timeout (PTO) instead of RTO (#2206, #2238) 5909 o Loosen constraints on retransmission of ACK ranges (#2199, #2245) 5911 o Limit Retry and Version Negotiation to once per datagram (#2259, 5912 #2303) 5914 o Set a maximum value for max_ack_delay transport parameter (#2282, 5915 #2301) 5917 o Allow server preferred address for both IPv4 and IPv6 (#2122, 5918 #2296) 5920 o Corrected requirements for migration to a preferred address 5921 (#2146, #2349) 5923 o ACK of non-existent packet is illegal (#2298, #2302) 5925 B.3. Since draft-ietf-quic-transport-16 5927 o Stream limits are defined as counts, not maximums (#1850, #1906) 5929 o Require amplification attack defense after closing (#1905, #1911) 5931 o Remove reservation of application error code 0 for STOPPING 5932 (#1804, #1922) 5934 o Renumbered frames (#1945) 5936 o Renumbered transport parameters (#1946) 5938 o Numeric transport parameters are expressed as varints (#1608, 5939 #1947, #1955) 5941 o Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 5943 o Rework the first byte (#2006) 5945 * Fix the 0x40 bit 5947 * Change type values for long header 5949 * Add spin bit to short header (#631, #1988) 5951 * Encrypt the remainder of the first byte (#1322) 5953 * Move packet number length to first byte 5955 * Move ODCIL to first byte of retry packets 5957 * Simplify packet number protection (#1575) 5959 o Allow STOP_SENDING to open a remote bidirectional stream (#1797, 5960 #2013) 5962 o Added mitigation for off-path migration attacks (#1278, #1749, 5963 #2033) 5965 o Don't let the PMTU to drop below 1280 (#2063, #2069) 5967 o Require peers to replace retired connection IDs (#2085) 5969 o Servers are required to ignore Version Negotiation packets (#2088) 5971 o Tokens are repeated in all Initial packets (#2089) 5973 o Clarified how PING frames are sent after loss (#2094) 5975 o Initial keys are discarded once Handshake are available (#1951, 5976 #2045) 5978 o ICMP PTB validation clarifications (#2161, #2109, #2108) 5980 B.4. Since draft-ietf-quic-transport-15 5982 Substantial editorial reorganization; no technical changes. 5984 B.5. Since draft-ietf-quic-transport-14 5986 o Merge ACK and ACK_ECN (#1778, #1801) 5988 o Explicitly communicate max_ack_delay (#981, #1781) 5990 o Validate original connection ID after Retry packets (#1710, #1486, 5991 #1793) 5993 o Idle timeout is optional and has no specified maximum (#1765) 5995 o Update connection ID handling; add RETIRE_CONNECTION_ID type 5996 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 5997 #1821) 5999 o Include a Token in all Initial packets (#1649, #1794) 6001 o Prevent handshake deadlock (#1764, #1824) 6003 B.6. Since draft-ietf-quic-transport-13 6005 o Streams open when higher-numbered streams of the same type open 6006 (#1342, #1549) 6008 o Split initial stream flow control limit into 3 transport 6009 parameters (#1016, #1542) 6011 o All flow control transport parameters are optional (#1610) 6013 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 6015 o Permit stateless reset in response to any packet (#1348, #1553) 6017 o Recommended defense against stateless reset spoofing (#1386, 6018 #1554) 6020 o Prevent infinite stateless reset exchanges (#1443, #1627) 6022 o Forbid processing of the same packet number twice (#1405, #1624) 6024 o Added a packet number decoding example (#1493) 6026 o More precisely define idle timeout (#1429, #1614, #1652) 6028 o Corrected format of Retry packet and prevented looping (#1492, 6029 #1451, #1448, #1498) 6031 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 6032 #1514, #1621) 6034 o Permit Retry in response to 0-RTT (#1547, #1552) 6036 o Looser verification of ECN counters to account for ACK loss 6037 (#1555, #1481, #1565) 6039 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 6041 B.7. Since draft-ietf-quic-transport-12 6043 o Changes to integration of the TLS handshake (#829, #1018, #1094, 6044 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 6046 * The cryptographic handshake uses CRYPTO frames, not stream 0 6048 * QUIC packet protection is used in place of TLS record 6049 protection 6051 * Separate QUIC packet number spaces are used for the handshake 6053 * Changed Retry to be independent of the cryptographic handshake 6055 * Added NEW_TOKEN frame and Token fields to Initial packet 6057 * Limit the use of HelloRetryRequest to address TLS needs (like 6058 key shares) 6060 o Enable server to transition connections to a preferred address 6061 (#560, #1251, #1373) 6063 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 6064 (#804, #805, #1372) 6066 o Changed rules and recommendations for use of new connection IDs 6067 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 6069 o Added a transport parameter to disable intentional connection 6070 migration (#1271, #1447) 6072 o Packets from different connection ID can't be coalesced (#1287, 6073 #1423) 6075 o Fixed sampling method for packet number encryption; the length 6076 field in long headers includes the packet number field in addition 6077 to the packet payload (#1387, #1389) 6079 o Stateless Reset is now symmetric and subject to size constraints 6080 (#466, #1346) 6082 o Added frame type extension mechanism (#58, #1473) 6084 B.8. Since draft-ietf-quic-transport-11 6086 o Enable server to transition connections to a preferred address 6087 (#560, #1251) 6089 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 6090 #990, #734, #1317, #1267, #1079) 6092 o Packet numbers use a variable-length encoding (#989, #1334) 6094 o STREAM frames can now be empty (#1350) 6096 B.9. Since draft-ietf-quic-transport-10 6098 o Swap payload length and packed number fields in long header 6099 (#1294) 6101 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 6102 (#1274) 6104 o Spin bit reserved (#1283) 6106 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 6107 o A more complete connection migration (#1249) 6109 o Refine opportunistic ACK defense text (#305, #1030, #1185) 6111 o A Stateless Reset Token isn't mandatory (#818, #1191) 6113 o Removed implicit stream opening (#896, #1193) 6115 o An empty STREAM frame can be used to open a stream without sending 6116 data (#901, #1194) 6118 o Define stream counts in transport parameters rather than a maximum 6119 stream ID (#1023, #1065) 6121 o STOP_SENDING is now prohibited before streams are used (#1050) 6123 o Recommend including ACK in Retry packets and allow PADDING (#1067, 6124 #882) 6126 o Endpoints now become closing after an idle timeout (#1178, #1179) 6128 o Remove implication that Version Negotiation is sent when a packet 6129 of the wrong version is received (#1197) 6131 B.10. Since draft-ietf-quic-transport-09 6133 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 6134 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 6135 (#1091, #725, #1086) 6137 o A server can now only send 3 packets without validating the client 6138 address (#38, #1090) 6140 o Delivery order of stream data is no longer strongly specified 6141 (#252, #1070) 6143 o Rework of packet handling and version negotiation (#1038) 6145 o Stream 0 is now exempt from flow control until the handshake 6146 completes (#1074, #725, #825, #1082) 6148 o Improved retransmission rules for all frame types: information is 6149 retransmitted, not packets or frames (#463, #765, #1095, #1053) 6151 o Added an error code for server busy signals (#1137) 6153 o Endpoints now set the connection ID that their peer uses. 6154 Connection IDs are variable length. Removed the 6155 omit_connection_id transport parameter and the corresponding short 6156 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 6158 B.11. Since draft-ietf-quic-transport-08 6160 o Clarified requirements for BLOCKED usage (#65, #924) 6162 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 6163 #928) 6165 o GAP limitation in ACK Frame (#613) 6167 o Improved PMTUD description (#614, #1036) 6169 o Clarified stream state machine (#634, #662, #743, #894) 6171 o Reserved versions don't need to be generated deterministically 6172 (#831, #931) 6174 o You don't always need the draining period (#871) 6176 o Stateless reset clarified as version-specific (#930, #986) 6178 o initial_max_stream_id_x transport parameters are optional (#970, 6179 #971) 6181 o Ack Delay assumes a default value during the handshake (#1007, 6182 #1009) 6184 o Removed transport parameters from NewSessionTicket (#1015) 6186 B.12. Since draft-ietf-quic-transport-07 6188 o The long header now has version before packet number (#926, #939) 6190 o Rename and consolidate packet types (#846, #822, #847) 6192 o Packet types are assigned new codepoints and the Connection ID 6193 Flag is inverted (#426, #956) 6195 o Removed type for Version Negotiation and use Version 0 (#963, 6196 #968) 6198 o Streams are split into unidirectional and bidirectional (#643, 6199 #656, #720, #872, #175, #885) 6201 * Stream limits now have separate uni- and bi-directional 6202 transport parameters (#909, #958) 6204 * Stream limit transport parameters are now optional and default 6205 to 0 (#970, #971) 6207 o The stream state machine has been split into read and write (#634, 6208 #894) 6210 o Employ variable-length integer encodings throughout (#595) 6212 o Improvements to connection close 6214 * Added distinct closing and draining states (#899, #871) 6216 * Draining period can terminate early (#869, #870) 6218 * Clarifications about stateless reset (#889, #890) 6220 o Address validation for connection migration (#161, #732, #878) 6222 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 6224 o negotiated_version is sent in server transport parameters (#710, 6225 #959) 6227 o Increased the range over which packet numbers are randomized 6228 (#864, #850, #964) 6230 B.13. Since draft-ietf-quic-transport-06 6232 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 6234 o Split error code space between application and transport (#485) 6236 o Stateless reset token moved to end (#820) 6238 o 1-RTT-protected long header types removed (#848) 6240 o No acknowledgments during draining period (#852) 6242 o Remove "application close" as a separate close type (#854) 6244 o Remove timestamps from the ACK frame (#841) 6246 o Require transport parameters to only appear once (#792) 6248 B.14. Since draft-ietf-quic-transport-05 6250 o Stateless token is server-only (#726) 6252 o Refactor section on connection termination (#733, #748, #328, 6253 #177) 6255 o Limit size of Version Negotiation packet (#585) 6257 o Clarify when and what to ack (#736) 6259 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 6261 o Clarify Keep-alive requirements (#729) 6263 B.15. Since draft-ietf-quic-transport-04 6265 o Introduce STOP_SENDING frame, RESET_STREAM only resets in one 6266 direction (#165) 6268 o Removed GOAWAY; application protocols are responsible for graceful 6269 shutdown (#696) 6271 o Reduced the number of error codes (#96, #177, #184, #211) 6273 o Version validation fields can't move or change (#121) 6275 o Removed versions from the transport parameters in a 6276 NewSessionTicket message (#547) 6278 o Clarify the meaning of "bytes in flight" (#550) 6280 o Public reset is now stateless reset and not visible to the path 6281 (#215) 6283 o Reordered bits and fields in STREAM frame (#620) 6285 o Clarifications to the stream state machine (#572, #571) 6287 o Increased the maximum length of the Largest Acknowledged field in 6288 ACK frames to 64 bits (#629) 6290 o truncate_connection_id is renamed to omit_connection_id (#659) 6292 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 6293 #328) 6295 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 6297 B.16. Since draft-ietf-quic-transport-03 6299 o Change STREAM and RESET_STREAM layout 6301 o Add MAX_STREAM_ID settings 6303 B.17. Since draft-ietf-quic-transport-02 6305 o The size of the initial packet payload has a fixed minimum (#267, 6306 #472) 6308 o Define when Version Negotiation packets are ignored (#284, #294, 6309 #241, #143, #474) 6311 o The 64-bit FNV-1a algorithm is used for integrity protection of 6312 unprotected packets (#167, #480, #481, #517) 6314 o Rework initial packet types to change how the connection ID is 6315 chosen (#482, #442, #493) 6317 o No timestamps are forbidden in unprotected packets (#542, #429) 6319 o Cryptographic handshake is now on stream 0 (#456) 6321 o Remove congestion control exemption for cryptographic handshake 6322 (#248, #476) 6324 o Version 1 of QUIC uses TLS; a new version is needed to use a 6325 different handshake protocol (#516) 6327 o STREAM frames have a reduced number of offset lengths (#543, #430) 6329 o Split some frames into separate connection- and stream- level 6330 frames (#443) 6332 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 6334 * BLOCKED split to match WINDOW_UPDATE split (#454) 6336 * Define STREAM_ID_NEEDED frame (#455) 6338 o A NEW_CONNECTION_ID frame supports connection migration without 6339 linkability (#232, #491, #496) 6341 o Transport parameters for 0-RTT are retained from a previous 6342 connection (#405, #513, #512) 6343 * A client in 0-RTT no longer required to reset excess streams 6344 (#425, #479) 6346 o Expanded security considerations (#440, #444, #445, #448) 6348 B.18. Since draft-ietf-quic-transport-01 6350 o Defined short and long packet headers (#40, #148, #361) 6352 o Defined a versioning scheme and stable fields (#51, #361) 6354 o Define reserved version values for "greasing" negotiation (#112, 6355 #278) 6357 o The initial packet number is randomized (#35, #283) 6359 o Narrow the packet number encoding range requirement (#67, #286, 6360 #299, #323, #356) 6362 o Defined client address validation (#52, #118, #120, #275) 6364 o Define transport parameters as a TLS extension (#49, #122) 6366 o SCUP and COPT parameters are no longer valid (#116, #117) 6368 o Transport parameters for 0-RTT are either remembered from before, 6369 or assume default values (#126) 6371 o The server chooses connection IDs in its final flight (#119, #349, 6372 #361) 6374 o The server echoes the Connection ID and packet number fields when 6375 sending a Version Negotiation packet (#133, #295, #244) 6377 o Defined a minimum packet size for the initial handshake packet 6378 from the client (#69, #136, #139, #164) 6380 o Path MTU Discovery (#64, #106) 6382 o The initial handshake packet from the client needs to fit in a 6383 single packet (#338) 6385 o Forbid acknowledgment of packets containing only ACK and PADDING 6386 (#291) 6388 o Require that frames are processed when packets are acknowledged 6389 (#381, #341) 6391 o Removed the STOP_WAITING frame (#66) 6393 o Don't require retransmission of old timestamps for lost ACK frames 6394 (#308) 6396 o Clarified that frames are not retransmitted, but the information 6397 in them can be (#157, #298) 6399 o Error handling definitions (#335) 6401 o Split error codes into four sections (#74) 6403 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 6404 (#289) 6406 o Define packet protection rules (#336) 6408 o Require that stream be entirely delivered or reset, including 6409 acknowledgment of all STREAM frames or the RESET_STREAM, before it 6410 closes (#381) 6412 o Remove stream reservation from state machine (#174, #280) 6414 o Only stream 1 does not contribute to connection-level flow control 6415 (#204) 6417 o Stream 1 counts towards the maximum concurrent stream limit (#201, 6418 #282) 6420 o Remove connection-level flow control exclusion for some streams 6421 (except 1) (#246) 6423 o RESET_STREAM affects connection-level flow control (#162, #163) 6425 o Flow control accounting uses the maximum data offset on each 6426 stream, rather than bytes received (#378) 6428 o Moved length-determining fields to the start of STREAM and ACK 6429 (#168, #277) 6431 o Added the ability to pad between frames (#158, #276) 6433 o Remove error code and reason phrase from GOAWAY (#352, #355) 6435 o GOAWAY includes a final stream number for both directions (#347) 6437 o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 6438 consistent offset (#249) 6440 o Defined priority as the responsibility of the application protocol 6441 (#104, #303) 6443 B.19. Since draft-ietf-quic-transport-00 6445 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 6447 o Defined versioning 6449 o Reworked description of packet and frame layout 6451 o Error code space is divided into regions for each component 6453 o Use big endian for all numeric values 6455 B.20. Since draft-hamilton-quic-transport-protocol-01 6457 o Adopted as base for draft-ietf-quic-tls 6459 o Updated authors/editors list 6461 o Added IANA Considerations section 6463 o Moved Contributors and Acknowledgments to appendices 6465 Acknowledgments 6467 Special thanks are due to the following for helping shape pre-IETF 6468 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 6469 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 6471 This document has benefited immensely from various private 6472 discussions and public ones on the quic@ietf.org and proto- 6473 quic@chromium.org mailing lists. Our thanks to all. 6475 Contributors 6477 The original authors of this specification were Ryan Hamilton, Jana 6478 Iyengar, Ian Swett, and Alyssa Wilk. 6480 The original design and rationale behind this protocol draw 6481 significantly from work by Jim Roskind [EARLY-DESIGN]. In 6482 alphabetical order, the contributors to the pre-IETF QUIC project at 6483 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 6484 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 6485 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 6486 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 6487 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 6489 Authors' Addresses 6491 Jana Iyengar (editor) 6492 Fastly 6494 Email: jri.ietf@gmail.com 6496 Martin Thomson (editor) 6497 Mozilla 6499 Email: mt@lowentropy.net