idnits 2.17.1 draft-ietf-quic-transport-22.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 (July 09, 2019) is 1751 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 1795 == Missing Reference: 'CH' is mentioned on line 1791, but not defined == Missing Reference: 'SH' is mentioned on line 1793, but not defined == Missing Reference: 'EE' is mentioned on line 1794, but not defined == Missing Reference: 'CERT' is mentioned on line 1794, but not defined == Missing Reference: 'CV' is mentioned on line 1794, but not defined == Missing Reference: 'FIN' is mentioned on line 1794, but not defined -- Looks like a reference, but probably isn't: '1' on line 1793 -- Looks like a reference, but probably isn't: '4' on line 4647 -- Looks like a reference, but probably isn't: '16' on line 4652 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-08 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-22 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-22 -- 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-05 == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-05 Summary: 0 errors (**), 0 flaws (~~), 14 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: January 10, 2020 Mozilla 6 July 09, 2019 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-22 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 January 10, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 11 69 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12 71 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14 72 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 73 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17 74 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 75 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20 77 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21 78 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22 79 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 80 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23 81 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24 83 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25 84 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26 85 5.2. Matching Packets to Connections . . . . . . . . . . . . . 27 86 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27 87 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28 88 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29 89 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29 90 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 29 91 6.2. Handling Version Negotiation Packets . . . . . . . . . . 29 92 6.2.1. Version Negotiation Between Draft Versions . . . . . 30 93 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 30 94 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 31 95 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 32 96 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 33 97 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 35 98 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 35 99 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 37 100 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 37 101 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 102 8.1. Address Validation During Connection Establishment . . . 38 103 8.1.1. Address Validation using Retry Packets . . . . . . . 39 104 8.1.2. Address Validation for Future Connections . . . . . . 39 105 8.1.3. Address Validation Token Integrity . . . . . . . . . 41 106 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 42 107 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 43 108 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 43 109 8.5. Successful Path Validation . . . . . . . . . . . . . . . 43 110 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 111 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44 112 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45 113 9.2. Initiating Connection Migration . . . . . . . . . . . . . 45 114 9.3. Responding to Connection Migration . . . . . . . . . . . 46 115 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 47 116 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47 117 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 48 118 9.4. Loss Detection and Congestion Control . . . . . . . . . . 49 119 9.5. Privacy Implications of Connection Migration . . . . . . 50 120 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 121 9.6.1. Communicating a Preferred Address . . . . . . . . . . 51 122 9.6.2. Responding to Connection Migration . . . . . . . . . 51 123 9.6.3. Interaction of Client Migration and Preferred Address 52 124 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 52 125 10. Connection Termination . . . . . . . . . . . . . . . . . . . 53 126 10.1. Closing and Draining Connection States . . . . . . . . . 53 127 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 54 128 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 55 129 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 56 130 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 59 131 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 59 132 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 60 133 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 61 134 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 61 135 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 62 136 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 62 137 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 63 138 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 63 139 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 64 140 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 66 141 13. Packetization and Reliability . . . . . . . . . . . . . . . . 68 142 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 69 143 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 69 144 13.1.2. Limiting ACK Ranges . . . . . . . . . . . . . . . . 70 145 13.1.3. ACK Frames and Packet Protection . . . . . . . . . . 70 146 13.2. Retransmission of Information . . . . . . . . . . . . . 71 147 13.3. Explicit Congestion Notification . . . . . . . . . . . . 73 148 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 73 149 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 74 150 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 75 151 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 76 152 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 77 153 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 78 154 14.3.1. PMTU Probes Containing Source Connection ID . . . . 78 155 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 79 156 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 80 157 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 80 158 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 81 159 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 82 160 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 84 161 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 86 162 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 88 163 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 90 164 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 91 165 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 93 166 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 95 167 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 96 168 18.1. Transport Parameter Definitions . . . . . . . . . . . . 97 169 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 100 170 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 101 171 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 101 172 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 101 173 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 103 174 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 105 175 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 106 176 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 106 177 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 107 178 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 108 179 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 108 180 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 110 181 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 110 182 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 111 183 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 112 184 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 113 185 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 113 186 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 114 187 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 116 188 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 116 189 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 117 190 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 117 191 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 118 192 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 119 193 20.1. Application Protocol Error Codes . . . . . . . . . . . . 120 194 21. Security Considerations . . . . . . . . . . . . . . . . . . . 120 195 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 120 196 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 121 197 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 122 198 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 122 199 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 122 200 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 123 201 21.7. Explicit Congestion Notification Attacks . . . . . . . . 123 202 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 124 203 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 124 204 21.10. Targeted Attacks by Routing . . . . . . . . . . . . . . 124 205 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 206 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 125 207 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 126 208 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 127 209 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 129 210 23.1. Normative References . . . . . . . . . . . . . . . . . . 130 211 23.2. Informative References . . . . . . . . . . . . . . . . . 131 212 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 133 213 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 133 214 B.1. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 134 215 B.2. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 134 216 B.3. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 135 217 B.4. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 135 218 B.5. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 136 219 B.6. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 136 220 B.7. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 138 221 B.8. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 138 222 B.9. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 138 223 B.10. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 139 224 B.11. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 140 225 B.12. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 140 226 B.13. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 141 227 B.14. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 141 228 B.15. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 142 229 B.16. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 143 230 B.17. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 143 231 B.18. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 143 232 B.19. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 144 233 B.20. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 144 234 B.21. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 145 235 B.22. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 147 236 B.23. Since draft-hamilton-quic-transport-protocol-01 . . . . . 147 237 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 148 238 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 148 239 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148 241 1. Introduction 243 QUIC is a multiplexed and secure general-purpose transport protocol 244 that provides: 246 o Stream multiplexing 248 o Stream and connection-level flow control 250 o Low-latency connection establishment 252 o Connection migration and resilience to NAT rebinding 254 o Authenticated and encrypted header and payload 256 QUIC uses UDP as a substrate to avoid requiring changes to legacy 257 client operating systems and middleboxes. QUIC authenticates all of 258 its headers and encrypts most of the data it exchanges, including its 259 signaling, to avoid incurring a dependency on middleboxes. 261 1.1. Document Structure 263 This document describes the core QUIC protocol and is structured as 264 follows. 266 o Streams are the basic service abstraction that QUIC provides. 268 * Section 2 describes core concepts related to streams, 270 * Section 3 provides a reference model for stream states, and 272 * Section 4 outlines the operation of flow control. 274 o Connections are the context in which QUIC endpoints communicate. 276 * Section 5 describes core concepts related to connections, 278 * Section 6 describes version negotiation, 280 * Section 7 details the process for establishing connections, 282 * Section 8 specifies critical denial of service mitigation 283 mechanisms, 285 * Section 9 describes how endpoints migrate a connection to a new 286 network path, 288 * Section 10 lists the options for terminating an open 289 connection, and 291 * Section 11 provides general guidance for error handling. 293 o Packets and frames are the basic unit used by QUIC to communicate. 295 * Section 12 describes concepts related to packets and frames, 297 * Section 13 defines models for the transmission, retransmission, 298 and acknowledgement of data, and 300 * Section 14 specifies rules for managing the size of packets. 302 o Finally, encoding details of QUIC protocol elements are described 303 in: 305 * Section 15 (Versions), 307 * Section 16 (Integer Encoding), 309 * Section 17 (Packet Headers), 311 * Section 18 (Transport Parameters), 313 * Section 19 (Frames), and 315 * Section 20 (Errors). 317 Accompanying documents describe QUIC's loss detection and congestion 318 control [QUIC-RECOVERY], and the use of TLS for key negotiation 319 [QUIC-TLS]. 321 This document defines QUIC version 1, which conforms to the protocol 322 invariants in [QUIC-INVARIANTS]. 324 1.2. Terms and Definitions 326 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 327 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 328 "OPTIONAL" in this document are to be interpreted as described in BCP 329 14 [RFC2119] [RFC8174] when, and only when, they appear in all 330 capitals, as shown here. 332 Commonly used terms in the document are described below. 334 QUIC: The transport protocol described by this document. QUIC is a 335 name, not an acronym. 337 QUIC packet: A complete processable unit of QUIC that can be 338 encapsulated in a UDP datagram. Multiple QUIC packets can be 339 encapsulated in a single UDP datagram. 341 Endpoint: An entity that can participate in a QUIC connection by 342 generating, receiving, and processing QUIC packets. There are 343 only two types of endpoint in QUIC: client and server. 345 Client: The endpoint initiating a QUIC connection. 347 Server: The endpoint accepting incoming QUIC connections. 349 Connection ID: An opaque identifier that is used to identify a QUIC 350 connection at an endpoint. Each endpoint sets a value for its 351 peer to include in packets sent towards the endpoint. 353 Stream: A unidirectional or bidirectional channel of ordered bytes 354 within a QUIC connection. A QUIC connection can carry multiple 355 simultaneous streams. 357 Application: An entity that uses QUIC to send and receive data. 359 1.3. Notational Conventions 361 Packet and frame diagrams in this document use the format described 362 in Section 3.1 of [RFC2360], with the following additional 363 conventions: 365 [x]: Indicates that x is optional 367 x (A): Indicates that x is A bits long 369 x (A/B/C) ...: Indicates that x is one of A, B, or C bits long 371 x (i) ...: Indicates that x uses the variable-length encoding in 372 Section 16 374 x (*) ...: Indicates that x is variable-length 376 2. Streams 378 Streams in QUIC provide a lightweight, ordered byte-stream 379 abstraction to an application. Streams can be unidirectional or 380 bidirecational. An alternative view of QUIC unidirectional streams 381 is a "message" abstraction of practically unlimited length. 383 Streams can be created by sending data. Other processes associated 384 with stream management - ending, cancelling, and managing flow 385 control - are all designed to impose minimal overheads. For 386 instance, a single STREAM frame (Section 19.8) can open, carry data 387 for, and close a stream. Streams can also be long-lived and can last 388 the entire duration of a connection. 390 Streams can be created by either endpoint, can concurrently send data 391 interleaved with other streams, and can be cancelled. QUIC does not 392 provide any means of ensuring ordering between bytes on different 393 streams. 395 QUIC allows for an arbitrary number of streams to operate 396 concurrently and for an arbitrary amount of data to be sent on any 397 stream, subject to flow control constraints (see Section 4) and 398 stream limits. 400 2.1. Stream Types and Identifiers 402 Streams can be unidirectional or bidirectional. Unidirectional 403 streams carry data in one direction: from the initiator of the stream 404 to its peer. Bidirectional streams allow for data to be sent in both 405 directions. 407 Streams are identified within a connection by a numeric value, 408 referred to as the stream ID. A stream ID is a 62-bit integer (0 to 409 2^62-1) that is unique for all streams on a connection. Stream IDs 410 are encoded as variable-length integers (see Section 16). A QUIC 411 endpoint MUST NOT reuse a stream ID within a connection. 413 The least significant bit (0x1) of the stream ID identifies the 414 initiator of the stream. Client-initiated streams have even-numbered 415 stream IDs (with the bit set to 0), and server-initiated streams have 416 odd-numbered stream IDs (with the bit set to 1). 418 The second least significant bit (0x2) of the stream ID distinguishes 419 between bidirectional streams (with the bit set to 0) and 420 unidirectional streams (with the bit set to 1). 422 The least significant two bits from a stream ID therefore identify a 423 stream as one of four types, as summarized in Table 1. 425 +------+----------------------------------+ 426 | Bits | Stream Type | 427 +------+----------------------------------+ 428 | 0x0 | Client-Initiated, Bidirectional | 429 | | | 430 | 0x1 | Server-Initiated, Bidirectional | 431 | | | 432 | 0x2 | Client-Initiated, Unidirectional | 433 | | | 434 | 0x3 | Server-Initiated, Unidirectional | 435 +------+----------------------------------+ 437 Table 1: Stream ID Types 439 Within each type, streams are created with numerically increasing 440 stream IDs. A stream ID that is used out of order results in all 441 streams of that type with lower-numbered stream IDs also being 442 opened. 444 The first bidirectional stream opened by the client has a stream ID 445 of 0. 447 2.2. Sending and Receiving Data 449 STREAM frames (Section 19.8) encapsulate data sent by an application. 450 An endpoint uses the Stream ID and Offset fields in STREAM frames to 451 place data in order. 453 Endpoints MUST be able to deliver stream data to an application as an 454 ordered byte-stream. Delivering an ordered byte-stream requires that 455 an endpoint buffer any data that is received out of order, up to the 456 advertised flow control limit. 458 QUIC makes no specific allowances for delivery of stream data out of 459 order. However, implementations MAY choose to offer the ability to 460 deliver data out of order to a receiving application. 462 An endpoint could receive data for a stream at the same stream offset 463 multiple times. Data that has already been received can be 464 discarded. The data at a given offset MUST NOT change if it is sent 465 multiple times; an endpoint MAY treat receipt of different data at 466 the same offset within a stream as a connection error of type 467 PROTOCOL_VIOLATION. 469 Streams are an ordered byte-stream abstraction with no other 470 structure visible to QUIC. STREAM frame boundaries are not expected 471 to be preserved when data is transmitted, retransmitted after packet 472 loss, or delivered to the application at a receiver. 474 An endpoint MUST NOT send data on any stream without ensuring that it 475 is within the flow control limits set by its peer. Flow control is 476 described in detail in Section 4. 478 2.3. Stream Prioritization 480 Stream multiplexing can have a significant effect on application 481 performance if resources allocated to streams are correctly 482 prioritized. 484 QUIC does not provide a mechanism for exchanging prioritization 485 information. Instead, it relies on receiving priority information 486 from the application that uses QUIC. 488 A QUIC implementation SHOULD provide ways in which an application can 489 indicate the relative priority of streams. When deciding which 490 streams to dedicate resources to, the implementation SHOULD use the 491 information provided by the application. 493 3. Stream States 495 This section describes streams in terms of their send or receive 496 components. Two state machines are described: one for the streams on 497 which an endpoint transmits data (Section 3.1), and another for 498 streams on which an endpoint receives data (Section 3.2). 500 Unidirectional streams use the applicable state machine directly. 501 Bidirectional streams use both state machines. For the most part, 502 the use of these state machines is the same whether the stream is 503 unidirectional or bidirectional. The conditions for opening a stream 504 are slightly more complex for a bidirectional stream because the 505 opening of either send or receive sides causes the stream to open in 506 both directions. 508 An endpoint MUST open streams of the same type in increasing order of 509 stream ID. 511 Note: These states are largely informative. This document uses 512 stream states to describe rules for when and how different types 513 of frames can be sent and the reactions that are expected when 514 different types of frames are received. Though these state 515 machines are intended to be useful in implementing QUIC, these 516 states aren't intended to constrain implementations. An 517 implementation can define a different state machine as long as its 518 behavior is consistent with an implementation that implements 519 these states. 521 3.1. Sending Stream States 523 Figure 1 shows the states for the part of a stream that sends data to 524 a peer. 526 o 527 | Create Stream (Sending) 528 | Peer Creates Bidirectional Stream 529 v 530 +-------+ 531 | Ready | Send RESET_STREAM 532 | |-----------------------. 533 +-------+ | 534 | | 535 | Send STREAM / | 536 | STREAM_DATA_BLOCKED | 537 | | 538 | Peer Creates | 539 | Bidirectional Stream | 540 v | 541 +-------+ | 542 | Send | Send RESET_STREAM | 543 | |---------------------->| 544 +-------+ | 545 | | 546 | Send STREAM + FIN | 547 v v 548 +-------+ +-------+ 549 | Data | Send RESET_STREAM | Reset | 550 | Sent |------------------>| Sent | 551 +-------+ +-------+ 552 | | 553 | Recv All ACKs | Recv ACK 554 v v 555 +-------+ +-------+ 556 | Data | | Reset | 557 | Recvd | | Recvd | 558 +-------+ +-------+ 560 Figure 1: States for Sending Parts of Streams 562 The sending part of stream that the endpoint initiates (types 0 and 2 563 for clients, 1 and 3 for servers) is opened by the application. The 564 "Ready" state represents a newly created stream that is able to 565 accept data from the application. Stream data might be buffered in 566 this state in preparation for sending. 568 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a 569 sending part of a stream to enter the "Send" state. An 570 implementation might choose to defer allocating a stream ID to a 571 stream until it sends the first STREAM frame and enters this state, 572 which can allow for better stream prioritization. 574 The sending part of a bidirectional stream initiated by a peer (type 575 0 for a server, type 1 for a client) enters the "Ready" state then 576 immediately transitions to the "Send" state if the receiving part 577 enters the "Recv" state (Section 3.2). 579 In the "Send" state, an endpoint transmits - and retransmits as 580 necessary - stream data in STREAM frames. The endpoint respects the 581 flow control limits set by its peer, and continues to accept and 582 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 583 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 584 stream or connection flow control limits Section 4.1. 586 After the application indicates that all stream data has been sent 587 and a STREAM frame containing the FIN bit is sent, the sending part 588 of the stream enters the "Data Sent" state. From this state, the 589 endpoint only retransmits stream data as necessary. The endpoint 590 does not need to check flow control limits or send 591 STREAM_DATA_BLOCKED frames for a stream in this state. 592 MAX_STREAM_DATA frames might be received until the peer receives the 593 final stream offset. The endpoint can safely ignore any 594 MAX_STREAM_DATA frames it receives from its peer for a stream in this 595 state. 597 Once all stream data has been successfully acknowledged, the sending 598 part of the stream enters the "Data Recvd" state, which is a terminal 599 state. 601 From any of the "Ready", "Send", or "Data Sent" states, an 602 application can signal that it wishes to abandon transmission of 603 stream data. Alternatively, an endpoint might receive a STOP_SENDING 604 frame from its peer. In either case, the endpoint sends a 605 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 606 state. 608 An endpoint MAY send a RESET_STREAM as the first frame that mentions 609 a stream; this causes the sending part of that stream to open and 610 then immediately transition to the "Reset Sent" state. 612 Once a packet containing a RESET_STREAM has been acknowledged, the 613 sending part of the stream enters the "Reset Recvd" state, which is a 614 terminal state. 616 3.2. Receiving Stream States 618 Figure 2 shows the states for the part of a stream that receives data 619 from a peer. The states for a receiving part of a stream mirror only 620 some of the states of the sending part of the stream at the peer. 621 The receiving part of a stream does not track states on the sending 622 part that cannot be observed, such as the "Ready" state. Instead, 623 the receiving part of a stream tracks the delivery of data to the 624 application, some of which cannot be observed by the sender. 626 o 627 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 628 | Create Bidirectional Stream (Sending) 629 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 630 | Create Higher-Numbered Stream 631 v 632 +-------+ 633 | Recv | Recv RESET_STREAM 634 | |-----------------------. 635 +-------+ | 636 | | 637 | Recv STREAM + FIN | 638 v | 639 +-------+ | 640 | Size | Recv RESET_STREAM | 641 | Known |---------------------->| 642 +-------+ | 643 | | 644 | Recv All Data | 645 v v 646 +-------+ Recv RESET_STREAM +-------+ 647 | Data |--- (optional) --->| Reset | 648 | Recvd | Recv All Data | Recvd | 649 +-------+<-- (optional) ----+-------+ 650 | | 651 | App Read All Data | App Read RST 652 v v 653 +-------+ +-------+ 654 | Data | | Reset | 655 | Read | | Read | 656 +-------+ +-------+ 658 Figure 2: States for Receiving Parts of Streams 660 The receiving part of a stream initiated by a peer (types 1 and 3 for 661 a client, or 0 and 2 for a server) is created when the first STREAM, 662 STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. 663 For bidirectional streams initiated by a peer, receipt of a 664 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 665 stream also creates the receiving part. The initial state for the 666 receiving part of stream is "Recv". 668 The receiving part of a stream enters the "Recv" state when the 669 sending part of a bidirectional stream initiated by the endpoint 670 (type 0 for a client, type 1 for a server) enters the "Ready" state. 672 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 673 STOP_SENDING frame is received from the peer for that stream. 674 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 675 that the remote peer has opened the stream and is providing flow 676 control credit. Receiving a STOP_SENDING frame for an unopened 677 stream indicates that the remote peer no longer wishes to receive 678 data on this stream. Either frame might arrive before a STREAM or 679 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 681 Before a stream is created, all streams of the same type with lower- 682 numbered stream IDs MUST be created. This ensures that the creation 683 order for streams is consistent on both endpoints. 685 In the "Recv" state, the endpoint receives STREAM and 686 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 687 reassembled into the correct order for delivery to the application. 688 As data is consumed by the application and buffer space becomes 689 available, the endpoint sends MAX_STREAM_DATA frames to allow the 690 peer to send more data. 692 When a STREAM frame with a FIN bit is received, the final size of the 693 stream is known (see Section 4.4). The receiving part of the stream 694 then enters the "Size Known" state. In this state, the endpoint no 695 longer needs to send MAX_STREAM_DATA frames, it only receives any 696 retransmissions of stream data. 698 Once all data for the stream has been received, the receiving part 699 enters the "Data Recvd" state. This might happen as a result of 700 receiving the same STREAM frame that causes the transition to "Size 701 Known". After all data has been received, any STREAM or 702 STREAM_DATA_BLOCKED frames for the stream can be discarded. 704 The "Data Recvd" state persists until stream data has been delivered 705 to the application. Once stream data has been delivered, the stream 706 enters the "Data Read" state, which is a terminal state. 708 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 709 causes the stream to enter the "Reset Recvd" state. This might cause 710 the delivery of stream data to the application to be interrupted. 712 It is possible that all stream data is received when a RESET_STREAM 713 is received (that is, from the "Data Recvd" state). Similarly, it is 714 possible for remaining stream data to arrive after receiving a 715 RESET_STREAM frame (the "Reset Recvd" state). An implementation is 716 free to manage this situation as it chooses. 718 Sending RESET_STREAM means that an endpoint cannot guarantee delivery 719 of stream data; however there is no requirement that stream data not 720 be delivered if a RESET_STREAM is received. An implementation MAY 721 interrupt delivery of stream data, discard any data that was not 722 consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM 723 signal might be suppressed or withheld if stream data is completely 724 received and is buffered to be read by the application. If the 725 RESET_STREAM is suppressed, the receiving part of the stream remains 726 in "Data Recvd". 728 Once the application receives the signal indicating that the stream 729 was reset, the receiving part of the stream transitions to the "Reset 730 Read" state, which is a terminal state. 732 3.3. Permitted Frame Types 734 The sender of a stream sends just three frame types that affect the 735 state of a stream at either sender or receiver: STREAM 736 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 737 (Section 19.4). 739 A sender MUST NOT send any of these frames from a terminal state 740 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 741 STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the 742 terminal states and in the "Reset Sent" state. A receiver could 743 receive any of these three frames in any state, due to the 744 possibility of delayed delivery of packets carrying them. 746 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 747 STOP_SENDING frames (Section 19.5). 749 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 750 receiver can send STOP_SENDING in any state where it has not received 751 a RESET_STREAM frame; that is states other than "Reset Recvd" or 752 "Reset Read". However there is little value in sending a 753 STOP_SENDING frame in the "Data Recvd" state, since all stream data 754 has been received. A sender could receive either of these two frames 755 in any state as a result of delayed delivery of packets. 757 3.4. Bidirectional Stream States 759 A bidirectional stream is composed of sending and receiving parts. 760 Implementations may represent states of the bidirectional stream as 761 composites of sending and receiving stream states. The simplest 762 model presents the stream as "open" when either sending or receiving 763 parts are in a non-terminal state and "closed" when both sending and 764 receiving streams are in terminal states. 766 Table 2 shows a more complex mapping of bidirectional stream states 767 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 768 shows that multiple states on sending or receiving parts of streams 769 are mapped to the same composite state. Note that this is just one 770 possibility for such a mapping; this mapping requires that data is 771 acknowledged before the transition to a "closed" or "half-closed" 772 state. 774 +-----------------------+---------------------+---------------------+ 775 | Sending Part | Receiving Part | Composite State | 776 +-----------------------+---------------------+---------------------+ 777 | No Stream/Ready | No Stream/Recv *1 | idle | 778 | | | | 779 | Ready/Send/Data Sent | Recv/Size Known | open | 780 | | | | 781 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 782 | | Read | (remote) | 783 | | | | 784 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 785 | | Read | (remote) | 786 | | | | 787 | Data Recvd | Recv/Size Known | half-closed (local) | 788 | | | | 789 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 790 | Recvd | | | 791 | | | | 792 | Reset Sent/Reset | Data Recvd/Data | closed | 793 | Recvd | Read | | 794 | | | | 795 | Reset Sent/Reset | Reset Recvd/Reset | closed | 796 | Recvd | Read | | 797 | | | | 798 | Data Recvd | Data Recvd/Data | closed | 799 | | Read | | 800 | | | | 801 | Data Recvd | Reset Recvd/Reset | closed | 802 | | Read | | 803 +-----------------------+---------------------+---------------------+ 805 Table 2: Possible Mapping of Stream States to HTTP/2 807 Note (*1): A stream is considered "idle" if it has not yet been 808 created, or if the receiving part of the stream is in the "Recv" 809 state without yet having received any frames. 811 3.5. Solicited State Transitions 813 If an endpoint is no longer interested in the data it is receiving on 814 a stream, it MAY send a STOP_SENDING frame identifying that stream to 815 prompt closure of the stream in the opposite direction. This 816 typically indicates that the receiving application is no longer 817 reading data it receives from the stream, but it is not a guarantee 818 that incoming data will be ignored. 820 STREAM frames received after sending STOP_SENDING are still counted 821 toward connection and stream flow control, even though these frames 822 can be discarded upon receipt. 824 A STOP_SENDING frame requests that the receiving endpoint send a 825 RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame 826 MUST send a RESET_STREAM frame if the stream is in the Ready or Send 827 state. If the stream is in the Data Sent state and any outstanding 828 data is declared lost, an endpoint SHOULD send a RESET_STREAM frame 829 in lieu of a retransmission. 831 An endpoint SHOULD copy the error code from the STOP_SENDING frame to 832 the RESET_STREAM frame it sends, but MAY use any application error 833 code. The endpoint that sends a STOP_SENDING frame MAY ignore the 834 error code carried in any RESET_STREAM frame it receives. 836 If the STOP_SENDING frame is received on a stream that is already in 837 the "Data Sent" state, an endpoint that wishes to cease 838 retransmission of previously-sent STREAM frames on that stream MUST 839 first send a RESET_STREAM frame. 841 STOP_SENDING SHOULD only be sent for a stream that has not been reset 842 by the peer. STOP_SENDING is most useful for streams in the "Recv" 843 or "Size Known" states. 845 An endpoint is expected to send another STOP_SENDING frame if a 846 packet containing a previous STOP_SENDING is lost. However, once 847 either all stream data or a RESET_STREAM frame has been received for 848 the stream - that is, the stream is in any state other than "Recv" or 849 "Size Known" - sending a STOP_SENDING frame is unnecessary. 851 An endpoint that wishes to terminate both directions of a 852 bidirectional stream can terminate one direction by sending a 853 RESET_STREAM, and it can encourage prompt termination in the opposite 854 direction by sending a STOP_SENDING frame. 856 4. Flow Control 858 It is necessary to limit the amount of data that a receiver could 859 buffer, to prevent a fast sender from overwhelming a slow receiver, 860 or to prevent a malicious sender from consuming a large amount of 861 memory at a receiver. To enable a receiver to limit memory 862 commitment to a connection and to apply back pressure on the sender, 863 streams are flow controlled both individually and as an aggregate. A 864 QUIC receiver controls the maximum amount of data the sender can send 865 on a stream at any time, as described in Section 4.1 and Section 4.2 866 Similarly, to limit concurrency within a connection, a QUIC endpoint 867 controls the maximum cumulative number of streams that its peer can 868 initiate, as described in Section 4.5. 870 Data sent in CRYPTO frames is not flow controlled in the same way as 871 stream data. QUIC relies on the cryptographic protocol 872 implementation to avoid excessive buffering of data; see [QUIC-TLS]. 873 The implementation SHOULD provide an interface to QUIC to tell it 874 about its buffering limits so that there is not excessive buffering 875 at multiple layers. 877 4.1. Data Flow Control 879 QUIC employs a credit-based flow-control scheme similar to that in 880 HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is 881 prepared to receive on a given stream and for the entire connection. 882 This leads to two levels of data flow control in QUIC: 884 o Stream flow control, which prevents a single stream from consuming 885 the entire receive buffer for a connection by limiting the amount 886 of data that can be sent on any stream. 888 o Connection flow control, which prevents senders from exceeding a 889 receiver's buffer capacity for the connection, by limiting the 890 total bytes of stream data sent in STREAM frames on all streams. 892 A receiver sets initial credits for all streams by sending transport 893 parameters during the handshake (Section 7.3). A receiver sends 894 MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to 895 the sender to advertise additional credit. 897 A receiver advertises credit for a stream by sending a 898 MAX_STREAM_DATA frame with the Stream ID field set appropriately. A 899 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 900 stream. A receiver could use the current offset of data consumed to 901 determine the flow control offset to be advertised. A receiver MAY 902 send MAX_STREAM_DATA frames in multiple packets in order to make sure 903 that the sender receives an update before running out of flow control 904 credit, even if one of the packets is lost. 906 A receiver advertises credit for a connection by sending a MAX_DATA 907 frame, which indicates the maximum of the sum of the absolute byte 908 offsets of all streams. A receiver maintains a cumulative sum of 909 bytes received on all streams, which is used to check for flow 910 control violations. A receiver might use a sum of bytes consumed on 911 all streams to determine the maximum data limit to be advertised. 913 A receiver can advertise a larger offset by sending MAX_STREAM_DATA 914 or MAX_DATA frames. Once a receiver advertises an offset, it MAY 915 advertise a smaller offset, but this has no effect. 917 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 918 (Section 11) if the sender violates the advertised connection or 919 stream data limits. 921 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 922 not increase flow control limits. 924 If a sender runs out of flow control credit, it will be unable to 925 send new data and is considered blocked. A sender SHOULD send a 926 STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to 927 write but is blocked by flow control limits. These frames are 928 expected to be sent infrequently in common cases, but they are 929 considered useful for debugging and monitoring purposes. 931 A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED 932 frames for the same data limit, unless the original frame is 933 determined to be lost. Another STREAM_DATA_BLOCKED or DATA_BLOCKED 934 frame can be sent after the data limit is increased. 936 4.2. Flow Credit Increments 938 This document leaves when and how many bytes to advertise in a 939 MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a 940 few considerations. These frames contribute to connection overhead. 941 Therefore frequently sending frames with small changes is 942 undesirable. At the same time, larger increments to limits are 943 necessary to avoid blocking if updates are less frequent, requiring 944 larger resource commitments at the receiver. Thus there is a trade- 945 off between resource commitment and overhead when determining how 946 large a limit is advertised. 948 A receiver can use an autotuning mechanism to tune the frequency and 949 amount of advertised additional credit based on a round-trip time 950 estimate and the rate at which the receiving application consumes 951 data, similar to common TCP implementations. As an optimization, 952 sending frames related to flow control only when there are other 953 frames to send or when a peer is blocked ensures that flow control 954 doesn't cause extra packets to be sent. 956 If a sender runs out of flow control credit, it will be unable to 957 send new data and is considered blocked. It is generally considered 958 best to not let the sender become blocked. To avoid blocking a 959 sender, and to reasonably account for the possibility of loss, a 960 receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two 961 round trips before it expects the sender to get blocked. 963 A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED 964 frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will 965 mean that a sender will be blocked for at least an entire round trip, 966 and potentially for longer if the peer chooses to not send 967 STREAM_DATA_BLOCKED or DATA_BLOCKED frames. 969 4.3. Handling Stream Cancellation 971 Endpoints need to eventually agree on the amount of flow control 972 credit that has been consumed, to avoid either exceeding flow control 973 limits or deadlocking. 975 On receipt of a RESET_STREAM frame, an endpoint will tear down state 976 for the matching stream and ignore further data arriving on that 977 stream. Without the offset included in RESET_STREAM, the two 978 endpoints could disagree on the number of bytes that count towards 979 connection flow control. 981 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes 982 the final size of data sent on the stream. On receiving a 983 RESET_STREAM frame, a receiver definitively knows how many bytes were 984 sent on that stream before the RESET_STREAM frame, and the receiver 985 MUST use the final size of the stream to account for all bytes sent 986 on the stream in its connection level flow controller. 988 RESET_STREAM terminates one direction of a stream abruptly. For a 989 bidirectional stream, RESET_STREAM has no effect on data flow in the 990 opposite direction. Both endpoints MUST maintain flow control state 991 for the stream in the unterminated direction until that direction 992 enters a terminal state, or until one of the endpoints sends 993 CONNECTION_CLOSE. 995 4.4. Stream Final Size 997 The final size is the amount of flow control credit that is consumed 998 by a stream. Assuming that every contiguous byte on the stream was 999 sent once, the final size is the number of bytes sent. More 1000 generally, this is one higher than the offset of the byte with the 1001 largest offset sent on the stream, or zero if no bytes were sent. 1003 For a stream that is reset, the final size is carried explicitly in a 1004 RESET_STREAM frame. Otherwise, the final size is the offset plus the 1005 length of a STREAM frame marked with a FIN flag, or 0 in the case of 1006 incoming unidirectional streams. 1008 An endpoint will know the final size for a stream when the receiving 1009 part of the stream enters the "Size Known" or "Reset Recvd" state 1010 (Section 3). 1012 An endpoint MUST NOT send data on a stream at or beyond the final 1013 size. 1015 Once a final size for a stream is known, it cannot change. If a 1016 RESET_STREAM or STREAM frame is received indicating a change in the 1017 final size for the stream, an endpoint SHOULD respond with a 1018 FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat 1019 receipt of data at or beyond the final size as a FINAL_SIZE_ERROR 1020 error, even after a stream is closed. Generating these errors is not 1021 mandatory, but only because requiring that an endpoint generate these 1022 errors also means that the endpoint needs to maintain the final size 1023 state for closed streams, which could mean a significant state 1024 commitment. 1026 4.5. Controlling Concurrency 1028 An endpoint limits the cumulative number of incoming streams a peer 1029 can open. Only streams with a stream ID less than (max_stream * 4 + 1030 initial_stream_id_for_type) can be opened (see Table 5). Initial 1031 limits are set in the transport parameters (see Section 18.1) and 1032 subsequently limits are advertised using MAX_STREAMS frames 1033 (Section 19.11). Separate limits apply to unidirectional and 1034 bidirectional streams. 1036 If a max_streams transport parameter or MAX_STREAMS frame is received 1037 with a value greater than 2^60, this would allow a maximum stream ID 1038 that cannot be expressed as a variable-length integer (see 1039 Section 16). If either is received, the connection MUST be closed 1040 immediately with a connection error of type STREAM_LIMIT_ERROR (see 1041 Section 10.3). 1043 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1044 that receives a frame with a stream ID exceeding the limit it has 1045 sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR 1046 (Section 11). 1048 Once a receiver advertises a stream limit using the MAX_STREAMS 1049 frame, advertising a smaller limit has no effect. A receiver MUST 1050 ignore any MAX_STREAMS frame that does not increase the stream limit. 1052 As with stream and connection flow control, this document leaves when 1053 and how many streams to advertise to a peer via MAX_STREAMS to 1054 implementations. Implementations might choose to increase limits as 1055 streams close to keep the number of streams available to peers 1056 roughly consistent. 1058 An endpoint that is unable to open a new stream due to the peer's 1059 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1060 signal is considered useful for debugging. An endpoint MUST NOT wait 1061 to receive this signal before advertising additional credit, since 1062 doing so will mean that the peer will be blocked for at least an 1063 entire round trip, and potentially for longer if the peer chooses to 1064 not send STREAMS_BLOCKED frames. 1066 5. Connections 1068 QUIC's connection establishment combines version negotiation with the 1069 cryptographic and transport handshakes to reduce connection 1070 establishment latency, as described in Section 7. Once established, 1071 a connection may migrate to a different IP or port at either endpoint 1072 as described in Section 9. Finally, a connection may be terminated 1073 by either endpoint, as described in Section 10. 1075 5.1. Connection ID 1077 Each connection possesses a set of connection identifiers, or 1078 connection IDs, each of which can identify the connection. 1079 Connection IDs are independently selected by endpoints; each endpoint 1080 selects the connection IDs that its peer uses. 1082 The primary function of a connection ID is to ensure that changes in 1083 addressing at lower protocol layers (UDP, IP) don't cause packets for 1084 a QUIC connection to be delivered to the wrong endpoint. Each 1085 endpoint selects connection IDs using an implementation-specific (and 1086 perhaps deployment-specific) method which will allow packets with 1087 that connection ID to be routed back to the endpoint and identified 1088 by the endpoint upon receipt. 1090 Connection IDs MUST NOT contain any information that can be used by 1091 an external observer to correlate them with other connection IDs for 1092 the same connection. As a trivial example, this means the same 1093 connection ID MUST NOT be issued more than once on the same 1094 connection. 1096 Packets with long headers include Source Connection ID and 1097 Destination Connection ID fields. These fields are used to set the 1098 connection IDs for new connections; see Section 7.2 for details. 1100 Packets with short headers (Section 17.3) only include the 1101 Destination Connection ID and omit the explicit length. The length 1102 of the Destination Connection ID field is expected to be known to 1103 endpoints. Endpoints using a load balancer that routes based on 1104 connection ID could agree with the load balancer on a fixed length 1105 for connection IDs, or agree on an encoding scheme. A fixed portion 1106 could encode an explicit length, which allows the entire connection 1107 ID to vary in length and still be used by the load balancer. 1109 A Version Negotiation (Section 17.2.1) packet echoes the connection 1110 IDs selected by the client, both to ensure correct routing toward the 1111 client and to allow the client to validate that the packet is in 1112 response to an Initial packet. 1114 A zero-length connection ID MAY be used when the connection ID is not 1115 needed for routing and the address/port tuple of packets is 1116 sufficient to identify a connection. An endpoint whose peer has 1117 selected a zero-length connection ID MUST continue to use a zero- 1118 length connection ID for the lifetime of the connection and MUST NOT 1119 send packets from any other local address. 1121 When an endpoint has requested a non-zero-length connection ID, it 1122 needs to ensure that the peer has a supply of connection IDs from 1123 which to choose for packets sent to the endpoint. These connection 1124 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1125 (Section 19.15). 1127 5.1.1. Issuing Connection IDs 1129 Each Connection ID has an associated sequence number to assist in 1130 deduplicating messages. The initial connection ID issued by an 1131 endpoint is sent in the Source Connection ID field of the long packet 1132 header (Section 17.2) during the handshake. The sequence number of 1133 the initial connection ID is 0. If the preferred_address transport 1134 parameter is sent, the sequence number of the supplied connection ID 1135 is 1. 1137 Additional connection IDs are communicated to the peer using 1138 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1139 each newly-issued connection ID MUST increase by 1. The connection 1140 ID randomly selected by the client in the Initial packet and any 1141 connection ID provided by a Retry packet are not assigned sequence 1142 numbers unless a server opts to retain them as its initial connection 1143 ID. 1145 When an endpoint issues a connection ID, it MUST accept packets that 1146 carry this connection ID for the duration of the connection or until 1147 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1148 frame (Section 19.16). 1150 An endpoint SHOULD ensure that its peer has a sufficient number of 1151 available and unused connection IDs. Endpoints store received 1152 connection IDs for future use and advertise the number of connection 1153 IDs they are willing to store with the active_connection_id_limit 1154 transport parameter. An endpoint SHOULD NOT provide more connection 1155 IDs than the peer's limit. 1157 An endpoint SHOULD supply a new connection ID when it receives a 1158 packet with a previously unused connection ID or when the peer 1159 retires one, unless providing the new connection ID would exceed the 1160 peer's limit. An endpoint MAY limit the frequency or the total 1161 number of connection IDs issued for each connection to avoid the risk 1162 of running out of connection IDs; see Section 10.4.2. 1164 An endpoint that initiates migration and requires non-zero-length 1165 connection IDs SHOULD ensure that the pool of connection IDs 1166 available to its peer allows the peer to use a new connection ID on 1167 migration, as the peer will close the connection if the pool is 1168 exhausted. 1170 5.1.2. Consuming and Retiring Connection IDs 1172 An endpoint can change the connection ID it uses for a peer to 1173 another available one at any time during the connection. An endpoint 1174 consumes connection IDs in response to a migrating peer; see 1175 Section 9.5 for more. 1177 An endpoint maintains a set of connection IDs received from its peer, 1178 any of which it can use when sending packets. When the endpoint 1179 wishes to remove a connection ID from use, it sends a 1180 RETIRE_CONNECTION_ID frame to its peer. Sending a 1181 RETIRE_CONNECTION_ID frame indicates that the connection ID will not 1182 be used again and requests that the peer replace it with a new 1183 connection ID using a NEW_CONNECTION_ID frame. 1185 As discussed in Section 9.5, each connection ID MUST be used on 1186 packets sent from only one local address. An endpoint that migrates 1187 away from a local address SHOULD retire all connection IDs used on 1188 that address once it no longer plans to use that address. 1190 An endpoint can request that its peer retire connection IDs by 1191 sending a NEW_CONNECTION_ID frame with an increased Retire Prior To 1192 field. Upon receipt, the peer SHOULD retire the corresponding 1193 connection IDs and send the corresponding RETIRE_CONNECTION_ID frames 1194 in a timely manner. Failing to do so can cause packets to be 1195 delayed, lost, or cause the original endpoint to send a stateless 1196 reset in response to a connection ID it can no longer route 1197 correctly. 1199 An endpoint MAY discard a connection ID for which retirement has been 1200 requested once an interval of no less than 3 PTO has elapsed since an 1201 acknowledgement is received for the NEW_CONNECTION_ID frame 1202 requesting that retirement. Subsequent incoming packets using that 1203 connection ID could elicit a response with the corresponding 1204 stateless reset token. 1206 5.2. Matching Packets to Connections 1208 Incoming packets are classified on receipt. Packets can either be 1209 associated with an existing connection, or - for servers - 1210 potentially create a new connection. 1212 Hosts try to associate a packet with an existing connection. If the 1213 packet has a Destination Connection ID corresponding to an existing 1214 connection, QUIC processes that packet accordingly. Note that more 1215 than one connection ID can be associated with a connection; see 1216 Section 5.1. 1218 If the Destination Connection ID is zero length and the packet 1219 matches the address/port tuple of a connection where the host did not 1220 require connection IDs, QUIC processes the packet as part of that 1221 connection. Endpoints SHOULD either reject connection attempts that 1222 use the same addresses as existing connections, or use a non-zero- 1223 length Destination Connection ID so that packets can be correctly 1224 attributed to connections. 1226 Endpoints can send a Stateless Reset (Section 10.4) for any packets 1227 that cannot be attributed to an existing connection. A stateless 1228 reset allows a peer to more quickly identify when a connection 1229 becomes unusable. 1231 Packets that are matched to an existing connection are discarded if 1232 the packets are inconsistent with the state of that connection. For 1233 example, packets are discarded if they indicate a different protocol 1234 version than that of the connection, or if the removal of packet 1235 protection is unsuccessful once the expected keys are available. 1237 Invalid packets without packet protection, such as Initial, Retry, or 1238 Version Negotiation, MAY be discarded. An endpoint MUST generate a 1239 connection error if it commits changes to state before discovering an 1240 error. 1242 5.2.1. Client Packet Handling 1244 Valid packets sent to clients always include a Destination Connection 1245 ID that matches a value the client selects. Clients that choose to 1246 receive zero-length connection IDs can use the address/port tuple to 1247 identify a connection. Packets that don't match an existing 1248 connection are discarded. 1250 Due to packet reordering or loss, a client might receive packets for 1251 a connection that are encrypted with a key it has not yet computed. 1252 The client MAY drop these packets, or MAY buffer them in anticipation 1253 of later packets that allow it to compute the key. 1255 If a client receives a packet that has an unsupported version, it 1256 MUST discard that packet. 1258 5.2.2. Server Packet Handling 1260 If a server receives a packet that has an unsupported version, but 1261 the packet is sufficiently large to initiate a new connection for any 1262 version supported by the server, it SHOULD send a Version Negotiation 1263 packet as described in Section 6.1. Servers MAY rate control these 1264 packets to avoid storms of Version Negotiation packets. Otherwise, 1265 servers MUST drop packets that specify unsupported versions. 1267 The first packet for an unsupported version can use different 1268 semantics and encodings for any version-specific field. In 1269 particular, different packet protection keys might be used for 1270 different versions. Servers that do not support a particular version 1271 are unlikely to be able to decrypt the payload of the packet. 1272 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1273 unknown version, but instead send a Version Negotiation packet, 1274 provided that the packet is sufficiently long. 1276 Packets with a supported version, or no version field, are matched to 1277 a connection using the connection ID or - for packets with zero- 1278 length connection IDs - the address tuple. If the packet doesn't 1279 match an existing connection, the server continues below. 1281 If the packet is an Initial packet fully conforming with the 1282 specification, the server proceeds with the handshake (Section 7). 1283 This commits the server to the version that the client selected. 1285 If a server isn't currently accepting any new connections, it SHOULD 1286 send an Initial packet containing a CONNECTION_CLOSE frame with error 1287 code SERVER_BUSY. 1289 If the packet is a 0-RTT packet, the server MAY buffer a limited 1290 number of these packets in anticipation of a late-arriving Initial 1291 packet. Clients are not able to send Handshake packets prior to 1292 receiving a server response, so servers SHOULD ignore any such 1293 packets. 1295 Servers MUST drop incoming packets under all other circumstances. 1297 5.3. Life of a QUIC Connection 1299 TBD. 1301 6. Version Negotiation 1303 Version negotiation ensures that client and server agree to a QUIC 1304 version that is mutually supported. A server sends a Version 1305 Negotiation packet in response to each packet that might initiate a 1306 new connection; see Section 5.2 for details. 1308 The size of the first packet sent by a client will determine whether 1309 a server sends a Version Negotiation packet. Clients that support 1310 multiple QUIC versions SHOULD pad the first packet they send to the 1311 largest of the minimum packet sizes across all versions they support. 1312 This ensures that the server responds if there is a mutually 1313 supported version. 1315 6.1. Sending Version Negotiation Packets 1317 If the version selected by the client is not acceptable to the 1318 server, the server responds with a Version Negotiation packet (see 1319 Section 17.2.1). This includes a list of versions that the server 1320 will accept. An endpoint MUST NOT send a Version Negotiation packet 1321 in response to receiving a Version Negotiation packet. 1323 This system allows a server to process packets with unsupported 1324 versions without retaining state. Though either the Initial packet 1325 or the Version Negotiation packet that is sent in response could be 1326 lost, the client will send new packets until it successfully receives 1327 a response or it abandons the connection attempt. As a result, the 1328 client discards all state for the connection and does not send any 1329 more packets on the connection. 1331 A server MAY limit the number of Version Negotiation packets it 1332 sends. For instance, a server that is able to recognize packets as 1333 0-RTT might choose not to send Version Negotiation packets in 1334 response to 0-RTT packets with the expectation that it will 1335 eventually receive an Initial packet. 1337 6.2. Handling Version Negotiation Packets 1339 When a client receives a Version Negotiation packet, it MUST abandon 1340 the current connection attempt. Version Negotiation packets are 1341 designed to allow future versions of QUIC to negotiate the version in 1342 use between endpoints. Future versions of QUIC might change how 1343 implementations that support multiple versions of QUIC react to 1344 Version Negotiation packets when attempting to establish a connection 1345 using this version. How to perform version negotiation is left as 1346 future work defined by future versions of QUIC. In particular, that 1347 future work will need to ensure robustness against version downgrade 1348 attacks Section 21.9. 1350 6.2.1. Version Negotiation Between Draft Versions 1352 [[RFC editor: please remove this section before publication.]] 1354 When a draft implementation receives a Version Negotiation packet, it 1355 MAY use it to attempt a new connection with one of the versions 1356 listed in the packet, instead of abandoning the current connection 1357 attempt Section 6.2. 1359 The client MUST check that the Destination and Source Connection ID 1360 fields match the Source and Destination Connection ID fields in a 1361 packet that the client sent. If this check fails, the packet MUST be 1362 discarded. 1364 Once the Version Negotiation packet is determined to be valid, the 1365 client then selects an acceptable protocol version from the list 1366 provided by the server. The client then attempts to create a new 1367 connection using that version. The new connection MUST use a new 1368 random Destination Connection ID different from the one it had 1369 previously sent. 1371 Note that this mechanism does not protect against downgrade attacks 1372 and MUST NOT be used outside of draft implementations. 1374 6.3. Using Reserved Versions 1376 For a server to use a new version in the future, clients need to 1377 correctly handle unsupported versions. To help ensure this, a server 1378 SHOULD include a version that is reserved for forcing version 1379 negotiation (0x?a?a?a?a as defined in Section 15) when generating a 1380 Version Negotiation packet. 1382 The design of version negotiation permits a server to avoid 1383 maintaining state for packets that it rejects in this fashion. 1385 A client MAY send a packet using a version that is reserved for 1386 forcing version negotiation. This can be used to solicit a list of 1387 supported versions from a server. 1389 7. Cryptographic and Transport Handshake 1391 QUIC relies on a combined cryptographic and transport handshake to 1392 minimize connection establishment latency. QUIC uses the CRYPTO 1393 frame Section 19.6 to transmit the cryptographic handshake. Version 1394 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 1395 QUIC version number could indicate that a different cryptographic 1396 handshake protocol is in use. 1398 QUIC provides reliable, ordered delivery of the cryptographic 1399 handshake data. QUIC packet protection is used to encrypt as much of 1400 the handshake protocol as possible. The cryptographic handshake MUST 1401 provide the following properties: 1403 o authenticated key exchange, where 1405 * a server is always authenticated, 1407 * a client is optionally authenticated, 1409 * every connection produces distinct and unrelated keys, 1411 * keying material is usable for packet protection for both 0-RTT 1412 and 1-RTT packets, and 1414 * 1-RTT keys have forward secrecy 1416 o authenticated values for the transport parameters of the peer (see 1417 Section 7.3) 1419 o authenticated negotiation of an application protocol (TLS uses 1420 ALPN [RFC7301] for this purpose) 1422 The first CRYPTO frame from a client MUST be sent in a single packet. 1423 Any second attempt that is triggered by address validation (see 1424 Section 8.1) MUST also be sent within a single packet. This avoids 1425 having to reassemble a message from multiple packets. 1427 The first client packet of the cryptographic handshake protocol MUST 1428 fit within a 1232 byte QUIC packet payload. This includes overheads 1429 that reduce the space available to the cryptographic handshake 1430 protocol. 1432 An endpoint can verify support for Explicit Congestion Notification 1433 (ECN) in the first packets it sends, as described in Section 13.3.2. 1435 The CRYPTO frame can be sent in different packet number spaces. The 1436 sequence numbers used by CRYPTO frames to ensure ordered delivery of 1437 cryptographic handshake data start from zero in each packet number 1438 space. 1440 Endpoints MUST explicitly negotiate an application protocol. This 1441 avoids situations where there is a disagreement about the protocol 1442 that is in use. 1444 7.1. Example Handshake Flows 1446 Details of how TLS is integrated with QUIC are provided in 1447 [QUIC-TLS], but some examples are provided here. An extension of 1448 this exchange to support client address validation is shown in 1449 Section 8.1.1. 1451 Once any address validation exchanges are complete, the cryptographic 1452 handshake is used to agree on cryptographic keys. The cryptographic 1453 handshake is carried in Initial (Section 17.2.2) and Handshake 1454 (Section 17.2.4) packets. 1456 Figure 3 provides an overview of the 1-RTT handshake. Each line 1457 shows a QUIC packet with the packet type and packet number shown 1458 first, followed by the frames that are typically contained in those 1459 packets. So, for instance the first packet is of type Initial, with 1460 packet number 0, and contains a CRYPTO frame carrying the 1461 ClientHello. 1463 Note that multiple QUIC packets - even of different encryption levels 1464 - may be coalesced into a single UDP datagram (see Section 12.2), and 1465 so this handshake may consist of as few as 4 UDP datagrams, or any 1466 number more. For instance, the server's first flight contains 1467 packets from the Initial encryption level (obfuscation), the 1468 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1469 encryption level. 1471 Client Server 1473 Initial[0]: CRYPTO[CH] -> 1475 Initial[0]: CRYPTO[SH] ACK[0] 1476 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1477 <- 1-RTT[0]: STREAM[1, "..."] 1479 Initial[1]: ACK[0] 1480 Handshake[0]: CRYPTO[FIN], ACK[0] 1481 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1483 1-RTT[1]: STREAM[3, "..."], ACK[0] 1484 <- Handshake[1]: ACK[0] 1486 Figure 3: Example 1-RTT Handshake 1488 Figure 4 shows an example of a connection with a 0-RTT handshake and 1489 a single packet of 0-RTT data. Note that as described in 1490 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1491 encryption level, and the client sends 1-RTT packets in the same 1492 packet number space. 1494 Client Server 1496 Initial[0]: CRYPTO[CH] 1497 0-RTT[0]: STREAM[0, "..."] -> 1499 Initial[0]: CRYPTO[SH] ACK[0] 1500 Handshake[0] CRYPTO[EE, FIN] 1501 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1503 Initial[1]: ACK[0] 1504 Handshake[0]: CRYPTO[FIN], ACK[0] 1505 1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1507 1-RTT[1]: STREAM[3, "..."], ACK[1] 1508 <- Handshake[1]: ACK[0] 1510 Figure 4: Example 0-RTT Handshake 1512 7.2. Negotiating Connection IDs 1514 A connection ID is used to ensure consistent routing of packets, as 1515 described in Section 5.1. The long header contains two connection 1516 IDs: the Destination Connection ID is chosen by the recipient of the 1517 packet and is used to provide consistent routing; the Source 1518 Connection ID is used to set the Destination Connection ID used by 1519 the peer. 1521 During the handshake, packets with the long header (Section 17.2) are 1522 used to establish the connection ID that each endpoint uses. Each 1523 endpoint uses the Source Connection ID field to specify the 1524 connection ID that is used in the Destination Connection ID field of 1525 packets being sent to them. Upon receiving a packet, each endpoint 1526 sets the Destination Connection ID it sends to match the value of the 1527 Source Connection ID that they receive. 1529 When an Initial packet is sent by a client that has not previously 1530 received an Initial or Retry packet from the server, it populates the 1531 Destination Connection ID field with an unpredictable value. This 1532 MUST be at least 8 bytes in length. Until a packet is received from 1533 the server, the client MUST use the same value unless it abandons the 1534 connection attempt and starts a new one. The initial Destination 1535 Connection ID is used to determine packet protection keys for Initial 1536 packets. 1538 The client populates the Source Connection ID field with a value of 1539 its choosing and sets the SCID Len field to indicate the length. 1541 The first flight of 0-RTT packets use the same Destination and Source 1542 Connection ID values as the client's first Initial. 1544 Upon first receiving an Initial or Retry packet from the server, the 1545 client uses the Source Connection ID supplied by the server as the 1546 Destination Connection ID for subsequent packets, including any 1547 subsequent 0-RTT packets. That means that a client might change the 1548 Destination Connection ID twice during connection establishment, once 1549 in response to a Retry and once in response to the first Initial 1550 packet from the server. Once a client has received an Initial packet 1551 from the server, it MUST discard any packet it receives with a 1552 different Source Connection ID. 1554 A client MUST only change the value it sends in the Destination 1555 Connection ID in response to the first packet of each type it 1556 receives from the server (Retry or Initial); a server MUST set its 1557 value based on the Initial packet. Any additional changes are not 1558 permitted; if subsequent packets of those types include a different 1559 Source Connection ID, they MUST be discarded. This avoids problems 1560 that might arise from stateless processing of multiple Initial 1561 packets producing different connection IDs. 1563 The connection ID can change over the lifetime of a connection, 1564 especially in response to connection migration (Section 9); see 1565 Section 5.1.1 for details. 1567 7.3. Transport Parameters 1569 During connection establishment, both endpoints make authenticated 1570 declarations of their transport parameters. These declarations are 1571 made unilaterally by each endpoint. Endpoints are required to comply 1572 with the restrictions implied by these parameters; the description of 1573 each parameter includes rules for its handling. 1575 The encoding of the transport parameters is detailed in Section 18. 1577 QUIC includes the encoded transport parameters in the cryptographic 1578 handshake. Once the handshake completes, the transport parameters 1579 declared by the peer are available. Each endpoint validates the 1580 value provided by its peer. 1582 Definitions for each of the defined transport parameters are included 1583 in Section 18.1. 1585 An endpoint MUST treat receipt of a transport parameter with an 1586 invalid value as a connection error of type 1587 TRANSPORT_PARAMETER_ERROR. 1589 An endpoint MUST NOT send a parameter more than once in a given 1590 transport parameters extension. An endpoint SHOULD treat receipt of 1591 duplicate transport parameters as a connection error of type 1592 TRANSPORT_PARAMETER_ERROR. 1594 A server MUST include the original_connection_id transport parameter 1595 (Section 18.1) if it sent a Retry packet to enable validation of the 1596 Retry, as described in Section 17.2.5. 1598 7.3.1. Values of Transport Parameters for 0-RTT 1600 Both endpoints store the value of the server transport parameters 1601 from a connection and apply them to any 0-RTT packets that are sent 1602 in subsequent connections to that peer, except for transport 1603 parameters that are explicitly excluded. Remembered transport 1604 parameters apply to the new connection until the handshake completes 1605 and the client starts sending 1-RTT packets. Once the handshake 1606 completes, the client uses the transport parameters established in 1607 the handshake. 1609 The definition of new transport parameters (Section 7.3.2) MUST 1610 specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A 1611 client need not store a transport parameter it cannot process. 1613 A client MUST NOT use remembered values for the following parameters: 1614 original_connection_id, preferred_address, stateless_reset_token, 1615 ack_delay_exponent and active_connection_id_limit. The client MUST 1616 use the server's new values in the handshake instead, and absent new 1617 values from the server, the default value. 1619 A client that attempts to send 0-RTT data MUST remember all other 1620 transport parameters used by the server. The server can remember 1621 these transport parameters, or store an integrity-protected copy of 1622 the values in the ticket and recover the information when accepting 1623 0-RTT data. A server uses the transport parameters in determining 1624 whether to accept 0-RTT data. 1626 If 0-RTT data is accepted by the server, the server MUST NOT reduce 1627 any limits or alter any values that might be violated by the client 1628 with its 0-RTT data. In particular, a server that accepts 0-RTT data 1629 MUST NOT set values for the following parameters (Section 18.1) that 1630 are smaller than the remembered value of the parameters. 1632 o initial_max_data 1634 o initial_max_stream_data_bidi_local 1636 o initial_max_stream_data_bidi_remote 1638 o initial_max_stream_data_uni 1640 o initial_max_streams_bidi 1642 o initial_max_streams_uni 1644 Omitting or setting a zero value for certain transport parameters can 1645 result in 0-RTT data being enabled, but not usable. The applicable 1646 subset of transport parameters that permit sending of application 1647 data SHOULD be set to non-zero values for 0-RTT. This includes 1648 initial_max_data and either initial_max_streams_bidi and 1649 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 1650 initial_max_stream_data_uni. 1652 A server MUST either reject 0-RTT data or abort a handshake if the 1653 implied values for transport parameters cannot be supported. 1655 When sending frames in 0-RTT packets, a client MUST only use 1656 remembered transport parameters; importantly, it MUST NOT use updated 1657 values that it learns from the server's updated transport parameters 1658 or from frames received in 1-RTT packets. Updated values of 1659 transport parameters from the handshake apply only to 1-RTT packets. 1660 For instance, flow control limits from remembered transport 1661 parameters apply to all 0-RTT packets even if those values are 1662 increased by the handshake or by frames sent in 1-RTT packets. A 1663 server MAY treat use of updated transport parameters in 0-RTT as a 1664 connection error of type PROTOCOL_VIOLATION. 1666 7.3.2. New Transport Parameters 1668 New transport parameters can be used to negotiate new protocol 1669 behavior. An endpoint MUST ignore transport parameters that it does 1670 not support. Absence of a transport parameter therefore disables any 1671 optional protocol feature that is negotiated using the parameter. 1673 New transport parameters can be registered according to the rules in 1674 Section 22.1. 1676 7.4. Cryptographic Message Buffering 1678 Implementations need to maintain a buffer of CRYPTO data received out 1679 of order. Because there is no flow control of CRYPTO frames, an 1680 endpoint could potentially force its peer to buffer an unbounded 1681 amount of data. 1683 Implementations MUST support buffering at least 4096 bytes of data 1684 received in CRYPTO frames out of order. Endpoints MAY choose to 1685 allow more data to be buffered during the handshake. A larger limit 1686 during the handshake could allow for larger keys or credentials to be 1687 exchanged. An endpoint's buffer size does not need to remain 1688 constant during the life of the connection. 1690 Being unable to buffer CRYPTO frames during the handshake can lead to 1691 a connection failure. If an endpoint's buffer is exceeded during the 1692 handshake, it can expand its buffer temporarily to complete the 1693 handshake. If an endpoint does not expand its buffer, it MUST close 1694 the connection with a CRYPTO_BUFFER_EXCEEDED error code. 1696 Once the handshake completes, if an endpoint is unable to buffer all 1697 data in a CRYPTO frame, it MAY discard that CRYPTO frame and all 1698 CRYPTO frames received in the future, or it MAY close the connection 1699 with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing 1700 discarded CRYPTO frames MUST be acknowledged because the packet has 1701 been received and processed by the transport even though the CRYPTO 1702 frame was discarded. 1704 8. Address Validation 1706 Address validation is used by QUIC to avoid being used for a traffic 1707 amplification attack. In such an attack, a packet is sent to a 1708 server with spoofed source address information that identifies a 1709 victim. If a server generates more or larger packets in response to 1710 that packet, the attacker can use the server to send more data toward 1711 the victim than it would be able to send on its own. 1713 The primary defense against amplification attack is verifying that an 1714 endpoint is able to receive packets at the transport address that it 1715 claims. Address validation is performed both during connection 1716 establishment (see Section 8.1) and during connection migration (see 1717 Section 8.2). 1719 8.1. Address Validation During Connection Establishment 1721 Connection establishment implicitly provides address validation for 1722 both endpoints. In particular, receipt of a packet protected with 1723 Handshake keys confirms that the client received the Initial packet 1724 from the server. Once the server has successfully processed a 1725 Handshake packet from the client, it can consider the client address 1726 to have been validated. 1728 Prior to validating the client address, servers MUST NOT send more 1729 than three times as many bytes as the number of bytes they have 1730 received. This limits the magnitude of any amplification attack that 1731 can be mounted using spoofed source addresses. In determining this 1732 limit, servers only count the size of successfully processed packets. 1734 Clients MUST ensure that UDP datagrams containing only Initial 1735 packets are sized to at least 1200 bytes, adding padding to packets 1736 in the datagram as necessary. Sending padded datagrams ensures that 1737 the server is not overly constrained by the amplification 1738 restriction. 1740 Packet loss, in particular loss of a Handshake packet from the 1741 server, can cause a situation in which the server cannot send when 1742 the client has no data to send and the anti-amplification limit is 1743 reached. In order to avoid this causing a handshake deadlock, 1744 clients SHOULD send a packet upon a crypto retransmission timeout, as 1745 described in [QUIC-RECOVERY]. If the client has no data to 1746 retransmit and does not have Handshake keys, it SHOULD send an 1747 Initial packet in a UDP datagram of at least 1200 bytes. If the 1748 client has Handshake keys, it SHOULD send a Handshake packet. 1750 A server might wish to validate the client address before starting 1751 the cryptographic handshake. QUIC uses a token in the Initial packet 1752 to provide address validation prior to completing the handshake. 1753 This token is delivered to the client during connection establishment 1754 with a Retry packet (see Section 8.1.1) or in a previous connection 1755 using the NEW_TOKEN frame (see Section 8.1.2). 1757 In addition to sending limits imposed prior to address validation, 1758 servers are also constrained in what they can send by the limits set 1759 by the congestion controller. Clients are only constrained by the 1760 congestion controller. 1762 8.1.1. Address Validation using Retry Packets 1764 Upon receiving the client's Initial packet, the server can request 1765 address validation by sending a Retry packet (Section 17.2.5) 1766 containing a token. This token MUST be repeated by the client in all 1767 Initial packets it sends for that connection after it receives the 1768 Retry packet. In response to processing an Initial containing a 1769 token, a server can either abort the connection or permit it to 1770 proceed. 1772 As long as it is not possible for an attacker to generate a valid 1773 token for its own address (see Section 8.1.3) and the client is able 1774 to return that token, it proves to the server that it received the 1775 token. 1777 A server can also use a Retry packet to defer the state and 1778 processing costs of connection establishment. By giving the client a 1779 different connection ID to use, a server can cause the connection to 1780 be routed to a server instance with more resources available for new 1781 connections. 1783 A flow showing the use of a Retry packet is shown in Figure 5. 1785 Client Server 1787 Initial[0]: CRYPTO[CH] -> 1789 <- Retry+Token 1791 Initial+Token[1]: CRYPTO[CH] -> 1793 Initial[0]: CRYPTO[SH] ACK[1] 1794 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1795 <- 1-RTT[0]: STREAM[1, "..."] 1797 Figure 5: Example Handshake with Retry 1799 8.1.2. Address Validation for Future Connections 1801 A server MAY provide clients with an address validation token during 1802 one connection that can be used on a subsequent connection. Address 1803 validation is especially important with 0-RTT because a server 1804 potentially sends a significant amount of data to a client in 1805 response to 0-RTT data. 1807 The server uses the NEW_TOKEN frame Section 19.7 to provide the 1808 client with an address validation token that can be used to validate 1809 future connections. The client includes this token in Initial 1810 packets to provide address validation in a future connection. The 1811 client MUST include the token in all Initial packets it sends, unless 1812 a Retry replaces the token with a newer one. The client MUST NOT use 1813 the token provided in a Retry for future connections. Servers MAY 1814 discard any Initial packet that does not carry the expected token. 1816 A token SHOULD be constructed for the server to easily distinguish it 1817 from tokens that are sent in Retry packets as they are carried in the 1818 same field. 1820 The token MUST NOT include information that would allow it to be 1821 linked by an on-path observer to the connection on which it was 1822 issued. For example, it cannot include the connection ID or 1823 addressing information unless the values are encrypted. 1825 Unlike the token that is created for a Retry packet, there might be 1826 some time between when the token is created and when the token is 1827 subsequently used. Thus, a token SHOULD have an expiration time, 1828 which could be either an explicit expiration time or an issued 1829 timestamp that can be used to dynamically calculate the expiration 1830 time. A server can store the expiration time or include it in an 1831 encrypted form in the token. 1833 It is unlikely that the client port number is the same on two 1834 different connections; validating the port is therefore unlikely to 1835 be successful. 1837 If the client has a token received in a NEW_TOKEN frame on a previous 1838 connection to what it believes to be the same server, it SHOULD 1839 include that value in the Token field of its Initial packet. 1840 Including a token might allow the server to validate the client 1841 address without an additional round trip. 1843 A token allows a server to correlate activity between the connection 1844 where the token was issued and any connection where it is used. 1845 Clients that want to break continuity of identity with a server MAY 1846 discard tokens provided using the NEW_TOKEN frame. A token obtained 1847 in a Retry packet MUST be used immediately during the connection 1848 attempt and cannot be used in subsequent connection attempts. 1850 A client SHOULD NOT reuse a token in different connections. Reusing 1851 a token allows connections to be linked by entities on the network 1852 path (see Section 9.5). A client MUST NOT reuse a token if it 1853 believes that its point of network attachment has changed since the 1854 token was last used; that is, if there is a change in its local IP 1855 address or network interface. A client needs to start the connection 1856 process over if it migrates prior to completing the handshake. 1858 When a server receives an Initial packet with an address validation 1859 token, it MUST attempt to validate the token, unless it has already 1860 completed address validation. If the token is invalid then the 1861 server SHOULD proceed as if the client did not have a validated 1862 address, including potentially sending a Retry. If the validation 1863 succeeds, the server SHOULD then allow the handshake to proceed. 1865 Note: The rationale for treating the client as unvalidated rather 1866 than discarding the packet is that the client might have received 1867 the token in a previous connection using the NEW_TOKEN frame, and 1868 if the server has lost state, it might be unable to validate the 1869 token at all, leading to connection failure if the packet is 1870 discarded. A server SHOULD encode tokens provided with NEW_TOKEN 1871 frames and Retry packets differently, and validate the latter more 1872 strictly. 1874 In a stateless design, a server can use encrypted and authenticated 1875 tokens to pass information to clients that the server can later 1876 recover and use to validate a client address. Tokens are not 1877 integrated into the cryptographic handshake and so they are not 1878 authenticated. For instance, a client might be able to reuse a 1879 token. To avoid attacks that exploit this property, a server can 1880 limit its use of tokens to only the information needed to validate 1881 client addresses. 1883 Attackers could replay tokens to use servers as amplifiers in DDoS 1884 attacks. To protect against such attacks, servers SHOULD ensure that 1885 tokens sent in Retry packets are only accepted for a short time. 1886 Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need 1887 to be valid for longer, but SHOULD NOT be accepted multiple times in 1888 a short period. Servers are encouraged to allow tokens to be used 1889 only once, if possible. 1891 8.1.3. Address Validation Token Integrity 1893 An address validation token MUST be difficult to guess. Including a 1894 large enough random value in the token would be sufficient, but this 1895 depends on the server remembering the value it sends to clients. 1897 A token-based scheme allows the server to offload any state 1898 associated with validation to the client. For this design to work, 1899 the token MUST be covered by integrity protection against 1900 modification or falsification by clients. Without integrity 1901 protection, malicious clients could generate or guess values for 1902 tokens that would be accepted by the server. Only the server 1903 requires access to the integrity protection key for tokens. 1905 There is no need for a single well-defined format for the token 1906 because the server that generates the token also consumes it. A 1907 token could include information about the claimed client address (IP 1908 and port), a timestamp, and any other supplementary information the 1909 server will need to validate the token in the future. 1911 8.2. Path Validation 1913 Path validation is used during connection migration (see Section 9 1914 and Section 9.6) by the migrating endpoint to verify reachability of 1915 a peer from a new local address. In path validation, endpoints test 1916 reachability between a specific local address and a specific peer 1917 address, where an address is the two-tuple of IP address and port. 1919 Path validation tests that packets (PATH_CHALLENGE) can be both sent 1920 to and received (PATH_RESPONSE) from a peer on the path. 1921 Importantly, it validates that the packets received from the 1922 migrating endpoint do not carry a spoofed source address. 1924 Path validation can be used at any time by either endpoint. For 1925 instance, an endpoint might check that a peer is still in possession 1926 of its address after a period of quiescence. 1928 Path validation is not designed as a NAT traversal mechanism. Though 1929 the mechanism described here might be effective for the creation of 1930 NAT bindings that support NAT traversal, the expectation is that one 1931 or other peer is able to receive packets without first having sent a 1932 packet on that path. Effective NAT traversal needs additional 1933 synchronization mechanisms that are not provided here. 1935 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 1936 are used for path validation with other frames. In particular, an 1937 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 1938 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 1939 PATH_CHALLENGE. 1941 When probing a new path, an endpoint might want to ensure that its 1942 peer has an unused connection ID available for responses. The 1943 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 1944 same packet. This ensures that an unused connection ID will be 1945 available to the peer when sending a response. 1947 8.3. Initiating Path Validation 1949 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 1950 containing a random payload on the path to be validated. 1952 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 1953 packet loss, however an endpoint SHOULD NOT send multiple 1954 PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT 1955 send a PATH_CHALLENGE more frequently than it would an Initial 1956 packet, ensuring that connection migration is no more load on a new 1957 path than establishing a new connection. 1959 The endpoint MUST use unpredictable data in every PATH_CHALLENGE 1960 frame so that it can associate the peer's response with the 1961 corresponding PATH_CHALLENGE. 1963 8.4. Path Validation Responses 1965 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 1966 immediately by echoing the data contained in the PATH_CHALLENGE frame 1967 in a PATH_RESPONSE frame. 1969 An endpoint MUST NOT send more than one PATH_RESPONSE frame in 1970 response to one PATH_CHALLENGE frame (see Section 13.2). The peer is 1971 expected to send more PATH_CHALLENGE frames as necessary to evoke 1972 additional PATH_RESPONSE frames. 1974 8.5. Successful Path Validation 1976 A new address is considered valid when a PATH_RESPONSE frame is 1977 received that contains the data that was sent in a previous 1978 PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing 1979 a PATH_CHALLENGE frame is not adequate validation, since the 1980 acknowledgment can be spoofed by a malicious peer. 1982 Note that receipt on a different local address does not result in 1983 path validation failure, as it might be a result of a forwarded 1984 packet (see Section 9.3.3) or misrouting. It is possible that a 1985 valid PATH_RESPONSE might be received in the future. 1987 8.6. Failed Path Validation 1989 Path validation only fails when the endpoint attempting to validate 1990 the path abandons its attempt to validate the path. 1992 Endpoints SHOULD abandon path validation based on a timer. When 1993 setting this timer, implementations are cautioned that the new path 1994 could have a longer round-trip time than the original. A value of 1995 three times the larger of the current Probe Timeout (PTO) or the 1996 initial timeout (that is, 2*kInitialRtt) as defined in 1997 [QUIC-RECOVERY] is RECOMMENDED. That is: 1999 validation_timeout = max(3*PTO, 6*kInitialRtt) 2001 Note that the endpoint might receive packets containing other frames 2002 on the new path, but a PATH_RESPONSE frame with appropriate data is 2003 required for path validation to succeed. 2005 When an endpoint abandons path validation, it determines that the 2006 path is unusable. This does not necessarily imply a failure of the 2007 connection - endpoints can continue sending packets over other paths 2008 as appropriate. If no paths are available, an endpoint can wait for 2009 a new path to become available or close the connection. 2011 A path validation might be abandoned for other reasons besides 2012 failure. Primarily, this happens if a connection migration to a new 2013 path is initiated while a path validation on the old path is in 2014 progress. 2016 9. Connection Migration 2018 The use of a connection ID allows connections to survive changes to 2019 endpoint addresses (IP address and port), such as those caused by an 2020 endpoint migrating to a new network. This section describes the 2021 process by which an endpoint migrates to a new address. 2023 The design of QUIC relies on endpoints retaining a stable address for 2024 the duration of the handshake. An endpoint MUST NOT initiate 2025 connection migration before the handshake is confirmed, as defined in 2026 section 4.1.2 of [QUIC-TLS]. 2028 An endpoint also MUST NOT initiate connection migration if the peer 2029 sent the "disable_migration" transport parameter during the 2030 handshake. An endpoint which has sent this transport parameter, but 2031 detects that a peer has nonetheless migrated to a different network 2032 MAY treat this as a connection error of type INVALID_MIGRATION. 2033 Similarly, an endpoint MUST NOT initiate migration if its peer 2034 supplies a zero-length connection ID as packets without a Destination 2035 Connection ID cannot be attributed to a connection based on address 2036 tuple. 2038 Not all changes of peer address are intentional migrations. The peer 2039 could experience NAT rebinding: a change of address due to a 2040 middlebox, usually a NAT, allocating a new outgoing port or even a 2041 new outgoing IP address for a flow. An endpoint MUST perform path 2042 validation (Section 8.2) if it detects any change to a peer's 2043 address, unless it has previously validated that address. 2045 When an endpoint has no validated path on which to send packets, it 2046 MAY discard connection state. An endpoint capable of connection 2047 migration MAY wait for a new path to become available before 2048 discarding connection state. 2050 This document limits migration of connections to new client 2051 addresses, except as described in Section 9.6. Clients are 2052 responsible for initiating all migrations. Servers do not send non- 2053 probing packets (see Section 9.1) toward a client address until they 2054 see a non-probing packet from that address. If a client receives 2055 packets from an unknown server address, the client MUST discard these 2056 packets. 2058 9.1. Probing a New Path 2060 An endpoint MAY probe for peer reachability from a new local address 2061 using path validation Section 8.2 prior to migrating the connection 2062 to the new local address. Failure of path validation simply means 2063 that the new path is not usable for this connection. Failure to 2064 validate a path does not cause the connection to end unless there are 2065 no valid alternative paths available. 2067 An endpoint uses a new connection ID for probes sent from a new local 2068 address, see Section 9.5 for further discussion. An endpoint that 2069 uses a new local address needs to ensure that at least one new 2070 connection ID is available at the peer. That can be achieved by 2071 including a NEW_CONNECTION_ID frame in the probe. 2073 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2074 is probing for reachability on a path. An endpoint sends a 2075 PATH_RESPONSE in response as per Section 8.2. 2077 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2078 are "probing frames", and all other frames are "non-probing frames". 2079 A packet containing only probing frames is a "probing packet", and a 2080 packet containing any other frame is a "non-probing packet". 2082 9.2. Initiating Connection Migration 2084 An endpoint can migrate a connection to a new local address by 2085 sending packets containing non-probing frames from that address. 2087 Each endpoint validates its peer's address during connection 2088 establishment. Therefore, a migrating endpoint can send to its peer 2089 knowing that the peer is willing to receive at the peer's current 2090 address. Thus an endpoint can migrate to a new local address without 2091 first validating the peer's address. 2093 When migrating, the new path might not support the endpoint's current 2094 sending rate. Therefore, the endpoint resets its congestion 2095 controller, as described in Section 9.4. 2097 The new path might not have the same ECN capability. Therefore, the 2098 endpoint verifies ECN capability as described in Section 13.3. 2100 Receiving acknowledgments for data sent on the new path serves as 2101 proof of the peer's reachability from the new address. Note that 2102 since acknowledgments may be received on any path, return 2103 reachability on the new path is not established. To establish return 2104 reachability on the new path, an endpoint MAY concurrently initiate 2105 path validation Section 8.2 on the new path. 2107 9.3. Responding to Connection Migration 2109 Receiving a packet from a new peer address containing a non-probing 2110 frame indicates that the peer has migrated to that address. 2112 In response to such a packet, an endpoint MUST start sending 2113 subsequent packets to the new peer address and MUST initiate path 2114 validation (Section 8.2) to verify the peer's ownership of the 2115 unvalidated address. 2117 An endpoint MAY send data to an unvalidated peer address, but it MUST 2118 protect against potential attacks as described in Section 9.3.1 and 2119 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2120 that address has been seen recently. 2122 An endpoint only changes the address that it sends packets to in 2123 response to the highest-numbered non-probing packet. This ensures 2124 that an endpoint does not send packets to an old peer address in the 2125 case that it receives reordered packets. 2127 After changing the address to which it sends non-probing packets, an 2128 endpoint could abandon any path validation for other addresses. 2130 Receiving a packet from a new peer address might be the result of a 2131 NAT rebinding at the peer. 2133 After verifying a new client address, the server SHOULD send new 2134 address validation tokens (Section 8) to the client. 2136 9.3.1. Peer Address Spoofing 2138 It is possible that a peer is spoofing its source address to cause an 2139 endpoint to send excessive amounts of data to an unwilling host. If 2140 the endpoint sends significantly more data than the spoofing peer, 2141 connection migration might be used to amplify the volume of data that 2142 an attacker can generate toward a victim. 2144 As described in Section 9.3, an endpoint is required to validate a 2145 peer's new address to confirm the peer's possession of the new 2146 address. Until a peer's address is deemed valid, an endpoint MUST 2147 limit the rate at which it sends data to this address. The endpoint 2148 MUST NOT send more than a minimum congestion window's worth of data 2149 per estimated round-trip time (kMinimumWindow, as defined in 2150 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2151 being used for a denial of service attack against an unsuspecting 2152 victim. Note that since the endpoint will not have any round-trip 2153 time measurements to this address, the estimate SHOULD be the default 2154 initial value (see [QUIC-RECOVERY]). 2156 If an endpoint skips validation of a peer address as described in 2157 Section 9.3, it does not need to limit its sending rate. 2159 9.3.2. On-Path Address Spoofing 2161 An on-path attacker could cause a spurious connection migration by 2162 copying and forwarding a packet with a spoofed address such that it 2163 arrives before the original packet. The packet with the spoofed 2164 address will be seen to come from a migrating connection, and the 2165 original packet will be seen as a duplicate and dropped. After a 2166 spurious migration, validation of the source address will fail 2167 because the entity at the source address does not have the necessary 2168 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2169 that is sent to it even if it wanted to. 2171 To protect the connection from failing due to such a spurious 2172 migration, an endpoint MUST revert to using the last validated peer 2173 address when validation of a new peer address fails. 2175 If an endpoint has no state about the last validated peer address, it 2176 MUST close the connection silently by discarding all connection 2177 state. This results in new packets on the connection being handled 2178 generically. For instance, an endpoint MAY send a stateless reset in 2179 response to any further incoming packets. 2181 Note that receipt of packets with higher packet numbers from the 2182 legitimate peer address will trigger another connection migration. 2184 This will cause the validation of the address of the spurious 2185 migration to be abandoned. 2187 9.3.3. Off-Path Packet Forwarding 2189 An off-path attacker that can observe packets might forward copies of 2190 genuine packets to endpoints. If the copied packet arrives before 2191 the genuine packet, this will appear as a NAT rebinding. Any genuine 2192 packet will be discarded as a duplicate. If the attacker is able to 2193 continue forwarding packets, it might be able to cause migration to a 2194 path via the attacker. This places the attacker on path, giving it 2195 the ability to observe or drop all subsequent packets. 2197 Unlike the attack described in Section 9.3.2, the attacker can ensure 2198 that the new path is successfully validated. 2200 This style of attack relies on the attacker using a path that is 2201 approximately as fast as the direct path between endpoints. The 2202 attack is more reliable if relatively few packets are sent or if 2203 packet loss coincides with the attempted attack. 2205 A non-probing packet received on the original path that increases the 2206 maximum received packet number will cause the endpoint to move back 2207 to that path. Eliciting packets on this path increases the 2208 likelihood that the attack is unsuccessful. Therefore, mitigation of 2209 this attack relies on triggering the exchange of packets. 2211 In response to an apparent migration, endpoints MUST validate the 2212 previously active path using a PATH_CHALLENGE frame. This induces 2213 the sending of new packets on that path. If the path is no longer 2214 viable, the validation attempt will time out and fail; if the path is 2215 viable, but no longer desired, the validation will succeed, but only 2216 results in probing packets being sent on the path. 2218 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2219 send a non-probing packet in response. If the non-probing packet 2220 arrives before any copy made by an attacker, this results in the 2221 connection being migrated back to the original path. Any subsequent 2222 migration to another path restarts this entire process. 2224 This defense is imperfect, but this is not considered a serious 2225 problem. If the path via the attack is reliably faster than the 2226 original path despite multiple attempts to use that original path, it 2227 is not possible to distinguish between attack and an improvement in 2228 routing. 2230 An endpoint could also use heuristics to improve detection of this 2231 style of attack. For instance, NAT rebinding is improbable if 2232 packets were recently received on the old path, similarly rebinding 2233 is rare on IPv6 paths. Endpoints can also look for duplicated 2234 packets. Conversely, a change in connection ID is more likely to 2235 indicate an intentional migration rather than an attack. 2237 9.4. Loss Detection and Congestion Control 2239 The capacity available on the new path might not be the same as the 2240 old path. Packets sent on the old path SHOULD NOT contribute to 2241 congestion control or RTT estimation for the new path. 2243 On confirming a peer's ownership of its new address, an endpoint 2244 SHOULD immediately reset the congestion controller and round-trip 2245 time estimator for the new path. 2247 An endpoint MUST NOT return to the send rate used for the previous 2248 path unless it is reasonably sure that the previous send rate is 2249 valid for the new path. For instance, a change in the client's port 2250 number is likely indicative of a rebinding in a middlebox and not a 2251 complete change in path. This determination likely depends on 2252 heuristics, which could be imperfect; if the new path capacity is 2253 significantly reduced, ultimately this relies on the congestion 2254 controller responding to congestion signals and reducing send rates 2255 appropriately. 2257 There may be apparent reordering at the receiver when an endpoint 2258 sends data and probes from/to multiple addresses during the migration 2259 period, since the two resulting paths may have different round-trip 2260 times. A receiver of packets on multiple paths will still send ACK 2261 frames covering all received packets. 2263 While multiple paths might be used during connection migration, a 2264 single congestion control context and a single loss recovery context 2265 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2266 endpoint might delay switching to a new congestion control context 2267 until it is confirmed that an old path is no longer needed (such as 2268 the case in Section 9.3.3). 2270 A sender can make exceptions for probe packets so that their loss 2271 detection is independent and does not unduly cause the congestion 2272 controller to reduce its sending rate. An endpoint might set a 2273 separate timer when a PATH_CHALLENGE is sent, which is cancelled when 2274 the corresponding PATH_RESPONSE is received. If the timer fires 2275 before the PATH_RESPONSE is received, the endpoint might send a new 2276 PATH_CHALLENGE, and restart the timer for a longer period of time. 2278 9.5. Privacy Implications of Connection Migration 2280 Using a stable connection ID on multiple network paths allows a 2281 passive observer to correlate activity between those paths. An 2282 endpoint that moves between networks might not wish to have their 2283 activity correlated by any entity other than their peer, so different 2284 connection IDs are used when sending from different local addresses, 2285 as discussed in Section 5.1. For this to be effective endpoints need 2286 to ensure that connections IDs they provide cannot be linked by any 2287 other entity. 2289 At any time, endpoints MAY change the Destination Connection ID they 2290 send to a value that has not been used on another path. 2292 An endpoint MUST use a new connection ID if it initiates connection 2293 migration. Using a new connection ID eliminates the use of the 2294 connection ID for linking activity from the same connection on 2295 different networks. Header protection ensures that packet numbers 2296 cannot be used to correlate activity. This does not prevent other 2297 properties of packets, such as timing and size, from being used to 2298 correlate activity. 2300 Unintentional changes in path without a change in connection ID are 2301 possible. For example, after a period of network inactivity, NAT 2302 rebinding might cause packets to be sent on a new path when the 2303 client resumes sending. 2305 A client might wish to reduce linkability by employing a new 2306 connection ID and source UDP port when sending traffic after a period 2307 of inactivity. Changing the UDP port from which it sends packets at 2308 the same time might cause the packet to appear as a connection 2309 migration. This ensures that the mechanisms that support migration 2310 are exercised even for clients that don't experience NAT rebindings 2311 or genuine migrations. Changing port number can cause a peer to 2312 reset its congestion state (see Section 9.4), so the port SHOULD only 2313 be changed infrequently. 2315 An endpoint that exhausts available connection IDs cannot migrate. 2316 To ensure that migration is possible and packets sent on different 2317 paths cannot be correlated, endpoints SHOULD provide new connection 2318 IDs before peers migrate. 2320 9.6. Server's Preferred Address 2322 QUIC allows servers to accept connections on one IP address and 2323 attempt to transfer these connections to a more preferred address 2324 shortly after the handshake. This is particularly useful when 2325 clients initially connect to an address shared by multiple servers 2326 but would prefer to use a unicast address to ensure connection 2327 stability. This section describes the protocol for migrating a 2328 connection to a preferred server address. 2330 Migrating a connection to a new server address mid-connection is left 2331 for future work. If a client receives packets from a new server 2332 address not indicated by the preferred_address transport parameter, 2333 the client SHOULD discard these packets. 2335 9.6.1. Communicating a Preferred Address 2337 A server conveys a preferred address by including the 2338 preferred_address transport parameter in the TLS handshake. 2340 Servers MAY communicate a preferred address of each address family 2341 (IPv4 and IPv6) to allow clients to pick the one most suited to their 2342 network attachment. 2344 Once the handshake is finished, the client SHOULD select one of the 2345 two server's preferred addresses and initiate path validation (see 2346 Section 8.2) of that address using the connection ID provided in the 2347 preferred_address transport parameter. 2349 If path validation succeeds, the client SHOULD immediately begin 2350 sending all future packets to the new server address using the new 2351 connection ID and discontinue use of the old server address. If path 2352 validation fails, the client MUST continue sending all future packets 2353 to the server's original IP address. 2355 9.6.2. Responding to Connection Migration 2357 A server might receive a packet addressed to its preferred IP address 2358 at any time after it accepts a connection. If this packet contains a 2359 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2360 Section 8.2. The server MUST send other non-probing frames from its 2361 original address until it receives a non-probing packet from the 2362 client at its preferred address and until the server has validated 2363 the new path. 2365 The server MUST probe on the path toward the client from its 2366 preferred address. This helps to guard against spurious migration 2367 initiated by an attacker. 2369 Once the server has completed its path validation and has received a 2370 non-probing packet with a new largest packet number on its preferred 2371 address, the server begins sending non-probing packets to the client 2372 exclusively from its preferred IP address. It SHOULD drop packets 2373 for this connection received on the old IP address, but MAY continue 2374 to process delayed packets. 2376 9.6.3. Interaction of Client Migration and Preferred Address 2378 A client might need to perform a connection migration before it has 2379 migrated to the server's preferred address. In this case, the client 2380 SHOULD perform path validation to both the original and preferred 2381 server address from the client's new address concurrently. 2383 If path validation of the server's preferred address succeeds, the 2384 client MUST abandon validation of the original address and migrate to 2385 using the server's preferred address. If path validation of the 2386 server's preferred address fails but validation of the server's 2387 original address succeeds, the client MAY migrate to its new address 2388 and continue sending to the server's original address. 2390 If the connection to the server's preferred address is not from the 2391 same client address, the server MUST protect against potential 2392 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2393 to intentional simultaneous migration, this might also occur because 2394 the client's access network used a different NAT binding for the 2395 server's preferred address. 2397 Servers SHOULD initiate path validation to the client's new address 2398 upon receiving a probe packet from a different address. Servers MUST 2399 NOT send more than a minimum congestion window's worth of non-probing 2400 packets to the new address before path validation is complete. 2402 A client that migrates to a new address SHOULD use a preferred 2403 address from the same address family for the server. 2405 9.7. Use of IPv6 Flow-Label and Migration 2407 Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label 2408 in compliance with [RFC6437], unless the local API does not allow 2409 setting IPv6 flow labels. 2411 The IPv6 flow label SHOULD be a pseudo-random function of the source 2412 and destination addresses, source and destination UDP ports, and the 2413 destination CID. The flow label generation MUST be designed to 2414 minimize the chances of linkability with a previously used flow 2415 label, as this would enable correlating activity on multiple paths 2416 (see Section 9.5). 2418 A possible implementation is to compute the flow label as a 2419 cryptographic hash function of the source and destination addresses, 2420 source and destination UDP ports, destination CID, and a local 2421 secret. 2423 10. Connection Termination 2425 An established QUIC connection can be terminated in one of three 2426 ways: 2428 o idle timeout (Section 10.2) 2430 o immediate close (Section 10.3) 2432 o stateless reset (Section 10.4) 2434 An endpoint MAY discard connection state if it does not have a 2435 validated path on which it can send packets (see Section 8.2). 2437 10.1. Closing and Draining Connection States 2439 The closing and draining connection states exist to ensure that 2440 connections close cleanly and that delayed or reordered packets are 2441 properly discarded. These states SHOULD persist for at least three 2442 times the current Probe Timeout (PTO) interval as defined in 2443 [QUIC-RECOVERY]. 2445 An endpoint enters a closing period after initiating an immediate 2446 close (Section 10.3). While closing, an endpoint MUST NOT send 2447 packets unless they contain a CONNECTION_CLOSE frame (see 2448 Section 10.3 for details). An endpoint retains only enough 2449 information to generate a packet containing a CONNECTION_CLOSE frame 2450 and to identify packets as belonging to the connection. The 2451 endpoint's selected connection ID and the QUIC version are sufficient 2452 information to identify packets for a closing connection; an endpoint 2453 can discard all other connection state. An endpoint MAY retain 2454 packet protection keys for incoming packets to allow it to read and 2455 process a CONNECTION_CLOSE frame. 2457 The draining state is entered once an endpoint receives a signal that 2458 its peer is closing or draining. While otherwise identical to the 2459 closing state, an endpoint in the draining state MUST NOT send any 2460 packets. Retaining packet protection keys is unnecessary once a 2461 connection is in the draining state. 2463 An endpoint MAY transition from the closing period to the draining 2464 period if it receives a CONNECTION_CLOSE frame or stateless reset, 2465 both of which indicate that the peer is also closing or draining. 2466 The draining period SHOULD end when the closing period would have 2467 ended. In other words, the endpoint can use the same end time, but 2468 cease retransmission of the closing packet. 2470 Disposing of connection state prior to the end of the closing or 2471 draining period could cause delayed or reordered packets to generate 2472 an unnecessary stateless reset. Endpoints that have some alternative 2473 means to ensure that late-arriving packets on the connection do not 2474 induce a response, such as those that are able to close the UDP 2475 socket, MAY use an abbreviated draining period which can allow for 2476 faster resource recovery. Servers that retain an open socket for 2477 accepting new connections SHOULD NOT exit the closing or draining 2478 period early. 2480 Once the closing or draining period has ended, an endpoint SHOULD 2481 discard all connection state. This results in new packets on the 2482 connection being handled generically. For instance, an endpoint MAY 2483 send a stateless reset in response to any further incoming packets. 2485 The draining and closing periods do not apply when a stateless reset 2486 (Section 10.4) is sent. 2488 An endpoint is not expected to handle key updates when it is closing 2489 or draining. A key update might prevent the endpoint from moving 2490 from the closing state to draining, but it otherwise has no impact. 2492 While in the closing period, an endpoint could receive packets from a 2493 new source address, indicating a connection migration (Section 9). 2494 An endpoint in the closing state MUST strictly limit the number of 2495 packets it sends to this new address until the address is validated 2496 (see Section 8.2). A server in the closing state MAY instead choose 2497 to discard packets received from a new source address. 2499 10.2. Idle Timeout 2501 If the idle timeout is enabled, a connection is silently closed and 2502 the state is discarded when it remains idle for longer than both the 2503 advertised idle timeout (see Section 18.1) and three times the 2504 current Probe Timeout (PTO). 2506 Each endpoint advertises its own idle timeout to its peer. An 2507 endpoint restarts any timer it maintains when a packet from its peer 2508 is received and processed successfully. The timer is also restarted 2509 when sending a packet containing frames other than ACK or PADDING (an 2510 ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK- 2511 eliciting packets have been sent since last receiving a packet. 2512 Restarting when sending packets ensures that connections do not 2513 prematurely time out when initiating new activity. 2515 The value for an idle timeout can be asymmetric. The value 2516 advertised by an endpoint is only used to determine whether the 2517 connection is live at that endpoint. An endpoint that sends packets 2518 near the end of the idle timeout period of a peer risks having those 2519 packets discarded if its peer enters the draining state before the 2520 packets arrive. If a peer could timeout within a Probe Timeout (PTO; 2521 see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for 2522 liveness before sending any data that cannot be retried safely. Note 2523 that it is likely that only applications or application protocols 2524 will know what information can be retried. 2526 10.3. Immediate Close 2528 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 2529 terminate the connection immediately. A CONNECTION_CLOSE frame 2530 causes all streams to immediately become closed; open streams can be 2531 assumed to be implicitly reset. 2533 After sending a CONNECTION_CLOSE frame, endpoints immediately enter 2534 the closing state. During the closing period, an endpoint that sends 2535 a CONNECTION_CLOSE frame SHOULD respond to any packet that it 2536 receives with another packet containing a CONNECTION_CLOSE frame. To 2537 minimize the state that an endpoint maintains for a closing 2538 connection, endpoints MAY send the exact same packet. However, 2539 endpoints SHOULD limit the number of packets they generate containing 2540 a CONNECTION_CLOSE frame. For instance, an endpoint could 2541 progressively increase the number of packets that it receives before 2542 sending additional packets or increase the time between packets. 2544 Note: Allowing retransmission of a closing packet contradicts other 2545 advice in this document that recommends the creation of new packet 2546 numbers for every packet. Sending new packet numbers is primarily 2547 of advantage to loss recovery and congestion control, which are 2548 not expected to be relevant for a closed connection. 2549 Retransmitting the final packet requires less state. 2551 New packets from unverified addresses could be used to create an 2552 amplification attack (see Section 8). To avoid this, endpoints MUST 2553 either limit transmission of CONNECTION_CLOSE frames to validated 2554 addresses or drop packets without response if the response would be 2555 more than three times larger than the received packet. 2557 After receiving a CONNECTION_CLOSE frame, endpoints enter the 2558 draining state. An endpoint that receives a CONNECTION_CLOSE frame 2559 MAY send a single packet containing a CONNECTION_CLOSE frame before 2560 entering the draining state, using a CONNECTION_CLOSE frame and a 2561 NO_ERROR code if appropriate. An endpoint MUST NOT send further 2562 packets, which could result in a constant exchange of 2563 CONNECTION_CLOSE frames until the closing period on either peer 2564 ended. 2566 An immediate close can be used after an application protocol has 2567 arranged to close a connection. This might be after the application 2568 protocols negotiates a graceful shutdown. The application protocol 2569 exchanges whatever messages that are needed to cause both endpoints 2570 to agree to close the connection, after which the application 2571 requests that the connection be closed. The application protocol can 2572 use a CONNECTION_CLOSE frame with an appropriate error code to signal 2573 closure. 2575 When sending CONNECTION_CLOSE, the goal is to ensure that the peer 2576 will process the frame. Generally, this means sending the frame in a 2577 packet with the highest level of packet protection to avoid the 2578 packet being discarded. However, during the handshake, it is 2579 possible that more advanced packet protection keys are not available 2580 to the peer, so the frame MAY be replicated in a packet that uses a 2581 lower packet protection level. 2583 After the handshake is confirmed, an endpoint MUST send any 2584 CONNECTION_CLOSE frames in a 1-RTT packet. Prior to handshake 2585 confirmation, the peer might not have 1-RTT keys, so the endpoint 2586 SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the 2587 endpoint does not have Handshake keys, it SHOULD send 2588 CONNECTION_CLOSE frames in an Initial packet. 2590 A client will always know whether the server has Handshake keys (see 2591 Section 17.2.2.1), but it is possible that a server does not know 2592 whether the client has Handshake keys. Under these circumstances, a 2593 server SHOULD send a CONNECTION_CLOSE frame in both Handshake and 2594 Initial packets to ensure that at least one of them is processable by 2595 the client. These packets can be coalesced into a single UDP 2596 datagram (see Section 12.2). 2598 10.4. Stateless Reset 2600 A stateless reset is provided as an option of last resort for an 2601 endpoint that does not have access to the state of a connection. A 2602 crash or outage might result in peers continuing to send data to an 2603 endpoint that is unable to properly continue the connection. An 2604 endpoint MAY send a stateless reset in response to receiving a packet 2605 that it cannot associate with an active connection. 2607 A stateless reset is not appropriate for signaling error conditions. 2608 An endpoint that wishes to communicate a fatal connection error MUST 2609 use a CONNECTION_CLOSE frame if it has sufficient state to do so. 2611 To support this process, a token is sent by endpoints. The token is 2612 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2613 servers can specify the stateless_reset_token transport parameter 2614 during the handshake (clients cannot because their transport 2615 parameters don't have confidentiality protection). This value is 2616 protected by encryption, so only client and server know this value. 2617 Tokens are invalidated when their associated connection ID is retired 2618 via a RETIRE_CONNECTION_ID frame (Section 19.16). 2620 An endpoint that receives packets that it cannot process sends a 2621 packet in the following layout: 2623 0 1 2 3 2624 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 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 |0|1| Unpredictable Bits (198..) ... 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | | 2629 + + 2630 | | 2631 + Stateless Reset Token (128) + 2632 | | 2633 + + 2634 | | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 Figure 6: Stateless Reset Packet 2639 This design ensures that a stateless reset packet is - to the extent 2640 possible - indistinguishable from a regular packet with a short 2641 header. 2643 A stateless reset uses an entire UDP datagram, starting with the 2644 first two bits of the packet header. The remainder of the first byte 2645 and an arbitrary number of bytes following it that are set to 2646 unpredictable values. The last 16 bytes of the datagram contain a 2647 Stateless Reset Token. 2649 To entities other than its intended recipient, a stateless reset will 2650 appear to be a packet with a short header. For the packet to appear 2651 as valid, the Unpredictable Bits field needs to include at least 198 2652 bits of data (or 25 bytes, less the two fixed bits). This is 2653 intended to allow for a Destination Connection ID of the maximum 2654 length permitted, with a minimal packet number, and payload. The 2655 Stateless Reset Token corresponds to the minimum expansion of the 2656 packet protection AEAD. More unpredictable bytes might be necessary 2657 if the endpoint could have negotiated a packet protection scheme with 2658 a larger minimum AEAD expansion. 2660 An endpoint SHOULD NOT send a stateless reset that is significantly 2661 larger than the packet it receives. Endpoints MUST discard packets 2662 that are too small to be valid QUIC packets. With the set of AEAD 2663 functions defined in [QUIC-TLS], packets that are smaller than 21 2664 bytes are never valid. 2666 Endpoints MUST send stateless reset packets formatted as a packet 2667 with a short header. However, endpoints MUST treat any packet ending 2668 in a valid stateless reset token as a stateless reset, as other QUIC 2669 versions might allow the use of a long header. 2671 An endpoint MAY send a stateless reset in response to a packet with a 2672 long header. Sending a stateless reset is not effective prior to the 2673 stateless reset token being available to a peer. In this QUIC 2674 version, packets with a long header are only used during connection 2675 establishment. Because the stateless reset token is not available 2676 until connection establishment is complete or near completion, 2677 ignoring an unknown packet with a long header might be as effective 2678 as sending a stateless reset. 2680 An endpoint cannot determine the Source Connection ID from a packet 2681 with a short header, therefore it cannot set the Destination 2682 Connection ID in the stateless reset packet. The Destination 2683 Connection ID will therefore differ from the value used in previous 2684 packets. A random Destination Connection ID makes the connection ID 2685 appear to be the result of moving to a new connection ID that was 2686 provided using a NEW_CONNECTION_ID frame (Section 19.15). 2688 Using a randomized connection ID results in two problems: 2690 o The packet might not reach the peer. If the Destination 2691 Connection ID is critical for routing toward the peer, then this 2692 packet could be incorrectly routed. This might also trigger 2693 another Stateless Reset in response; see Section 10.4.3. A 2694 Stateless Reset that is not correctly routed is an ineffective 2695 error detection and recovery mechanism. In this case, endpoints 2696 will need to rely on other methods - such as timers - to detect 2697 that the connection has failed. 2699 o The randomly generated connection ID can be used by entities other 2700 than the peer to identify this as a potential stateless reset. An 2701 endpoint that occasionally uses different connection IDs might 2702 introduce some uncertainty about this. 2704 Finally, the last 16 bytes of the packet are set to the value of the 2705 Stateless Reset Token. 2707 This stateless reset design is specific to QUIC version 1. An 2708 endpoint that supports multiple versions of QUIC needs to generate a 2709 stateless reset that will be accepted by peers that support any 2710 version that the endpoint might support (or might have supported 2711 prior to losing state). Designers of new versions of QUIC need to be 2712 aware of this and either reuse this design, or use a portion of the 2713 packet other than the last 16 bytes for carrying data. 2715 10.4.1. Detecting a Stateless Reset 2717 An endpoint detects a potential stateless reset when an incoming 2718 packet either cannot be associated with a connection, cannot be 2719 decrypted, or is marked as a duplicate packet. The endpoint MUST 2720 then compare the last 16 bytes of the packet with all Stateless Reset 2721 Tokens that are associated with connection IDs that the endpoint 2722 recently used to send packets from the IP address and port on which 2723 the datagram is received. This includes Stateless Reset Tokens from 2724 NEW_CONNECTION_ID frames and the server's transport parameters. An 2725 endpoint MUST NOT check for any Stateless Reset Tokens associated 2726 with connection IDs it has not used or for connection IDs that have 2727 been retired. 2729 If the last 16 bytes of the packet values are identical to a 2730 Stateless Reset Token, the endpoint MUST enter the draining period 2731 and not send any further packets on this connection. If the 2732 comparison fails, the packet can be discarded. 2734 10.4.2. Calculating a Stateless Reset Token 2736 The stateless reset token MUST be difficult to guess. In order to 2737 create a Stateless Reset Token, an endpoint could randomly generate 2738 [RFC4086] a secret for every connection that it creates. However, 2739 this presents a coordination problem when there are multiple 2740 instances in a cluster or a storage problem for an endpoint that 2741 might lose state. Stateless reset specifically exists to handle the 2742 case where state is lost, so this approach is suboptimal. 2744 A single static key can be used across all connections to the same 2745 endpoint by generating the proof using a second iteration of a 2746 preimage-resistant function that takes a static key and the 2747 connection ID chosen by the endpoint (see Section 5.1) as input. An 2748 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2749 connection_id)) or HKDF [RFC5869] (for example, using the static key 2750 as input keying material, with the connection ID as salt). The 2751 output of this function is truncated to 16 bytes to produce the 2752 Stateless Reset Token for that connection. 2754 An endpoint that loses state can use the same method to generate a 2755 valid Stateless Reset Token. The connection ID comes from the packet 2756 that the endpoint receives. 2758 This design relies on the peer always sending a connection ID in its 2759 packets so that the endpoint can use the connection ID from a packet 2760 to reset the connection. An endpoint that uses this design MUST 2761 either use the same connection ID length for all connections or 2762 encode the length of the connection ID such that it can be recovered 2763 without state. In addition, it cannot provide a zero-length 2764 connection ID. 2766 Revealing the Stateless Reset Token allows any entity to terminate 2767 the connection, so a value can only be used once. This method for 2768 choosing the Stateless Reset Token means that the combination of 2769 connection ID and static key MUST NOT be used for another connection. 2770 A denial of service attack is possible if the same connection ID is 2771 used by instances that share a static key, or if an attacker can 2772 cause a packet to be routed to an instance that has no state but the 2773 same static key; see Section 21.8. A connection ID from a connection 2774 that is reset by revealing the Stateless Reset Token MUST NOT be 2775 reused for new connections at nodes that share a static key. 2777 The same Stateless Reset Token MAY be used for multiple connection 2778 IDs on the same connection. However, reuse of a Stateless Reset 2779 Token might expose an endpoint to denial of service if associated 2780 connection IDs are forgotten while the associated token is still 2781 active at a peer. An endpoint MUST ensure that packets with 2782 Destination Connection ID field values that correspond to a reused 2783 Stateless Reset Token are attributed to the same connection as long 2784 as the Stateless Reset Token is still usable, even when the 2785 connection ID has been retired. Otherwise, an attacker might be able 2786 to send a packet with a retired connection ID and cause the endpoint 2787 to produce a Stateless Reset that it can use to disrupt the 2788 connection, just as with the attacks in Section 21.8. 2790 Note that Stateless Reset packets do not have any cryptographic 2791 protection. 2793 10.4.3. Looping 2795 The design of a Stateless Reset is such that without knowing the 2796 stateless reset token it is indistinguishable from a valid packet. 2797 For instance, if a server sends a Stateless Reset to another server 2798 it might receive another Stateless Reset in response, which could 2799 lead to an infinite exchange. 2801 An endpoint MUST ensure that every Stateless Reset that it sends is 2802 smaller than the packet which triggered it, unless it maintains state 2803 sufficient to prevent looping. In the event of a loop, this results 2804 in packets eventually being too small to trigger a response. 2806 An endpoint can remember the number of Stateless Reset packets that 2807 it has sent and stop generating new Stateless Reset packets once a 2808 limit is reached. Using separate limits for different remote 2809 addresses will ensure that Stateless Reset packets can be used to 2810 close connections when other peers or connections have exhausted 2811 limits. 2813 Reducing the size of a Stateless Reset below the recommended minimum 2814 size of 41 bytes could mean that the packet could reveal to an 2815 observer that it is a Stateless Reset. Conversely, refusing to send 2816 a Stateless Reset in response to a small packet might result in 2817 Stateless Reset not being useful in detecting cases of broken 2818 connections where only very small packets are sent; such failures 2819 might only be detected by other means, such as timers. 2821 An endpoint can increase the odds that a packet will trigger a 2822 Stateless Reset if it cannot be processed by padding it to at least 2823 42 bytes. 2825 11. Error Handling 2827 An endpoint that detects an error SHOULD signal the existence of that 2828 error to its peer. Both transport-level and application-level errors 2829 can affect an entire connection (see Section 11.1), while only 2830 application-level errors can be isolated to a single stream (see 2831 Section 11.2). 2833 The most appropriate error code (Section 20) SHOULD be included in 2834 the frame that signals the error. Where this specification 2835 identifies error conditions, it also identifies the error code that 2836 is used. 2838 A stateless reset (Section 10.4) is not suitable for any error that 2839 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 2840 stateless reset MUST NOT be used by an endpoint that has the state 2841 necessary to send a frame on the connection. 2843 11.1. Connection Errors 2845 Errors that result in the connection being unusable, such as an 2846 obvious violation of protocol semantics or corruption of state that 2847 affects an entire connection, MUST be signaled using a 2848 CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the 2849 connection in this manner even if the error only affects a single 2850 stream. 2852 Application protocols can signal application-specific protocol errors 2853 using the application-specific variant of the CONNECTION_CLOSE frame. 2854 Errors that are specific to the transport, including all those 2855 described in this document, are carried in the QUIC-specific variant 2856 of the CONNECTION_CLOSE frame. 2858 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 2859 endpoint SHOULD be prepared to retransmit a packet containing a 2860 CONNECTION_CLOSE frame if it receives more packets on a terminated 2861 connection. Limiting the number of retransmissions and the time over 2862 which this final packet is sent limits the effort expended on 2863 terminated connections. 2865 An endpoint that chooses not to retransmit packets containing a 2866 CONNECTION_CLOSE frame risks a peer missing the first such packet. 2867 The only mechanism available to an endpoint that continues to receive 2868 data for a terminated connection is to use the stateless reset 2869 process (Section 10.4). 2871 An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT 2872 signal the existence of the error to its peer. 2874 11.2. Stream Errors 2876 If an application-level error affects a single stream, but otherwise 2877 leaves the connection in a recoverable state, the endpoint can send a 2878 RESET_STREAM frame (Section 19.4) with an appropriate error code to 2879 terminate just the affected stream. 2881 RESET_STREAM MUST be instigated by the protocol using QUIC, either 2882 directly or through the receipt of a STOP_SENDING frame from a peer. 2883 RESET_STREAM carries an application error code. Resetting a stream 2884 without knowledge of the application protocol could cause the 2885 protocol to enter an unrecoverable state. Application protocols 2886 might require certain streams to be reliably delivered in order to 2887 guarantee consistent state between endpoints. 2889 12. Packets and Frames 2891 QUIC endpoints communicate by exchanging packets. Packets have 2892 confidentiality and integrity protection (see Section 12.1) and are 2893 carried in UDP datagrams (see Section 12.2). 2895 This version of QUIC uses the long packet header (see Section 17.2) 2896 during connection establishment. Packets with the long header are 2897 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake 2898 (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation 2899 uses a version-independent packet with a long header (see 2900 Section 17.2.1). 2902 Packets with the short header (Section 17.3) are designed for minimal 2903 overhead and are used after a connection is established and 1-RTT 2904 keys are available. 2906 12.1. Protected Packets 2908 All QUIC packets except Version Negotiation and Retry packets use 2909 authenticated encryption with additional data (AEAD) [RFC5116] to 2910 provide confidentiality and integrity protection. Details of packet 2911 protection are found in [QUIC-TLS]; this section includes an overview 2912 of the process. 2914 Initial packets are protected using keys that are statically derived. 2915 This packet protection is not effective confidentiality protection. 2916 Initial protection only exists to ensure that the sender of the 2917 packet is on the network path. Any entity that receives the Initial 2918 packet from a client can recover the keys necessary to remove packet 2919 protection or to generate packets that will be successfully 2920 authenticated. 2922 All other packets are protected with keys derived from the 2923 cryptographic handshake. The type of the packet from the long header 2924 or key phase from the short header are used to identify which 2925 encryption level - and therefore the keys - that are used. Packets 2926 protected with 0-RTT and 1-RTT keys are expected to have 2927 confidentiality and data origin authentication; the cryptographic 2928 handshake ensures that only the communicating endpoints receive the 2929 corresponding keys. 2931 The packet number field contains a packet number, which has 2932 additional confidentiality protection that is applied after packet 2933 protection is applied (see [QUIC-TLS] for details). The underlying 2934 packet number increases with each packet sent in a given packet 2935 number space; see Section 12.3 for details. 2937 12.2. Coalescing Packets 2939 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake 2940 (Section 17.2.4) packets contain a Length field, which determines the 2941 end of the packet. The length includes both the Packet Number and 2942 Payload fields, both of which are confidentiality protected and 2943 initially of unknown length. The length of the Payload field is 2944 learned once header protection is removed. 2946 Using the Length field, a sender can coalesce multiple QUIC packets 2947 into one UDP datagram. This can reduce the number of UDP datagrams 2948 needed to complete the cryptographic handshake and start sending 2949 data. This can also be used to construct PMTU probes (see 2950 Section 14.3.1). Receivers MUST be able to process coalesced 2951 packets. 2953 Coalescing packets in order of increasing encryption levels (Initial, 2954 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 2955 able to process all the packets in a single pass. A packet with a 2956 short header does not include a length, so it can only be the last 2957 packet included in a UDP datagram. An endpoint SHOULD NOT coalesce 2958 multiple packets at the same encryption level. 2960 Senders MUST NOT coalesce QUIC packets for different connections into 2961 a single UDP datagram. Receivers SHOULD ignore any subsequent 2962 packets with a different Destination Connection ID than the first 2963 packet in the datagram. 2965 Every QUIC packet that is coalesced into a single UDP datagram is 2966 separate and complete. Though the values of some fields in the 2967 packet header might be redundant, no fields are omitted. The 2968 receiver of coalesced QUIC packets MUST individually process each 2969 QUIC packet and separately acknowledge them, as if they were received 2970 as the payload of different UDP datagrams. For example, if 2971 decryption fails (because the keys are not available or any other 2972 reason), the receiver MAY either discard or buffer the packet for 2973 later processing and MUST attempt to process the remaining packets. 2975 Retry packets (Section 17.2.5), Version Negotiation packets 2976 (Section 17.2.1), and packets with a short header (Section 17.3) do 2977 not contain a Length field and so cannot be followed by other packets 2978 in the same UDP datagram. 2980 12.3. Packet Numbers 2982 The packet number is an integer in the range 0 to 2^62-1. This 2983 number is used in determining the cryptographic nonce for packet 2984 protection. Each endpoint maintains a separate packet number for 2985 sending and receiving. 2987 Packet numbers are limited to this range because they need to be 2988 representable in whole in the Largest Acknowledged field of an ACK 2989 frame (Section 19.3). When present in a long or short header 2990 however, packet numbers are reduced and encoded in 1 to 4 bytes (see 2991 Section 17.1). 2993 Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) 2994 packets do not include a packet number. 2996 Packet numbers are divided into 3 spaces in QUIC: 2998 o Initial space: All Initial packets (Section 17.2.2) are in this 2999 space. 3001 o Handshake space: All Handshake packets (Section 17.2.4) are in 3002 this space. 3004 o Application data space: All 0-RTT and 1-RTT encrypted packets 3005 (Section 12.1) are in this space. 3007 As described in [QUIC-TLS], each packet type uses different 3008 protection keys. 3010 Conceptually, a packet number space is the context in which a packet 3011 can be processed and acknowledged. Initial packets can only be sent 3012 with Initial packet protection keys and acknowledged in packets which 3013 are also Initial packets. Similarly, Handshake packets are sent at 3014 the Handshake encryption level and can only be acknowledged in 3015 Handshake packets. 3017 This enforces cryptographic separation between the data sent in the 3018 different packet sequence number spaces. Packet numbers in each 3019 space start at packet number 0. Subsequent packets sent in the same 3020 packet number space MUST increase the packet number by at least one. 3022 0-RTT and 1-RTT data exist in the same packet number space to make 3023 loss recovery algorithms easier to implement between the two packet 3024 types. 3026 A QUIC endpoint MUST NOT reuse a packet number within the same packet 3027 number space in one connection. If the packet number for sending 3028 reaches 2^62 - 1, the sender MUST close the connection without 3029 sending a CONNECTION_CLOSE frame or any further packets; an endpoint 3030 MAY send a Stateless Reset (Section 10.4) in response to further 3031 packets that it receives. 3033 A receiver MUST discard a newly unprotected packet unless it is 3034 certain that it has not processed another packet with the same packet 3035 number from the same packet number space. Duplicate suppression MUST 3036 happen after removing packet protection for the reasons described in 3037 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 3038 suppression can be found in Section 3.4.3 of [RFC4303]. 3040 Packet number encoding at a sender and decoding at a receiver are 3041 described in Section 17.1. 3043 12.4. Frames and Frame Types 3045 The payload of QUIC packets, after removing packet protection, 3046 consists of a sequence of complete frames, as shown in Figure 7. 3047 Version Negotiation, Stateless Reset, and Retry packets do not 3048 contain frames. 3050 0 1 2 3 3051 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 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | Frame 1 (*) ... 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 | Frame 2 (*) ... 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 ... 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 | Frame N (*) ... 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 Figure 7: QUIC Payload 3064 The payload of a packet that contains frames MUST contain at least 3065 one frame, and MAY contain multiple frames and multiple frame types. 3066 Frames always fit within a single QUIC packet and cannot span 3067 multiple packets. 3069 Each frame begins with a Frame Type, indicating its type, followed by 3070 additional type-dependent fields: 3072 0 1 2 3 3073 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 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 | Frame Type (i) ... 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 | Type-Dependent Fields (*) ... 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 Figure 8: Generic Frame Layout 3082 The frame types defined in this specification are listed in Table 3. 3083 The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and 3084 CONNECTION_CLOSE frames is used to carry other frame-specific flags. 3085 For all other frames, the Frame Type field simply identifies the 3086 frame. These frames are explained in more detail in Section 19. 3088 +-------------+----------------------+---------------+ 3089 | Type Value | Frame Type Name | Definition | 3090 +-------------+----------------------+---------------+ 3091 | 0x00 | PADDING | Section 19.1 | 3092 | | | | 3093 | 0x01 | PING | Section 19.2 | 3094 | | | | 3095 | 0x02 - 0x03 | ACK | Section 19.3 | 3096 | | | | 3097 | 0x04 | RESET_STREAM | Section 19.4 | 3098 | | | | 3099 | 0x05 | STOP_SENDING | Section 19.5 | 3100 | | | | 3101 | 0x06 | CRYPTO | Section 19.6 | 3102 | | | | 3103 | 0x07 | NEW_TOKEN | Section 19.7 | 3104 | | | | 3105 | 0x08 - 0x0f | STREAM | Section 19.8 | 3106 | | | | 3107 | 0x10 | MAX_DATA | Section 19.9 | 3108 | | | | 3109 | 0x11 | MAX_STREAM_DATA | Section 19.10 | 3110 | | | | 3111 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | 3112 | | | | 3113 | 0x14 | DATA_BLOCKED | Section 19.12 | 3114 | | | | 3115 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | 3116 | | | | 3117 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | 3118 | | | | 3119 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | 3120 | | | | 3121 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | 3122 | | | | 3123 | 0x1a | PATH_CHALLENGE | Section 19.17 | 3124 | | | | 3125 | 0x1b | PATH_RESPONSE | Section 19.18 | 3126 | | | | 3127 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | 3128 +-------------+----------------------+---------------+ 3130 Table 3: Frame Types 3132 An endpoint MUST treat the receipt of a frame of unknown type as a 3133 connection error of type FRAME_ENCODING_ERROR. 3135 All QUIC frames are idempotent in this version of QUIC. That is, a 3136 valid frame does not cause undesirable side effects or errors when 3137 received more than once. 3139 The Frame Type field uses a variable length integer encoding (see 3140 Section 16) with one exception. To ensure simple and efficient 3141 implementations of frame parsing, a frame type MUST use the shortest 3142 possible encoding. Though a two-, four- or eight-byte encoding of 3143 the frame types defined in this document is possible, the Frame Type 3144 field for these frames is encoded on a single byte. For instance, 3145 though 0x4001 is a legitimate two-byte encoding for a variable-length 3146 integer with a value of 1, PING frames are always encoded as a single 3147 byte with the value 0x01. An endpoint MAY treat the receipt of a 3148 frame type that uses a longer encoding than necessary as a connection 3149 error of type PROTOCOL_VIOLATION. 3151 13. Packetization and Reliability 3153 A sender bundles one or more frames in a QUIC packet (see 3154 Section 12.4). 3156 A sender can minimize per-packet bandwidth and computational costs by 3157 bundling as many frames as possible within a QUIC packet. A sender 3158 MAY wait for a short period of time to bundle multiple frames before 3159 sending a packet that is not maximally packed, to avoid sending out 3160 large numbers of small packets. An implementation MAY use knowledge 3161 about application sending behavior or heuristics to determine whether 3162 and for how long to wait. This waiting period is an implementation 3163 decision, and an implementation should be careful to delay 3164 conservatively, since any delay is likely to increase application- 3165 visible latency. 3167 Stream multiplexing is achieved by interleaving STREAM frames from 3168 multiple streams into one or more QUIC packets. A single QUIC packet 3169 can include multiple STREAM frames from one or more streams. 3171 One of the benefits of QUIC is avoidance of head-of-line blocking 3172 across multiple streams. When a packet loss occurs, only streams 3173 with data in that packet are blocked waiting for a retransmission to 3174 be received, while other streams can continue making progress. Note 3175 that when data from multiple streams is bundled into a single QUIC 3176 packet, loss of that packet blocks all those streams from making 3177 progress. Implementations are advised to bundle as few streams as 3178 necessary in outgoing packets without losing transmission efficiency 3179 to underfilled packets. 3181 13.1. Packet Processing and Acknowledgment 3183 A packet MUST NOT be acknowledged until packet protection has been 3184 successfully removed and all frames contained in the packet have been 3185 processed. For STREAM frames, this means the data has been enqueued 3186 in preparation to be received by the application protocol, but it 3187 does not require that data is delivered and consumed. 3189 Once the packet has been fully processed, a receiver acknowledges 3190 receipt by sending one or more ACK frames containing the packet 3191 number of the received packet. 3193 13.1.1. Sending ACK Frames 3195 An endpoint sends ACK frames to acknowledge packets it has received 3196 and processed. 3198 Packets containing only ACK frames are not congestion controlled, so 3199 there are limits on how frequently they can be sent. An endpoint 3200 MUST NOT send more than one ACK-frame-only packet in response to 3201 receiving an ACK-eliciting packet (one containing frames other than 3202 ACK and/or PADDING). An endpoint MUST NOT send a packet containing 3203 only an ACK frame in response to a non-ACK-eliciting packet (one 3204 containing only ACK and/or PADDING frames), even if there are packet 3205 gaps which precede the received packet. Limiting ACK frames avoids 3206 an infinite feedback loop of acknowledgements, which could prevent 3207 the connection from ever becoming idle. However, the endpoint 3208 acknowledges non-ACK-eliciting packets when it sends an ACK frame. 3210 Packets containing PADDING frames are considered to be in flight for 3211 congestion control purposes [QUIC-RECOVERY]. Sending only PADDING 3212 frames might cause the sender to become limited by the congestion 3213 controller (as described in [QUIC-RECOVERY]) with no acknowledgments 3214 forthcoming from the receiver. Therefore, a sender SHOULD ensure 3215 that other frames are sent in addition to PADDING frames to elicit 3216 acknowledgments from the receiver. 3218 An endpoint that is only sending ACK frames will not receive 3219 acknowledgments from its peer unless those acknowledgements are 3220 included in packets with ACK-eliciting frames. An endpoint SHOULD 3221 bundle ACK frames with other frames when there are new ACK-eliciting 3222 packets to acknowledge. When only non-ACK-eliciting packets need to 3223 be acknowledged, an endpoint MAY wait until an ACK-eliciting packet 3224 has been received to bundle an ACK frame with outgoing frames. 3226 An endpoint SHOULD treat receipt of an acknowledgment for a packet it 3227 did not send as a connection error of type PROTOCOL_VIOLATION, if it 3228 is able to detect the condition. 3230 The receiver's delayed acknowledgment timer SHOULD NOT exceed the 3231 current RTT estimate or the value it indicates in the "max_ack_delay" 3232 transport parameter. This ensures an acknowledgment is sent at least 3233 once per RTT when packets needing acknowledgement are received. The 3234 sender can use the receiver's "max_ack_delay" value in determining 3235 timeouts for timer-based retransmission. 3237 Strategies and implications of the frequency of generating 3238 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 3240 13.1.2. Limiting ACK Ranges 3242 To limit ACK Ranges (see Section 19.3.1) to those that have not yet 3243 been received by the sender, the receiver SHOULD track which ACK 3244 frames have been acknowledged by its peer. The receiver SHOULD 3245 exclude already acknowledged packets from future ACK frames whenever 3246 these packets would unnecessarily contribute to the ACK frame size. 3247 When the receiver is only sending non-ACK-eliciting packets, it can 3248 bundle a PING or other small ACK-eliciting frame with a fraction of 3249 them, such as once per round trip, to enable dropping unnecessary ACK 3250 ranges and any state for previously sent packets. The receiver MUST 3251 NOT bundle an ACK-elicing frame, such as a PING, with all packets 3252 that would otherwise be non-ACK-eliciting, in order to avoid an 3253 infinite feedback loop of acknowledgements. 3255 To limit receiver state or the size of ACK frames, a receiver MAY 3256 limit the number of ACK Ranges it sends. A receiver can do this even 3257 without receiving acknowledgment of its ACK frames, with the 3258 knowledge this could cause the sender to unnecessarily retransmit 3259 some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare 3260 packets lost after sufficiently newer packets are acknowledged. 3261 Therefore, the receiver SHOULD repeatedly acknowledge newly received 3262 packets in preference to packets received in the past. 3264 13.1.3. ACK Frames and Packet Protection 3266 ACK frames MUST only be carried in a packet that has the same packet 3267 number space as the packet being ACKed (see Section 12.1). For 3268 instance, packets that are protected with 1-RTT keys MUST be 3269 acknowledged in packets that are also protected with 1-RTT keys. 3271 Packets that a client sends with 0-RTT packet protection MUST be 3272 acknowledged by the server in packets protected by 1-RTT keys. This 3273 can mean that the client is unable to use these acknowledgments if 3274 the server cryptographic handshake messages are delayed or lost. 3275 Note that the same limitation applies to other data sent by the 3276 server protected by the 1-RTT keys. 3278 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3279 frames with a reduced delay; see Section 6.2 of [QUIC-RECOVERY]. 3281 13.2. Retransmission of Information 3283 QUIC packets that are determined to be lost are not retransmitted 3284 whole. The same applies to the frames that are contained within lost 3285 packets. Instead, the information that might be carried in frames is 3286 sent again in new frames as needed. 3288 New frames and packets are used to carry information that is 3289 determined to have been lost. In general, information is sent again 3290 when a packet containing that information is determined to be lost 3291 and sending ceases when a packet containing that information is 3292 acknowledged. 3294 o Data sent in CRYPTO frames is retransmitted according to the rules 3295 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 3296 CRYPTO frames for Initial and Handshake packets is discarded when 3297 keys for the corresponding encryption level are discarded. 3299 o Application data sent in STREAM frames is retransmitted in new 3300 STREAM frames unless the endpoint has sent a RESET_STREAM for that 3301 stream. Once an endpoint sends a RESET_STREAM frame, no further 3302 STREAM frames are needed. 3304 o The most recent set of acknowledgments are sent in ACK frames. An 3305 ACK frame SHOULD contain all unacknowledged acknowledgments, as 3306 described in Section 13.1.1. 3308 o Cancellation of stream transmission, as carried in a RESET_STREAM 3309 frame, is sent until acknowledged or until all stream data is 3310 acknowledged by the peer (that is, either the "Reset Recvd" or 3311 "Data Recvd" state is reached on the sending part of the stream). 3312 The content of a RESET_STREAM frame MUST NOT change when it is 3313 sent again. 3315 o Similarly, a request to cancel stream transmission, as encoded in 3316 a STOP_SENDING frame, is sent until the receiving part of the 3317 stream enters either a "Data Recvd" or "Reset Recvd" state; see 3318 Section 3.5. 3320 o Connection close signals, including packets that contain 3321 CONNECTION_CLOSE frames, are not sent again when packet loss is 3322 detected, but as described in Section 10. 3324 o The current connection maximum data is sent in MAX_DATA frames. 3325 An updated value is sent in a MAX_DATA frame if the packet 3326 containing the most recently sent MAX_DATA frame is declared lost, 3327 or when the endpoint decides to update the limit. Care is 3328 necessary to avoid sending this frame too often as the limit can 3329 increase frequently and cause an unnecessarily large number of 3330 MAX_DATA frames to be sent. 3332 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3333 frames. Like MAX_DATA, an updated value is sent when the packet 3334 containing the most recent MAX_STREAM_DATA frame for a stream is 3335 lost or when the limit is updated, with care taken to prevent the 3336 frame from being sent too often. An endpoint SHOULD stop sending 3337 MAX_STREAM_DATA frames when the receiving part of the stream 3338 enters a "Size Known" state. 3340 o The limit on streams of a given type is sent in MAX_STREAMS 3341 frames. Like MAX_DATA, an updated value is sent when a packet 3342 containing the most recent MAX_STREAMS for a stream type frame is 3343 declared lost or when the limit is updated, with care taken to 3344 prevent the frame from being sent too often. 3346 o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 3347 and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection 3348 scope, STREAM_DATA_BLOCKED frames have stream scope, and 3349 STREAMS_BLOCKED frames are scoped to a specific stream type. New 3350 frames are sent if packets containing the most recent frame for a 3351 scope is lost, but only while the endpoint is blocked on the 3352 corresponding limit. These frames always include the limit that 3353 is causing blocking at the time that they are transmitted. 3355 o A liveness or path validation check using PATH_CHALLENGE frames is 3356 sent periodically until a matching PATH_RESPONSE frame is received 3357 or until there is no remaining need for liveness or path 3358 validation checking. PATH_CHALLENGE frames include a different 3359 payload each time they are sent. 3361 o Responses to path validation using PATH_RESPONSE frames are sent 3362 just once. The peer is expected to send more PATH_CHALLENGE 3363 frames as necessary to evoke additional PATH_RESPONSE frames. 3365 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3366 retransmitted if the packet containing them is lost. 3367 Retransmissions of this frame carry the same sequence number 3368 value. Likewise, retired connection IDs are sent in 3369 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3370 containing them is lost. 3372 o PING and PADDING frames contain no information, so lost PING or 3373 PADDING frames do not require repair. 3375 Endpoints SHOULD prioritize retransmission of data over sending new 3376 data, unless priorities specified by the application indicate 3377 otherwise (see Section 2.3). 3379 Even though a sender is encouraged to assemble frames containing up- 3380 to-date information every time it sends a packet, it is not forbidden 3381 to retransmit copies of frames from lost packets. A receiver MUST 3382 accept packets containing an outdated frame, such as a MAX_DATA frame 3383 carrying a smaller maximum data than one found in an older packet. 3385 Upon detecting losses, a sender MUST take appropriate congestion 3386 control action. The details of loss detection and congestion control 3387 are described in [QUIC-RECOVERY]. 3389 13.3. Explicit Congestion Notification 3391 QUIC endpoints can use Explicit Congestion Notification (ECN) 3392 [RFC3168] to detect and respond to network congestion. ECN allows a 3393 network node to indicate congestion in the network by setting a 3394 codepoint in the IP header of a packet instead of dropping it. 3395 Endpoints react to congestion by reducing their sending rate in 3396 response, as described in [QUIC-RECOVERY]. 3398 To use ECN, QUIC endpoints first determine whether a path supports 3399 ECN marking and the peer is able to access the ECN codepoint in the 3400 IP header. A network path does not support ECN if ECN marked packets 3401 get dropped or ECN markings are rewritten on the path. An endpoint 3402 verifies the path, both during connection establishment and when 3403 migrating to a new path (see Section 9). 3405 13.3.1. ECN Counts 3407 On receiving a QUIC packet with an ECT or CE codepoint, an ECN- 3408 enabled endpoint that can access the ECN codepoints from the 3409 enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE 3410 count, and includes these counts in subsequent ACK frames (see 3411 Section 13.1 and Section 19.3). Note that this requires being able 3412 to read the ECN codepoints from the enclosing IP packet, which is not 3413 possible on all platforms. 3415 A packet detected by a receiver as a duplicate does not affect the 3416 receiver's local ECN codepoint counts; see (Section 21.7) for 3417 relevant security concerns. 3419 If an endpoint receives a QUIC packet without an ECT or CE codepoint 3420 in the IP packet header, it responds per Section 13.1 with an ACK 3421 frame without increasing any ECN counts. If an endpoint does not 3422 implement ECN support or does not have access to received ECN 3423 codepoints, it does not increase ECN counts. 3425 Coalesced packets (see Section 12.2) mean that several packets can 3426 share the same IP header. The ECN counter for the ECN codepoint 3427 received in the associated IP header are incremented once for each 3428 QUIC packet, not per enclosing IP packet or UDP datagram. 3430 Each packet number space maintains separate acknowledgement state and 3431 separate ECN counts. For example, if one each of an Initial, 0-RTT, 3432 Handshake, and 1-RTT QUIC packet are coalesced, the corresponding 3433 counts for the Initial and Handshake packet number space will be 3434 incremented by one and the counts for the 1-RTT packet number space 3435 will be increased by two. 3437 13.3.2. ECN Verification 3439 Each endpoint independently verifies and enables use of ECN by 3440 setting the IP header ECN codepoint to ECN Capable Transport (ECT) 3441 for the path from it to the other peer. Even if not setting ECN 3442 codepoints on packets it transmits, the endpoint SHOULD provide 3443 feedback about ECN markings received (if accessible). 3445 To verify both that a path supports ECN and the peer can provide ECN 3446 feedback, an endpoint sets the ECT(0) codepoint in the IP header of 3447 all outgoing packets [RFC8311]. 3449 If an ECT codepoint set in the IP header is not corrupted by a 3450 network device, then a received packet contains either the codepoint 3451 sent by the peer or the Congestion Experienced (CE) codepoint set by 3452 a network device that is experiencing congestion. 3454 If a QUIC packet sent with an ECT codepoint is newly acknowledged by 3455 the peer in an ACK frame without ECN feedback, the endpoint stops 3456 setting ECT codepoints in subsequent IP packets, with the expectation 3457 that either the network path or the peer no longer supports ECN. 3459 Network devices that corrupt or apply non-standard ECN markings might 3460 result in reduced throughput or other undesirable side-effects. To 3461 reduce this risk, an endpoint uses the following steps to verify the 3462 counts it receives in an ACK frame. 3464 o The total increase in ECT(0), ECT(1), and CE counts MUST be no 3465 smaller than the total number of QUIC packets sent with an ECT 3466 codepoint that are newly acknowledged in this ACK frame. This 3467 step detects any network remarking from ECT(0), ECT(1), or CE 3468 codepoints to Not-ECT. 3470 o Any increase in either ECT(0) or ECT(1) counts, plus any increase 3471 in the CE count, MUST be no smaller than the number of packets 3472 sent with the corresponding ECT codepoint that are newly 3473 acknowledged in this ACK frame. This step detects any erroneous 3474 network remarking from ECT(0) to ECT(1) (or vice versa). 3476 An endpoint could miss acknowledgements for a packet when ACK frames 3477 are lost. It is therefore possible for the total increase in ECT(0), 3478 ECT(1), and CE counts to be greater than the number of packets 3479 acknowledged in an ACK frame. When this happens, and if verification 3480 succeeds, the local reference counts MUST be increased to match the 3481 counts in the ACK frame. 3483 Processing counts out of order can result in verification failure. 3484 An endpoint SHOULD NOT perform this verification if the ACK frame is 3485 received in a packet with packet number lower than a previously 3486 received ACK frame. Verifying based on ACK frames that arrive out of 3487 order can result in disabling ECN unnecessarily. 3489 Upon successful verification, an endpoint continues to set ECT 3490 codepoints in subsequent packets with the expectation that the path 3491 is ECN-capable. 3493 If verification fails, then the endpoint ceases setting ECT 3494 codepoints in subsequent IP packets with the expectation that either 3495 the network path or the peer does not support ECN. 3497 If an endpoint sets ECT codepoints on outgoing IP packets and 3498 encounters a retransmission timeout due to the absence of 3499 acknowledgments from the peer (see [QUIC-RECOVERY]), or if an 3500 endpoint has reason to believe that an element on the network path 3501 might be corrupting ECN codepoints, the endpoint MAY cease setting 3502 ECT codepoints in subsequent packets. Doing so allows the connection 3503 to be resilient to network elements that corrupt ECN codepoints in 3504 the IP header or drop packets with ECT or CE codepoints in the IP 3505 header. 3507 14. Packet Size 3509 The QUIC packet size includes the QUIC header and protected payload, 3510 but not the UDP or IP header. 3512 Clients MUST ensure they send the first Initial packet in a single IP 3513 packet. Similarly, the first Initial packet sent after receiving a 3514 Retry packet MUST be sent in a single IP packet. 3516 The payload of a UDP datagram carrying the first Initial packet MUST 3517 be expanded to at least 1200 bytes, by adding PADDING frames to the 3518 Initial packet and/or by coalescing the Initial packet (see 3519 Section 12.2). Sending a UDP datagram of this size ensures that the 3520 network path supports a reasonable Maximum Transmission Unit (MTU), 3521 and helps reduce the amplitude of amplification attacks caused by 3522 server responses toward an unverified client address; see Section 8. 3524 The datagram containing the first Initial packet from a client MAY 3525 exceed 1200 bytes if the client believes that the Path Maximum 3526 Transmission Unit (PMTU) supports the size that it chooses. 3528 A server MAY send a CONNECTION_CLOSE frame with error code 3529 PROTOCOL_VIOLATION in response to the first Initial packet it 3530 receives from a client if the UDP datagram is smaller than 1200 3531 bytes. It MUST NOT send any other frame type in response, or 3532 otherwise behave as if any part of the offending packet was processed 3533 as valid. 3535 The server MUST also limit the number of bytes it sends before 3536 validating the address of the client; see Section 8. 3538 14.1. Path Maximum Transmission Unit (PMTU) 3540 The PMTU is the maximum size of the entire IP packet including the IP 3541 header, UDP header, and UDP payload. The UDP payload includes the 3542 QUIC packet header, protected payload, and any authentication fields. 3543 The PMTU can depend upon the current path characteristics. 3544 Therefore, the current largest UDP payload an implementation will 3545 send is referred to as the QUIC maximum packet size. 3547 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 3548 minimum size [RFC8200] and is also supported by most modern IPv4 3549 networks. All QUIC packets (except for PMTU probe packets) SHOULD be 3550 sized to fit within the maximum packet size to avoid the packet being 3551 fragmented or dropped [RFC8085]. 3553 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery 3554 ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] 3555 [RFC8201] to determine whether the path to a destination will support 3556 a desired message size without fragmentation. 3558 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3559 packets larger than 1280 bytes. Assuming the minimum IP header size, 3560 this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 3561 1252 bytes for IPv4. A QUIC implementation MAY be more conservative 3562 in computing the QUIC maximum packet size to allow for unknown tunnel 3563 overheads or IP header options/extensions. 3565 Each pair of local and remote addresses could have a different PMTU. 3566 QUIC implementations that implement any kind of PMTU discovery 3567 therefore SHOULD maintain a maximum packet size for each combination 3568 of local and remote IP addresses. 3570 If a QUIC endpoint determines that the PMTU between any pair of local 3571 and remote IP addresses has fallen below the size needed to support 3572 the smallest allowed maximum packet size, it MUST immediately cease 3573 sending QUIC packets, except for PMTU probe packets, on the affected 3574 path. An endpoint MAY terminate the connection if an alternative 3575 path cannot be found. 3577 14.2. ICMP Packet Too Big Messages 3579 PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP 3580 messages (e.g., IPv6 Packet Too Big messages) that indicate when a 3581 packet is dropped because it is larger than the local router MTU. 3582 DPLPMTUD can also optionally use these messages. This use of ICMP 3583 messages is potentially vulnerable to off-path attacks that 3584 successfully guess the addresses used on the path and reduce the PMTU 3585 to a bandwidth-inefficient value. 3587 An endpoint MUST ignore an ICMP message that claims the PMTU has 3588 decreased below 1280 bytes. 3590 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 3591 that the quoted packet should contain as much of the original packet 3592 as possible without exceeding the minimum MTU for the IP version. 3593 The size of the quoted packet can actually be smaller, or the 3594 information unintelligible, as described in Section 1.1 of 3595 [DPLPMTUD]. 3597 QUIC endpoints SHOULD validate ICMP messages to protect from off-path 3598 injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. 3599 This validation SHOULD use the quoted packet supplied in the payload 3600 of an ICMP message to associate the message with a corresponding 3601 transport connection [DPLPMTUD]. 3603 ICMP message validation MUST include matching IP addresses and UDP 3604 ports [RFC8085] and, when possible, connection IDs to an active QUIC 3605 session. 3607 Further validation can also be provided: 3609 o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small 3610 proportion of packets, so that most invalid ICMP messages arrive 3611 when there are no DF packets outstanding, and can therefore be 3612 identified as spurious. 3614 o An endpoint could store additional information from the IP or UDP 3615 headers to use for validation (for example, the IP ID or UDP 3616 checksum). 3618 The endpoint SHOULD ignore all ICMP messages that fail validation. 3620 An endpoint MUST NOT increase PMTU based on ICMP messages. Any 3621 reduction in the QUIC maximum packet size MAY be provisional until 3622 QUIC's loss detection algorithm determines that the quoted packet has 3623 actually been lost. 3625 14.3. Datagram Packetization Layer PMTU Discovery 3627 Section 6.4 of [DPLPMTUD] provides considerations for implementing 3628 Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. 3630 When implementing the algorithm in Section 5.3 of [DPLPMTUD], the 3631 initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC 3632 packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). 3634 PING and PADDING frames can be used to generate PMTU probe packets. 3635 These frames might not be retransmitted if a probe packet containing 3636 them is lost. However, these frames do consume congestion window, 3637 which could delay the transmission of subsequent application data. 3639 A PING frame can be included in a PMTU probe to ensure that a valid 3640 probe is acknowledged. 3642 The considerations for processing ICMP messages in the previous 3643 section also apply if these messages are used by DPLPMTUD. 3645 14.3.1. PMTU Probes Containing Source Connection ID 3647 Endpoints that rely on the destination connection ID for routing QUIC 3648 packets are likely to require that the connection ID be included in 3649 PMTU probe packets to route any resulting ICMP messages 3650 (Section 14.2) back to the correct endpoint. However, only long 3651 header packets (Section 17.2) contain source connection IDs, and long 3652 header packets are not decrypted or acknowledged by the peer once the 3653 handshake is complete. One way to construct a PMTU probe is to 3654 coalesce (see Section 12.2) a Handshake packet (Section 17.2.4) with 3655 a short header packet in a single UDP datagram. If the UDP datagram 3656 reaches the endpoint, the Handshake packet will be ignored, but the 3657 short header packet will be acknowledged. If the UDP datagram 3658 elicits an ICMP message, that message will likely contain the source 3659 connection ID within the quoted portion of the UDP datagram. 3661 15. Versions 3663 QUIC versions are identified using a 32-bit unsigned number. 3665 The version 0x00000000 is reserved to represent version negotiation. 3666 This version of the specification is identified by the number 3667 0x00000001. 3669 Other versions of QUIC might have different properties to this 3670 version. The properties of QUIC that are guaranteed to be consistent 3671 across all versions of the protocol are described in 3672 [QUIC-INVARIANTS]. 3674 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 3675 protocol, as described in [QUIC-TLS]. 3677 Versions with the most significant 16 bits of the version number 3678 cleared are reserved for use in future IETF consensus documents. 3680 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 3681 forcing version negotiation to be exercised. That is, any version 3682 number where the low four bits of all bytes is 1010 (in binary). A 3683 client or server MAY advertise support for any of these reserved 3684 versions. 3686 Reserved version numbers will probably never represent a real 3687 protocol; a client MAY use one of these version numbers with the 3688 expectation that the server will initiate version negotiation; a 3689 server MAY advertise support for one of these versions and can expect 3690 that clients ignore the value. 3692 [[RFC editor: please remove the remainder of this section before 3693 publication.]] 3695 The version number for the final version of this specification 3696 (0x00000001), is reserved for the version of the protocol that is 3697 published as an RFC. 3699 Version numbers used to identify IETF drafts are created by adding 3700 the draft number to 0xff000000. For example, draft-ietf-quic- 3701 transport-13 would be identified as 0xff00000D. 3703 Implementors are encouraged to register version numbers of QUIC that 3704 they are using for private experimentation on the GitHub wiki at 3705 . 3707 16. Variable-Length Integer Encoding 3709 QUIC packets and frames commonly use a variable-length encoding for 3710 non-negative integer values. This encoding ensures that smaller 3711 integer values need fewer bytes to encode. 3713 The QUIC variable-length integer encoding reserves the two most 3714 significant bits of the first byte to encode the base 2 logarithm of 3715 the integer encoding length in bytes. The integer value is encoded 3716 on the remaining bits, in network byte order. 3718 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 3719 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3720 the encoding properties. 3722 +------+--------+-------------+-----------------------+ 3723 | 2Bit | Length | Usable Bits | Range | 3724 +------+--------+-------------+-----------------------+ 3725 | 00 | 1 | 6 | 0-63 | 3726 | | | | | 3727 | 01 | 2 | 14 | 0-16383 | 3728 | | | | | 3729 | 10 | 4 | 30 | 0-1073741823 | 3730 | | | | | 3731 | 11 | 8 | 62 | 0-4611686018427387903 | 3732 +------+--------+-------------+-----------------------+ 3734 Table 4: Summary of Integer Encodings 3736 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 3737 hexadecimal) decodes to the decimal value 151288809941952652; the 3738 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 3739 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 3740 (as does the two byte sequence 40 25). 3742 Error codes (Section 20) and versions (Section 15) are described 3743 using integers, but do not use this encoding. 3745 17. Packet Formats 3747 All numeric values are encoded in network byte order (that is, big- 3748 endian) and all field sizes are in bits. Hexadecimal notation is 3749 used for describing the value of fields. 3751 17.1. Packet Number Encoding and Decoding 3753 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). 3754 When present in long or short packet headers, they are encoded in 1 3755 to 4 bytes. The number of bits required to represent the packet 3756 number is reduced by including the least significant bits of the 3757 packet number. 3759 The encoded packet number is protected as described in Section 5.4 of 3760 [QUIC-TLS]. 3762 The sender MUST use a packet number size able to represent more than 3763 twice as large a range than the difference between the largest 3764 acknowledged packet and packet number being sent. A peer receiving 3765 the packet will then correctly decode the packet number, unless the 3766 packet is delayed in transit such that it arrives after many higher- 3767 numbered packets have been received. An endpoint SHOULD use a large 3768 enough packet number encoding to allow the packet number to be 3769 recovered even if the packet arrives after packets that are sent 3770 afterwards. 3772 As a result, the size of the packet number encoding is at least one 3773 bit more than the base-2 logarithm of the number of contiguous 3774 unacknowledged packet numbers, including the new packet. 3776 For example, if an endpoint has received an acknowledgment for packet 3777 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 3778 packet number encoding with 16 bits or more; whereas the 24-bit 3779 packet number encoding is needed to send a packet with a number of 3780 0xace8fe. 3782 At a receiver, protection of the packet number is removed prior to 3783 recovering the full packet number. The full packet number is then 3784 reconstructed based on the number of significant bits present, the 3785 value of those bits, and the largest packet number received on a 3786 successfully authenticated packet. Recovering the full packet number 3787 is necessary to successfully remove packet protection. 3789 Once header protection is removed, the packet number is decoded by 3790 finding the packet number value that is closest to the next expected 3791 packet. The next expected packet is the highest received packet 3792 number plus one. For example, if the highest successfully 3793 authenticated packet had a packet number of 0xa82f30ea, then a packet 3794 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 3795 Example pseudo-code for packet number decoding can be found in 3796 Appendix A. 3798 17.2. Long Header Packets 3800 0 1 2 3 3801 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 3802 +-+-+-+-+-+-+-+-+ 3803 |1|1|T T|X X X X| 3804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3805 | Version (32) | 3806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3807 | DCID Len (8) | 3808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3809 | Destination Connection ID (0..160) ... 3810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3811 | SCID Len (8) | 3812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3813 | Source Connection ID (0..160) ... 3814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3816 Figure 9: Long Header Packet Format 3818 Long headers are used for packets that are sent prior to the 3819 establishment of 1-RTT keys. Once both conditions are met, a sender 3820 switches to sending packets using the short header (Section 17.3). 3821 The long form allows for special packets - such as the Version 3822 Negotiation packet - to be represented in this uniform fixed-length 3823 packet format. Packets that use the long header contain the 3824 following fields: 3826 Header Form: The most significant bit (0x80) of byte 0 (the first 3827 byte) is set to 1 for long headers. 3829 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 3830 containing a zero value for this bit are not valid packets in this 3831 version and MUST be discarded. 3833 Long Packet Type (T): The next two bits (those with a mask of 0x30) 3834 of byte 0 contain a packet type. Packet types are listed in 3835 Table 5. 3837 Type-Specific Bits (X): The lower four bits (those with a mask of 3838 0x0f) of byte 0 are type-specific. 3840 Version: The QUIC Version is a 32-bit field that follows the first 3841 byte. This field indicates which version of QUIC is in use and 3842 determines how the rest of the protocol fields are interpreted. 3844 DCID Len: The byte following the version contains the lengths of the 3845 two connection ID fields that follow it. These lengths are 3846 encoded as two 4-bit unsigned integers. The Destination 3847 Connection ID Length (DCIL) field occupies the 4 high bits of the 3848 byte and the Source Connection ID Length (SCIL) field occupies the 3849 4 low bits of the byte. An encoded length of 0 indicates that the 3850 connection ID is also 0 bytes in length. Non-zero encoded lengths 3851 are increased by 3 to get the full length of the connection ID, 3852 producing a length between 4 and 18 bytes inclusive. For example, 3853 a byte with the value 0x50 describes an 8-byte Destination 3854 Connection ID and a zero-length Source Connection ID. 3856 Destination Connection ID: The Destination Connection ID field 3857 follows the DCID Len and is between 0 and 20 bytes in length. 3858 Section 7.2 describes the use of this field in more detail. 3860 SCID Len: The byte following the Destination Connection ID contains 3861 the length in bytes of the Source Connection ID field that follows 3862 it. This length is encoded as a 8-bit unsigned integer. In QUIC 3863 version 1, this value MUST NOT exceed 20 bytes. Endpoints that 3864 receive a version 1 long header with a value larger than 20 MUST 3865 drop the packet. Servers SHOULD be able to read longer connection 3866 IDs from other QUIC versions in order to properly form a version 3867 negotiation packet. 3869 Source Connection ID: The Source Connection ID field follows the 3870 SCID Len and is between 0 and 20 bytes in length. Section 7.2 3871 describes the use of this field in more detail. 3873 In this version of QUIC, the following packet types with the long 3874 header are defined: 3876 +------+-----------+----------------+ 3877 | Type | Name | Section | 3878 +------+-----------+----------------+ 3879 | 0x0 | Initial | Section 17.2.2 | 3880 | | | | 3881 | 0x1 | 0-RTT | Section 17.2.3 | 3882 | | | | 3883 | 0x2 | Handshake | Section 17.2.4 | 3884 | | | | 3885 | 0x3 | Retry | Section 17.2.5 | 3886 +------+-----------+----------------+ 3888 Table 5: Long Header Packet Types 3890 The header form bit, connection ID lengths byte, Destination and 3891 Source Connection ID fields, and Version fields of a long header 3892 packet are version-independent. The other fields in the first byte 3893 are version-specific. See [QUIC-INVARIANTS] for details on how 3894 packets from different versions of QUIC are interpreted. 3896 The interpretation of the fields and the payload are specific to a 3897 version and packet type. While type-specific semantics for this 3898 version are described in the following sections, several long-header 3899 packets in this version of QUIC contain these additional fields: 3901 Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 3902 are reserved across multiple packet types. These bits are 3903 protected using header protection (see Section 5.4 of [QUIC-TLS]). 3904 The value included prior to protection MUST be set to 0. An 3905 endpoint MUST treat receipt of a packet that has a non-zero value 3906 for these bits, after removing both packet and header protection, 3907 as a connection error of type PROTOCOL_VIOLATION. Discarding such 3908 a packet after only removing header protection can expose the 3909 endpoint to attacks (see Section 9.3 of [QUIC-TLS]). 3911 Packet Number Length (P): In packet types which contain a Packet 3912 Number field, the least significant two bits (those with a mask of 3913 0x03) of byte 0 contain the length of the packet number, encoded 3914 as an unsigned, two-bit integer that is one less than the length 3915 of the packet number field in bytes. That is, the length of the 3916 packet number field is the value of this field, plus one. These 3917 bits are protected using header protection (see Section 5.4 of 3918 [QUIC-TLS]). 3920 Length: The length of the remainder of the packet (that is, the 3921 Packet Number and Payload fields) in bytes, encoded as a variable- 3922 length integer (Section 16). 3924 Packet Number: The packet number field is 1 to 4 bytes long. The 3925 packet number has confidentiality protection separate from packet 3926 protection, as described in Section 5.4 of [QUIC-TLS]. The length 3927 of the packet number field is encoded in the Packet Number Length 3928 bits of byte 0 (see above). 3930 17.2.1. Version Negotiation Packet 3932 A Version Negotiation packet is inherently not version-specific. 3933 Upon receipt by a client, it will be identified as a Version 3934 Negotiation packet based on the Version field having a value of 0. 3936 The Version Negotiation packet is a response to a client packet that 3937 contains a version that is not supported by the server, and is only 3938 sent by servers. 3940 The layout of a Version Negotiation packet is: 3942 0 1 2 3 3943 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 3944 +-+-+-+-+-+-+-+-+ 3945 |1| Unused (7) | 3946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3947 | Version (32) | 3948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3949 | DCID Len (8) | 3950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 | Destination Connection ID (0..2040) ... 3952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3953 | SCID Len (8) | 3954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3955 | Source Connection ID (0..2040) ... 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3957 | Supported Version 1 (32) ... 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 | [Supported Version 2 (32)] ... 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3961 ... 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3963 | [Supported Version N (32)] ... 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3966 Figure 10: Version Negotiation Packet 3968 The value in the Unused field is selected randomly by the server. 3969 Clients MUST ignore the value of this field. Servers SHOULD set the 3970 most significant bit of this field (0x40) to 1 so that Version 3971 Negotiation packets appear to have the Fixed Bit field. 3973 The Version field of a Version Negotiation packet MUST be set to 3974 0x00000000. 3976 The server MUST include the value from the Source Connection ID field 3977 of the packet it receives in the Destination Connection ID field. 3978 The value for Source Connection ID MUST be copied from the 3979 Destination Connection ID of the received packet, which is initially 3980 randomly selected by a client. Echoing both connection IDs gives 3981 clients some assurance that the server received the packet and that 3982 the Version Negotiation packet was not generated by an off-path 3983 attacker. 3985 As future versions of QUIC may support Connection IDs larger than the 3986 version 1 limit, Version Negotiation packets could carry Connection 3987 IDs that are longer than 20 bytes. 3989 The remainder of the Version Negotiation packet is a list of 32-bit 3990 versions which the server supports. 3992 A Version Negotiation packet cannot be explicitly acknowledged in an 3993 ACK frame by a client. Receiving another Initial packet implicitly 3994 acknowledges a Version Negotiation packet. 3996 The Version Negotiation packet does not include the Packet Number and 3997 Length fields present in other packets that use the long header form. 3998 Consequently, a Version Negotiation packet consumes an entire UDP 3999 datagram. 4001 A server MUST NOT send more than one Version Negotiation packet in 4002 response to a single UDP datagram. 4004 See Section 6 for a description of the version negotiation process. 4006 17.2.2. Initial Packet 4008 An Initial packet uses long headers with a type value of 0x0. It 4009 carries the first CRYPTO frames sent by the client and server to 4010 perform key exchange, and carries ACKs in either direction. 4012 +-+-+-+-+-+-+-+-+ 4013 |1|1| 0 |R R|P P| 4014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4015 | Version (32) | 4016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4017 | DCID Len (8) | 4018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4019 | Destination Connection ID (0..160) ... 4020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4021 | SCID Len (8) | 4022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4023 | Source Connection ID (0..160) ... 4024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4025 | Token Length (i) ... 4026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4027 | Token (*) ... 4028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4029 | Length (i) ... 4030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4031 | Packet Number (8/16/24/32) ... 4032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4033 | Payload (*) ... 4034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4036 Figure 11: Initial Packet 4038 The Initial packet contains a long header as well as the Length and 4039 Packet Number fields. The first byte contains the Reserved and 4040 Packet Number Length bits. Between the SCID and Length fields, there 4041 are two additional field specific to the Initial packet. 4043 Token Length: A variable-length integer specifying the length of the 4044 Token field, in bytes. This value is zero if no token is present. 4045 Initial packets sent by the server MUST set the Token Length field 4046 to zero; clients that receive an Initial packet with a non-zero 4047 Token Length field MUST either discard the packet or generate a 4048 connection error of type PROTOCOL_VIOLATION. 4050 Token: The value of the token that was previously provided in a 4051 Retry packet or NEW_TOKEN frame. 4053 Payload: The payload of the packet. 4055 In order to prevent tampering by version-unaware middleboxes, Initial 4056 packets are protected with connection- and version-specific keys 4057 (Initial keys) as described in [QUIC-TLS]. This protection does not 4058 provide confidentiality or integrity against on-path attackers, but 4059 provides some level of protection against off-path attackers. 4061 The client and server use the Initial packet type for any packet that 4062 contains an initial cryptographic handshake message. This includes 4063 all cases where a new packet containing the initial cryptographic 4064 message needs to be created, such as the packets sent after receiving 4065 a Retry packet (Section 17.2.5). 4067 A server sends its first Initial packet in response to a client 4068 Initial. A server may send multiple Initial packets. The 4069 cryptographic key exchange could require multiple round trips or 4070 retransmissions of this data. 4072 The payload of an Initial packet includes a CRYPTO frame (or frames) 4073 containing a cryptographic handshake message, ACK frames, or both. 4074 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 4075 that receives an Initial packet containing other frames can either 4076 discard the packet as spurious or treat it as a connection error. 4078 The first packet sent by a client always includes a CRYPTO frame that 4079 contains the entirety of the first cryptographic handshake message. 4080 This packet, and the cryptographic handshake message, MUST fit in a 4081 single UDP datagram (see Section 7). The first CRYPTO frame sent 4082 always begins at an offset of 0 (see Section 7). 4084 Note that if the server sends a HelloRetryRequest, the client will 4085 send a second Initial packet. This Initial packet will continue the 4086 cryptographic handshake and will contain a CRYPTO frame with an 4087 offset matching the size of the CRYPTO frame sent in the first 4088 Initial packet. Cryptographic handshake messages subsequent to the 4089 first do not need to fit within a single UDP datagram. 4091 17.2.2.1. Abandoning Initial Packets 4093 A client stops both sending and processing Initial packets when it 4094 sends its first Handshake packet. A server stops sending and 4095 processing Initial packets when it receives its first Handshake 4096 packet. Though packets might still be in flight or awaiting 4097 acknowledgment, no further Initial packets need to be exchanged 4098 beyond this point. Initial packet protection keys are discarded (see 4099 Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and 4100 congestion control state (see Section 6.5 of [QUIC-RECOVERY]). 4102 Any data in CRYPTO frames is discarded - and no longer retransmitted 4103 - when Initial keys are discarded. 4105 17.2.3. 0-RTT 4107 A 0-RTT packet uses long headers with a type value of 0x1, followed 4108 by the Length and Packet Number fields. The first byte contains the 4109 Reserved and Packet Number Length bits. It is used to carry "early" 4110 data from the client to the server as part of the first flight, prior 4111 to handshake completion. As part of the TLS handshake, the server 4112 can accept or reject this early data. 4114 See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its 4115 limitations. 4117 +-+-+-+-+-+-+-+-+ 4118 |1|1| 1 |R R|P P| 4119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4120 | Version (32) | 4121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4122 | DCID Len (8) | 4123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4124 | Destination Connection ID (0..160) ... 4125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4126 | SCID Len (8) | 4127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4128 | Source Connection ID (0..160) ... 4129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4130 | Length (i) ... 4131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 | Packet Number (8/16/24/32) ... 4133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4134 | Payload (*) ... 4135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4137 0-RTT Packet 4139 Packet numbers for 0-RTT protected packets use the same space as 4140 1-RTT protected packets. 4142 After a client receives a Retry packet, 0-RTT packets are likely to 4143 have been lost or discarded by the server. A client MAY attempt to 4144 resend data in 0-RTT packets after it sends a new Initial packet. 4146 A client MUST NOT reset the packet number it uses for 0-RTT packets, 4147 since the keys used to protect 0-RTT packets will not change as a 4148 result of responding to a Retry packet. Sending packets with the 4149 same packet number in that case is likely to compromise the packet 4150 protection for all 0-RTT packets because the same key and nonce could 4151 be used to protect different content. 4153 A client only receives acknowledgments for its 0-RTT packets once the 4154 handshake is complete. Consequently, a server might expect 0-RTT 4155 packets to start with a packet number of 0. Therefore, in 4156 determining the length of the packet number encoding for 0-RTT 4157 packets, a client MUST assume that all packets up to the current 4158 packet number are in flight, starting from a packet number of 0. 4159 Thus, 0-RTT packets could need to use a longer packet number 4160 encoding. 4162 A client MUST NOT send 0-RTT packets once it starts processing 1-RTT 4163 packets from the server. This means that 0-RTT packets cannot 4164 contain any response to frames from 1-RTT packets. For instance, a 4165 client cannot send an ACK frame in a 0-RTT packet, because that can 4166 only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT 4167 packet MUST be carried in a 1-RTT packet. 4169 A server SHOULD treat a violation of remembered limits as a 4170 connection error of an appropriate type (for instance, a 4171 FLOW_CONTROL_ERROR for exceeding stream data limits). 4173 17.2.4. Handshake Packet 4175 A Handshake packet uses long headers with a type value of 0x2, 4176 followed by the Length and Packet Number fields. The first byte 4177 contains the Reserved and Packet Number Length bits. It is used to 4178 carry acknowledgments and cryptographic handshake messages from the 4179 server and client. 4181 +-+-+-+-+-+-+-+-+ 4182 |1|1| 2 |R R|P P| 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | Version (32) | 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4186 | DCID Len (8) | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 | Destination Connection ID (0..160) ... 4189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4190 | SCID Len (8) | 4191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4192 | Source Connection ID (0..160) ... 4193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4194 | Length (i) ... 4195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4196 | Packet Number (8/16/24/32) ... 4197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4198 | Payload (*) ... 4199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4201 Figure 12: Handshake Protected Packet 4203 Once a client has received a Handshake packet from a server, it uses 4204 Handshake packets to send subsequent cryptographic handshake messages 4205 and acknowledgments to the server. 4207 The Destination Connection ID field in a Handshake packet contains a 4208 connection ID that is chosen by the recipient of the packet; the 4209 Source Connection ID includes the connection ID that the sender of 4210 the packet wishes to use (see Section 7.2). 4212 Handshake packets are their own packet number space, and thus the 4213 first Handshake packet sent by a server contains a packet number of 4214 0. 4216 The payload of this packet contains CRYPTO frames and could contain 4217 PADDING, or ACK frames. Handshake packets MAY contain 4218 CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake 4219 packets with other frames as a connection error. 4221 Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at 4222 the Handshake encryption level is discarded - and no longer 4223 retransmitted - when Handshake protection keys are discarded. 4225 17.2.5. Retry Packet 4227 A Retry packet uses a long packet header with a type value of 0x3. 4228 It carries an address validation token created by the server. It is 4229 used by a server that wishes to perform a retry (see Section 8.1). 4231 0 1 2 3 4232 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 4233 +-+-+-+-+-+-+-+-+ 4234 |1|1| 3 | Unused| 4235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4236 | Version (32) | 4237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4238 | DCID Len (8) | 4239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4240 | Destination Connection ID (0..160) ... 4241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4242 | SCID Len (8) | 4243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4244 | Source Connection ID (0..160) ... 4245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4246 | ODCID Len (8) | 4247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4248 | Original Destination Connection ID (0..160) ... 4249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4250 | Retry Token (*) ... 4251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4253 Figure 13: Retry Packet 4255 A Retry packet (shown in Figure 13) does not contain any protected 4256 fields. The value in the Unused field is selected randomly by the 4257 server. In addition to the long header, it contains these additional 4258 fields: 4260 ODCID Len: The ODCID Len contains the length in bytes of the 4261 Original Destination Connection ID field that follows it. This 4262 length is encoded as a 8-bit unsigned integer. In QUIC version 1, 4263 this value MUST NOT exceed 20 bytes. Clients that receive a 4264 version 1 Retry Packet with a value larger than 20 MUST drop the 4265 packet. 4267 Original Destination Connection ID: The Original Destination 4268 Connection ID contains the value of the Destination Connection ID 4269 from the Initial packet that this Retry is in response to. The 4270 length of this field is given in ODCID Len. 4272 Retry Token: An opaque token that the server can use to validate the 4273 client's address. 4275 The server populates the Destination Connection ID with the 4276 connection ID that the client included in the Source Connection ID of 4277 the Initial packet. 4279 The server includes a connection ID of its choice in the Source 4280 Connection ID field. This value MUST not be equal to the Destination 4281 Connection ID field of the packet sent by the client. The client 4282 MUST use this connection ID in the Destination Connection ID of 4283 subsequent packets that it sends. 4285 A server MAY send Retry packets in response to Initial and 0-RTT 4286 packets. A server can either discard or buffer 0-RTT packets that it 4287 receives. A server can send multiple Retry packets as it receives 4288 Initial or 0-RTT packets. A server MUST NOT send more than one Retry 4289 packet in response to a single UDP datagram. 4291 A client MUST accept and process at most one Retry packet for each 4292 connection attempt. After the client has received and processed an 4293 Initial or Retry packet from the server, it MUST discard any 4294 subsequent Retry packets that it receives. 4296 Clients MUST discard Retry packets that contain an Original 4297 Destination Connection ID field that does not match the Destination 4298 Connection ID from its Initial packet. This prevents an off-path 4299 attacker from injecting a Retry packet. 4301 The client responds to a Retry packet with an Initial packet that 4302 includes the provided Retry Token to continue connection 4303 establishment. 4305 A client sets the Destination Connection ID field of this Initial 4306 packet to the value from the Source Connection ID in the Retry 4307 packet. Changing Destination Connection ID also results in a change 4308 to the keys used to protect the Initial packet. It also sets the 4309 Token field to the token provided in the Retry. The client MUST NOT 4310 change the Source Connection ID because the server could include the 4311 connection ID as part of its token validation logic (see 4312 Section 8.1.3). 4314 The next Initial packet from the client uses the connection ID and 4315 token values from the Retry packet (see Section 7.2). Aside from 4316 this, the Initial packet sent by the client is subject to the same 4317 restrictions as the first Initial packet. A client MUST use the same 4318 cryptographic handshake message it includes in this packet. A server 4319 MAY treat a packet that contains a different cryptographic handshake 4320 message as a connection error or discard it. 4322 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4323 0-RTT packets to the connection ID provided by the server. A client 4324 MUST NOT change the cryptographic handshake message it sends in 4325 response to receiving a Retry. 4327 A client MUST NOT reset the packet number for any packet number space 4328 after processing a Retry packet; Section 17.2.3 contains more 4329 information on this. 4331 A server acknowledges the use of a Retry packet for a connection 4332 using the original_connection_id transport parameter (see 4333 Section 18.1). If the server sends a Retry packet, it MUST include 4334 the value of the Original Destination Connection ID field of the 4335 Retry packet (that is, the Destination Connection ID field from the 4336 client's first Initial packet) in the transport parameter. 4338 If the client received and processed a Retry packet, it MUST validate 4339 that the original_connection_id transport parameter is present and 4340 correct; otherwise, it MUST validate that the transport parameter is 4341 absent. A client MUST treat a failed validation as a connection 4342 error of type TRANSPORT_PARAMETER_ERROR. 4344 A Retry packet does not include a packet number and cannot be 4345 explicitly acknowledged by a client. 4347 17.3. Short Header Packets 4349 This version of QUIC defines a single packet type which uses the 4350 short packet header. 4352 0 1 2 3 4353 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 4354 +-+-+-+-+-+-+-+-+ 4355 |0|1|S|R|R|K|P P| 4356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4357 | Destination Connection ID (0..160) ... 4358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4359 | Packet Number (8/16/24/32) ... 4360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4361 | Protected Payload (*) ... 4362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4364 Figure 14: Short Header Packet Format 4366 The short header can be used after the version and 1-RTT keys are 4367 negotiated. Packets that use the short header contain the following 4368 fields: 4370 Header Form: The most significant bit (0x80) of byte 0 is set to 0 4371 for the short header. 4373 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4374 containing a zero value for this bit are not valid packets in this 4375 version and MUST be discarded. 4377 Spin Bit (S): The third most significant bit (0x20) of byte 0 is the 4378 latency spin bit, set as described in Section 17.3.1. 4380 Reserved Bits (R): The next two bits (those with a mask of 0x18) of 4381 byte 0 are reserved. These bits are protected using header 4382 protection (see Section 5.4 of [QUIC-TLS]). The value included 4383 prior to protection MUST be set to 0. An endpoint MUST treat 4384 receipt of a packet that has a non-zero value for these bits, 4385 after removing both packet and header protection, as a connection 4386 error of type PROTOCOL_VIOLATION. Discarding such a packet after 4387 only removing header protection can expose the endpoint to attacks 4388 (see Section 9.3 of [QUIC-TLS]). 4390 Key Phase (K): The next bit (0x04) of byte 0 indicates the key 4391 phase, which allows a recipient of a packet to identify the packet 4392 protection keys that are used to protect the packet. See 4393 [QUIC-TLS] for details. This bit is protected using header 4394 protection (see Section 5.4 of [QUIC-TLS]). 4396 Packet Number Length (P): The least significant two bits (those with 4397 a mask of 0x03) of byte 0 contain the length of the packet number, 4398 encoded as an unsigned, two-bit integer that is one less than the 4399 length of the packet number field in bytes. That is, the length 4400 of the packet number field is the value of this field, plus one. 4401 These bits are protected using header protection (see Section 5.4 4402 of [QUIC-TLS]). 4404 Destination Connection ID: The Destination Connection ID is a 4405 connection ID that is chosen by the intended recipient of the 4406 packet. See Section 5.1 for more details. 4408 Packet Number: The packet number field is 1 to 4 bytes long. The 4409 packet number has confidentiality protection separate from packet 4410 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4411 of the packet number field is encoded in Packet Number Length 4412 field. See Section 17.1 for details. 4414 Protected Payload: Packets with a short header always include a 4415 1-RTT protected payload. 4417 The header form bit and the connection ID field of a short header 4418 packet are version-independent. The remaining fields are specific to 4419 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 4420 packets from different versions of QUIC are interpreted. 4422 17.3.1. Latency Spin Bit 4424 The latency spin bit enables passive latency monitoring from 4425 observation points on the network path throughout the duration of a 4426 connection. The spin bit is only present in the short packet header, 4427 since it is possible to measure the initial RTT of a connection by 4428 observing the handshake. Therefore, the spin bit is available after 4429 version negotiation and connection establishment are completed. On- 4430 path measurement and use of the latency spin bit is further discussed 4431 in [QUIC-MANAGEABILITY]. 4433 The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that 4434 chooses to support the spin bit MUST implement it as specified in 4435 this section. 4437 Each endpoint unilaterally decides if the spin bit is enabled or 4438 disabled for a connection. Implementations MUST allow administrators 4439 of clients and servers to disable the spin bit either globally or on 4440 a per-connection basis. Even when the spin bit is not disabled by 4441 the administrator, implementations MUST disable the spin bit for a 4442 given connection with a certain likelihood. The random selection 4443 process SHOULD be designed such that on average the spin bit is 4444 disabled for at least one eighth of network paths. The selection 4445 process performed at the beginning of the connection SHOULD be 4446 applied for all paths used by the connection. 4448 In case multiple connections share the same network path, as 4449 determined by having the same source and destination IP address and 4450 UDP ports, endpoints should try to co-ordinate across all connections 4451 to ensure a clear signal to any on-path measurement points. 4453 When the spin bit is disabled, endpoints MAY set the spin bit to any 4454 value, and MUST ignore any incoming value. It is RECOMMENDED that 4455 endpoints set the spin bit to a random value either chosen 4456 independently for each packet or chosen independently for each 4457 connection ID. 4459 If the spin bit is enabled for the connection, the endpoint maintains 4460 a spin value and sets the spin bit in the short header to the 4461 currently stored value when a packet with a short header is sent out. 4462 The spin value is initialized to 0 in the endpoint at connection 4463 start. Each endpoint also remembers the highest packet number seen 4464 from its peer on the connection. 4466 When a server receives a short header packet that increments the 4467 highest packet number seen by the server from the client, it sets the 4468 spin value to be equal to the spin bit in the received packet. 4470 When a client receives a short header packet that increments the 4471 highest packet number seen by the client from the server, it sets the 4472 spin value to the inverse of the spin bit in the received packet. 4474 An endpoint resets its spin value to zero when sending the first 4475 packet of a given connection with a new connection ID. This reduces 4476 the risk that transient spin bit state can be used to link flows 4477 across connection migration or ID change. 4479 With this mechanism, the server reflects the spin value received, 4480 while the client 'spins' it after one RTT. On-path observers can 4481 measure the time between two spin bit toggle events to estimate the 4482 end-to-end RTT of a connection. 4484 18. Transport Parameter Encoding 4486 The format of the transport parameters is the TransportParameters 4487 struct from Figure 15. This is described using the presentation 4488 language from Section 3 of [TLS13]. 4490 enum { 4491 original_connection_id(0), 4492 idle_timeout(1), 4493 stateless_reset_token(2), 4494 max_packet_size(3), 4495 initial_max_data(4), 4496 initial_max_stream_data_bidi_local(5), 4497 initial_max_stream_data_bidi_remote(6), 4498 initial_max_stream_data_uni(7), 4499 initial_max_streams_bidi(8), 4500 initial_max_streams_uni(9), 4501 ack_delay_exponent(10), 4502 max_ack_delay(11), 4503 disable_migration(12), 4504 preferred_address(13), 4505 active_connection_id_limit(14), 4506 (65535) 4507 } TransportParameterId; 4509 struct { 4510 TransportParameterId parameter; 4511 opaque value<0..2^16-1>; 4512 } TransportParameter; 4514 TransportParameter TransportParameters<0..2^16-1>; 4516 Figure 15: Definition of TransportParameters 4518 The "extension_data" field of the quic_transport_parameters extension 4519 defined in [QUIC-TLS] contains a TransportParameters value. TLS 4520 encoding rules are therefore used to describe the encoding of 4521 transport parameters. 4523 QUIC encodes transport parameters into a sequence of bytes, which are 4524 then included in the cryptographic handshake. 4526 18.1. Transport Parameter Definitions 4528 This section details the transport parameters defined in this 4529 document. 4531 Many transport parameters listed here have integer values. Those 4532 transport parameters that are identified as integers use a variable- 4533 length integer encoding (see Section 16) and have a default value of 4534 0 if the transport parameter is absent, unless otherwise stated. 4536 The following transport parameters are defined: 4538 original_connection_id (0x0000): The value of the Destination 4539 Connection ID field from the first Initial packet sent by the 4540 client. This transport parameter is only sent by a server. A 4541 server MUST include the original_connection_id transport parameter 4542 if it sent a Retry packet. 4544 idle_timeout (0x0001): The idle timeout is a value in milliseconds 4545 that is encoded as an integer; see (Section 10.2). If this 4546 parameter is absent or zero then the idle timeout is disabled. 4548 stateless_reset_token (0x0002): A stateless reset token is used in 4549 verifying a stateless reset; see Section 10.4. This parameter is 4550 a sequence of 16 bytes. This transport parameter MUST NOT be sent 4551 by a client, but MAY be sent by a server. A server that does not 4552 send this transport parameter cannot use stateless reset 4553 (Section 10.4) for the connection ID negotiated during the 4554 handshake. 4556 max_packet_size (0x0003): The maximum packet size parameter is an 4557 integer value that limits the size of packets that the endpoint is 4558 willing to receive. This indicates that packets larger than this 4559 limit will be dropped. The default for this parameter is the 4560 maximum permitted UDP payload of 65527. Values below 1200 are 4561 invalid. This limit only applies to protected packets 4562 (Section 12.1). 4564 initial_max_data (0x0004): The initial maximum data parameter is an 4565 integer value that contains the initial value for the maximum 4566 amount of data that can be sent on the connection. This is 4567 equivalent to sending a MAX_DATA (Section 19.9) for the connection 4568 immediately after completing the handshake. 4570 initial_max_stream_data_bidi_local (0x0005): This parameter is an 4571 integer value specifying the initial flow control limit for 4572 locally-initiated bidirectional streams. This limit applies to 4573 newly created bidirectional streams opened by the endpoint that 4574 sends the transport parameter. In client transport parameters, 4575 this applies to streams with an identifier with the least 4576 significant two bits set to 0x0; in server transport parameters, 4577 this applies to streams with the least significant two bits set to 4578 0x1. 4580 initial_max_stream_data_bidi_remote (0x0006): This parameter is an 4581 integer value specifying the initial flow control limit for peer- 4582 initiated bidirectional streams. This limit applies to newly 4583 created bidirectional streams opened by the endpoint that receives 4584 the transport parameter. In client transport parameters, this 4585 applies to streams with an identifier with the least significant 4586 two bits set to 0x1; in server transport parameters, this applies 4587 to streams with the least significant two bits set to 0x0. 4589 initial_max_stream_data_uni (0x0007): This parameter is an integer 4590 value specifying the initial flow control limit for unidirectional 4591 streams. This limit applies to newly created unidirectional 4592 streams opened by the endpoint that receives the transport 4593 parameter. In client transport parameters, this applies to 4594 streams with an identifier with the least significant two bits set 4595 to 0x3; in server transport parameters, this applies to streams 4596 with the least significant two bits set to 0x2. 4598 initial_max_streams_bidi (0x0008): The initial maximum bidirectional 4599 streams parameter is an integer value that contains the initial 4600 maximum number of bidirectional streams the peer may initiate. If 4601 this parameter is absent or zero, the peer cannot open 4602 bidirectional streams until a MAX_STREAMS frame is sent. Setting 4603 this parameter is equivalent to sending a MAX_STREAMS 4604 (Section 19.11) of the corresponding type with the same value. 4606 initial_max_streams_uni (0x0009): The initial maximum unidirectional 4607 streams parameter is an integer value that contains the initial 4608 maximum number of unidirectional streams the peer may initiate. 4609 If this parameter is absent or zero, the peer cannot open 4610 unidirectional streams until a MAX_STREAMS frame is sent. Setting 4611 this parameter is equivalent to sending a MAX_STREAMS 4612 (Section 19.11) of the corresponding type with the same value. 4614 ack_delay_exponent (0x000a): The ACK delay exponent is an integer 4615 value indicating an exponent used to decode the ACK Delay field in 4616 the ACK frame (Section 19.3). If this value is absent, a default 4617 value of 3 is assumed (indicating a multiplier of 8). Values 4618 above 20 are invalid. 4620 max_ack_delay (0x000b): The maximum ACK delay is an integer value 4621 indicating the maximum amount of time in milliseconds by which the 4622 endpoint will delay sending acknowledgments. This value SHOULD 4623 include the receiver's expected delays in alarms firing. For 4624 example, if a receiver sets a timer for 5ms and alarms commonly 4625 fire up to 1ms late, then it should send a max_ack_delay of 6ms. 4626 If this value is absent, a default of 25 milliseconds is assumed. 4627 Values of 2^14 or greater are invalid. 4629 disable_migration (0x000c): The disable migration transport 4630 parameter is included if the endpoint does not support connection 4631 migration (Section 9). Peers of an endpoint that sets this 4632 transport parameter MUST NOT send any packets, including probing 4633 packets (Section 9.1), from a local address or port other than 4634 that used to perform the handshake. This parameter is a zero- 4635 length value. 4637 preferred_address (0x000d): The server's preferred address is used 4638 to effect a change in server address at the end of the handshake, 4639 as described in Section 9.6. The format of this transport 4640 parameter is the PreferredAddress struct shown in Figure 16. This 4641 transport parameter is only sent by a server. Servers MAY choose 4642 to only send a preferred address of one address family by sending 4643 an all-zero address and port (0.0.0.0:0 or ::.0) for the other 4644 family. 4646 struct { 4647 opaque ipv4Address[4]; 4648 uint16 ipv4Port; 4649 opaque ipv6Address[16]; 4650 uint16 ipv6Port; 4651 opaque connectionId<0..18>; 4652 opaque statelessResetToken[16]; 4653 } PreferredAddress; 4655 Figure 16: Preferred Address format 4657 active_connection_id_limit (0x000e): The maximum number of 4658 connection IDs from the peer that an endpoint is willing to store. 4659 This value includes only connection IDs sent in NEW_CONNECTION_ID 4660 frames. If this parameter is absent, a default of 0 is assumed. 4662 If present, transport parameters that set initial flow control limits 4663 (initial_max_stream_data_bidi_local, 4664 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 4665 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 4666 every stream of the corresponding type immediately after opening. If 4667 the transport parameter is absent, streams of that type start with a 4668 flow control limit of 0. 4670 A client MUST NOT include an original connection ID, a stateless 4671 reset token, or a preferred address. A server MUST treat receipt of 4672 any of these transport parameters as a connection error of type 4673 TRANSPORT_PARAMETER_ERROR. 4675 19. Frame Types and Formats 4677 As described in Section 12.4, packets contain one or more frames. 4678 This section describes the format and semantics of the core QUIC 4679 frame types. 4681 19.1. PADDING Frame 4683 The PADDING frame (type=0x00) has no semantic value. PADDING frames 4684 can be used to increase the size of a packet. Padding can be used to 4685 increase an initial client packet to the minimum required size, or to 4686 provide protection against traffic analysis for protected packets. 4688 A PADDING frame has no content. That is, a PADDING frame consists of 4689 the single byte that identifies the frame as a PADDING frame. 4691 19.2. PING Frame 4693 Endpoints can use PING frames (type=0x01) to verify that their peers 4694 are still alive or to check reachability to the peer. The PING frame 4695 contains no additional fields. 4697 The receiver of a PING frame simply needs to acknowledge the packet 4698 containing this frame. 4700 The PING frame can be used to keep a connection alive when an 4701 application or application protocol wishes to prevent the connection 4702 from timing out. An application protocol SHOULD provide guidance 4703 about the conditions under which generating a PING is recommended. 4704 This guidance SHOULD indicate whether it is the client or the server 4705 that is expected to send the PING. Having both endpoints send PING 4706 frames without coordination can produce an excessive number of 4707 packets and poor performance. 4709 A connection will time out if no packets are sent or received for a 4710 period longer than the time specified in the idle_timeout transport 4711 parameter (see Section 10). However, state in middleboxes might time 4712 out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 4713 minute timeout interval, experience shows that sending packets every 4714 15 to 30 seconds is necessary to prevent the majority of middleboxes 4715 from losing state for UDP flows. 4717 19.3. ACK Frames 4719 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 4720 packets they have received and processed. The ACK frame contains one 4721 or more ACK Ranges. ACK Ranges identify acknowledged packets. If 4722 the frame type is 0x03, ACK frames also contain the sum of QUIC 4723 packets with associated ECN marks received on the connection up until 4724 this point. QUIC implementations MUST properly handle both types 4725 and, if they have enabled ECN for packets they send, they SHOULD use 4726 the information in the ECN section to manage their congestion state. 4728 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 4729 remains acknowledged, even if it does not appear in a future ACK 4730 frame. This is unlike TCP SACKs ([RFC2018]). 4732 It is expected that a sender will reuse the same packet number across 4733 different packet number spaces. ACK frames only acknowledge the 4734 packet numbers that were transmitted by the sender in the same packet 4735 number space of the packet that the ACK was received in. 4737 Version Negotiation and Retry packets cannot be acknowledged because 4738 they do not contain a packet number. Rather than relying on ACK 4739 frames, these packets are implicitly acknowledged by the next Initial 4740 packet sent by the client. 4742 An ACK frame is as follows: 4744 0 1 2 3 4745 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 4746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4747 | Largest Acknowledged (i) ... 4748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4749 | ACK Delay (i) ... 4750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4751 | ACK Range Count (i) ... 4752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4753 | First ACK Range (i) ... 4754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4755 | ACK Ranges (*) ... 4756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4757 | [ECN Counts] ... 4758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 Figure 17: ACK Frame Format 4762 ACK frames contain the following fields: 4764 Largest Acknowledged: A variable-length integer representing the 4765 largest packet number the peer is acknowledging; this is usually 4766 the largest packet number that the peer has received prior to 4767 generating the ACK frame. Unlike the packet number in the QUIC 4768 long or short header, the value in an ACK frame is not truncated. 4770 ACK Delay: A variable-length integer representing the time delta in 4771 microseconds between when this ACK was sent and when the largest 4772 acknowledged packet, as indicated in the Largest Acknowledged 4773 field, was received by this peer. The value of the ACK Delay 4774 field is scaled by multiplying the encoded value by 2 to the power 4775 of the value of the "ack_delay_exponent" transport parameter set 4776 by the sender of the ACK frame (see Section 18.1). Scaling in 4777 this fashion allows for a larger range of values with a shorter 4778 encoding at the cost of lower resolution. Because the receiver 4779 doesn't use the ACK Delay for Initial and Handshake packets, a 4780 sender SHOULD send a value of 0. 4782 ACK Range Count: A variable-length integer specifying the number of 4783 Gap and ACK Range fields in the frame. 4785 First ACK Range: A variable-length integer indicating the number of 4786 contiguous packets preceding the Largest Acknowledged that are 4787 being acknowledged. The First ACK Range is encoded as an ACK 4788 Range (see Section 19.3.1) starting from the Largest Acknowledged. 4789 That is, the smallest packet acknowledged in the range is 4790 determined by subtracting the First ACK Range value from the 4791 Largest Acknowledged. 4793 ACK Ranges: Contains additional ranges of packets which are 4794 alternately not acknowledged (Gap) and acknowledged (ACK Range); 4795 see Section 19.3.1. 4797 ECN Counts: The three ECN Counts; see Section 19.3.2. 4799 19.3.1. ACK Ranges 4801 The ACK Ranges field consists of alternating Gap and ACK Range values 4802 in descending packet number order. The number of Gap and ACK Range 4803 values is determined by the ACK Range Count field; one of each value 4804 is present for each value in the ACK Range Count field. 4806 ACK Ranges are structured as follows: 4808 0 1 2 3 4809 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 4810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4811 | [Gap (i)] ... 4812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4813 | [ACK Range (i)] ... 4814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4815 | [Gap (i)] ... 4816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4817 | [ACK Range (i)] ... 4818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4819 ... 4820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4821 | [Gap (i)] ... 4822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4823 | [ACK Range (i)] ... 4824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 Figure 18: ACK Ranges 4828 The fields that form the ACK Ranges are: 4830 Gap (repeated): A variable-length integer indicating the number of 4831 contiguous unacknowledged packets preceding the packet number one 4832 lower than the smallest in the preceding ACK Range. 4834 ACK Range (repeated): A variable-length integer indicating the 4835 number of contiguous acknowledged packets preceding the largest 4836 packet number, as determined by the preceding Gap. 4838 Gap and ACK Range value use a relative integer encoding for 4839 efficiency. Though each encoded value is positive, the values are 4840 subtracted, so that each ACK Range describes progressively lower- 4841 numbered packets. 4843 Each ACK Range acknowledges a contiguous range of packets by 4844 indicating the number of acknowledged packets that precede the 4845 largest packet number in that range. A value of zero indicates that 4846 only the largest packet number is acknowledged. Larger ACK Range 4847 values indicate a larger range, with corresponding lower values for 4848 the smallest packet number in the range. Thus, given a largest 4849 packet number for the range, the smallest value is determined by the 4850 formula: 4852 smallest = largest - ack_range 4854 An ACK Range acknowledges all packets between the smallest packet 4855 number and the largest, inclusive. 4857 The largest value for an ACK Range is determined by cumulatively 4858 subtracting the size of all preceding ACK Ranges and Gaps. 4860 Each Gap indicates a range of packets that are not being 4861 acknowledged. The number of packets in the gap is one higher than 4862 the encoded value of the Gap field. 4864 The value of the Gap field establishes the largest packet number 4865 value for the subsequent ACK Range using the following formula: 4867 largest = previous_smallest - gap - 2 4869 If any computed packet number is negative, an endpoint MUST generate 4870 a connection error of type FRAME_ENCODING_ERROR indicating an error 4871 in an ACK frame. 4873 19.3.2. ECN Counts 4875 The ACK frame uses the least significant bit (that is, type 0x03) to 4876 indicate ECN feedback and report receipt of QUIC packets with 4877 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 4878 header. ECN Counts are only present when the ACK frame type is 0x03. 4880 ECN Counts are only parsed when the ACK frame type is 0x03. There 4881 are 3 ECN counts, as follows: 4883 0 1 2 3 4884 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 4885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4886 | ECT(0) Count (i) ... 4887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4888 | ECT(1) Count (i) ... 4889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4890 | ECN-CE Count (i) ... 4891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4893 The three ECN Counts are: 4895 ECT(0) Count: A variable-length integer representing the total 4896 number of packets received with the ECT(0) codepoint. 4898 ECT(1) Count: A variable-length integer representing the total 4899 number of packets received with the ECT(1) codepoint. 4901 CE Count: A variable-length integer representing the total number of 4902 packets received with the CE codepoint. 4904 ECN counts are maintained separately for each packet number space. 4906 19.4. RESET_STREAM Frame 4908 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 4909 terminate the sending part of a stream. 4911 After sending a RESET_STREAM, an endpoint ceases transmission and 4912 retransmission of STREAM frames on the identified stream. A receiver 4913 of RESET_STREAM can discard any data that it already received on that 4914 stream. 4916 An endpoint that receives a RESET_STREAM frame for a send-only stream 4917 MUST terminate the connection with error STREAM_STATE_ERROR. 4919 The RESET_STREAM frame is as follows: 4921 0 1 2 3 4922 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 4923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4924 | Stream ID (i) ... 4925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4926 | Application Error Code (i) ... 4927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4928 | Final Size (i) ... 4929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4931 RESET_STREAM frames contain the following fields: 4933 Stream ID: A variable-length integer encoding of the Stream ID of 4934 the stream being terminated. 4936 Application Protocol Error Code: A variable-length integer 4937 containing the application protocol error code (see Section 20.1) 4938 which indicates why the stream is being closed. 4940 Final Size: A variable-length integer indicating the final size of 4941 the stream by the RESET_STREAM sender, in unit of bytes. 4943 19.5. STOP_SENDING Frame 4945 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 4946 incoming data is being discarded on receipt at application request. 4947 STOP_SENDING requests that a peer cease transmission on a stream. 4949 A STOP_SENDING frame can be sent for streams in the Recv or Size 4950 Known states (see Section 3.1). Receiving a STOP_SENDING frame for a 4951 locally-initiated stream that has not yet been created MUST be 4952 treated as a connection error of type STREAM_STATE_ERROR. An 4953 endpoint that receives a STOP_SENDING frame for a receive-only stream 4954 MUST terminate the connection with error STREAM_STATE_ERROR. 4956 The STOP_SENDING frame is as follows: 4958 0 1 2 3 4959 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 4960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4961 | Stream ID (i) ... 4962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4963 | Application Error Code (i) ... 4964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4966 STOP_SENDING frames contain the following fields: 4968 Stream ID: A variable-length integer carrying the Stream ID of the 4969 stream being ignored. 4971 Application Error Code: A variable-length integer containing the 4972 application-specified reason the sender is ignoring the stream 4973 (see Section 20.1). 4975 19.6. CRYPTO Frame 4977 The CRYPTO frame (type=0x06) is used to transmit cryptographic 4978 handshake messages. It can be sent in all packet types. The CRYPTO 4979 frame offers the cryptographic protocol an in-order stream of bytes. 4980 CRYPTO frames are functionally identical to STREAM frames, except 4981 that they do not bear a stream identifier; they are not flow 4982 controlled; and they do not carry markers for optional offset, 4983 optional length, and the end of the stream. 4985 The CRYPTO frame is as follows: 4987 0 1 2 3 4988 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 4989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4990 | Offset (i) ... 4991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4992 | Length (i) ... 4993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4994 | Crypto Data (*) ... 4995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4997 Figure 19: CRYPTO Frame Format 4999 CRYPTO frames contain the following fields: 5001 Offset: A variable-length integer specifying the byte offset in the 5002 stream for the data in this CRYPTO frame. 5004 Length: A variable-length integer specifying the length of the 5005 Crypto Data field in this CRYPTO frame. 5007 Crypto Data: The cryptographic message data. 5009 There is a separate flow of cryptographic handshake data in each 5010 encryption level, each of which starts at an offset of 0. This 5011 implies that each encryption level is treated as a separate CRYPTO 5012 stream of data. 5014 Unlike STREAM frames, which include a Stream ID indicating to which 5015 stream the data belongs, the CRYPTO frame carries data for a single 5016 stream per encryption level. The stream does not have an explicit 5017 end, so CRYPTO frames do not have a FIN bit. 5019 19.7. NEW_TOKEN Frame 5021 A server sends a NEW_TOKEN frame (type=0x07) to provide the client 5022 with a token to send in the header of an Initial packet for a future 5023 connection. 5025 The NEW_TOKEN frame is as follows: 5027 0 1 2 3 5028 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 5029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5030 | Token Length (i) ... 5031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5032 | Token (*) ... 5033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5035 NEW_TOKEN frames contain the following fields: 5037 Token Length: A variable-length integer specifying the length of the 5038 token in bytes. 5040 Token: An opaque blob that the client may use with a future Initial 5041 packet. 5043 19.8. STREAM Frames 5045 STREAM frames implicitly create a stream and carry stream data. The 5046 STREAM frame takes the form 0b00001XXX (or the set of values from 5047 0x08 to 0x0f). The value of the three low-order bits of the frame 5048 type determines the fields that are present in the frame. 5050 o The OFF bit (0x04) in the frame type is set to indicate that there 5051 is an Offset field present. When set to 1, the Offset field is 5052 present. When set to 0, the Offset field is absent and the Stream 5053 Data starts at an offset of 0 (that is, the frame contains the 5054 first bytes of the stream, or the end of a stream that includes no 5055 data). 5057 o The LEN bit (0x02) in the frame type is set to indicate that there 5058 is a Length field present. If this bit is set to 0, the Length 5059 field is absent and the Stream Data field extends to the end of 5060 the packet. If this bit is set to 1, the Length field is present. 5062 o The FIN bit (0x01) of the frame type is set only on frames that 5063 contain the final size of the stream. Setting this bit indicates 5064 that the frame marks the end of the stream. 5066 An endpoint that receives a STREAM frame for a send-only stream MUST 5067 terminate the connection with error STREAM_STATE_ERROR. 5069 The STREAM frames are as follows: 5071 0 1 2 3 5072 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 5073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5074 | Stream ID (i) ... 5075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5076 | [Offset (i)] ... 5077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5078 | [Length (i)] ... 5079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5080 | Stream Data (*) ... 5081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5083 Figure 20: STREAM Frame Format 5085 STREAM frames contain the following fields: 5087 Stream ID: A variable-length integer indicating the stream ID of the 5088 stream (see Section 2.1). 5090 Offset: A variable-length integer specifying the byte offset in the 5091 stream for the data in this STREAM frame. This field is present 5092 when the OFF bit is set to 1. When the Offset field is absent, 5093 the offset is 0. 5095 Length: A variable-length integer specifying the length of the 5096 Stream Data field in this STREAM frame. This field is present 5097 when the LEN bit is set to 1. When the LEN bit is set to 0, the 5098 Stream Data field consumes all the remaining bytes in the packet. 5100 Stream Data: The bytes from the designated stream to be delivered. 5102 When a Stream Data field has a length of 0, the offset in the STREAM 5103 frame is the offset of the next byte that would be sent. 5105 The first byte in the stream has an offset of 0. The largest offset 5106 delivered on a stream - the sum of the offset and data length - 5107 cannot exceed 2^62-1, as it is not possible to provide flow control 5108 credit for that data. Receipt of a frame that exceeds this limit 5109 will be treated as a connection error of type FLOW_CONTROL_ERROR. 5111 19.9. MAX_DATA Frame 5113 The MAX_DATA frame (type=0x10) is used in flow control to inform the 5114 peer of the maximum amount of data that can be sent on the connection 5115 as a whole. 5117 The MAX_DATA frame is as follows: 5119 0 1 2 3 5120 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 5121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5122 | Maximum Data (i) ... 5123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5125 MAX_DATA frames contain the following fields: 5127 Maximum Data: A variable-length integer indicating the maximum 5128 amount of data that can be sent on the entire connection, in units 5129 of bytes. 5131 All data sent in STREAM frames counts toward this limit. The sum of 5132 the largest received offsets on all streams - including streams in 5133 terminal states - MUST NOT exceed the value advertised by a receiver. 5134 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 5135 error if it receives more data than the maximum data value that it 5136 has sent, unless this is a result of a change in the initial limits 5137 (see Section 7.3.1). 5139 19.10. MAX_STREAM_DATA Frame 5141 The MAX_STREAM_DATA frame (type=0x11) is used in flow control to 5142 inform a peer of the maximum amount of data that can be sent on a 5143 stream. 5145 A MAX_STREAM_DATA frame can be sent for streams in the Recv state 5146 (see Section 3.1). Receiving a MAX_STREAM_DATA frame for a locally- 5147 initiated stream that has not yet been created MUST be treated as a 5148 connection error of type STREAM_STATE_ERROR. An endpoint that 5149 receives a MAX_STREAM_DATA frame for a receive-only stream MUST 5150 terminate the connection with error STREAM_STATE_ERROR. 5152 The MAX_STREAM_DATA frame is as follows: 5154 0 1 2 3 5155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5157 | Stream ID (i) ... 5158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5159 | Maximum Stream Data (i) ... 5160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5162 MAX_STREAM_DATA frames contain the following fields: 5164 Stream ID: The stream ID of the stream that is affected encoded as a 5165 variable-length integer. 5167 Maximum Stream Data: A variable-length integer indicating the 5168 maximum amount of data that can be sent on the identified stream, 5169 in units of bytes. 5171 When counting data toward this limit, an endpoint accounts for the 5172 largest received offset of data that is sent or received on the 5173 stream. Loss or reordering can mean that the largest received offset 5174 on a stream can be greater than the total size of data received on 5175 that stream. Receiving STREAM frames might not increase the largest 5176 received offset. 5178 The data sent on a stream MUST NOT exceed the largest maximum stream 5179 data value advertised by the receiver. An endpoint MUST terminate a 5180 connection with a FLOW_CONTROL_ERROR error if it receives more data 5181 than the largest maximum stream data that it has sent for the 5182 affected stream, unless this is a result of a change in the initial 5183 limits (see Section 7.3.1). 5185 19.11. MAX_STREAMS Frames 5187 The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the 5188 cumulative number of streams of a given type it is permitted to open. 5189 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 5190 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 5191 unidirectional streams. 5193 The MAX_STREAMS frames are as follows: 5195 0 1 2 3 5196 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 5197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5198 | Maximum Streams (i) ... 5199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5201 MAX_STREAMS frames contain the following fields: 5203 Maximum Streams: A count of the cumulative number of streams of the 5204 corresponding type that can be opened over the lifetime of the 5205 connection. 5207 Loss or reordering can cause a MAX_STREAMS frame to be received which 5208 states a lower stream limit than an endpoint has previously received. 5209 MAX_STREAMS frames which do not increase the stream limit MUST be 5210 ignored. 5212 An endpoint MUST NOT open more streams than permitted by the current 5213 stream limit set by its peer. For instance, a server that receives a 5214 unidirectional stream limit of 3 is permitted to open stream 3, 7, 5215 and 11, but not stream 15. An endpoint MUST terminate a connection 5216 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 5217 permitted. 5219 Note that these frames (and the corresponding transport parameters) 5220 do not describe the number of streams that can be opened 5221 concurrently. The limit includes streams that have been closed as 5222 well as those that are open. 5224 19.12. DATA_BLOCKED Frame 5226 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 5227 to send data, but is unable to due to connection-level flow control 5228 (see Section 4). DATA_BLOCKED frames can be used as input to tuning 5229 of flow control algorithms (see Section 4.2). 5231 The DATA_BLOCKED frame is as follows: 5233 0 1 2 3 5234 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 5235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5236 | Data Limit (i) ... 5237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5239 DATA_BLOCKED frames contain the following fields: 5241 Data Limit: A variable-length integer indicating the connection- 5242 level limit at which blocking occurred. 5244 19.13. STREAM_DATA_BLOCKED Frame 5246 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 5247 wishes to send data, but is unable to due to stream-level flow 5248 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 5250 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 5251 stream MUST terminate the connection with error STREAM_STATE_ERROR. 5253 The STREAM_DATA_BLOCKED frame is as follows: 5255 0 1 2 3 5256 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 5257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5258 | Stream ID (i) ... 5259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5260 | Stream Data Limit (i) ... 5261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5263 STREAM_DATA_BLOCKED frames contain the following fields: 5265 Stream ID: A variable-length integer indicating the stream which is 5266 flow control blocked. 5268 Stream Data Limit: A variable-length integer indicating the offset 5269 of the stream at which the blocking occurred. 5271 19.14. STREAMS_BLOCKED Frames 5273 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 5274 it wishes to open a stream, but is unable to due to the maximum 5275 stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED 5276 frame of type 0x16 is used to indicate reaching the bidirectional 5277 stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates 5278 reaching the unidirectional stream limit. 5280 A STREAMS_BLOCKED frame does not open the stream, but informs the 5281 peer that a new stream was needed and the stream limit prevented the 5282 creation of the stream. 5284 The STREAMS_BLOCKED frames are as follows: 5286 0 1 2 3 5287 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 5288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5289 | Stream Limit (i) ... 5290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5292 STREAMS_BLOCKED frames contain the following fields: 5294 Stream Limit: A variable-length integer indicating the stream limit 5295 at the time the frame was sent. 5297 19.15. NEW_CONNECTION_ID Frame 5299 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 5300 its peer with alternative connection IDs that can be used to break 5301 linkability when migrating connections (see Section 9.5). 5303 The NEW_CONNECTION_ID frame is as follows: 5305 0 1 2 3 5306 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 5307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5308 | Sequence Number (i) ... 5309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5310 | Retire Prior To (i) ... 5311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5312 | Length (8) | | 5313 +-+-+-+-+-+-+-+-+ Connection ID (8..160) + 5314 | ... 5315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5316 | | 5317 + + 5318 | | 5319 + Stateless Reset Token (128) + 5320 | | 5321 + + 5322 | | 5323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5325 NEW_CONNECTION_ID frames contain the following fields: 5327 Sequence Number: The sequence number assigned to the connection ID 5328 by the sender. See Section 5.1.1. 5330 Retire Prior To: A variable-length integer indicating which 5331 connection IDs should be retired. See Section 5.1.2. 5333 Length: An 8-bit unsigned integer containing the length of the 5334 connection ID. Values less than 1 and greater than 20 are invalid 5335 and MUST be treated as a connection error of type 5336 PROTOCOL_VIOLATION. 5338 Connection ID: A connection ID of the specified length. 5340 Stateless Reset Token: A 128-bit value that will be used for a 5341 stateless reset when the associated connection ID is used (see 5342 Section 10.4). 5344 An endpoint MUST NOT send this frame if it currently requires that 5345 its peer send packets with a zero-length Destination Connection ID. 5346 Changing the length of a connection ID to or from zero-length makes 5347 it difficult to identify when the value of the connection ID changed. 5348 An endpoint that is sending packets with a zero-length Destination 5349 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 5350 connection error of type PROTOCOL_VIOLATION. 5352 Transmission errors, timeouts and retransmissions might cause the 5353 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 5354 of the same frame multiple times MUST NOT be treated as a connection 5355 error. A receiver can use the sequence number supplied in the 5356 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 5358 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 5359 previously issued connection ID with a different Stateless Reset 5360 Token or a different sequence number, or if a sequence number is used 5361 for different connection IDs, the endpoint MAY treat that receipt as 5362 a connection error of type PROTOCOL_VIOLATION. 5364 The Retire Prior To field is a request for the peer to retire all 5365 connection IDs with a sequence number less than the specified value. 5366 This includes the initial and preferred_address transport parameter 5367 connection IDs. The peer SHOULD retire the corresponding connection 5368 IDs and send the corresponding RETIRE_CONNECTION_ID frames in a 5369 timely manner. 5371 The Retire Prior To field MUST be less than or equal to the Sequence 5372 Number field. Receiving a value greater than the Sequence Number 5373 MUST be treated as a connection error of type PROTOCOL_VIOLATION. 5375 Once a sender indicates a Retire Prior To value, smaller values sent 5376 in subsequent NEW_CONNECTION_ID frames have no effect. A receiver 5377 MUST ignore any Retire Prior To fields that do not increase the 5378 largest received Retire Prior To value. 5380 19.16. RETIRE_CONNECTION_ID Frame 5382 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 5383 indicate that it will no longer use a connection ID that was issued 5384 by its peer. This may include the connection ID provided during the 5385 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 5386 request to the peer to send additional connection IDs for future use 5387 (see Section 5.1). New connection IDs can be delivered to a peer 5388 using the NEW_CONNECTION_ID frame (Section 19.15). 5390 Retiring a connection ID invalidates the stateless reset token 5391 associated with that connection ID. 5393 The RETIRE_CONNECTION_ID frame is as follows: 5395 0 1 2 3 5396 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 5397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5398 | Sequence Number (i) ... 5399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5401 RETIRE_CONNECTION_ID frames contain the following fields: 5403 Sequence Number: The sequence number of the connection ID being 5404 retired. See Section 5.1.2. 5406 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 5407 greater than any previously sent to the peer MAY be treated as a 5408 connection error of type PROTOCOL_VIOLATION. 5410 The sequence number specified in a RETIRE_CONNECTION_ID frame MUST 5411 NOT refer to the Destination Connection ID field of the packet in 5412 which the frame is contained. The peer MAY treat this as a 5413 connection error of type PROTOCOL_VIOLATION. 5415 An endpoint cannot send this frame if it was provided with a zero- 5416 length connection ID by its peer. An endpoint that provides a zero- 5417 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 5418 frame as a connection error of type PROTOCOL_VIOLATION. 5420 19.17. PATH_CHALLENGE Frame 5422 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 5423 reachability to the peer and for path validation during connection 5424 migration. 5426 The PATH_CHALLENGE frames are as follows: 5428 0 1 2 3 5429 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 5430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5431 | | 5432 + Data (64) + 5433 | | 5434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5436 PATH_CHALLENGE frames contain the following fields: 5438 Data: This 8-byte field contains arbitrary data. 5440 A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is 5441 sufficient to ensure that it is easier to receive the packet than it 5442 is to guess the value correctly. 5444 The recipient of this frame MUST generate a PATH_RESPONSE frame 5445 (Section 19.18) containing the same Data. 5447 19.18. PATH_RESPONSE Frame 5449 The PATH_RESPONSE frame (type=0x1b) is sent in response to a 5450 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 5451 frame (Section 19.17). 5453 If the content of a PATH_RESPONSE frame does not match the content of 5454 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 5455 MAY generate a connection error of type PROTOCOL_VIOLATION. 5457 19.19. CONNECTION_CLOSE Frames 5459 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 5460 notify its peer that the connection is being closed. The 5461 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 5462 at only the QUIC layer, or the absence of errors (with the NO_ERROR 5463 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 5464 signal an error with the application that uses QUIC. 5466 If there are open streams that haven't been explicitly closed, they 5467 are implicitly closed when the connection is closed. 5469 The CONNECTION_CLOSE frames are as follows: 5471 0 1 2 3 5472 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 5473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5474 | Error Code (i) ... 5475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5476 | [ Frame Type (i) ] ... 5477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5478 | Reason Phrase Length (i) ... 5479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5480 | Reason Phrase (*) ... 5481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5483 CONNECTION_CLOSE frames contain the following fields: 5485 Error Code: A variable length integer error code which indicates the 5486 reason for closing this connection. A CONNECTION_CLOSE frame of 5487 type 0x1c uses codes from the space defined in Section 20. A 5488 CONNECTION_CLOSE frame of type 0x1d uses codes from the 5489 application protocol error code space; see Section 20.1 5491 Frame Type: A variable-length integer encoding the type of frame 5492 that triggered the error. A value of 0 (equivalent to the mention 5493 of the PADDING frame) is used when the frame type is unknown. The 5494 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 5495 not include this field. 5497 Reason Phrase Length: A variable-length integer specifying the 5498 length of the reason phrase in bytes. Because a CONNECTION_CLOSE 5499 frame cannot be split between packets, any limits on packet size 5500 will also limit the space available for a reason phrase. 5502 Reason Phrase: A human-readable explanation for why the connection 5503 was closed. This can be zero length if the sender chooses to not 5504 give details beyond the Error Code. This SHOULD be a UTF-8 5505 encoded string [RFC3629]. 5507 19.20. Extension Frames 5509 QUIC frames do not use a self-describing encoding. An endpoint 5510 therefore needs to understand the syntax of all frames before it can 5511 successfully process a packet. This allows for efficient encoding of 5512 frames, but it means that an endpoint cannot send a frame of a type 5513 that is unknown to its peer. 5515 An extension to QUIC that wishes to use a new type of frame MUST 5516 first ensure that a peer is able to understand the frame. An 5517 endpoint can use a transport parameter to signal its willingness to 5518 receive one or more extension frame types with the one transport 5519 parameter. 5521 Extension frames MUST be congestion controlled and MUST cause an ACK 5522 frame to be sent. The exception is extension frames that replace or 5523 supplement the ACK frame. Extension frames are not included in flow 5524 control unless specified in the extension. 5526 An IANA registry is used to manage the assignment of frame types; see 5527 Section 22.2. 5529 20. Transport Error Codes 5531 QUIC error codes are 62-bit unsigned integers. 5533 This section lists the defined QUIC transport error codes that may be 5534 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5535 connection. 5537 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5538 signal that the connection is being closed abruptly in the absence 5539 of any error. 5541 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5542 cannot continue with the connection. 5544 SERVER_BUSY (0x2): The server is currently busy and does not accept 5545 any new connections. 5547 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5548 permitted in its advertised data limits (see Section 4). 5550 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 5551 identifier that exceeded its advertised stream limit for the 5552 corresponding stream type. 5554 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5555 that was not in a state that permitted that frame (see Section 3). 5557 FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame 5558 containing data that exceeded the previously established final 5559 size. Or an endpoint received a STREAM frame or a RESET_STREAM 5560 frame containing a final size that was lower than the size of 5561 stream data that was already received. Or an endpoint received a 5562 STREAM frame or a RESET_STREAM frame containing a different final 5563 size to the one already established. 5565 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5566 badly formatted. For instance, a frame of an unknown type, or an 5567 ACK frame that has more acknowledgment ranges than the remainder 5568 of the packet could carry. 5570 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5571 parameters that were badly formatted, included an invalid value, 5572 was absent even though it is mandatory, was present though it is 5573 forbidden, or is otherwise in error. 5575 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5576 protocol compliance that was not covered by more specific error 5577 codes. 5579 INVALID_MIGRATION (0xC): A peer has migrated to a different network 5580 when the endpoint had disabled migration. 5582 CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in 5583 CRYPTO frames than it can buffer. 5585 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5586 of 256 values is reserved for carrying error codes specific to the 5587 cryptographic handshake that is used. Codes for errors occurring 5588 when TLS is used for the crypto handshake are described in 5589 Section 4.8 of [QUIC-TLS]. 5591 See Section 22.3 for details of registering new error codes. 5593 20.1. Application Protocol Error Codes 5595 Application protocol error codes are 62-bit unsigned integers, but 5596 the management of application error codes is left to application 5597 protocols. Application protocol error codes are used for the 5598 RESET_STREAM frame (Section 19.4), the STOP_SENDING frame 5599 (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d 5600 (Section 19.19). 5602 21. Security Considerations 5604 21.1. Handshake Denial of Service 5606 As an encrypted and authenticated transport QUIC provides a range of 5607 protections against denial of service. Once the cryptographic 5608 handshake is complete, QUIC endpoints discard most packets that are 5609 not authenticated, greatly limiting the ability of an attacker to 5610 interfere with existing connections. 5612 Once a connection is established QUIC endpoints might accept some 5613 unauthenticated ICMP packets (see Section 14.2), but the use of these 5614 packets is extremely limited. The only other type of packet that an 5615 endpoint might accept is a stateless reset (Section 10.4) which 5616 relies on the token being kept secret until it is used. 5618 During the creation of a connection, QUIC only provides protection 5619 against attack from off the network path. All QUIC packets contain 5620 proof that the recipient saw a preceding packet from its peer. 5622 The first mechanism used is the source and destination connection 5623 IDs, which are required to match those set by a peer. Except for an 5624 Initial and stateless reset packets, an endpoint only accepts packets 5625 that include a destination connection that matches a connection ID 5626 the endpoint previously chose. This is the only protection offered 5627 for Version Negotiation packets. 5629 The destination connection ID in an Initial packet is selected by a 5630 client to be unpredictable, which serves an additional purpose. The 5631 packets that carry the cryptographic handshake are protected with a 5632 key that is derived from this connection ID and salt specific to the 5633 QUIC version. This allows endpoints to use the same process for 5634 authenticating packets that they receive as they use after the 5635 cryptographic handshake completes. Packets that cannot be 5636 authenticated are discarded. Protecting packets in this fashion 5637 provides a strong assurance that the sender of the packet saw the 5638 Initial packet and understood it. 5640 These protections are not intended to be effective against an 5641 attacker that is able to receive QUIC packets prior to the connection 5642 being established. Such an attacker can potentially send packets 5643 that will be accepted by QUIC endpoints. This version of QUIC 5644 attempts to detect this sort of attack, but it expects that endpoints 5645 will fail to establish a connection rather than recovering. For the 5646 most part, the cryptographic handshake protocol [QUIC-TLS] is 5647 responsible for detecting tampering during the handshake. 5649 Endpoints are permitted to use other methods to detect and attempt to 5650 recover from interference with the handshake. Invalid packets may be 5651 identified and discarded using other methods, but no specific method 5652 is mandated in this document. 5654 21.2. Amplification Attack 5656 An attacker might be able to receive an address validation token 5657 (Section 8) from a server and then release the IP address it used to 5658 acquire that token. At a later time, the attacker may initiate a 5659 0-RTT connection with a server by spoofing this same address, which 5660 might now address a different (victim) endpoint. The attacker can 5661 thus potentially cause the server to send an initial congestion 5662 window's worth of data towards the victim. 5664 Servers SHOULD provide mitigations for this attack by limiting the 5665 usage and lifetime of address validation tokens (see Section 8.1.2). 5667 21.3. Optimistic ACK Attack 5669 An endpoint that acknowledges packets it has not received might cause 5670 a congestion controller to permit sending at rates beyond what the 5671 network supports. An endpoint MAY skip packet numbers when sending 5672 packets to detect this behavior. An endpoint can then immediately 5673 close the connection with a connection error of type 5674 PROTOCOL_VIOLATION (see Section 10.3). 5676 21.4. Slowloris Attacks 5678 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 5679 connections to the target endpoint open and hold them open as long as 5680 possible. These attacks can be executed against a QUIC endpoint by 5681 generating the minimum amount of activity necessary to avoid being 5682 closed for inactivity. This might involve sending small amounts of 5683 data, gradually opening flow control windows in order to control the 5684 sender rate, or manufacturing ACK frames that simulate a high loss 5685 rate. 5687 QUIC deployments SHOULD provide mitigations for the Slowloris 5688 attacks, such as increasing the maximum number of clients the server 5689 will allow, limiting the number of connections a single IP address is 5690 allowed to make, imposing restrictions on the minimum transfer speed 5691 a connection is allowed to have, and restricting the length of time 5692 an endpoint is allowed to stay connected. 5694 21.5. Stream Fragmentation and Reassembly Attacks 5696 An adversarial sender might intentionally send fragments of stream 5697 data in order to cause disproportionate receive buffer memory 5698 commitment and/or creation of a large and inefficient data structure. 5700 An adversarial receiver might intentionally not acknowledge packets 5701 containing stream data in order to force the sender to store the 5702 unacknowledged stream data for retransmission. 5704 The attack on receivers is mitigated if flow control windows 5705 correspond to available memory. However, some receivers will over- 5706 commit memory and advertise flow control offsets in the aggregate 5707 that exceed actual available memory. The over-commitment strategy 5708 can lead to better performance when endpoints are well behaved, but 5709 renders endpoints vulnerable to the stream fragmentation attack. 5711 QUIC deployments SHOULD provide mitigations against stream 5712 fragmentation attacks. Mitigations could consist of avoiding over- 5713 committing memory, limiting the size of tracking data structures, 5714 delaying reassembly of STREAM frames, implementing heuristics based 5715 on the age and duration of reassembly holes, or some combination. 5717 21.6. Stream Commitment Attack 5719 An adversarial endpoint can open lots of streams, exhausting state on 5720 an endpoint. The adversarial endpoint could repeat the process on a 5721 large number of connections, in a manner similar to SYN flooding 5722 attacks in TCP. 5724 Normally, clients will open streams sequentially, as explained in 5725 Section 2.1. However, when several streams are initiated at short 5726 intervals, transmission error may cause STREAM DATA frames opening 5727 streams to be received out of sequence. A receiver is obligated to 5728 open intervening streams if a higher-numbered stream ID is received. 5729 Thus, on a new connection, opening stream 2000001 opens 1 million 5730 streams, as required by the specification. 5732 The number of active streams is limited by the 5733 initial_max_streams_bidi and initial_max_streams_uni transport 5734 parameters, as explained in Section 4.5. If chosen judiciously, 5735 these limits mitigate the effect of the stream commitment attack. 5736 However, setting the limit too low could affect performance when 5737 applications expect to open large number of streams. 5739 21.7. Explicit Congestion Notification Attacks 5741 An on-path attacker could manipulate the value of ECN codepoints in 5742 the IP header to influence the sender's rate. [RFC3168] discusses 5743 manipulations and their effects in more detail. 5745 An on-the-side attacker can duplicate and send packets with modified 5746 ECN codepoints to affect the sender's rate. If duplicate packets are 5747 discarded by a receiver, an off-path attacker will need to race the 5748 duplicate packet against the original to be successful in this 5749 attack. Therefore, QUIC endpoints ignore the ECN codepoint field on 5750 an IP packet unless at least one QUIC packet in that IP packet is 5751 successfully processed; see Section 13.3. 5753 21.8. Stateless Reset Oracle 5755 Stateless resets create a possible denial of service attack analogous 5756 to a TCP reset injection. This attack is possible if an attacker is 5757 able to cause a stateless reset token to be generated for a 5758 connection with a selected connection ID. An attacker that can cause 5759 this token to be generated can reset an active connection with the 5760 same connection ID. 5762 If a packet can be routed to different instances that share a static 5763 key, for example by changing an IP address or port, then an attacker 5764 can cause the server to send a stateless reset. To defend against 5765 this style of denial service, endpoints that share a static key for 5766 stateless reset (see Section 10.4.2) MUST be arranged so that packets 5767 with a given connection ID always arrive at an instance that has 5768 connection state, unless that connection is no longer active. 5770 In the case of a cluster that uses dynamic load balancing, it's 5771 possible that a change in load balancer configuration could happen 5772 while an active instance retains connection state; even if an 5773 instance retains connection state, the change in routing and 5774 resulting stateless reset will result in the connection being 5775 terminated. If there is no chance in the packet being routed to the 5776 correct instance, it is better to send a stateless reset than wait 5777 for connections to time out. However, this is acceptable only if the 5778 routing cannot be influenced by an attacker. 5780 21.9. Version Downgrade 5782 This document defines QUIC Version Negotiation packets Section 6, 5783 which can be used to negotiate the QUIC version used between two 5784 endpoints. However, this document does not specify how this 5785 negotiation will be performed between this version and subsequent 5786 future versions. In particular, Version Negotiation packets do not 5787 contain any mechanism to prevent version downgrade attacks. Future 5788 versions of QUIC that use Version Negotiation packets MUST define a 5789 mechanism that is robust against version downgrade attacks. 5791 21.10. Targeted Attacks by Routing 5793 Deployments should limit the ability of an attacker to target a new 5794 connection to a particular server instance. This means that client- 5795 controlled fields, such as the initial Destination Connection ID used 5796 on Initial and 0-RTT packets SHOULD NOT be used by themselves to make 5797 routing decisions. Ideally, routing decisions are made independently 5798 of client-selected values; a Source Connection ID can be selected to 5799 route later packets to the same server. 5801 22. IANA Considerations 5803 22.1. QUIC Transport Parameter Registry 5805 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 5806 under a "QUIC Protocol" heading. 5808 The "QUIC Transport Parameters" registry governs a 16-bit space. 5809 This space is split into two spaces that are governed by different 5810 policies. Values with the first byte in the range 0x00 to 0xfe (in 5811 hexadecimal) are assigned via the Specification Required policy 5812 [RFC8126]. Values with the first byte 0xff are reserved for Private 5813 Use [RFC8126]. 5815 Registrations MUST include the following fields: 5817 Value: The numeric value of the assignment (registrations will be 5818 between 0x0000 and 0xfeff). 5820 Parameter Name: A short mnemonic for the parameter. 5822 Specification: A reference to a publicly available specification for 5823 the value. 5825 The nominated expert(s) verify that a specification exists and is 5826 readily accessible. Expert(s) are encouraged to be biased towards 5827 approving registrations unless they are abusive, frivolous, or 5828 actively harmful (not merely aesthetically displeasing, or 5829 architecturally dubious). 5831 The initial contents of this registry are shown in Table 6. 5833 +--------+-------------------------------------+---------------+ 5834 | Value | Parameter Name | Specification | 5835 +--------+-------------------------------------+---------------+ 5836 | 0x0000 | original_connection_id | Section 18.1 | 5837 | | | | 5838 | 0x0001 | idle_timeout | Section 18.1 | 5839 | | | | 5840 | 0x0002 | stateless_reset_token | Section 18.1 | 5841 | | | | 5842 | 0x0003 | max_packet_size | Section 18.1 | 5843 | | | | 5844 | 0x0004 | initial_max_data | Section 18.1 | 5845 | | | | 5846 | 0x0005 | initial_max_stream_data_bidi_local | Section 18.1 | 5847 | | | | 5848 | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.1 | 5849 | | | | 5850 | 0x0007 | initial_max_stream_data_uni | Section 18.1 | 5851 | | | | 5852 | 0x0008 | initial_max_streams_bidi | Section 18.1 | 5853 | | | | 5854 | 0x0009 | initial_max_streams_uni | Section 18.1 | 5855 | | | | 5856 | 0x000a | ack_delay_exponent | Section 18.1 | 5857 | | | | 5858 | 0x000b | max_ack_delay | Section 18.1 | 5859 | | | | 5860 | 0x000c | disable_migration | Section 18.1 | 5861 | | | | 5862 | 0x000d | preferred_address | Section 18.1 | 5863 | | | | 5864 | 0x000e | active_connection_id_limit | Section 18.1 | 5865 +--------+-------------------------------------+---------------+ 5867 Table 6: Initial QUIC Transport Parameters Entries 5869 22.2. QUIC Frame Type Registry 5871 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 5872 "QUIC Protocol" heading. 5874 The "QUIC Frame Types" registry governs a 62-bit space. This space 5875 is split into three spaces that are governed by different policies. 5876 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 5877 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 5878 to 0x3fff operate on the Specification Required policy [RFC8126]. 5879 All other values are assigned to Private Use [RFC8126]. 5881 Registrations MUST include the following fields: 5883 Value: The numeric value of the assignment (registrations will be 5884 between 0x00 and 0x3fff). A range of values MAY be assigned. 5886 Frame Name: A short mnemonic for the frame type. 5888 Specification: A reference to a publicly available specification for 5889 the value. 5891 The nominated expert(s) verify that a specification exists and is 5892 readily accessible. Specifications for new registrations need to 5893 describe the means by which an endpoint might determine that it can 5894 send the identified type of frame. An accompanying transport 5895 parameter registration (see Section 22.1) is expected for most 5896 registrations. The specification needs to describe the format and 5897 assigned semantics of any fields in the frame. 5899 Expert(s) are encouraged to be biased towards approving registrations 5900 unless they are abusive, frivolous, or actively harmful (not merely 5901 aesthetically displeasing, or architecturally dubious). 5903 The initial contents of this registry are tabulated in Table 3. 5905 22.3. QUIC Transport Error Codes Registry 5907 IANA [SHALL add/has added] a registry for "QUIC Transport Error 5908 Codes" under a "QUIC Protocol" heading. 5910 The "QUIC Transport Error Codes" registry governs a 62-bit space. 5911 This space is split into three spaces that are governed by different 5912 policies. Values between 0x00 and 0x3f (in hexadecimal) are assigned 5913 via the Standards Action or IESG Review policies [RFC8126]. Values 5914 from 0x40 to 0x3fff operate on the Specification Required policy 5915 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 5917 Registrations MUST include the following fields: 5919 Value: The numeric value of the assignment (registrations will be 5920 between 0x0000 and 0x3fff). 5922 Code: A short mnemonic for the parameter. 5924 Description: A brief description of the error code semantics, which 5925 MAY be a summary if a specification reference is provided. 5927 Specification: A reference to a publicly available specification for 5928 the value. 5930 The nominated expert(s) verify that a specification exists and is 5931 readily accessible. Expert(s) are encouraged to be biased towards 5932 approving registrations unless they are abusive, frivolous, or 5933 actively harmful (not merely aesthetically displeasing, or 5934 architecturally dubious). 5936 The initial contents of this registry are shown in Table 7. 5938 +------+---------------------------+----------------+---------------+ 5939 | Valu | Error | Description | Specification | 5940 | e | | | | 5941 +------+---------------------------+----------------+---------------+ 5942 | 0x0 | NO_ERROR | No error | Section 20 | 5943 | | | | | 5944 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 5945 | | | error | | 5946 | | | | | 5947 | 0x2 | SERVER_BUSY | Server | Section 20 | 5948 | | | currently busy | | 5949 | | | | | 5950 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 5951 | | | error | | 5952 | | | | | 5953 | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | 5954 | | | streams opened | | 5955 | | | | | 5956 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 5957 | | | in invalid | | 5958 | | | stream state | | 5959 | | | | | 5960 | 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 | 5961 | | | final size | | 5962 | | | | | 5963 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 5964 | | | error | | 5965 | | | | | 5966 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 5967 | | | transport | | 5968 | | | parameters | | 5969 | | | | | 5970 | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | 5971 | | | protocol | | 5972 | | | violation | | 5973 | | | | | 5974 | 0xC | INVALID_MIGRATION | Violated | Section 20 | 5975 | | | disabled | | 5976 | | | migration | | 5977 +------+---------------------------+----------------+---------------+ 5979 Table 7: Initial QUIC Transport Error Codes Entries 5981 23. References 5982 23.1. Normative References 5984 [DPLPMTUD] 5985 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 5986 T. Voelker, "Packetization Layer Path MTU Discovery for 5987 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 5988 (work in progress), June 2019. 5990 [QUIC-RECOVERY] 5991 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5992 and Congestion Control", draft-ietf-quic-recovery-22 (work 5993 in progress), July 2019. 5995 [QUIC-TLS] 5996 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5997 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5998 tls-22 (work in progress), July 2019. 6000 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6001 DOI 10.17487/RFC1191, November 1990, 6002 . 6004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6005 Requirement Levels", BCP 14, RFC 2119, 6006 DOI 10.17487/RFC2119, March 1997, 6007 . 6009 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 6010 of Explicit Congestion Notification (ECN) to IP", 6011 RFC 3168, DOI 10.17487/RFC3168, September 2001, 6012 . 6014 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6015 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 6016 2003, . 6018 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 6019 "Randomness Requirements for Security", BCP 106, RFC 4086, 6020 DOI 10.17487/RFC4086, June 2005, 6021 . 6023 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 6024 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 6025 . 6027 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 6028 "IPv6 Flow Label Specification", RFC 6437, 6029 DOI 10.17487/RFC6437, November 2011, 6030 . 6032 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 6033 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 6034 March 2017, . 6036 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6037 Writing an IANA Considerations Section in RFCs", BCP 26, 6038 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6039 . 6041 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6042 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6043 May 2017, . 6045 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 6046 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 6047 DOI 10.17487/RFC8201, July 2017, 6048 . 6050 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 6051 Notification (ECN) Experimentation", RFC 8311, 6052 DOI 10.17487/RFC8311, January 2018, 6053 . 6055 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 6056 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 6057 . 6059 23.2. Informative References 6061 [EARLY-DESIGN] 6062 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 6063 December 2013, . 6065 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 6066 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 6067 DOI 10.17487/RFC7540, May 2015, 6068 . 6070 [QUIC-INVARIANTS] 6071 Thomson, M., "Version-Independent Properties of QUIC", 6072 draft-ietf-quic-invariants-05 (work in progress), July 6073 2019. 6075 [QUIC-MANAGEABILITY] 6076 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 6077 Transport Protocol", draft-ietf-quic-manageability-05 6078 (work in progress), July 2019. 6080 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 6081 RFC 1812, DOI 10.17487/RFC1812, June 1995, 6082 . 6084 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 6085 Selective Acknowledgment Options", RFC 2018, 6086 DOI 10.17487/RFC2018, October 1996, 6087 . 6089 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 6090 Hashing for Message Authentication", RFC 2104, 6091 DOI 10.17487/RFC2104, February 1997, 6092 . 6094 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 6095 RFC 2360, DOI 10.17487/RFC2360, June 1998, 6096 . 6098 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 6099 RFC 4303, DOI 10.17487/RFC4303, December 2005, 6100 . 6102 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 6103 Control Message Protocol (ICMPv6) for the Internet 6104 Protocol Version 6 (IPv6) Specification", STD 89, 6105 RFC 4443, DOI 10.17487/RFC4443, March 2006, 6106 . 6108 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 6109 Translation (NAT) Behavioral Requirements for Unicast 6110 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 6111 2007, . 6113 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 6114 Key Derivation Function (HKDF)", RFC 5869, 6115 DOI 10.17487/RFC5869, May 2010, 6116 . 6118 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 6119 "Transport Layer Security (TLS) Application-Layer Protocol 6120 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 6121 July 2014, . 6123 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6124 (IPv6) Specification", STD 86, RFC 8200, 6125 DOI 10.17487/RFC8200, July 2017, 6126 . 6128 [SLOWLORIS] 6129 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 6130 . 6133 Appendix A. Sample Packet Number Decoding Algorithm 6135 The following pseudo-code shows how an implementation can decode 6136 packet numbers after header protection has been removed. 6138 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 6139 expected_pn = largest_pn + 1 6140 pn_win = 1 << pn_nbits 6141 pn_hwin = pn_win / 2 6142 pn_mask = pn_win - 1 6143 // The incoming packet number should be greater than 6144 // expected_pn - pn_hwin and less than or equal to 6145 // expected_pn + pn_hwin 6146 // 6147 // This means we can't just strip the trailing bits from 6148 // expected_pn and add the truncated_pn because that might 6149 // yield a value outside the window. 6150 // 6151 // The following code calculates a candidate value and 6152 // makes sure it's within the packet number window. 6153 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 6154 if candidate_pn <= expected_pn - pn_hwin: 6155 return candidate_pn + pn_win 6156 // Note the extra check for underflow when candidate_pn 6157 // is near zero. 6158 if candidate_pn > expected_pn + pn_hwin and 6159 candidate_pn > pn_win: 6160 return candidate_pn - pn_win 6161 return candidate_pn 6163 Appendix B. Change Log 6165 *RFC Editor's Note:* Please remove this section prior to 6166 publication of a final version of this document. 6168 Issue and pull request numbers are listed with a leading octothorp. 6170 B.1. Since draft-ietf-quic-transport-21 6172 o Connection ID lengths are now one octet, but limited in version 1 6173 to 20 octets of length (#2736, #2749) 6175 B.2. Since draft-ietf-quic-transport-20 6177 o Error codes are encoded as variable-length integers (#2672, #2680) 6179 o NEW_CONNECTION_ID includes a request to retire old connection IDs 6180 (#2645, #2769) 6182 o Tighter rules for generating and explicitly eliciting ACK frames 6183 (#2546, #2794) 6185 o Recommend having only one packet per encryption level in a 6186 datagram (#2308, #2747) 6188 o More normative language about use of stateless reset (#2471, 6189 #2574) 6191 o Allow reuse of stateless reset tokens (#2732, #2733) 6193 o Allow, but not require, enforcing non-duplicate transport 6194 parameters (#2689, #2691) 6196 o Added a active_connection_id_limit transport parameter (#1994, 6197 #1998) 6199 o max_ack_delay transport parameter defaults to 0 (#2638, #2646) 6201 o When sending 0-RTT, only remembered transport parameters apply 6202 (#2458, #2360, #2466, #2461) 6204 o Define handshake completion and confirmation; define clearer rules 6205 when it encryption keys should be discarded (#2214, #2267, #2673) 6207 o Prohibit path migration prior to handshake confirmation (#2309, 6208 #2370) 6210 o PATH_RESPONSE no longer needs to be received on the validated path 6211 (#2582, #2580, #2579, #2637) 6213 o PATH_RESPONSE frames are not stored and retransmitted (#2724, 6214 #2729) 6216 o Document hack for enabling routing of ICMP when doing PMTU probing 6217 (#1243, #2402) 6219 B.3. Since draft-ietf-quic-transport-19 6221 o Refine discussion of 0-RTT transport parameters (#2467, #2464) 6223 o Fewer transport parameters need to be remembered for 0-RTT (#2624, 6224 #2467) 6226 o Spin bit text incorporated (#2564) 6228 o Close the connection when maximum stream ID in MAX_STREAMS exceeds 6229 2^62 - 1 (#2499, #2487) 6231 o New connection ID required for intentional migration (#2414, 6232 #2413) 6234 o Connection ID issuance can be rate-limited (#2436, #2428) 6236 o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) 6238 o Initial packets from clients need to be padded to 1200 unless a 6239 Handshake packet is sent as well (#2522, #2523) 6241 o CRYPTO frames can be discarded if too much data is buffered 6242 (#1834, #2524) 6244 o Stateless reset uses a short header packet (#2599, #2600) 6246 B.4. Since draft-ietf-quic-transport-18 6248 o Removed version negotiation; version negotiation, including 6249 authentication of the result, will be addressed in the next 6250 version of QUIC (#1773, #2313) 6252 o Added discussion of the use of IPv6 flow labels (#2348, #2399) 6254 o A connection ID can't be retired in a packet that uses that 6255 connection ID (#2101, #2420) 6257 o Idle timeout transport parameter is in milliseconds (from seconds) 6258 (#2453, #2454) 6260 o Endpoints are required to use new connection IDs when they use new 6261 network paths (#2413, #2414) 6263 o Increased the set of permissible frames in 0-RTT (#2344, #2355) 6265 B.5. Since draft-ietf-quic-transport-17 6267 o Stream-related errors now use STREAM_STATE_ERROR (#2305) 6269 o Endpoints discard initial keys as soon as handshake keys are 6270 available (#1951, #2045) 6272 o Expanded conditions for ignoring ICMP packet too big messages 6273 (#2108, #2161) 6275 o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, 6276 #2241) 6278 o Endpoints are permitted to discard malformed initial packets 6279 (#2141) 6281 o Clarified ECN implementation and usage requirements (#2156, #2201) 6283 o Disable ECN count verification for packets that arrive out of 6284 order (#2198, #2215) 6286 o Use Probe Timeout (PTO) instead of RTO (#2206, #2238) 6288 o Loosen constraints on retransmission of ACK ranges (#2199, #2245) 6290 o Limit Retry and Version Negotiation to once per datagram (#2259, 6291 #2303) 6293 o Set a maximum value for max_ack_delay transport parameter (#2282, 6294 #2301) 6296 o Allow server preferred address for both IPv4 and IPv6 (#2122, 6297 #2296) 6299 o Corrected requirements for migration to a preferred address 6300 (#2146, #2349) 6302 o ACK of non-existent packet is illegal (#2298, #2302) 6304 B.6. Since draft-ietf-quic-transport-16 6306 o Stream limits are defined as counts, not maximums (#1850, #1906) 6308 o Require amplification attack defense after closing (#1905, #1911) 6310 o Remove reservation of application error code 0 for STOPPING 6311 (#1804, #1922) 6313 o Renumbered frames (#1945) 6315 o Renumbered transport parameters (#1946) 6317 o Numeric transport parameters are expressed as varints (#1608, 6318 #1947, #1955) 6320 o Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 6322 o Rework the first byte (#2006) 6324 * Fix the 0x40 bit 6326 * Change type values for long header 6328 * Add spin bit to short header (#631, #1988) 6330 * Encrypt the remainder of the first byte (#1322) 6332 * Move packet number length to first byte 6334 * Move ODCIL to first byte of retry packets 6336 * Simplify packet number protection (#1575) 6338 o Allow STOP_SENDING to open a remote bidirectional stream (#1797, 6339 #2013) 6341 o Added mitigation for off-path migration attacks (#1278, #1749, 6342 #2033) 6344 o Don't let the PMTU to drop below 1280 (#2063, #2069) 6346 o Require peers to replace retired connection IDs (#2085) 6348 o Servers are required to ignore Version Negotiation packets (#2088) 6350 o Tokens are repeated in all Initial packets (#2089) 6352 o Clarified how PING frames are sent after loss (#2094) 6354 o Initial keys are discarded once Handshake are available (#1951, 6355 #2045) 6357 o ICMP PTB validation clarifications (#2161, #2109, #2108) 6359 B.7. Since draft-ietf-quic-transport-15 6361 Substantial editorial reorganization; no technical changes. 6363 B.8. Since draft-ietf-quic-transport-14 6365 o Merge ACK and ACK_ECN (#1778, #1801) 6367 o Explicitly communicate max_ack_delay (#981, #1781) 6369 o Validate original connection ID after Retry packets (#1710, #1486, 6370 #1793) 6372 o Idle timeout is optional and has no specified maximum (#1765) 6374 o Update connection ID handling; add RETIRE_CONNECTION_ID type 6375 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 6376 #1821) 6378 o Include a Token in all Initial packets (#1649, #1794) 6380 o Prevent handshake deadlock (#1764, #1824) 6382 B.9. Since draft-ietf-quic-transport-13 6384 o Streams open when higher-numbered streams of the same type open 6385 (#1342, #1549) 6387 o Split initial stream flow control limit into 3 transport 6388 parameters (#1016, #1542) 6390 o All flow control transport parameters are optional (#1610) 6392 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 6394 o Permit stateless reset in response to any packet (#1348, #1553) 6396 o Recommended defense against stateless reset spoofing (#1386, 6397 #1554) 6399 o Prevent infinite stateless reset exchanges (#1443, #1627) 6401 o Forbid processing of the same packet number twice (#1405, #1624) 6403 o Added a packet number decoding example (#1493) 6405 o More precisely define idle timeout (#1429, #1614, #1652) 6406 o Corrected format of Retry packet and prevented looping (#1492, 6407 #1451, #1448, #1498) 6409 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 6410 #1514, #1621) 6412 o Permit Retry in response to 0-RTT (#1547, #1552) 6414 o Looser verification of ECN counters to account for ACK loss 6415 (#1555, #1481, #1565) 6417 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 6419 B.10. Since draft-ietf-quic-transport-12 6421 o Changes to integration of the TLS handshake (#829, #1018, #1094, 6422 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 6424 * The cryptographic handshake uses CRYPTO frames, not stream 0 6426 * QUIC packet protection is used in place of TLS record 6427 protection 6429 * Separate QUIC packet number spaces are used for the handshake 6431 * Changed Retry to be independent of the cryptographic handshake 6433 * Added NEW_TOKEN frame and Token fields to Initial packet 6435 * Limit the use of HelloRetryRequest to address TLS needs (like 6436 key shares) 6438 o Enable server to transition connections to a preferred address 6439 (#560, #1251, #1373) 6441 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 6442 (#804, #805, #1372) 6444 o Changed rules and recommendations for use of new connection IDs 6445 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 6447 o Added a transport parameter to disable intentional connection 6448 migration (#1271, #1447) 6450 o Packets from different connection ID can't be coalesced (#1287, 6451 #1423) 6453 o Fixed sampling method for packet number encryption; the length 6454 field in long headers includes the packet number field in addition 6455 to the packet payload (#1387, #1389) 6457 o Stateless Reset is now symmetric and subject to size constraints 6458 (#466, #1346) 6460 o Added frame type extension mechanism (#58, #1473) 6462 B.11. Since draft-ietf-quic-transport-11 6464 o Enable server to transition connections to a preferred address 6465 (#560, #1251) 6467 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 6468 #990, #734, #1317, #1267, #1079) 6470 o Packet numbers use a variable-length encoding (#989, #1334) 6472 o STREAM frames can now be empty (#1350) 6474 B.12. Since draft-ietf-quic-transport-10 6476 o Swap payload length and packed number fields in long header 6477 (#1294) 6479 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 6480 (#1274) 6482 o Spin bit reserved (#1283) 6484 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 6486 o A more complete connection migration (#1249) 6488 o Refine opportunistic ACK defense text (#305, #1030, #1185) 6490 o A Stateless Reset Token isn't mandatory (#818, #1191) 6492 o Removed implicit stream opening (#896, #1193) 6494 o An empty STREAM frame can be used to open a stream without sending 6495 data (#901, #1194) 6497 o Define stream counts in transport parameters rather than a maximum 6498 stream ID (#1023, #1065) 6500 o STOP_SENDING is now prohibited before streams are used (#1050) 6501 o Recommend including ACK in Retry packets and allow PADDING (#1067, 6502 #882) 6504 o Endpoints now become closing after an idle timeout (#1178, #1179) 6506 o Remove implication that Version Negotiation is sent when a packet 6507 of the wrong version is received (#1197) 6509 B.13. Since draft-ietf-quic-transport-09 6511 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 6512 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 6513 (#1091, #725, #1086) 6515 o A server can now only send 3 packets without validating the client 6516 address (#38, #1090) 6518 o Delivery order of stream data is no longer strongly specified 6519 (#252, #1070) 6521 o Rework of packet handling and version negotiation (#1038) 6523 o Stream 0 is now exempt from flow control until the handshake 6524 completes (#1074, #725, #825, #1082) 6526 o Improved retransmission rules for all frame types: information is 6527 retransmitted, not packets or frames (#463, #765, #1095, #1053) 6529 o Added an error code for server busy signals (#1137) 6531 o Endpoints now set the connection ID that their peer uses. 6532 Connection IDs are variable length. Removed the 6533 omit_connection_id transport parameter and the corresponding short 6534 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 6536 B.14. Since draft-ietf-quic-transport-08 6538 o Clarified requirements for BLOCKED usage (#65, #924) 6540 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 6541 #928) 6543 o GAP limitation in ACK Frame (#613) 6545 o Improved PMTUD description (#614, #1036) 6547 o Clarified stream state machine (#634, #662, #743, #894) 6548 o Reserved versions don't need to be generated deterministically 6549 (#831, #931) 6551 o You don't always need the draining period (#871) 6553 o Stateless reset clarified as version-specific (#930, #986) 6555 o initial_max_stream_id_x transport parameters are optional (#970, 6556 #971) 6558 o Ack Delay assumes a default value during the handshake (#1007, 6559 #1009) 6561 o Removed transport parameters from NewSessionTicket (#1015) 6563 B.15. Since draft-ietf-quic-transport-07 6565 o The long header now has version before packet number (#926, #939) 6567 o Rename and consolidate packet types (#846, #822, #847) 6569 o Packet types are assigned new codepoints and the Connection ID 6570 Flag is inverted (#426, #956) 6572 o Removed type for Version Negotiation and use Version 0 (#963, 6573 #968) 6575 o Streams are split into unidirectional and bidirectional (#643, 6576 #656, #720, #872, #175, #885) 6578 * Stream limits now have separate uni- and bi-directional 6579 transport parameters (#909, #958) 6581 * Stream limit transport parameters are now optional and default 6582 to 0 (#970, #971) 6584 o The stream state machine has been split into read and write (#634, 6585 #894) 6587 o Employ variable-length integer encodings throughout (#595) 6589 o Improvements to connection close 6591 * Added distinct closing and draining states (#899, #871) 6593 * Draining period can terminate early (#869, #870) 6595 * Clarifications about stateless reset (#889, #890) 6597 o Address validation for connection migration (#161, #732, #878) 6599 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 6601 o negotiated_version is sent in server transport parameters (#710, 6602 #959) 6604 o Increased the range over which packet numbers are randomized 6605 (#864, #850, #964) 6607 B.16. Since draft-ietf-quic-transport-06 6609 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 6611 o Split error code space between application and transport (#485) 6613 o Stateless reset token moved to end (#820) 6615 o 1-RTT-protected long header types removed (#848) 6617 o No acknowledgments during draining period (#852) 6619 o Remove "application close" as a separate close type (#854) 6621 o Remove timestamps from the ACK frame (#841) 6623 o Require transport parameters to only appear once (#792) 6625 B.17. Since draft-ietf-quic-transport-05 6627 o Stateless token is server-only (#726) 6629 o Refactor section on connection termination (#733, #748, #328, 6630 #177) 6632 o Limit size of Version Negotiation packet (#585) 6634 o Clarify when and what to ack (#736) 6636 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 6638 o Clarify Keep-alive requirements (#729) 6640 B.18. Since draft-ietf-quic-transport-04 6642 o Introduce STOP_SENDING frame, RESET_STREAM only resets in one 6643 direction (#165) 6645 o Removed GOAWAY; application protocols are responsible for graceful 6646 shutdown (#696) 6648 o Reduced the number of error codes (#96, #177, #184, #211) 6650 o Version validation fields can't move or change (#121) 6652 o Removed versions from the transport parameters in a 6653 NewSessionTicket message (#547) 6655 o Clarify the meaning of "bytes in flight" (#550) 6657 o Public reset is now stateless reset and not visible to the path 6658 (#215) 6660 o Reordered bits and fields in STREAM frame (#620) 6662 o Clarifications to the stream state machine (#572, #571) 6664 o Increased the maximum length of the Largest Acknowledged field in 6665 ACK frames to 64 bits (#629) 6667 o truncate_connection_id is renamed to omit_connection_id (#659) 6669 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 6670 #328) 6672 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 6674 B.19. Since draft-ietf-quic-transport-03 6676 o Change STREAM and RESET_STREAM layout 6678 o Add MAX_STREAM_ID settings 6680 B.20. Since draft-ietf-quic-transport-02 6682 o The size of the initial packet payload has a fixed minimum (#267, 6683 #472) 6685 o Define when Version Negotiation packets are ignored (#284, #294, 6686 #241, #143, #474) 6688 o The 64-bit FNV-1a algorithm is used for integrity protection of 6689 unprotected packets (#167, #480, #481, #517) 6691 o Rework initial packet types to change how the connection ID is 6692 chosen (#482, #442, #493) 6694 o No timestamps are forbidden in unprotected packets (#542, #429) 6696 o Cryptographic handshake is now on stream 0 (#456) 6698 o Remove congestion control exemption for cryptographic handshake 6699 (#248, #476) 6701 o Version 1 of QUIC uses TLS; a new version is needed to use a 6702 different handshake protocol (#516) 6704 o STREAM frames have a reduced number of offset lengths (#543, #430) 6706 o Split some frames into separate connection- and stream- level 6707 frames (#443) 6709 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 6711 * BLOCKED split to match WINDOW_UPDATE split (#454) 6713 * Define STREAM_ID_NEEDED frame (#455) 6715 o A NEW_CONNECTION_ID frame supports connection migration without 6716 linkability (#232, #491, #496) 6718 o Transport parameters for 0-RTT are retained from a previous 6719 connection (#405, #513, #512) 6721 * A client in 0-RTT no longer required to reset excess streams 6722 (#425, #479) 6724 o Expanded security considerations (#440, #444, #445, #448) 6726 B.21. Since draft-ietf-quic-transport-01 6728 o Defined short and long packet headers (#40, #148, #361) 6730 o Defined a versioning scheme and stable fields (#51, #361) 6732 o Define reserved version values for "greasing" negotiation (#112, 6733 #278) 6735 o The initial packet number is randomized (#35, #283) 6737 o Narrow the packet number encoding range requirement (#67, #286, 6738 #299, #323, #356) 6740 o Defined client address validation (#52, #118, #120, #275) 6741 o Define transport parameters as a TLS extension (#49, #122) 6743 o SCUP and COPT parameters are no longer valid (#116, #117) 6745 o Transport parameters for 0-RTT are either remembered from before, 6746 or assume default values (#126) 6748 o The server chooses connection IDs in its final flight (#119, #349, 6749 #361) 6751 o The server echoes the Connection ID and packet number fields when 6752 sending a Version Negotiation packet (#133, #295, #244) 6754 o Defined a minimum packet size for the initial handshake packet 6755 from the client (#69, #136, #139, #164) 6757 o Path MTU Discovery (#64, #106) 6759 o The initial handshake packet from the client needs to fit in a 6760 single packet (#338) 6762 o Forbid acknowledgment of packets containing only ACK and PADDING 6763 (#291) 6765 o Require that frames are processed when packets are acknowledged 6766 (#381, #341) 6768 o Removed the STOP_WAITING frame (#66) 6770 o Don't require retransmission of old timestamps for lost ACK frames 6771 (#308) 6773 o Clarified that frames are not retransmitted, but the information 6774 in them can be (#157, #298) 6776 o Error handling definitions (#335) 6778 o Split error codes into four sections (#74) 6780 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 6781 (#289) 6783 o Define packet protection rules (#336) 6785 o Require that stream be entirely delivered or reset, including 6786 acknowledgment of all STREAM frames or the RESET_STREAM, before it 6787 closes (#381) 6789 o Remove stream reservation from state machine (#174, #280) 6791 o Only stream 1 does not contribute to connection-level flow control 6792 (#204) 6794 o Stream 1 counts towards the maximum concurrent stream limit (#201, 6795 #282) 6797 o Remove connection-level flow control exclusion for some streams 6798 (except 1) (#246) 6800 o RESET_STREAM affects connection-level flow control (#162, #163) 6802 o Flow control accounting uses the maximum data offset on each 6803 stream, rather than bytes received (#378) 6805 o Moved length-determining fields to the start of STREAM and ACK 6806 (#168, #277) 6808 o Added the ability to pad between frames (#158, #276) 6810 o Remove error code and reason phrase from GOAWAY (#352, #355) 6812 o GOAWAY includes a final stream number for both directions (#347) 6814 o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 6815 consistent offset (#249) 6817 o Defined priority as the responsibility of the application protocol 6818 (#104, #303) 6820 B.22. Since draft-ietf-quic-transport-00 6822 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 6824 o Defined versioning 6826 o Reworked description of packet and frame layout 6828 o Error code space is divided into regions for each component 6830 o Use big endian for all numeric values 6832 B.23. Since draft-hamilton-quic-transport-protocol-01 6834 o Adopted as base for draft-ietf-quic-tls 6836 o Updated authors/editors list 6837 o Added IANA Considerations section 6839 o Moved Contributors and Acknowledgments to appendices 6841 Acknowledgments 6843 Special thanks are due to the following for helping shape pre-IETF 6844 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 6845 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 6847 This document has benefited immensely from various private 6848 discussions and public ones on the quic@ietf.org and proto- 6849 quic@chromium.org mailing lists. Our thanks to all. 6851 Contributors 6853 The original authors of this specification were Ryan Hamilton, Jana 6854 Iyengar, Ian Swett, and Alyssa Wilk. 6856 The original design and rationale behind this protocol draw 6857 significantly from work by Jim Roskind [EARLY-DESIGN]. In 6858 alphabetical order, the contributors to the pre-IETF QUIC project at 6859 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 6860 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 6861 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 6862 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 6863 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 6865 Authors' Addresses 6867 Jana Iyengar (editor) 6868 Fastly 6870 Email: jri.ietf@gmail.com 6872 Martin Thomson (editor) 6873 Mozilla 6875 Email: mt@lowentropy.net