idnits 2.17.1 draft-ietf-quic-transport-24.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. A client MUST discard a Retry packet that contains a Source Connection ID field that is identical to the Destination Connection ID field of its Initial packet. The client MUST use the value from the Source Connection ID field of the Retry packet in the Destination Connection ID field of subsequent packets that it sends. -- The document date (November 04, 2019) is 1634 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 1893 == Missing Reference: 'CH' is mentioned on line 1889, but not defined == Missing Reference: 'SH' is mentioned on line 1891, but not defined == Missing Reference: 'EE' is mentioned on line 1892, but not defined == Missing Reference: 'CERT' is mentioned on line 1892, but not defined == Missing Reference: 'CV' is mentioned on line 1892, but not defined == Missing Reference: 'FIN' is mentioned on line 1892, but not defined -- Looks like a reference, but probably isn't: '1' on line 1891 == 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-24 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-24 -- 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-07 == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-05 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 5 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: May 7, 2020 Mozilla 6 November 04, 2019 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-24 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 May 7, 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 . . . . . . . . . . . . . . . . . . 8 64 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 65 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 67 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 68 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 69 2.4. Required Operations on Streams . . . . . . . . . . . . . 11 70 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12 72 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14 73 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 17 74 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17 75 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19 76 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 20 77 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20 78 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21 79 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22 80 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 23 81 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23 82 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24 84 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25 85 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26 86 5.2. Matching Packets to Connections . . . . . . . . . . . . . 27 87 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 28 88 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28 89 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29 90 5.4. Required Operations on Connections . . . . . . . . . . . 29 91 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 30 92 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 30 93 6.2. Handling Version Negotiation Packets . . . . . . . . . . 31 94 6.2.1. Version Negotiation Between Draft Versions . . . . . 31 95 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 31 96 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 32 97 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 33 98 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 34 99 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 36 100 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 36 101 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 38 102 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 38 103 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 38 104 8.1. Address Validation During Connection Establishment . . . 39 105 8.1.1. Address Validation using Retry Packets . . . . . . . 40 106 8.1.2. Address Validation for Future Connections . . . . . . 41 107 8.1.3. Address Validation Token Integrity . . . . . . . . . 43 108 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 43 109 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 44 110 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 44 111 8.5. Successful Path Validation . . . . . . . . . . . . . . . 44 112 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 45 113 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 45 114 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46 115 9.2. Initiating Connection Migration . . . . . . . . . . . . . 47 116 9.3. Responding to Connection Migration . . . . . . . . . . . 47 117 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48 118 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48 119 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49 120 9.4. Loss Detection and Congestion Control . . . . . . . . . . 50 121 9.5. Privacy Implications of Connection Migration . . . . . . 51 122 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 52 123 9.6.1. Communicating a Preferred Address . . . . . . . . . . 52 124 9.6.2. Responding to Connection Migration . . . . . . . . . 53 125 9.6.3. Interaction of Client Migration and Preferred Address 53 126 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 54 127 10. Connection Termination . . . . . . . . . . . . . . . . . . . 54 128 10.1. Closing and Draining Connection States . . . . . . . . . 54 129 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 56 130 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56 131 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 58 132 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60 133 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61 134 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62 135 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 63 136 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63 137 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64 138 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64 139 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 65 140 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65 141 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66 142 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 68 143 13. Packetization and Reliability . . . . . . . . . . . . . . . . 70 144 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 71 145 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 71 146 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 71 147 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 73 148 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 73 149 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 73 150 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 74 151 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 74 152 13.3. Retransmission of Information . . . . . . . . . . . . . 74 153 13.4. Explicit Congestion Notification . . . . . . . . . . . . 77 154 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 77 155 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78 156 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80 157 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 80 158 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 81 159 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 82 160 14.3.1. PMTU Probes Containing Source Connection ID . . . . 83 161 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83 162 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84 163 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 85 164 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 85 165 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 86 166 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 89 167 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 90 168 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 92 169 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 94 170 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 95 171 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 98 172 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 99 173 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 100 174 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 101 175 18.2. Transport Parameter Definitions . . . . . . . . . . . . 101 176 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 106 177 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 106 178 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 106 179 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 107 180 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 108 181 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 110 182 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 111 183 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 111 184 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 112 185 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 113 186 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 114 187 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 115 188 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 116 189 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 117 190 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 118 191 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 118 192 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 119 193 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 120 194 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 121 195 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 122 196 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 123 197 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 123 198 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 124 199 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 124 200 20.1. Application Protocol Error Codes . . . . . . . . . . . . 126 201 21. Security Considerations . . . . . . . . . . . . . . . . . . . 126 202 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 126 203 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 127 204 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 127 205 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 128 206 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 128 207 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 129 208 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 129 209 21.8. Explicit Congestion Notification Attacks . . . . . . . . 130 210 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 130 211 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 130 212 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 131 213 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131 214 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 131 215 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 132 216 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 133 217 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 218 23.1. Normative References . . . . . . . . . . . . . . . . . . 136 219 23.2. Informative References . . . . . . . . . . . . . . . . . 137 220 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 139 221 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 140 222 B.1. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 140 223 B.2. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 140 224 B.3. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 142 225 B.4. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 142 226 B.5. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 143 227 B.6. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 143 228 B.7. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 144 229 B.8. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 144 230 B.9. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 146 231 B.10. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 146 232 B.11. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 146 233 B.12. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 147 234 B.13. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 148 235 B.14. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 148 236 B.15. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 149 237 B.16. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 149 238 B.17. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 150 239 B.18. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 151 240 B.19. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 151 241 B.20. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 151 242 B.21. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 152 243 B.22. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 152 244 B.23. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 153 245 B.24. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 155 246 B.25. Since draft-hamilton-quic-transport-protocol-01 . . . . . 155 247 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 156 248 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 156 249 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 251 1. Introduction 253 QUIC is a multiplexed and secure general-purpose transport protocol 254 that provides: 256 o Stream multiplexing 258 o Stream and connection-level flow control 260 o Low-latency connection establishment 262 o Connection migration and resilience to NAT rebinding 264 o Authenticated and encrypted header and payload 266 QUIC uses UDP as a substrate to avoid requiring changes to legacy 267 client operating systems and middleboxes. QUIC authenticates all of 268 its headers and encrypts most of the data it exchanges, including its 269 signaling, to avoid incurring a dependency on middleboxes. 271 1.1. Document Structure 273 This document describes the core QUIC protocol and is structured as 274 follows. 276 o Streams are the basic service abstraction that QUIC provides. 278 * Section 2 describes core concepts related to streams, 280 * Section 3 provides a reference model for stream states, and 282 * Section 4 outlines the operation of flow control. 284 o Connections are the context in which QUIC endpoints communicate. 286 * Section 5 describes core concepts related to connections, 288 * Section 6 describes version negotiation, 289 * Section 7 details the process for establishing connections, 291 * Section 8 specifies critical denial of service mitigation 292 mechanisms, 294 * Section 9 describes how endpoints migrate a connection to a new 295 network path, 297 * Section 10 lists the options for terminating an open 298 connection, and 300 * Section 11 provides general guidance for error handling. 302 o Packets and frames are the basic unit used by QUIC to communicate. 304 * Section 12 describes concepts related to packets and frames, 306 * Section 13 defines models for the transmission, retransmission, 307 and acknowledgement of data, and 309 * Section 14 specifies rules for managing the size of packets. 311 o Finally, encoding details of QUIC protocol elements are described 312 in: 314 * Section 15 (Versions), 316 * Section 16 (Integer Encoding), 318 * Section 17 (Packet Headers), 320 * Section 18 (Transport Parameters), 322 * Section 19 (Frames), and 324 * Section 20 (Errors). 326 Accompanying documents describe QUIC's loss detection and congestion 327 control [QUIC-RECOVERY], and the use of TLS for key negotiation 328 [QUIC-TLS]. 330 This document defines QUIC version 1, which conforms to the protocol 331 invariants in [QUIC-INVARIANTS]. 333 1.2. Terms and Definitions 335 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 336 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 337 "OPTIONAL" in this document are to be interpreted as described in BCP 338 14 [RFC2119] [RFC8174] when, and only when, they appear in all 339 capitals, as shown here. 341 Commonly used terms in the document are described below. 343 QUIC: The transport protocol described by this document. QUIC is a 344 name, not an acronym. 346 QUIC packet: A complete processable unit of QUIC that can be 347 encapsulated in a UDP datagram. Multiple QUIC packets can be 348 encapsulated in a single UDP datagram. 350 Ack-eliciting Packet: A QUIC packet that contains frames other than 351 ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to 352 send an acknowledgment (see Section 13.2.1). 354 Endpoint: An entity that can participate in a QUIC connection by 355 generating, receiving, and processing QUIC packets. There are 356 only two types of endpoint in QUIC: client and server. 358 Client: The endpoint initiating a QUIC connection. 360 Server: The endpoint accepting incoming QUIC connections. 362 Connection ID: An opaque identifier that is used to identify a QUIC 363 connection at an endpoint. Each endpoint sets a value for its 364 peer to include in packets sent towards the endpoint. 366 Stream: A unidirectional or bidirectional channel of ordered bytes 367 within a QUIC connection. A QUIC connection can carry multiple 368 simultaneous streams. 370 Application: An entity that uses QUIC to send and receive data. 372 1.3. Notational Conventions 374 Packet and frame diagrams in this document use the format described 375 in Section 3.1 of [RFC2360], with the following additional 376 conventions: 378 [x]: Indicates that x is optional 380 x (A): Indicates that x is A bits long 381 x (A/B/C) ...: Indicates that x is one of A, B, or C bits long 383 x (i) ...: Indicates that x uses the variable-length encoding in 384 Section 16 386 x (*) ...: Indicates that x is variable-length 388 2. Streams 390 Streams in QUIC provide a lightweight, ordered byte-stream 391 abstraction to an application. Streams can be unidirectional or 392 bidirectional. An alternative view of QUIC unidirectional streams is 393 a "message" abstraction of practically unlimited length. 395 Streams can be created by sending data. Other processes associated 396 with stream management - ending, cancelling, and managing flow 397 control - are all designed to impose minimal overheads. For 398 instance, a single STREAM frame (Section 19.8) can open, carry data 399 for, and close a stream. Streams can also be long-lived and can last 400 the entire duration of a connection. 402 Streams can be created by either endpoint, can concurrently send data 403 interleaved with other streams, and can be cancelled. QUIC does not 404 provide any means of ensuring ordering between bytes on different 405 streams. 407 QUIC allows for an arbitrary number of streams to operate 408 concurrently and for an arbitrary amount of data to be sent on any 409 stream, subject to flow control constraints (see Section 4) and 410 stream limits. 412 2.1. Stream Types and Identifiers 414 Streams can be unidirectional or bidirectional. Unidirectional 415 streams carry data in one direction: from the initiator of the stream 416 to its peer. Bidirectional streams allow for data to be sent in both 417 directions. 419 Streams are identified within a connection by a numeric value, 420 referred to as the stream ID. A stream ID is a 62-bit integer (0 to 421 2^62-1) that is unique for all streams on a connection. Stream IDs 422 are encoded as variable-length integers (see Section 16). A QUIC 423 endpoint MUST NOT reuse a stream ID within a connection. 425 The least significant bit (0x1) of the stream ID identifies the 426 initiator of the stream. Client-initiated streams have even-numbered 427 stream IDs (with the bit set to 0), and server-initiated streams have 428 odd-numbered stream IDs (with the bit set to 1). 430 The second least significant bit (0x2) of the stream ID distinguishes 431 between bidirectional streams (with the bit set to 0) and 432 unidirectional streams (with the bit set to 1). 434 The least significant two bits from a stream ID therefore identify a 435 stream as one of four types, as summarized in Table 1. 437 +------+----------------------------------+ 438 | Bits | Stream Type | 439 +------+----------------------------------+ 440 | 0x0 | Client-Initiated, Bidirectional | 441 | | | 442 | 0x1 | Server-Initiated, Bidirectional | 443 | | | 444 | 0x2 | Client-Initiated, Unidirectional | 445 | | | 446 | 0x3 | Server-Initiated, Unidirectional | 447 +------+----------------------------------+ 449 Table 1: Stream ID Types 451 Within each type, streams are created with numerically increasing 452 stream IDs. A stream ID that is used out of order results in all 453 streams of that type with lower-numbered stream IDs also being 454 opened. 456 The first bidirectional stream opened by the client has a stream ID 457 of 0. 459 2.2. Sending and Receiving Data 461 STREAM frames (Section 19.8) encapsulate data sent by an application. 462 An endpoint uses the Stream ID and Offset fields in STREAM frames to 463 place data in order. 465 Endpoints MUST be able to deliver stream data to an application as an 466 ordered byte-stream. Delivering an ordered byte-stream requires that 467 an endpoint buffer any data that is received out of order, up to the 468 advertised flow control limit. 470 QUIC makes no specific allowances for delivery of stream data out of 471 order. However, implementations MAY choose to offer the ability to 472 deliver data out of order to a receiving application. 474 An endpoint could receive data for a stream at the same stream offset 475 multiple times. Data that has already been received can be 476 discarded. The data at a given offset MUST NOT change if it is sent 477 multiple times; an endpoint MAY treat receipt of different data at 478 the same offset within a stream as a connection error of type 479 PROTOCOL_VIOLATION. 481 Streams are an ordered byte-stream abstraction with no other 482 structure visible to QUIC. STREAM frame boundaries are not expected 483 to be preserved when data is transmitted, retransmitted after packet 484 loss, or delivered to the application at a receiver. 486 An endpoint MUST NOT send data on any stream without ensuring that it 487 is within the flow control limits set by its peer. Flow control is 488 described in detail in Section 4. 490 2.3. Stream Prioritization 492 Stream multiplexing can have a significant effect on application 493 performance if resources allocated to streams are correctly 494 prioritized. 496 QUIC does not provide a mechanism for exchanging prioritization 497 information. Instead, it relies on receiving priority information 498 from the application that uses QUIC. 500 A QUIC implementation SHOULD provide ways in which an application can 501 indicate the relative priority of streams. When deciding which 502 streams to dedicate resources to, the implementation SHOULD use the 503 information provided by the application. 505 2.4. Required Operations on Streams 507 There are certain operations which an application MUST be able to 508 perform when interacting with QUIC streams. This document does not 509 specify an API, but any implementation of this version of QUIC MUST 510 expose the ability to perform the operations described in this 511 section on a QUIC stream. 513 On the sending part of a stream, application protocols need to be 514 able to: 516 o write data, understanding when stream flow control credit 517 (Section 4.1) has successfully been reserved to send the written 518 data; 520 o end the stream (clean termination), resulting in a STREAM frame 521 (Section 19.8) with the FIN bit set; and 523 o reset the stream (abrupt termination), resulting in a RESET_STREAM 524 frame (Section 19.4), if the stream was not already in a terminal 525 state. 527 On the receiving part of a stream, application protocols need to be 528 able to: 530 o read data; and 532 o abort reading of the stream and request closure, possibly 533 resulting in a STOP_SENDING frame (Section 19.5). 535 Applications also need to be informed of state changes on streams, 536 including when the peer has opened or reset a stream, when a peer 537 aborts reading on a stream, when new data is available, and when data 538 can or cannot be written to the stream due to flow control. 540 3. Stream States 542 This section describes streams in terms of their send or receive 543 components. Two state machines are described: one for the streams on 544 which an endpoint transmits data (Section 3.1), and another for 545 streams on which an endpoint receives data (Section 3.2). 547 Unidirectional streams use the applicable state machine directly. 548 Bidirectional streams use both state machines. For the most part, 549 the use of these state machines is the same whether the stream is 550 unidirectional or bidirectional. The conditions for opening a stream 551 are slightly more complex for a bidirectional stream because the 552 opening of either send or receive sides causes the stream to open in 553 both directions. 555 An endpoint MUST open streams of the same type in increasing order of 556 stream ID. 558 Note: These states are largely informative. This document uses 559 stream states to describe rules for when and how different types 560 of frames can be sent and the reactions that are expected when 561 different types of frames are received. Though these state 562 machines are intended to be useful in implementing QUIC, these 563 states aren't intended to constrain implementations. An 564 implementation can define a different state machine as long as its 565 behavior is consistent with an implementation that implements 566 these states. 568 3.1. Sending Stream States 570 Figure 1 shows the states for the part of a stream that sends data to 571 a peer. 573 o 574 | Create Stream (Sending) 575 | Peer Creates Bidirectional Stream 576 v 577 +-------+ 578 | Ready | Send RESET_STREAM 579 | |-----------------------. 580 +-------+ | 581 | | 582 | Send STREAM / | 583 | STREAM_DATA_BLOCKED | 584 | | 585 | Peer Creates | 586 | Bidirectional Stream | 587 v | 588 +-------+ | 589 | Send | Send RESET_STREAM | 590 | |---------------------->| 591 +-------+ | 592 | | 593 | Send STREAM + FIN | 594 v v 595 +-------+ +-------+ 596 | Data | Send RESET_STREAM | Reset | 597 | Sent |------------------>| Sent | 598 +-------+ +-------+ 599 | | 600 | Recv All ACKs | Recv ACK 601 v v 602 +-------+ +-------+ 603 | Data | | Reset | 604 | Recvd | | Recvd | 605 +-------+ +-------+ 607 Figure 1: States for Sending Parts of Streams 609 The sending part of stream that the endpoint initiates (types 0 and 2 610 for clients, 1 and 3 for servers) is opened by the application. The 611 "Ready" state represents a newly created stream that is able to 612 accept data from the application. Stream data might be buffered in 613 this state in preparation for sending. 615 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a 616 sending part of a stream to enter the "Send" state. An 617 implementation might choose to defer allocating a stream ID to a 618 stream until it sends the first STREAM frame and enters this state, 619 which can allow for better stream prioritization. 621 The sending part of a bidirectional stream initiated by a peer (type 622 0 for a server, type 1 for a client) enters the "Ready" state then 623 immediately transitions to the "Send" state if the receiving part 624 enters the "Recv" state (Section 3.2). 626 In the "Send" state, an endpoint transmits - and retransmits as 627 necessary - stream data in STREAM frames. The endpoint respects the 628 flow control limits set by its peer, and continues to accept and 629 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 630 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 631 stream or connection flow control limits Section 4.1. 633 After the application indicates that all stream data has been sent 634 and a STREAM frame containing the FIN bit is sent, the sending part 635 of the stream enters the "Data Sent" state. From this state, the 636 endpoint only retransmits stream data as necessary. The endpoint 637 does not need to check flow control limits or send 638 STREAM_DATA_BLOCKED frames for a stream in this state. 639 MAX_STREAM_DATA frames might be received until the peer receives the 640 final stream offset. The endpoint can safely ignore any 641 MAX_STREAM_DATA frames it receives from its peer for a stream in this 642 state. 644 Once all stream data has been successfully acknowledged, the sending 645 part of the stream enters the "Data Recvd" state, which is a terminal 646 state. 648 From any of the "Ready", "Send", or "Data Sent" states, an 649 application can signal that it wishes to abandon transmission of 650 stream data. Alternatively, an endpoint might receive a STOP_SENDING 651 frame from its peer. In either case, the endpoint sends a 652 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 653 state. 655 An endpoint MAY send a RESET_STREAM as the first frame that mentions 656 a stream; this causes the sending part of that stream to open and 657 then immediately transition to the "Reset Sent" state. 659 Once a packet containing a RESET_STREAM has been acknowledged, the 660 sending part of the stream enters the "Reset Recvd" state, which is a 661 terminal state. 663 3.2. Receiving Stream States 665 Figure 2 shows the states for the part of a stream that receives data 666 from a peer. The states for a receiving part of a stream mirror only 667 some of the states of the sending part of the stream at the peer. 668 The receiving part of a stream does not track states on the sending 669 part that cannot be observed, such as the "Ready" state. Instead, 670 the receiving part of a stream tracks the delivery of data to the 671 application, some of which cannot be observed by the sender. 673 o 674 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 675 | Create Bidirectional Stream (Sending) 676 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 677 | Create Higher-Numbered Stream 678 v 679 +-------+ 680 | Recv | Recv RESET_STREAM 681 | |-----------------------. 682 +-------+ | 683 | | 684 | Recv STREAM + FIN | 685 v | 686 +-------+ | 687 | Size | Recv RESET_STREAM | 688 | Known |---------------------->| 689 +-------+ | 690 | | 691 | Recv All Data | 692 v v 693 +-------+ Recv RESET_STREAM +-------+ 694 | Data |--- (optional) --->| Reset | 695 | Recvd | Recv All Data | Recvd | 696 +-------+<-- (optional) ----+-------+ 697 | | 698 | App Read All Data | App Read RST 699 v v 700 +-------+ +-------+ 701 | Data | | Reset | 702 | Read | | Read | 703 +-------+ +-------+ 705 Figure 2: States for Receiving Parts of Streams 707 The receiving part of a stream initiated by a peer (types 1 and 3 for 708 a client, or 0 and 2 for a server) is created when the first STREAM, 709 STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. 710 For bidirectional streams initiated by a peer, receipt of a 711 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 712 stream also creates the receiving part. The initial state for the 713 receiving part of stream is "Recv". 715 The receiving part of a stream enters the "Recv" state when the 716 sending part of a bidirectional stream initiated by the endpoint 717 (type 0 for a client, type 1 for a server) enters the "Ready" state. 719 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 720 STOP_SENDING frame is received from the peer for that stream. 721 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 722 that the remote peer has opened the stream and is providing flow 723 control credit. Receiving a STOP_SENDING frame for an unopened 724 stream indicates that the remote peer no longer wishes to receive 725 data on this stream. Either frame might arrive before a STREAM or 726 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 728 Before a stream is created, all streams of the same type with lower- 729 numbered stream IDs MUST be created. This ensures that the creation 730 order for streams is consistent on both endpoints. 732 In the "Recv" state, the endpoint receives STREAM and 733 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 734 reassembled into the correct order for delivery to the application. 735 As data is consumed by the application and buffer space becomes 736 available, the endpoint sends MAX_STREAM_DATA frames to allow the 737 peer to send more data. 739 When a STREAM frame with a FIN bit is received, the final size of the 740 stream is known (see Section 4.4). The receiving part of the stream 741 then enters the "Size Known" state. In this state, the endpoint no 742 longer needs to send MAX_STREAM_DATA frames, it only receives any 743 retransmissions of stream data. 745 Once all data for the stream has been received, the receiving part 746 enters the "Data Recvd" state. This might happen as a result of 747 receiving the same STREAM frame that causes the transition to "Size 748 Known". After all data has been received, any STREAM or 749 STREAM_DATA_BLOCKED frames for the stream can be discarded. 751 The "Data Recvd" state persists until stream data has been delivered 752 to the application. Once stream data has been delivered, the stream 753 enters the "Data Read" state, which is a terminal state. 755 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 756 causes the stream to enter the "Reset Recvd" state. This might cause 757 the delivery of stream data to the application to be interrupted. 759 It is possible that all stream data is received when a RESET_STREAM 760 is received (that is, from the "Data Recvd" state). Similarly, it is 761 possible for remaining stream data to arrive after receiving a 762 RESET_STREAM frame (the "Reset Recvd" state). An implementation is 763 free to manage this situation as it chooses. 765 Sending RESET_STREAM means that an endpoint cannot guarantee delivery 766 of stream data; however there is no requirement that stream data not 767 be delivered if a RESET_STREAM is received. An implementation MAY 768 interrupt delivery of stream data, discard any data that was not 769 consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM 770 signal might be suppressed or withheld if stream data is completely 771 received and is buffered to be read by the application. If the 772 RESET_STREAM is suppressed, the receiving part of the stream remains 773 in "Data Recvd". 775 Once the application receives the signal indicating that the stream 776 was reset, the receiving part of the stream transitions to the "Reset 777 Read" state, which is a terminal state. 779 3.3. Permitted Frame Types 781 The sender of a stream sends just three frame types that affect the 782 state of a stream at either sender or receiver: STREAM 783 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 784 (Section 19.4). 786 A sender MUST NOT send any of these frames from a terminal state 787 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 788 STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the 789 terminal states and in the "Reset Sent" state. A receiver could 790 receive any of these three frames in any state, due to the 791 possibility of delayed delivery of packets carrying them. 793 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 794 STOP_SENDING frames (Section 19.5). 796 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 797 receiver can send STOP_SENDING in any state where it has not received 798 a RESET_STREAM frame; that is states other than "Reset Recvd" or 799 "Reset Read". However there is little value in sending a 800 STOP_SENDING frame in the "Data Recvd" state, since all stream data 801 has been received. A sender could receive either of these two frames 802 in any state as a result of delayed delivery of packets. 804 3.4. Bidirectional Stream States 806 A bidirectional stream is composed of sending and receiving parts. 807 Implementations may represent states of the bidirectional stream as 808 composites of sending and receiving stream states. The simplest 809 model presents the stream as "open" when either sending or receiving 810 parts are in a non-terminal state and "closed" when both sending and 811 receiving streams are in terminal states. 813 Table 2 shows a more complex mapping of bidirectional stream states 814 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 815 shows that multiple states on sending or receiving parts of streams 816 are mapped to the same composite state. Note that this is just one 817 possibility for such a mapping; this mapping requires that data is 818 acknowledged before the transition to a "closed" or "half-closed" 819 state. 821 +-----------------------+---------------------+---------------------+ 822 | Sending Part | Receiving Part | Composite State | 823 +-----------------------+---------------------+---------------------+ 824 | No Stream/Ready | No Stream/Recv *1 | idle | 825 | | | | 826 | Ready/Send/Data Sent | Recv/Size Known | open | 827 | | | | 828 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 829 | | Read | (remote) | 830 | | | | 831 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 832 | | Read | (remote) | 833 | | | | 834 | Data Recvd | Recv/Size Known | half-closed (local) | 835 | | | | 836 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 837 | Recvd | | | 838 | | | | 839 | Reset Sent/Reset | Data Recvd/Data | closed | 840 | Recvd | Read | | 841 | | | | 842 | Reset Sent/Reset | Reset Recvd/Reset | closed | 843 | Recvd | Read | | 844 | | | | 845 | Data Recvd | Data Recvd/Data | closed | 846 | | Read | | 847 | | | | 848 | Data Recvd | Reset Recvd/Reset | closed | 849 | | Read | | 850 +-----------------------+---------------------+---------------------+ 852 Table 2: Possible Mapping of Stream States to HTTP/2 854 Note (*1): A stream is considered "idle" if it has not yet been 855 created, or if the receiving part of the stream is in the "Recv" 856 state without yet having received any frames. 858 3.5. Solicited State Transitions 860 If an application is no longer interested in the data it is receiving 861 on a stream, it can abort reading the stream and specify an 862 application error code. 864 If the stream is in the "Recv" or "Size Known" states, the transport 865 SHOULD signal this by sending a STOP_SENDING frame to prompt closure 866 of the stream in the opposite direction. This typically indicates 867 that the receiving application is no longer reading data it receives 868 from the stream, but it is not a guarantee that incoming data will be 869 ignored. 871 STREAM frames received after sending STOP_SENDING are still counted 872 toward connection and stream flow control, even though these frames 873 can be discarded upon receipt. 875 A STOP_SENDING frame requests that the receiving endpoint send a 876 RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame 877 MUST send a RESET_STREAM frame if the stream is in the Ready or Send 878 state. If the stream is in the Data Sent state and any outstanding 879 data is declared lost, an endpoint SHOULD send a RESET_STREAM frame 880 in lieu of a retransmission. 882 An endpoint SHOULD copy the error code from the STOP_SENDING frame to 883 the RESET_STREAM frame it sends, but MAY use any application error 884 code. The endpoint that sends a STOP_SENDING frame MAY ignore the 885 error code carried in any RESET_STREAM frame it receives. 887 If the STOP_SENDING frame is received on a stream that is already in 888 the "Data Sent" state, an endpoint that wishes to cease 889 retransmission of previously-sent STREAM frames on that stream MUST 890 first send a RESET_STREAM frame. 892 STOP_SENDING SHOULD only be sent for a stream that has not been reset 893 by the peer. STOP_SENDING is most useful for streams in the "Recv" 894 or "Size Known" states. 896 An endpoint is expected to send another STOP_SENDING frame if a 897 packet containing a previous STOP_SENDING is lost. However, once 898 either all stream data or a RESET_STREAM frame has been received for 899 the stream - that is, the stream is in any state other than "Recv" or 900 "Size Known" - sending a STOP_SENDING frame is unnecessary. 902 An endpoint that wishes to terminate both directions of a 903 bidirectional stream can terminate one direction by sending a 904 RESET_STREAM, and it can encourage prompt termination in the opposite 905 direction by sending a STOP_SENDING frame. 907 4. Flow Control 909 It is necessary to limit the amount of data that a receiver could 910 buffer, to prevent a fast sender from overwhelming a slow receiver, 911 or to prevent a malicious sender from consuming a large amount of 912 memory at a receiver. To enable a receiver to limit memory 913 commitment to a connection and to apply back pressure on the sender, 914 streams are flow controlled both individually and as an aggregate. A 915 QUIC receiver controls the maximum amount of data the sender can send 916 on a stream at any time, as described in Section 4.1 and Section 4.2 918 Similarly, to limit concurrency within a connection, a QUIC endpoint 919 controls the maximum cumulative number of streams that its peer can 920 initiate, as described in Section 4.5. 922 Data sent in CRYPTO frames is not flow controlled in the same way as 923 stream data. QUIC relies on the cryptographic protocol 924 implementation to avoid excessive buffering of data; see [QUIC-TLS]. 925 The implementation SHOULD provide an interface to QUIC to tell it 926 about its buffering limits so that there is not excessive buffering 927 at multiple layers. 929 4.1. Data Flow Control 931 QUIC employs a credit-based flow-control scheme similar to that in 932 HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is 933 prepared to receive on a given stream and for the entire connection. 934 This leads to two levels of data flow control in QUIC: 936 o Stream flow control, which prevents a single stream from consuming 937 the entire receive buffer for a connection by limiting the amount 938 of data that can be sent on any stream. 940 o Connection flow control, which prevents senders from exceeding a 941 receiver's buffer capacity for the connection, by limiting the 942 total bytes of stream data sent in STREAM frames on all streams. 944 A receiver sets initial credits for all streams by sending transport 945 parameters during the handshake (Section 7.3). A receiver sends 946 MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to 947 the sender to advertise additional credit. 949 A receiver advertises credit for a stream by sending a 950 MAX_STREAM_DATA frame with the Stream ID field set appropriately. A 951 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 952 stream. A receiver could use the current offset of data consumed to 953 determine the flow control offset to be advertised. A receiver MAY 954 send MAX_STREAM_DATA frames in multiple packets in order to make sure 955 that the sender receives an update before running out of flow control 956 credit, even if one of the packets is lost. 958 A receiver advertises credit for a connection by sending a MAX_DATA 959 frame, which indicates the maximum of the sum of the absolute byte 960 offsets of all streams. A receiver maintains a cumulative sum of 961 bytes received on all streams, which is used to check for flow 962 control violations. A receiver might use a sum of bytes consumed on 963 all streams to determine the maximum data limit to be advertised. 965 A receiver can advertise a larger offset by sending MAX_STREAM_DATA 966 or MAX_DATA frames. Once a receiver advertises an offset, it MAY 967 advertise a smaller offset, but this has no effect. 969 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 970 (Section 11) if the sender violates the advertised connection or 971 stream data limits. 973 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 974 not increase flow control limits. 976 If a sender runs out of flow control credit, it will be unable to 977 send new data and is considered blocked. A sender SHOULD send a 978 STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to 979 write but is blocked by flow control limits. These frames are 980 expected to be sent infrequently in common cases, but they are 981 considered useful for debugging and monitoring purposes. 983 A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED 984 frames for the same data limit, unless the original frame is 985 determined to be lost. Another STREAM_DATA_BLOCKED or DATA_BLOCKED 986 frame can be sent after the data limit is increased. 988 4.2. Flow Credit Increments 990 This document leaves when and how many bytes to advertise in a 991 MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a 992 few considerations. These frames contribute to connection overhead. 993 Therefore frequently sending frames with small changes is 994 undesirable. At the same time, larger increments to limits are 995 necessary to avoid blocking if updates are less frequent, requiring 996 larger resource commitments at the receiver. Thus there is a trade- 997 off between resource commitment and overhead when determining how 998 large a limit is advertised. 1000 A receiver can use an autotuning mechanism to tune the frequency and 1001 amount of advertised additional credit based on a round-trip time 1002 estimate and the rate at which the receiving application consumes 1003 data, similar to common TCP implementations. As an optimization, 1004 sending frames related to flow control only when there are other 1005 frames to send or when a peer is blocked ensures that flow control 1006 doesn't cause extra packets to be sent. 1008 If a sender runs out of flow control credit, it will be unable to 1009 send new data and is considered blocked. It is generally considered 1010 best to not let the sender become blocked. To avoid blocking a 1011 sender, and to reasonably account for the possibility of loss, a 1012 receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two 1013 round trips before it expects the sender to get blocked. 1015 A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED 1016 frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will 1017 mean that a sender will be blocked for at least an entire round trip, 1018 and potentially for longer if the peer chooses to not send 1019 STREAM_DATA_BLOCKED or DATA_BLOCKED frames. 1021 4.3. Handling Stream Cancellation 1023 Endpoints need to eventually agree on the amount of flow control 1024 credit that has been consumed, to avoid either exceeding flow control 1025 limits or deadlocking. 1027 On receipt of a RESET_STREAM frame, an endpoint will tear down state 1028 for the matching stream and ignore further data arriving on that 1029 stream. Without the offset included in RESET_STREAM, the two 1030 endpoints could disagree on the number of bytes that count towards 1031 connection flow control. 1033 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes 1034 the final size of data sent on the stream. On receiving a 1035 RESET_STREAM frame, a receiver definitively knows how many bytes were 1036 sent on that stream before the RESET_STREAM frame, and the receiver 1037 MUST use the final size of the stream to account for all bytes sent 1038 on the stream in its connection level flow controller. 1040 RESET_STREAM terminates one direction of a stream abruptly. For a 1041 bidirectional stream, RESET_STREAM has no effect on data flow in the 1042 opposite direction. Both endpoints MUST maintain flow control state 1043 for the stream in the unterminated direction until that direction 1044 enters a terminal state, or until one of the endpoints sends 1045 CONNECTION_CLOSE. 1047 4.4. Stream Final Size 1049 The final size is the amount of flow control credit that is consumed 1050 by a stream. Assuming that every contiguous byte on the stream was 1051 sent once, the final size is the number of bytes sent. More 1052 generally, this is one higher than the offset of the byte with the 1053 largest offset sent on the stream, or zero if no bytes were sent. 1055 For a stream that is reset, the final size is carried explicitly in a 1056 RESET_STREAM frame. Otherwise, the final size is the offset plus the 1057 length of a STREAM frame marked with a FIN flag, or 0 in the case of 1058 incoming unidirectional streams. 1060 An endpoint will know the final size for a stream when the receiving 1061 part of the stream enters the "Size Known" or "Reset Recvd" state 1062 (Section 3). 1064 An endpoint MUST NOT send data on a stream at or beyond the final 1065 size. 1067 Once a final size for a stream is known, it cannot change. If a 1068 RESET_STREAM or STREAM frame is received indicating a change in the 1069 final size for the stream, an endpoint SHOULD respond with a 1070 FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat 1071 receipt of data at or beyond the final size as a FINAL_SIZE_ERROR 1072 error, even after a stream is closed. Generating these errors is not 1073 mandatory, but only because requiring that an endpoint generate these 1074 errors also means that the endpoint needs to maintain the final size 1075 state for closed streams, which could mean a significant state 1076 commitment. 1078 4.5. Controlling Concurrency 1080 An endpoint limits the cumulative number of incoming streams a peer 1081 can open. Only streams with a stream ID less than (max_stream * 4 + 1082 initial_stream_id_for_type) can be opened (see Table 5). Initial 1083 limits are set in the transport parameters (see Section 18.2) and 1084 subsequently limits are advertised using MAX_STREAMS frames 1085 (Section 19.11). Separate limits apply to unidirectional and 1086 bidirectional streams. 1088 If a max_streams transport parameter or MAX_STREAMS frame is received 1089 with a value greater than 2^60, this would allow a maximum stream ID 1090 that cannot be expressed as a variable-length integer (see 1091 Section 16). If either is received, the connection MUST be closed 1092 immediately with a connection error of type STREAM_LIMIT_ERROR (see 1093 Section 10.3). 1095 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1096 that receives a frame with a stream ID exceeding the limit it has 1097 sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR 1098 (Section 11). 1100 Once a receiver advertises a stream limit using the MAX_STREAMS 1101 frame, advertising a smaller limit has no effect. A receiver MUST 1102 ignore any MAX_STREAMS frame that does not increase the stream limit. 1104 As with stream and connection flow control, this document leaves when 1105 and how many streams to advertise to a peer via MAX_STREAMS to 1106 implementations. Implementations might choose to increase limits as 1107 streams close to keep the number of streams available to peers 1108 roughly consistent. 1110 An endpoint that is unable to open a new stream due to the peer's 1111 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1112 signal is considered useful for debugging. An endpoint MUST NOT wait 1113 to receive this signal before advertising additional credit, since 1114 doing so will mean that the peer will be blocked for at least an 1115 entire round trip, and potentially for longer if the peer chooses to 1116 not send STREAMS_BLOCKED frames. 1118 5. Connections 1120 QUIC's connection establishment combines version negotiation with the 1121 cryptographic and transport handshakes to reduce connection 1122 establishment latency, as described in Section 7. Once established, 1123 a connection may migrate to a different IP or port at either endpoint 1124 as described in Section 9. Finally, a connection may be terminated 1125 by either endpoint, as described in Section 10. 1127 5.1. Connection ID 1129 Each connection possesses a set of connection identifiers, or 1130 connection IDs, each of which can identify the connection. 1131 Connection IDs are independently selected by endpoints; each endpoint 1132 selects the connection IDs that its peer uses. 1134 The primary function of a connection ID is to ensure that changes in 1135 addressing at lower protocol layers (UDP, IP) don't cause packets for 1136 a QUIC connection to be delivered to the wrong endpoint. Each 1137 endpoint selects connection IDs using an implementation-specific (and 1138 perhaps deployment-specific) method which will allow packets with 1139 that connection ID to be routed back to the endpoint and identified 1140 by the endpoint upon receipt. 1142 Connection IDs MUST NOT contain any information that can be used by 1143 an external observer (that is, one that does not cooperate with the 1144 issuer) to correlate them with other connection IDs for the same 1145 connection. As a trivial example, this means the same connection ID 1146 MUST NOT be issued more than once on the same connection. 1148 Packets with long headers include Source Connection ID and 1149 Destination Connection ID fields. These fields are used to set the 1150 connection IDs for new connections; see Section 7.2 for details. 1152 Packets with short headers (Section 17.3) only include the 1153 Destination Connection ID and omit the explicit length. The length 1154 of the Destination Connection ID field is expected to be known to 1155 endpoints. Endpoints using a load balancer that routes based on 1156 connection ID could agree with the load balancer on a fixed length 1157 for connection IDs, or agree on an encoding scheme. A fixed portion 1158 could encode an explicit length, which allows the entire connection 1159 ID to vary in length and still be used by the load balancer. 1161 A Version Negotiation (Section 17.2.1) packet echoes the connection 1162 IDs selected by the client, both to ensure correct routing toward the 1163 client and to allow the client to validate that the packet is in 1164 response to an Initial packet. 1166 A zero-length connection ID can be used when a connection ID is not 1167 needed to route to the correct endpoint. However, multiplexing 1168 connections on the same local IP address and port while using zero- 1169 length connection IDs will cause failures in the presence of peer 1170 connection migration, NAT rebinding, and client port reuse; and 1171 therefore MUST NOT be done unless an endpoint is certain that those 1172 protocol features are not in use. 1174 When an endpoint has requested a non-zero-length connection ID, it 1175 needs to ensure that the peer has a supply of connection IDs from 1176 which to choose for packets sent to the endpoint. These connection 1177 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1178 (Section 19.15). 1180 5.1.1. Issuing Connection IDs 1182 Each Connection ID has an associated sequence number to assist in 1183 deduplicating messages. The initial connection ID issued by an 1184 endpoint is sent in the Source Connection ID field of the long packet 1185 header (Section 17.2) during the handshake. The sequence number of 1186 the initial connection ID is 0. If the preferred_address transport 1187 parameter is sent, the sequence number of the supplied connection ID 1188 is 1. 1190 Additional connection IDs are communicated to the peer using 1191 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1192 each newly-issued connection ID MUST increase by 1. The connection 1193 ID randomly selected by the client in the Initial packet and any 1194 connection ID provided by a Retry packet are not assigned sequence 1195 numbers unless a server opts to retain them as its initial connection 1196 ID. 1198 When an endpoint issues a connection ID, it MUST accept packets that 1199 carry this connection ID for the duration of the connection or until 1200 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1201 frame (Section 19.16). Connection IDs that are issued and not 1202 retired are considered active; any active connection ID can be used. 1204 An endpoint SHOULD ensure that its peer has a sufficient number of 1205 available and unused connection IDs. Endpoints store received 1206 connection IDs for future use and advertise the number of connection 1207 IDs they are willing to store with the active_connection_id_limit 1208 transport parameter. An endpoint SHOULD NOT provide more connection 1209 IDs than the peer's limit. 1211 An endpoint SHOULD supply a new connection ID when it receives a 1212 packet with a previously unused connection ID or when the peer 1213 retires one, unless providing the new connection ID would exceed the 1214 peer's limit. An endpoint MAY limit the frequency or the total 1215 number of connection IDs issued for each connection to avoid the risk 1216 of running out of connection IDs; see Section 10.4.2. 1218 An endpoint that initiates migration and requires non-zero-length 1219 connection IDs SHOULD ensure that the pool of connection IDs 1220 available to its peer allows the peer to use a new connection ID on 1221 migration, as the peer will close the connection if the pool is 1222 exhausted. 1224 5.1.2. Consuming and Retiring Connection IDs 1226 An endpoint can change the connection ID it uses for a peer to 1227 another available one at any time during the connection. An endpoint 1228 consumes connection IDs in response to a migrating peer; see 1229 Section 9.5 for more. 1231 An endpoint maintains a set of connection IDs received from its peer, 1232 any of which it can use when sending packets. When the endpoint 1233 wishes to remove a connection ID from use, it sends a 1234 RETIRE_CONNECTION_ID frame to its peer. Sending a 1235 RETIRE_CONNECTION_ID frame indicates that the connection ID will not 1236 be used again and requests that the peer replace it with a new 1237 connection ID using a NEW_CONNECTION_ID frame. 1239 As discussed in Section 9.5, each connection ID MUST be used on 1240 packets sent from only one local address. An endpoint that migrates 1241 away from a local address SHOULD retire all connection IDs used on 1242 that address once it no longer plans to use that address. 1244 An endpoint can cause its peer to retire connection IDs by sending a 1245 NEW_CONNECTION_ID frame with an increased Retire Prior To field. 1246 Upon receipt, the peer MUST retire the corresponding connection IDs 1247 and send corresponding RETIRE_CONNECTION_ID frames. Failing to 1248 retire the connection IDs within approximately one PTO can cause 1249 packets to be delayed, lost, or cause the original endpoint to send a 1250 stateless reset in response to a connection ID it can no longer route 1251 correctly. 1253 An endpoint MAY discard a connection ID for which retirement has been 1254 requested once an interval of no less than 3 PTO has elapsed since an 1255 acknowledgement is received for the NEW_CONNECTION_ID frame 1256 requesting that retirement. Until then, the endpoint SHOULD be 1257 prepared to receive packets that contain the connection ID that it 1258 has requested be retired. Subsequent incoming packets using that 1259 connection ID could elicit a response with the corresponding 1260 stateless reset token. 1262 5.2. Matching Packets to Connections 1264 Incoming packets are classified on receipt. Packets can either be 1265 associated with an existing connection, or - for servers - 1266 potentially create a new connection. 1268 Hosts try to associate a packet with an existing connection. If the 1269 packet has a non-zero-length Destination Connection ID corresponding 1270 to an existing connection, QUIC processes that packet accordingly. 1271 Note that more than one connection ID can be associated with a 1272 connection; see Section 5.1. 1274 If the Destination Connection ID is zero length and the packet 1275 matches the local address and port of a connection where the host 1276 used zero-length connection IDs, QUIC processes the packet as part of 1277 that connection. 1279 Endpoints can send a Stateless Reset (Section 10.4) for any packets 1280 that cannot be attributed to an existing connection. A stateless 1281 reset allows a peer to more quickly identify when a connection 1282 becomes unusable. 1284 Packets that are matched to an existing connection are discarded if 1285 the packets are inconsistent with the state of that connection. For 1286 example, packets are discarded if they indicate a different protocol 1287 version than that of the connection, or if the removal of packet 1288 protection is unsuccessful once the expected keys are available. 1290 Invalid packets without packet protection, such as Initial, Retry, or 1291 Version Negotiation, MAY be discarded. An endpoint MUST generate a 1292 connection error if it commits changes to state before discovering an 1293 error. 1295 5.2.1. Client Packet Handling 1297 Valid packets sent to clients always include a Destination Connection 1298 ID that matches a value the client selects. Clients that choose to 1299 receive zero-length connection IDs can use the local address and port 1300 to identify a connection. Packets that don't match an existing 1301 connection are discarded. 1303 Due to packet reordering or loss, a client might receive packets for 1304 a connection that are encrypted with a key it has not yet computed. 1305 The client MAY drop these packets, or MAY buffer them in anticipation 1306 of later packets that allow it to compute the key. 1308 If a client receives a packet that has an unsupported version, it 1309 MUST discard that packet. 1311 5.2.2. Server Packet Handling 1313 If a server receives a packet that has an unsupported version, but 1314 the packet is sufficiently large to initiate a new connection for any 1315 version supported by the server, it SHOULD send a Version Negotiation 1316 packet as described in Section 6.1. Servers MAY rate control these 1317 packets to avoid storms of Version Negotiation packets. Otherwise, 1318 servers MUST drop packets that specify unsupported versions. 1320 The first packet for an unsupported version can use different 1321 semantics and encodings for any version-specific field. In 1322 particular, different packet protection keys might be used for 1323 different versions. Servers that do not support a particular version 1324 are unlikely to be able to decrypt the payload of the packet. 1325 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1326 unknown version, but instead send a Version Negotiation packet, 1327 provided that the packet is sufficiently long. 1329 Packets with a supported version, or no version field, are matched to 1330 a connection using the connection ID or - for packets with zero- 1331 length connection IDs - the local address and port. If the packet 1332 doesn't match an existing connection, the server continues below. 1334 If the packet is an Initial packet fully conforming with the 1335 specification, the server proceeds with the handshake (Section 7). 1336 This commits the server to the version that the client selected. 1338 If a server isn't currently accepting any new connections, it SHOULD 1339 send an Initial packet containing a CONNECTION_CLOSE frame with error 1340 code SERVER_BUSY. 1342 If the packet is a 0-RTT packet, the server MAY buffer a limited 1343 number of these packets in anticipation of a late-arriving Initial 1344 packet. Clients are not able to send Handshake packets prior to 1345 receiving a server response, so servers SHOULD ignore any such 1346 packets. 1348 Servers MUST drop incoming packets under all other circumstances. 1350 5.3. Life of a QUIC Connection 1352 TBD. 1354 5.4. Required Operations on Connections 1356 There are certain operations which an application MUST be able to 1357 perform when interacting with the QUIC transport. This document does 1358 not specify an API, but any implementation of this version of QUIC 1359 MUST expose the ability to perform the operations described in this 1360 section on a QUIC connection. 1362 When implementing the client role, applications need to be able to: 1364 o open a connection, which begins the exchange described in 1365 Section 7; 1367 o enable 0-RTT when available; and 1369 o be informed when 0-RTT has been accepted or rejected by a server. 1371 When implementing the server role, applications need to be able to: 1373 o listen for incoming connections, which prepares for the exchange 1374 described in Section 7; 1376 o if Early Data is supported, embed application-controlled data in 1377 the TLS resumption ticket sent to the client; and 1379 o if Early Data is supported, retrieve application-controlled data 1380 from the client's resumption ticket and enable rejecting Early 1381 Data based on that information. 1383 In either role, applications need to be able to: 1385 o configure minimum values for the initial number of permitted 1386 streams of each type, as communicated in the transport parameters 1387 (Section 7.3); 1389 o control resource allocation of various types, including flow 1390 control and the number of permitted streams of each type; 1392 o identify whether the handshake has completed successfully or is 1393 still ongoing 1395 o keep a connection from silently closing, either by generating PING 1396 frames (Section 19.2) or by requesting that the transport send 1397 additional frames before the idle timeout expires (Section 10.2); 1398 and 1400 o immediately close (Section 10.3) the connection. 1402 6. Version Negotiation 1404 Version negotiation ensures that client and server agree to a QUIC 1405 version that is mutually supported. A server sends a Version 1406 Negotiation packet in response to each packet that might initiate a 1407 new connection; see Section 5.2 for details. 1409 The size of the first packet sent by a client will determine whether 1410 a server sends a Version Negotiation packet. Clients that support 1411 multiple QUIC versions SHOULD pad the first packet they send to the 1412 largest of the minimum packet sizes across all versions they support. 1413 This ensures that the server responds if there is a mutually 1414 supported version. 1416 6.1. Sending Version Negotiation Packets 1418 If the version selected by the client is not acceptable to the 1419 server, the server responds with a Version Negotiation packet (see 1420 Section 17.2.1). This includes a list of versions that the server 1421 will accept. An endpoint MUST NOT send a Version Negotiation packet 1422 in response to receiving a Version Negotiation packet. 1424 This system allows a server to process packets with unsupported 1425 versions without retaining state. Though either the Initial packet 1426 or the Version Negotiation packet that is sent in response could be 1427 lost, the client will send new packets until it successfully receives 1428 a response or it abandons the connection attempt. As a result, the 1429 client discards all state for the connection and does not send any 1430 more packets on the connection. 1432 A server MAY limit the number of Version Negotiation packets it 1433 sends. For instance, a server that is able to recognize packets as 1434 0-RTT might choose not to send Version Negotiation packets in 1435 response to 0-RTT packets with the expectation that it will 1436 eventually receive an Initial packet. 1438 6.2. Handling Version Negotiation Packets 1440 When a client receives a Version Negotiation packet, it MUST abandon 1441 the current connection attempt. Version Negotiation packets are 1442 designed to allow future versions of QUIC to negotiate the version in 1443 use between endpoints. Future versions of QUIC might change how 1444 implementations that support multiple versions of QUIC react to 1445 Version Negotiation packets when attempting to establish a connection 1446 using this version. How to perform version negotiation is left as 1447 future work defined by future versions of QUIC. In particular, that 1448 future work will need to ensure robustness against version downgrade 1449 attacks Section 21.10. 1451 6.2.1. Version Negotiation Between Draft Versions 1453 [[RFC editor: please remove this section before publication.]] 1455 When a draft implementation receives a Version Negotiation packet, it 1456 MAY use it to attempt a new connection with one of the versions 1457 listed in the packet, instead of abandoning the current connection 1458 attempt Section 6.2. 1460 The client MUST check that the Destination and Source Connection ID 1461 fields match the Source and Destination Connection ID fields in a 1462 packet that the client sent. If this check fails, the packet MUST be 1463 discarded. 1465 Once the Version Negotiation packet is determined to be valid, the 1466 client then selects an acceptable protocol version from the list 1467 provided by the server. The client then attempts to create a new 1468 connection using that version. The new connection MUST use a new 1469 random Destination Connection ID different from the one it had 1470 previously sent. 1472 Note that this mechanism does not protect against downgrade attacks 1473 and MUST NOT be used outside of draft implementations. 1475 6.3. Using Reserved Versions 1477 For a server to use a new version in the future, clients need to 1478 correctly handle unsupported versions. To help ensure this, a server 1479 SHOULD include a version that is reserved for forcing version 1480 negotiation (0x?a?a?a?a as defined in Section 15) when generating a 1481 Version Negotiation packet. 1483 The design of version negotiation permits a server to avoid 1484 maintaining state for packets that it rejects in this fashion. 1486 A client MAY send a packet using a version that is reserved for 1487 forcing version negotiation. This can be used to solicit a list of 1488 supported versions from a server. 1490 7. Cryptographic and Transport Handshake 1492 QUIC relies on a combined cryptographic and transport handshake to 1493 minimize connection establishment latency. QUIC uses the CRYPTO 1494 frame Section 19.6 to transmit the cryptographic handshake. Version 1495 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 1496 QUIC version number could indicate that a different cryptographic 1497 handshake protocol is in use. 1499 QUIC provides reliable, ordered delivery of the cryptographic 1500 handshake data. QUIC packet protection is used to encrypt as much of 1501 the handshake protocol as possible. The cryptographic handshake MUST 1502 provide the following properties: 1504 o authenticated key exchange, where 1506 * a server is always authenticated, 1508 * a client is optionally authenticated, 1510 * every connection produces distinct and unrelated keys, 1512 * keying material is usable for packet protection for both 0-RTT 1513 and 1-RTT packets, and 1515 * 1-RTT keys have forward secrecy 1517 o authenticated values for transport parameters of both endpoints, 1518 and confidentiality protection for server transport parameters 1519 (see Section 7.3) 1521 o authenticated negotiation of an application protocol (TLS uses 1522 ALPN [RFC7301] for this purpose) 1524 An endpoint can verify support for Explicit Congestion Notification 1525 (ECN) in the first packets it sends, as described in Section 13.4.2. 1527 The CRYPTO frame can be sent in different packet number spaces. The 1528 sequence numbers used by CRYPTO frames to ensure ordered delivery of 1529 cryptographic handshake data start from zero in each packet number 1530 space. 1532 Endpoints MUST explicitly negotiate an application protocol. This 1533 avoids situations where there is a disagreement about the protocol 1534 that is in use. 1536 7.1. Example Handshake Flows 1538 Details of how TLS is integrated with QUIC are provided in 1539 [QUIC-TLS], but some examples are provided here. An extension of 1540 this exchange to support client address validation is shown in 1541 Section 8.1.1. 1543 Once any address validation exchanges are complete, the cryptographic 1544 handshake is used to agree on cryptographic keys. The cryptographic 1545 handshake is carried in Initial (Section 17.2.2) and Handshake 1546 (Section 17.2.4) packets. 1548 Figure 3 provides an overview of the 1-RTT handshake. Each line 1549 shows a QUIC packet with the packet type and packet number shown 1550 first, followed by the frames that are typically contained in those 1551 packets. So, for instance the first packet is of type Initial, with 1552 packet number 0, and contains a CRYPTO frame carrying the 1553 ClientHello. 1555 Note that multiple QUIC packets - even of different encryption levels 1556 - may be coalesced into a single UDP datagram (see Section 12.2), and 1557 so this handshake may consist of as few as 4 UDP datagrams, or any 1558 number more. For instance, the server's first flight contains 1559 packets from the Initial encryption level (obfuscation), the 1560 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1561 encryption level. 1563 Client Server 1565 Initial[0]: CRYPTO[CH] -> 1567 Initial[0]: CRYPTO[SH] ACK[0] 1568 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1569 <- 1-RTT[0]: STREAM[1, "..."] 1571 Initial[1]: ACK[0] 1572 Handshake[0]: CRYPTO[FIN], ACK[0] 1573 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1575 1-RTT[1]: STREAM[3, "..."], ACK[0] 1576 <- Handshake[1]: ACK[0] 1578 Figure 3: Example 1-RTT Handshake 1580 Figure 4 shows an example of a connection with a 0-RTT handshake and 1581 a single packet of 0-RTT data. Note that as described in 1582 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1583 encryption level, and the client sends 1-RTT packets in the same 1584 packet number space. 1586 Client Server 1588 Initial[0]: CRYPTO[CH] 1589 0-RTT[0]: STREAM[0, "..."] -> 1591 Initial[0]: CRYPTO[SH] ACK[0] 1592 Handshake[0] CRYPTO[EE, FIN] 1593 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1595 Initial[1]: ACK[0] 1596 Handshake[0]: CRYPTO[FIN], ACK[0] 1597 1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1599 1-RTT[1]: STREAM[3, "..."], ACK[1] 1600 <- Handshake[1]: ACK[0] 1602 Figure 4: Example 0-RTT Handshake 1604 7.2. Negotiating Connection IDs 1606 A connection ID is used to ensure consistent routing of packets, as 1607 described in Section 5.1. The long header contains two connection 1608 IDs: the Destination Connection ID is chosen by the recipient of the 1609 packet and is used to provide consistent routing; the Source 1610 Connection ID is used to set the Destination Connection ID used by 1611 the peer. 1613 During the handshake, packets with the long header (Section 17.2) are 1614 used to establish the connection ID that each endpoint uses. Each 1615 endpoint uses the Source Connection ID field to specify the 1616 connection ID that is used in the Destination Connection ID field of 1617 packets being sent to them. Upon receiving a packet, each endpoint 1618 sets the Destination Connection ID it sends to match the value of the 1619 Source Connection ID that they receive. 1621 When an Initial packet is sent by a client that has not previously 1622 received an Initial or Retry packet from the server, it populates the 1623 Destination Connection ID field with an unpredictable value. This 1624 MUST be at least 8 bytes in length. Until a packet is received from 1625 the server, the client MUST use the same value unless it abandons the 1626 connection attempt and starts a new one. The initial Destination 1627 Connection ID is used to determine packet protection keys for Initial 1628 packets. 1630 The client populates the Source Connection ID field with a value of 1631 its choosing and sets the SCID Len field to indicate the length. 1633 The first flight of 0-RTT packets use the same Destination and Source 1634 Connection ID values as the client's first Initial. 1636 Upon first receiving an Initial or Retry packet from the server, the 1637 client uses the Source Connection ID supplied by the server as the 1638 Destination Connection ID for subsequent packets, including any 1639 subsequent 0-RTT packets. That means that a client might change the 1640 Destination Connection ID twice during connection establishment, once 1641 in response to a Retry and once in response to the first Initial 1642 packet from the server. Once a client has received an Initial packet 1643 from the server, it MUST discard any packet it receives with a 1644 different Source Connection ID. 1646 A client MUST only change the value it sends in the Destination 1647 Connection ID in response to the first packet of each type it 1648 receives from the server (Retry or Initial); a server MUST set its 1649 value based on the Initial packet. Any additional changes are not 1650 permitted; if subsequent packets of those types include a different 1651 Source Connection ID, they MUST be discarded. This avoids problems 1652 that might arise from stateless processing of multiple Initial 1653 packets producing different connection IDs. 1655 The connection ID can change over the lifetime of a connection, 1656 especially in response to connection migration (Section 9); see 1657 Section 5.1.1 for details. 1659 7.3. Transport Parameters 1661 During connection establishment, both endpoints make authenticated 1662 declarations of their transport parameters. These declarations are 1663 made unilaterally by each endpoint. Endpoints are required to comply 1664 with the restrictions implied by these parameters; the description of 1665 each parameter includes rules for its handling. 1667 The encoding of the transport parameters is detailed in Section 18. 1669 QUIC includes the encoded transport parameters in the cryptographic 1670 handshake. Once the handshake completes, the transport parameters 1671 declared by the peer are available. Each endpoint validates the 1672 value provided by its peer. 1674 Definitions for each of the defined transport parameters are included 1675 in Section 18.2. 1677 An endpoint MUST treat receipt of a transport parameter with an 1678 invalid value as a connection error of type 1679 TRANSPORT_PARAMETER_ERROR. 1681 An endpoint MUST NOT send a parameter more than once in a given 1682 transport parameters extension. An endpoint SHOULD treat receipt of 1683 duplicate transport parameters as a connection error of type 1684 TRANSPORT_PARAMETER_ERROR. 1686 A server MUST include the original_connection_id transport parameter 1687 (Section 18.2) if it sent a Retry packet to enable validation of the 1688 Retry, as described in Section 17.2.5. 1690 7.3.1. Values of Transport Parameters for 0-RTT 1692 Both endpoints store the value of the server transport parameters 1693 from a connection and apply them to any 0-RTT packets that are sent 1694 in subsequent connections to that peer, except for transport 1695 parameters that are explicitly excluded. Remembered transport 1696 parameters apply to the new connection until the handshake completes 1697 and the client starts sending 1-RTT packets. Once the handshake 1698 completes, the client uses the transport parameters established in 1699 the handshake. 1701 The definition of new transport parameters (Section 7.3.2) MUST 1702 specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A 1703 client need not store a transport parameter it cannot process. 1705 A client MUST NOT use remembered values for the following parameters: 1706 original_connection_id, preferred_address, stateless_reset_token, 1707 ack_delay_exponent and active_connection_id_limit. The client MUST 1708 use the server's new values in the handshake instead, and absent new 1709 values from the server, the default value. 1711 A client that attempts to send 0-RTT data MUST remember all other 1712 transport parameters used by the server. The server can remember 1713 these transport parameters, or store an integrity-protected copy of 1714 the values in the ticket and recover the information when accepting 1715 0-RTT data. A server uses the transport parameters in determining 1716 whether to accept 0-RTT data. 1718 If 0-RTT data is accepted by the server, the server MUST NOT reduce 1719 any limits or alter any values that might be violated by the client 1720 with its 0-RTT data. In particular, a server that accepts 0-RTT data 1721 MUST NOT set values for the following parameters (Section 18.2) that 1722 are smaller than the remembered value of the parameters. 1724 o initial_max_data 1726 o initial_max_stream_data_bidi_local 1728 o initial_max_stream_data_bidi_remote 1730 o initial_max_stream_data_uni 1732 o initial_max_streams_bidi 1734 o initial_max_streams_uni 1736 Omitting or setting a zero value for certain transport parameters can 1737 result in 0-RTT data being enabled, but not usable. The applicable 1738 subset of transport parameters that permit sending of application 1739 data SHOULD be set to non-zero values for 0-RTT. This includes 1740 initial_max_data and either initial_max_streams_bidi and 1741 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 1742 initial_max_stream_data_uni. 1744 A server MUST either reject 0-RTT data or abort a handshake if the 1745 implied values for transport parameters cannot be supported. 1747 When sending frames in 0-RTT packets, a client MUST only use 1748 remembered transport parameters; importantly, it MUST NOT use updated 1749 values that it learns from the server's updated transport parameters 1750 or from frames received in 1-RTT packets. Updated values of 1751 transport parameters from the handshake apply only to 1-RTT packets. 1752 For instance, flow control limits from remembered transport 1753 parameters apply to all 0-RTT packets even if those values are 1754 increased by the handshake or by frames sent in 1-RTT packets. A 1755 server MAY treat use of updated transport parameters in 0-RTT as a 1756 connection error of type PROTOCOL_VIOLATION. 1758 7.3.2. New Transport Parameters 1760 New transport parameters can be used to negotiate new protocol 1761 behavior. An endpoint MUST ignore transport parameters that it does 1762 not support. Absence of a transport parameter therefore disables any 1763 optional protocol feature that is negotiated using the parameter. As 1764 described in Section 18.1, some identifiers are reserved in order to 1765 exercise this requirement. 1767 New transport parameters can be registered according to the rules in 1768 Section 22.1. 1770 7.4. Cryptographic Message Buffering 1772 Implementations need to maintain a buffer of CRYPTO data received out 1773 of order. Because there is no flow control of CRYPTO frames, an 1774 endpoint could potentially force its peer to buffer an unbounded 1775 amount of data. 1777 Implementations MUST support buffering at least 4096 bytes of data 1778 received in CRYPTO frames out of order. Endpoints MAY choose to 1779 allow more data to be buffered during the handshake. A larger limit 1780 during the handshake could allow for larger keys or credentials to be 1781 exchanged. An endpoint's buffer size does not need to remain 1782 constant during the life of the connection. 1784 Being unable to buffer CRYPTO frames during the handshake can lead to 1785 a connection failure. If an endpoint's buffer is exceeded during the 1786 handshake, it can expand its buffer temporarily to complete the 1787 handshake. If an endpoint does not expand its buffer, it MUST close 1788 the connection with a CRYPTO_BUFFER_EXCEEDED error code. 1790 Once the handshake completes, if an endpoint is unable to buffer all 1791 data in a CRYPTO frame, it MAY discard that CRYPTO frame and all 1792 CRYPTO frames received in the future, or it MAY close the connection 1793 with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing 1794 discarded CRYPTO frames MUST be acknowledged because the packet has 1795 been received and processed by the transport even though the CRYPTO 1796 frame was discarded. 1798 8. Address Validation 1800 Address validation is used by QUIC to avoid being used for a traffic 1801 amplification attack. In such an attack, a packet is sent to a 1802 server with spoofed source address information that identifies a 1803 victim. If a server generates more or larger packets in response to 1804 that packet, the attacker can use the server to send more data toward 1805 the victim than it would be able to send on its own. 1807 The primary defense against amplification attack is verifying that an 1808 endpoint is able to receive packets at the transport address that it 1809 claims. Address validation is performed both during connection 1810 establishment (see Section 8.1) and during connection migration (see 1811 Section 8.2). 1813 8.1. Address Validation During Connection Establishment 1815 Connection establishment implicitly provides address validation for 1816 both endpoints. In particular, receipt of a packet protected with 1817 Handshake keys confirms that the client received the Initial packet 1818 from the server. Once the server has successfully processed a 1819 Handshake packet from the client, it can consider the client address 1820 to have been validated. 1822 Prior to validating the client address, servers MUST NOT send more 1823 than three times as many bytes as the number of bytes they have 1824 received. This limits the magnitude of any amplification attack that 1825 can be mounted using spoofed source addresses. In determining this 1826 limit, servers only count the size of successfully processed packets. 1828 Clients MUST ensure that UDP datagrams containing Initial packets 1829 have UDP payloads of at least 1200 bytes, adding padding to packets 1830 in the datagram as necessary. Sending padded datagrams ensures that 1831 the server is not overly constrained by the amplification 1832 restriction. 1834 Packet loss, in particular loss of a Handshake packet from the 1835 server, can cause a situation in which the server cannot send when 1836 the client has no data to send and the anti-amplification limit is 1837 reached. In order to avoid this causing a handshake deadlock, 1838 clients SHOULD send a packet upon a probe timeout, as described in 1839 [QUIC-RECOVERY]. If the client has no data to retransmit and does 1840 not have Handshake keys, it SHOULD send an Initial packet in a UDP 1841 datagram of at least 1200 bytes. If the client has Handshake keys, 1842 it SHOULD send a Handshake packet. 1844 A server might wish to validate the client address before starting 1845 the cryptographic handshake. QUIC uses a token in the Initial packet 1846 to provide address validation prior to completing the handshake. 1847 This token is delivered to the client during connection establishment 1848 with a Retry packet (see Section 8.1.1) or in a previous connection 1849 using the NEW_TOKEN frame (see Section 8.1.2). 1851 In addition to sending limits imposed prior to address validation, 1852 servers are also constrained in what they can send by the limits set 1853 by the congestion controller. Clients are only constrained by the 1854 congestion controller. 1856 8.1.1. Address Validation using Retry Packets 1858 Upon receiving the client's Initial packet, the server can request 1859 address validation by sending a Retry packet (Section 17.2.5) 1860 containing a token. This token MUST be repeated by the client in all 1861 Initial packets it sends for that connection after it receives the 1862 Retry packet. In response to processing an Initial containing a 1863 token, a server can either abort the connection or permit it to 1864 proceed. 1866 As long as it is not possible for an attacker to generate a valid 1867 token for its own address (see Section 8.1.3) and the client is able 1868 to return that token, it proves to the server that it received the 1869 token. 1871 A server can also use a Retry packet to defer the state and 1872 processing costs of connection establishment. Requiring the server 1873 to provide a different connection ID, along with the 1874 original_connection_id transport parameter defined in Section 18.2, 1875 forces the server to demonstrate that it, or an entity it cooperates 1876 with, received the original Initial packet from the client. 1877 Providing a different connection ID also grants a server some control 1878 over how subsequent packets are routed. This can be used to direct 1879 connections to a different server instance. 1881 A flow showing the use of a Retry packet is shown in Figure 5. 1883 Client Server 1885 Initial[0]: CRYPTO[CH] -> 1887 <- Retry+Token 1889 Initial+Token[1]: CRYPTO[CH] -> 1891 Initial[0]: CRYPTO[SH] ACK[1] 1892 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1893 <- 1-RTT[0]: STREAM[1, "..."] 1895 Figure 5: Example Handshake with Retry 1897 8.1.2. Address Validation for Future Connections 1899 A server MAY provide clients with an address validation token during 1900 one connection that can be used on a subsequent connection. Address 1901 validation is especially important with 0-RTT because a server 1902 potentially sends a significant amount of data to a client in 1903 response to 0-RTT data. 1905 The server uses the NEW_TOKEN frame Section 19.7 to provide the 1906 client with an address validation token that can be used to validate 1907 future connections. The client includes this token in Initial 1908 packets to provide address validation in a future connection. The 1909 client MUST include the token in all Initial packets it sends, unless 1910 a Retry replaces the token with a newer one. The client MUST NOT use 1911 the token provided in a Retry for future connections. Servers MAY 1912 discard any Initial packet that does not carry the expected token. 1914 A token SHOULD be constructed in a way that allows the server to 1915 distinguish it from tokens that are sent in Retry packets as they are 1916 carried in the same field. 1918 The token MUST NOT include information that would allow it to be 1919 linked by an on-path observer to the connection on which it was 1920 issued. For example, it cannot include the connection ID or 1921 addressing information unless the values are encrypted. 1923 Unlike the token that is created for a Retry packet, there might be 1924 some time between when the token is created and when the token is 1925 subsequently used. Thus, a token SHOULD have an expiration time, 1926 which could be either an explicit expiration time or an issued 1927 timestamp that can be used to dynamically calculate the expiration 1928 time. A server can store the expiration time or include it in an 1929 encrypted form in the token. 1931 It is unlikely that the client port number is the same on two 1932 different connections; validating the port is therefore unlikely to 1933 be successful. 1935 If the client has a token received in a NEW_TOKEN frame on a previous 1936 connection to what it believes to be the same server, it SHOULD 1937 include that value in the Token field of its Initial packet. 1938 Including a token might allow the server to validate the client 1939 address without an additional round trip. 1941 A token allows a server to correlate activity between the connection 1942 where the token was issued and any connection where it is used. 1943 Clients that want to break continuity of identity with a server MAY 1944 discard tokens provided using the NEW_TOKEN frame. A token obtained 1945 in a Retry packet MUST be used immediately during the connection 1946 attempt and cannot be used in subsequent connection attempts. 1948 A client SHOULD NOT reuse a token in different connections. Reusing 1949 a token allows connections to be linked by entities on the network 1950 path; see Section 9.5. A client MUST NOT reuse a token if it 1951 believes that its point of network attachment has changed since the 1952 token was last used; that is, if there is a change in its local IP 1953 address or network interface. A client needs to start the connection 1954 process over if there is any change in its local address prior to 1955 completing the handshake. 1957 Clients might receive multiple tokens on a single connection. Aside 1958 from preventing linkability, any token can be used in any connection 1959 attempt. Servers can send additional tokens to either enable address 1960 validation for multiple connection attempts or to replace older 1961 tokens that might become invalid. For a client, this ambiguity means 1962 that sending the most recent unused token is most likely to be 1963 effective. Though saving and using older tokens has no negative 1964 consequences, clients can regard older tokens as being less likely be 1965 useful to the server for address validation. 1967 When a server receives an Initial packet with an address validation 1968 token, it MUST attempt to validate the token, unless it has already 1969 completed address validation. If the token is invalid then the 1970 server SHOULD proceed as if the client did not have a validated 1971 address, including potentially sending a Retry. If the validation 1972 succeeds, the server SHOULD then allow the handshake to proceed. 1974 Note: The rationale for treating the client as unvalidated rather 1975 than discarding the packet is that the client might have received 1976 the token in a previous connection using the NEW_TOKEN frame, and 1977 if the server has lost state, it might be unable to validate the 1978 token at all, leading to connection failure if the packet is 1979 discarded. A server SHOULD encode tokens provided with NEW_TOKEN 1980 frames and Retry packets differently, and validate the latter more 1981 strictly. 1983 In a stateless design, a server can use encrypted and authenticated 1984 tokens to pass information to clients that the server can later 1985 recover and use to validate a client address. Tokens are not 1986 integrated into the cryptographic handshake and so they are not 1987 authenticated. For instance, a client might be able to reuse a 1988 token. To avoid attacks that exploit this property, a server can 1989 limit its use of tokens to only the information needed to validate 1990 client addresses. 1992 Attackers could replay tokens to use servers as amplifiers in DDoS 1993 attacks. To protect against such attacks, servers SHOULD ensure that 1994 tokens sent in Retry packets are only accepted for a short time. 1995 Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need 1996 to be valid for longer, but SHOULD NOT be accepted multiple times in 1997 a short period. Servers are encouraged to allow tokens to be used 1998 only once, if possible. 2000 8.1.3. Address Validation Token Integrity 2002 An address validation token MUST be difficult to guess. Including a 2003 large enough random value in the token would be sufficient, but this 2004 depends on the server remembering the value it sends to clients. 2006 A token-based scheme allows the server to offload any state 2007 associated with validation to the client. For this design to work, 2008 the token MUST be covered by integrity protection against 2009 modification or falsification by clients. Without integrity 2010 protection, malicious clients could generate or guess values for 2011 tokens that would be accepted by the server. Only the server 2012 requires access to the integrity protection key for tokens. 2014 There is no need for a single well-defined format for the token 2015 because the server that generates the token also consumes it. A 2016 token could include information about the claimed client address (IP 2017 and port), a timestamp, and any other supplementary information the 2018 server will need to validate the token in the future. 2020 8.2. Path Validation 2022 Path validation is used during connection migration (see Section 9 2023 and Section 9.6) by the migrating endpoint to verify reachability of 2024 a peer from a new local address. In path validation, endpoints test 2025 reachability between a specific local address and a specific peer 2026 address, where an address is the two-tuple of IP address and port. 2028 Path validation tests that packets (PATH_CHALLENGE) can be both sent 2029 to and received (PATH_RESPONSE) from a peer on the path. 2030 Importantly, it validates that the packets received from the 2031 migrating endpoint do not carry a spoofed source address. 2033 Path validation can be used at any time by either endpoint. For 2034 instance, an endpoint might check that a peer is still in possession 2035 of its address after a period of quiescence. 2037 Path validation is not designed as a NAT traversal mechanism. Though 2038 the mechanism described here might be effective for the creation of 2039 NAT bindings that support NAT traversal, the expectation is that one 2040 or other peer is able to receive packets without first having sent a 2041 packet on that path. Effective NAT traversal needs additional 2042 synchronization mechanisms that are not provided here. 2044 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 2045 are used for path validation with other frames. In particular, an 2046 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 2047 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 2048 PATH_CHALLENGE. 2050 When probing a new path, an endpoint might want to ensure that its 2051 peer has an unused connection ID available for responses. The 2052 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 2053 same packet. This ensures that an unused connection ID will be 2054 available to the peer when sending a response. 2056 8.3. Initiating Path Validation 2058 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 2059 containing a random payload on the path to be validated. 2061 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 2062 packet loss. However, an endpoint SHOULD NOT send multiple 2063 PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT 2064 send a PATH_CHALLENGE more frequently than it would an Initial 2065 packet, ensuring that connection migration is no more load on a new 2066 path than establishing a new connection. 2068 The endpoint MUST use unpredictable data in every PATH_CHALLENGE 2069 frame so that it can associate the peer's response with the 2070 corresponding PATH_CHALLENGE. 2072 8.4. Path Validation Responses 2074 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 2075 immediately by echoing the data contained in the PATH_CHALLENGE frame 2076 in a PATH_RESPONSE frame. 2078 An endpoint MUST NOT send more than one PATH_RESPONSE frame in 2079 response to one PATH_CHALLENGE frame (see Section 13.3). The peer is 2080 expected to send more PATH_CHALLENGE frames as necessary to evoke 2081 additional PATH_RESPONSE frames. 2083 8.5. Successful Path Validation 2085 A new address is considered valid when a PATH_RESPONSE frame is 2086 received that contains the data that was sent in a previous 2087 PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing 2088 a PATH_CHALLENGE frame is not adequate validation, since the 2089 acknowledgment can be spoofed by a malicious peer. 2091 Note that receipt on a different local address does not result in 2092 path validation failure, as it might be a result of a forwarded 2093 packet (see Section 9.3.3) or misrouting. It is possible that a 2094 valid PATH_RESPONSE might be received in the future. 2096 8.6. Failed Path Validation 2098 Path validation only fails when the endpoint attempting to validate 2099 the path abandons its attempt to validate the path. 2101 Endpoints SHOULD abandon path validation based on a timer. When 2102 setting this timer, implementations are cautioned that the new path 2103 could have a longer round-trip time than the original. A value of 2104 three times the larger of the current Probe Timeout (PTO) or the 2105 initial timeout (that is, 2*kInitialRtt) as defined in 2106 [QUIC-RECOVERY] is RECOMMENDED. That is: 2108 validation_timeout = max(3*PTO, 6*kInitialRtt) 2110 Note that the endpoint might receive packets containing other frames 2111 on the new path, but a PATH_RESPONSE frame with appropriate data is 2112 required for path validation to succeed. 2114 When an endpoint abandons path validation, it determines that the 2115 path is unusable. This does not necessarily imply a failure of the 2116 connection - endpoints can continue sending packets over other paths 2117 as appropriate. If no paths are available, an endpoint can wait for 2118 a new path to become available or close the connection. 2120 A path validation might be abandoned for other reasons besides 2121 failure. Primarily, this happens if a connection migration to a new 2122 path is initiated while a path validation on the old path is in 2123 progress. 2125 9. Connection Migration 2127 The use of a connection ID allows connections to survive changes to 2128 endpoint addresses (IP address and port), such as those caused by an 2129 endpoint migrating to a new network. This section describes the 2130 process by which an endpoint migrates to a new address. 2132 The design of QUIC relies on endpoints retaining a stable address for 2133 the duration of the handshake. An endpoint MUST NOT initiate 2134 connection migration before the handshake is confirmed, as defined in 2135 section 4.1.2 of [QUIC-TLS]. 2137 An endpoint also MUST NOT send packets from a different local 2138 address, actively initiating migration, if the peer sent the 2139 "disable_active_migration" transport parameter during the handshake. 2140 An endpoint which has sent this transport parameter, but detects that 2141 a peer has nonetheless migrated to a different network MUST either 2142 drop the incoming packets on that path without generating a stateless 2143 reset or proceed with path validation and allow the peer to migrate. 2144 Generating a stateless reset or closing the connection would allow 2145 third parties in the network to cause connections to close by 2146 spoofing or otherwise manipulating observed traffic. 2148 Not all changes of peer address are intentional, or active, 2149 migrations. The peer could experience NAT rebinding: a change of 2150 address due to a middlebox, usually a NAT, allocating a new outgoing 2151 port or even a new outgoing IP address for a flow. An endpoint MUST 2152 perform path validation (Section 8.2) if it detects any change to a 2153 peer's address, unless it has previously validated that address. 2155 When an endpoint has no validated path on which to send packets, it 2156 MAY discard connection state. An endpoint capable of connection 2157 migration MAY wait for a new path to become available before 2158 discarding connection state. 2160 This document limits migration of connections to new client 2161 addresses, except as described in Section 9.6. Clients are 2162 responsible for initiating all migrations. Servers do not send non- 2163 probing packets (see Section 9.1) toward a client address until they 2164 see a non-probing packet from that address. If a client receives 2165 packets from an unknown server address, the client MUST discard these 2166 packets. 2168 9.1. Probing a New Path 2170 An endpoint MAY probe for peer reachability from a new local address 2171 using path validation Section 8.2 prior to migrating the connection 2172 to the new local address. Failure of path validation simply means 2173 that the new path is not usable for this connection. Failure to 2174 validate a path does not cause the connection to end unless there are 2175 no valid alternative paths available. 2177 An endpoint uses a new connection ID for probes sent from a new local 2178 address, see Section 9.5 for further discussion. An endpoint that 2179 uses a new local address needs to ensure that at least one new 2180 connection ID is available at the peer. That can be achieved by 2181 including a NEW_CONNECTION_ID frame in the probe. 2183 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2184 is probing for reachability on a path. An endpoint sends a 2185 PATH_RESPONSE in response as per Section 8.2. 2187 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2188 are "probing frames", and all other frames are "non-probing frames". 2189 A packet containing only probing frames is a "probing packet", and a 2190 packet containing any other frame is a "non-probing packet". 2192 9.2. Initiating Connection Migration 2194 An endpoint can migrate a connection to a new local address by 2195 sending packets containing non-probing frames from that address. 2197 Each endpoint validates its peer's address during connection 2198 establishment. Therefore, a migrating endpoint can send to its peer 2199 knowing that the peer is willing to receive at the peer's current 2200 address. Thus an endpoint can migrate to a new local address without 2201 first validating the peer's address. 2203 When migrating, the new path might not support the endpoint's current 2204 sending rate. Therefore, the endpoint resets its congestion 2205 controller, as described in Section 9.4. 2207 The new path might not have the same ECN capability. Therefore, the 2208 endpoint verifies ECN capability as described in Section 13.4. 2210 Receiving acknowledgments for data sent on the new path serves as 2211 proof of the peer's reachability from the new address. Note that 2212 since acknowledgments may be received on any path, return 2213 reachability on the new path is not established. To establish return 2214 reachability on the new path, an endpoint MAY concurrently initiate 2215 path validation Section 8.2 on the new path. 2217 9.3. Responding to Connection Migration 2219 Receiving a packet from a new peer address containing a non-probing 2220 frame indicates that the peer has migrated to that address. 2222 In response to such a packet, an endpoint MUST start sending 2223 subsequent packets to the new peer address and MUST initiate path 2224 validation (Section 8.2) to verify the peer's ownership of the 2225 unvalidated address. 2227 An endpoint MAY send data to an unvalidated peer address, but it MUST 2228 protect against potential attacks as described in Section 9.3.1 and 2229 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2230 that address has been seen recently. 2232 An endpoint only changes the address that it sends packets to in 2233 response to the highest-numbered non-probing packet. This ensures 2234 that an endpoint does not send packets to an old peer address in the 2235 case that it receives reordered packets. 2237 After changing the address to which it sends non-probing packets, an 2238 endpoint could abandon any path validation for other addresses. 2240 Receiving a packet from a new peer address might be the result of a 2241 NAT rebinding at the peer. 2243 After verifying a new client address, the server SHOULD send new 2244 address validation tokens (Section 8) to the client. 2246 9.3.1. Peer Address Spoofing 2248 It is possible that a peer is spoofing its source address to cause an 2249 endpoint to send excessive amounts of data to an unwilling host. If 2250 the endpoint sends significantly more data than the spoofing peer, 2251 connection migration might be used to amplify the volume of data that 2252 an attacker can generate toward a victim. 2254 As described in Section 9.3, an endpoint is required to validate a 2255 peer's new address to confirm the peer's possession of the new 2256 address. Until a peer's address is deemed valid, an endpoint MUST 2257 limit the rate at which it sends data to this address. The endpoint 2258 MUST NOT send more than a minimum congestion window's worth of data 2259 per estimated round-trip time (kMinimumWindow, as defined in 2260 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2261 being used for a denial of service attack against an unsuspecting 2262 victim. Note that since the endpoint will not have any round-trip 2263 time measurements to this address, the estimate SHOULD be the default 2264 initial value (see [QUIC-RECOVERY]). 2266 If an endpoint skips validation of a peer address as described in 2267 Section 9.3, it does not need to limit its sending rate. 2269 9.3.2. On-Path Address Spoofing 2271 An on-path attacker could cause a spurious connection migration by 2272 copying and forwarding a packet with a spoofed address such that it 2273 arrives before the original packet. The packet with the spoofed 2274 address will be seen to come from a migrating connection, and the 2275 original packet will be seen as a duplicate and dropped. After a 2276 spurious migration, validation of the source address will fail 2277 because the entity at the source address does not have the necessary 2278 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2279 that is sent to it even if it wanted to. 2281 To protect the connection from failing due to such a spurious 2282 migration, an endpoint MUST revert to using the last validated peer 2283 address when validation of a new peer address fails. 2285 If an endpoint has no state about the last validated peer address, it 2286 MUST close the connection silently by discarding all connection 2287 state. This results in new packets on the connection being handled 2288 generically. For instance, an endpoint MAY send a stateless reset in 2289 response to any further incoming packets. 2291 Note that receipt of packets with higher packet numbers from the 2292 legitimate peer address will trigger another connection migration. 2293 This will cause the validation of the address of the spurious 2294 migration to be abandoned. 2296 9.3.3. Off-Path Packet Forwarding 2298 An off-path attacker that can observe packets might forward copies of 2299 genuine packets to endpoints. If the copied packet arrives before 2300 the genuine packet, this will appear as a NAT rebinding. Any genuine 2301 packet will be discarded as a duplicate. If the attacker is able to 2302 continue forwarding packets, it might be able to cause migration to a 2303 path via the attacker. This places the attacker on path, giving it 2304 the ability to observe or drop all subsequent packets. 2306 Unlike the attack described in Section 9.3.2, the attacker can ensure 2307 that the new path is successfully validated. 2309 This style of attack relies on the attacker using a path that is 2310 approximately as fast as the direct path between endpoints. The 2311 attack is more reliable if relatively few packets are sent or if 2312 packet loss coincides with the attempted attack. 2314 A non-probing packet received on the original path that increases the 2315 maximum received packet number will cause the endpoint to move back 2316 to that path. Eliciting packets on this path increases the 2317 likelihood that the attack is unsuccessful. Therefore, mitigation of 2318 this attack relies on triggering the exchange of packets. 2320 In response to an apparent migration, endpoints MUST validate the 2321 previously active path using a PATH_CHALLENGE frame. This induces 2322 the sending of new packets on that path. If the path is no longer 2323 viable, the validation attempt will time out and fail; if the path is 2324 viable, but no longer desired, the validation will succeed, but only 2325 results in probing packets being sent on the path. 2327 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2328 send a non-probing packet in response. If the non-probing packet 2329 arrives before any copy made by an attacker, this results in the 2330 connection being migrated back to the original path. Any subsequent 2331 migration to another path restarts this entire process. 2333 This defense is imperfect, but this is not considered a serious 2334 problem. If the path via the attack is reliably faster than the 2335 original path despite multiple attempts to use that original path, it 2336 is not possible to distinguish between attack and an improvement in 2337 routing. 2339 An endpoint could also use heuristics to improve detection of this 2340 style of attack. For instance, NAT rebinding is improbable if 2341 packets were recently received on the old path, similarly rebinding 2342 is rare on IPv6 paths. Endpoints can also look for duplicated 2343 packets. Conversely, a change in connection ID is more likely to 2344 indicate an intentional migration rather than an attack. 2346 9.4. Loss Detection and Congestion Control 2348 The capacity available on the new path might not be the same as the 2349 old path. Packets sent on the old path SHOULD NOT contribute to 2350 congestion control or RTT estimation for the new path. 2352 On confirming a peer's ownership of its new address, an endpoint MUST 2353 immediately reset the congestion controller and round-trip time 2354 estimator for the new path to initial values (see Sections A.3 and 2355 B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send 2356 rate or round-trip time estimate is valid for the new path. For 2357 instance, an endpoint might infer that a change in only the client's 2358 port number is indicative of a NAT rebinding, meaning that the new 2359 path is likely to have similar bandwidth and round-trip time. 2360 However, this determination will be imperfect. If the determination 2361 is incorrect, the congestion controller and the RTT estimator are 2362 expected to adapt to the new path. Generally, implementations are 2363 advised to be cautious when using previous values on a new path. 2365 There may be apparent reordering at the receiver when an endpoint 2366 sends data and probes from/to multiple addresses during the migration 2367 period, since the two resulting paths may have different round-trip 2368 times. A receiver of packets on multiple paths will still send ACK 2369 frames covering all received packets. 2371 While multiple paths might be used during connection migration, a 2372 single congestion control context and a single loss recovery context 2373 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2374 endpoint might delay switching to a new congestion control context 2375 until it is confirmed that an old path is no longer needed (such as 2376 the case in Section 9.3.3). 2378 A sender can make exceptions for probe packets so that their loss 2379 detection is independent and does not unduly cause the congestion 2380 controller to reduce its sending rate. An endpoint might set a 2381 separate timer when a PATH_CHALLENGE is sent, which is cancelled when 2382 the corresponding PATH_RESPONSE is received. If the timer fires 2383 before the PATH_RESPONSE is received, the endpoint might send a new 2384 PATH_CHALLENGE, and restart the timer for a longer period of time. 2386 9.5. Privacy Implications of Connection Migration 2388 Using a stable connection ID on multiple network paths allows a 2389 passive observer to correlate activity between those paths. An 2390 endpoint that moves between networks might not wish to have their 2391 activity correlated by any entity other than their peer, so different 2392 connection IDs are used when sending from different local addresses, 2393 as discussed in Section 5.1. For this to be effective endpoints need 2394 to ensure that connection IDs they provide cannot be linked by any 2395 other entity. 2397 At any time, endpoints MAY change the Destination Connection ID they 2398 send to a value that has not been used on another path. 2400 An endpoint MUST use a new connection ID if it initiates connection 2401 migration as described in Section 9.2 or probes a new network path as 2402 described in Section 9.1. An endpoint MUST use a new connection ID 2403 in response to a change in the address of a peer if the packet with 2404 the new peer address uses an active connection ID that has not been 2405 previously used by the peer. 2407 Using different connection IDs for packets sent in both directions on 2408 each new network path eliminates the use of the connection ID for 2409 linking packets from the same connection across different network 2410 paths. Header protection ensures that packet numbers cannot be used 2411 to correlate activity. This does not prevent other properties of 2412 packets, such as timing and size, from being used to correlate 2413 activity. 2415 Unintentional changes in path without a change in connection ID are 2416 possible. For example, after a period of network inactivity, NAT 2417 rebinding might cause packets to be sent on a new path when the 2418 client resumes sending. 2420 A client might wish to reduce linkability by employing a new 2421 connection ID and source UDP port when sending traffic after a period 2422 of inactivity. Changing the UDP port from which it sends packets at 2423 the same time might cause the packet to appear as a connection 2424 migration. This ensures that the mechanisms that support migration 2425 are exercised even for clients that don't experience NAT rebindings 2426 or genuine migrations. Changing port number can cause a peer to 2427 reset its congestion state (see Section 9.4), so the port SHOULD only 2428 be changed infrequently. 2430 An endpoint that exhausts available connection IDs cannot probe new 2431 paths or initiate migration, nor can it respond to probes or attempts 2432 by its peer to migrate. To ensure that migration is possible and 2433 packets sent on different paths cannot be correlated, endpoints 2434 SHOULD provide new connection IDs before peers migrate; see 2435 Section 5.1.1. If a peer might have exhausted available connection 2436 IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in 2437 all packets sent on a new network path. 2439 9.6. Server's Preferred Address 2441 QUIC allows servers to accept connections on one IP address and 2442 attempt to transfer these connections to a more preferred address 2443 shortly after the handshake. This is particularly useful when 2444 clients initially connect to an address shared by multiple servers 2445 but would prefer to use a unicast address to ensure connection 2446 stability. This section describes the protocol for migrating a 2447 connection to a preferred server address. 2449 Migrating a connection to a new server address mid-connection is left 2450 for future work. If a client receives packets from a new server 2451 address not indicated by the preferred_address transport parameter, 2452 the client SHOULD discard these packets. 2454 9.6.1. Communicating a Preferred Address 2456 A server conveys a preferred address by including the 2457 preferred_address transport parameter in the TLS handshake. 2459 Servers MAY communicate a preferred address of each address family 2460 (IPv4 and IPv6) to allow clients to pick the one most suited to their 2461 network attachment. 2463 Once the handshake is finished, the client SHOULD select one of the 2464 two server's preferred addresses and initiate path validation (see 2465 Section 8.2) of that address using the connection ID provided in the 2466 preferred_address transport parameter. 2468 If path validation succeeds, the client SHOULD immediately begin 2469 sending all future packets to the new server address using the new 2470 connection ID and discontinue use of the old server address. If path 2471 validation fails, the client MUST continue sending all future packets 2472 to the server's original IP address. 2474 9.6.2. Responding to Connection Migration 2476 A server might receive a packet addressed to its preferred IP address 2477 at any time after it accepts a connection. If this packet contains a 2478 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2479 Section 8.2. The server MUST send other non-probing frames from its 2480 original address until it receives a non-probing packet from the 2481 client at its preferred address and until the server has validated 2482 the new path. 2484 The server MUST probe on the path toward the client from its 2485 preferred address. This helps to guard against spurious migration 2486 initiated by an attacker. 2488 Once the server has completed its path validation and has received a 2489 non-probing packet with a new largest packet number on its preferred 2490 address, the server begins sending non-probing packets to the client 2491 exclusively from its preferred IP address. It SHOULD drop packets 2492 for this connection received on the old IP address, but MAY continue 2493 to process delayed packets. 2495 9.6.3. Interaction of Client Migration and Preferred Address 2497 A client might need to perform a connection migration before it has 2498 migrated to the server's preferred address. In this case, the client 2499 SHOULD perform path validation to both the original and preferred 2500 server address from the client's new address concurrently. 2502 If path validation of the server's preferred address succeeds, the 2503 client MUST abandon validation of the original address and migrate to 2504 using the server's preferred address. If path validation of the 2505 server's preferred address fails but validation of the server's 2506 original address succeeds, the client MAY migrate to its new address 2507 and continue sending to the server's original address. 2509 If the connection to the server's preferred address is not from the 2510 same client address, the server MUST protect against potential 2511 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2512 to intentional simultaneous migration, this might also occur because 2513 the client's access network used a different NAT binding for the 2514 server's preferred address. 2516 Servers SHOULD initiate path validation to the client's new address 2517 upon receiving a probe packet from a different address. Servers MUST 2518 NOT send more than a minimum congestion window's worth of non-probing 2519 packets to the new address before path validation is complete. 2521 A client that migrates to a new address SHOULD use a preferred 2522 address from the same address family for the server. 2524 9.7. Use of IPv6 Flow-Label and Migration 2526 Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label 2527 in compliance with [RFC6437], unless the local API does not allow 2528 setting IPv6 flow labels. 2530 The IPv6 flow label SHOULD be a pseudo-random function of the source 2531 and destination addresses, source and destination UDP ports, and the 2532 destination CID. The flow label generation MUST be designed to 2533 minimize the chances of linkability with a previously used flow 2534 label, as this would enable correlating activity on multiple paths 2535 (see Section 9.5). 2537 A possible implementation is to compute the flow label as a 2538 cryptographic hash function of the source and destination addresses, 2539 source and destination UDP ports, destination CID, and a local 2540 secret. 2542 10. Connection Termination 2544 An established QUIC connection can be terminated in one of three 2545 ways: 2547 o idle timeout (Section 10.2) 2549 o immediate close (Section 10.3) 2551 o stateless reset (Section 10.4) 2553 An endpoint MAY discard connection state if it does not have a 2554 validated path on which it can send packets (see Section 8.2). 2556 10.1. Closing and Draining Connection States 2558 The closing and draining connection states exist to ensure that 2559 connections close cleanly and that delayed or reordered packets are 2560 properly discarded. These states SHOULD persist for at least three 2561 times the current Probe Timeout (PTO) interval as defined in 2562 [QUIC-RECOVERY]. 2564 An endpoint enters a closing period after initiating an immediate 2565 close (Section 10.3). While closing, an endpoint MUST NOT send 2566 packets unless they contain a CONNECTION_CLOSE frame (see 2567 Section 10.3 for details). An endpoint retains only enough 2568 information to generate a packet containing a CONNECTION_CLOSE frame 2569 and to identify packets as belonging to the connection. The 2570 endpoint's selected connection ID and the QUIC version are sufficient 2571 information to identify packets for a closing connection; an endpoint 2572 can discard all other connection state. An endpoint MAY retain 2573 packet protection keys for incoming packets to allow it to read and 2574 process a CONNECTION_CLOSE frame. 2576 The draining state is entered once an endpoint receives a signal that 2577 its peer is closing or draining. While otherwise identical to the 2578 closing state, an endpoint in the draining state MUST NOT send any 2579 packets. Retaining packet protection keys is unnecessary once a 2580 connection is in the draining state. 2582 An endpoint MAY transition from the closing period to the draining 2583 period if it receives a CONNECTION_CLOSE frame or stateless reset, 2584 both of which indicate that the peer is also closing or draining. 2585 The draining period SHOULD end when the closing period would have 2586 ended. In other words, the endpoint can use the same end time, but 2587 cease retransmission of the closing packet. 2589 Disposing of connection state prior to the end of the closing or 2590 draining period could cause delayed or reordered packets to generate 2591 an unnecessary stateless reset. Endpoints that have some alternative 2592 means to ensure that late-arriving packets on the connection do not 2593 induce a response, such as those that are able to close the UDP 2594 socket, MAY use an abbreviated draining period which can allow for 2595 faster resource recovery. Servers that retain an open socket for 2596 accepting new connections SHOULD NOT exit the closing or draining 2597 period early. 2599 Once the closing or draining period has ended, an endpoint SHOULD 2600 discard all connection state. This results in new packets on the 2601 connection being handled generically. For instance, an endpoint MAY 2602 send a stateless reset in response to any further incoming packets. 2604 The draining and closing periods do not apply when a stateless reset 2605 (Section 10.4) is sent. 2607 An endpoint is not expected to handle key updates when it is closing 2608 or draining. A key update might prevent the endpoint from moving 2609 from the closing state to draining, but it otherwise has no impact. 2611 While in the closing period, an endpoint could receive packets from a 2612 new source address, indicating a connection migration (Section 9). 2613 An endpoint in the closing state MUST strictly limit the number of 2614 packets it sends to this new address until the address is validated 2615 (see Section 8.2). A server in the closing state MAY instead choose 2616 to discard packets received from a new source address. 2618 10.2. Idle Timeout 2620 If the idle timeout is enabled, a connection is silently closed and 2621 the state is discarded when it remains idle for longer than both the 2622 advertised idle timeout (see Section 18.2) and three times the 2623 current Probe Timeout (PTO). 2625 Each endpoint advertises its own idle timeout to its peer. An 2626 endpoint restarts any timer it maintains when a packet from its peer 2627 is received and processed successfully. The timer is also restarted 2628 when sending an ack-eliciting packet (see [QUIC-RECOVERY]), but only 2629 if no other ack-eliciting packets have been sent since last receiving 2630 a packet. Restarting when sending packets ensures that connections 2631 do not prematurely time out when initiating new activity. 2633 The value for an idle timeout can be asymmetric. The value 2634 advertised by an endpoint is only used to determine whether the 2635 connection is live at that endpoint. An endpoint that sends packets 2636 near the end of the idle timeout period of a peer risks having those 2637 packets discarded if its peer enters the draining state before the 2638 packets arrive. If a peer could timeout within a Probe Timeout (PTO; 2639 see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for 2640 liveness before sending any data that cannot be retried safely. Note 2641 that it is likely that only applications or application protocols 2642 will know what information can be retried. 2644 10.3. Immediate Close 2646 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 2647 terminate the connection immediately. A CONNECTION_CLOSE frame 2648 causes all streams to immediately become closed; open streams can be 2649 assumed to be implicitly reset. 2651 After sending a CONNECTION_CLOSE frame, endpoints immediately enter 2652 the closing state. During the closing period, an endpoint that sends 2653 a CONNECTION_CLOSE frame SHOULD respond to any packet that it 2654 receives with another packet containing a CONNECTION_CLOSE frame. To 2655 minimize the state that an endpoint maintains for a closing 2656 connection, endpoints MAY send the exact same packet. However, 2657 endpoints SHOULD limit the number of packets they generate containing 2658 a CONNECTION_CLOSE frame. For instance, an endpoint could 2659 progressively increase the number of packets that it receives before 2660 sending additional packets or increase the time between packets. 2662 Note: Allowing retransmission of a closing packet contradicts other 2663 advice in this document that recommends the creation of new packet 2664 numbers for every packet. Sending new packet numbers is primarily 2665 of advantage to loss recovery and congestion control, which are 2666 not expected to be relevant for a closed connection. 2667 Retransmitting the final packet requires less state. 2669 New packets from unverified addresses could be used to create an 2670 amplification attack (see Section 8). To avoid this, endpoints MUST 2671 either limit transmission of CONNECTION_CLOSE frames to validated 2672 addresses or drop packets without response if the response would be 2673 more than three times larger than the received packet. 2675 After receiving a CONNECTION_CLOSE frame, endpoints enter the 2676 draining state. An endpoint that receives a CONNECTION_CLOSE frame 2677 MAY send a single packet containing a CONNECTION_CLOSE frame before 2678 entering the draining state, using a CONNECTION_CLOSE frame and a 2679 NO_ERROR code if appropriate. An endpoint MUST NOT send further 2680 packets, which could result in a constant exchange of 2681 CONNECTION_CLOSE frames until the closing period on either peer 2682 ended. 2684 An immediate close can be used after an application protocol has 2685 arranged to close a connection. This might be after the application 2686 protocols negotiates a graceful shutdown. The application protocol 2687 exchanges whatever messages that are needed to cause both endpoints 2688 to agree to close the connection, after which the application 2689 requests that the connection be closed. The application protocol can 2690 use a CONNECTION_CLOSE frame with an appropriate error code to signal 2691 closure. 2693 When sending CONNECTION_CLOSE, the goal is to ensure that the peer 2694 will process the frame. Generally, this means sending the frame in a 2695 packet with the highest level of packet protection to avoid the 2696 packet being discarded. However, during the handshake, it is 2697 possible that more advanced packet protection keys are not available 2698 to the peer, so the frame MAY be replicated in a packet that uses a 2699 lower packet protection level. 2701 After the handshake is confirmed, an endpoint MUST send any 2702 CONNECTION_CLOSE frames in a 1-RTT packet. Prior to handshake 2703 confirmation, the peer might not have 1-RTT keys, so the endpoint 2704 SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the 2705 endpoint does not have Handshake keys, it SHOULD send 2706 CONNECTION_CLOSE frames in an Initial packet. 2708 A client will always know whether the server has Handshake keys (see 2709 Section 17.2.2.1), but it is possible that a server does not know 2710 whether the client has Handshake keys. Under these circumstances, a 2711 server SHOULD send a CONNECTION_CLOSE frame in both Handshake and 2712 Initial packets to ensure that at least one of them is processable by 2713 the client. These packets can be coalesced into a single UDP 2714 datagram (see Section 12.2). 2716 10.4. Stateless Reset 2718 A stateless reset is provided as an option of last resort for an 2719 endpoint that does not have access to the state of a connection. A 2720 crash or outage might result in peers continuing to send data to an 2721 endpoint that is unable to properly continue the connection. An 2722 endpoint MAY send a stateless reset in response to receiving a packet 2723 that it cannot associate with an active connection. 2725 A stateless reset is not appropriate for signaling error conditions. 2726 An endpoint that wishes to communicate a fatal connection error MUST 2727 use a CONNECTION_CLOSE frame if it has sufficient state to do so. 2729 To support this process, a token is sent by endpoints. The token is 2730 carried in the Stateless Reset Token field of a NEW_CONNECTION_ID 2731 frame. Servers can also specify a stateless_reset_token transport 2732 parameter during the handshake that applies to the connection ID that 2733 it selected during the handshake; clients cannot use this transport 2734 parameter because their transport parameters don't have 2735 confidentiality protection. These tokens are protected by 2736 encryption, so only client and server know their value. Tokens are 2737 invalidated when their associated connection ID is retired via a 2738 RETIRE_CONNECTION_ID frame (Section 19.16). 2740 An endpoint that receives packets that it cannot process sends a 2741 packet in the following layout: 2743 0 1 2 3 2744 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 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 |0|1| Unpredictable Bits (38 ..) ... 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | | 2749 + + 2750 | | 2751 + Stateless Reset Token (128) + 2752 | | 2753 + + 2754 | | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 Figure 6: Stateless Reset Packet 2759 This design ensures that a stateless reset packet is - to the extent 2760 possible - indistinguishable from a regular packet with a short 2761 header. 2763 A stateless reset uses an entire UDP datagram, starting with the 2764 first two bits of the packet header. The remainder of the first byte 2765 and an arbitrary number of bytes following it that are set to 2766 unpredictable values. The last 16 bytes of the datagram contain a 2767 Stateless Reset Token. 2769 To entities other than its intended recipient, a stateless reset will 2770 appear to be a packet with a short header. For the stateless reset 2771 to appear as a valid QUIC packet, the Unpredictable Bits field needs 2772 to include at least 38 bits of data (or 5 bytes, less the two fixed 2773 bits). 2775 A minimum size of 21 bytes does not guarantee that a stateless reset 2776 is difficult to distinguish from other packets if the recipient 2777 requires the use of a connection ID. To prevent a resulting 2778 stateless reset from being trivially distinguishable from a valid 2779 packet, all packets sent by an endpoint SHOULD be padded to at least 2780 22 bytes longer than the minimum connection ID that the endpoint 2781 might use. An endpoint that sends a stateless reset in response to 2782 packet that is 43 bytes or less in length SHOULD send a stateless 2783 reset that is one byte shorter than the packet it responds to. 2785 These values assume that the Stateless Reset Token is the same as the 2786 minimum expansion of the packet protection AEAD. Additional 2787 unpredictable bytes are necessary if the endpoint could have 2788 negotiated a packet protection scheme with a larger minimum 2789 expansion. 2791 An endpoint MUST NOT send a stateless reset that is three times or 2792 more larger than the packet it receives to avoid being used for 2793 amplification. Section 10.4.3 describes additional limits on 2794 stateless reset size. 2796 Endpoints MUST discard packets that are too small to be valid QUIC 2797 packets. With the set of AEAD functions defined in [QUIC-TLS], 2798 packets that are smaller than 21 bytes are never valid. 2800 Endpoints MUST send stateless reset packets formatted as a packet 2801 with a short header. However, endpoints MUST treat any packet ending 2802 in a valid stateless reset token as a stateless reset, as other QUIC 2803 versions might allow the use of a long header. 2805 An endpoint MAY send a stateless reset in response to a packet with a 2806 long header. Sending a stateless reset is not effective prior to the 2807 stateless reset token being available to a peer. In this QUIC 2808 version, packets with a long header are only used during connection 2809 establishment. Because the stateless reset token is not available 2810 until connection establishment is complete or near completion, 2811 ignoring an unknown packet with a long header might be as effective 2812 as sending a stateless reset. 2814 An endpoint cannot determine the Source Connection ID from a packet 2815 with a short header, therefore it cannot set the Destination 2816 Connection ID in the stateless reset packet. The Destination 2817 Connection ID will therefore differ from the value used in previous 2818 packets. A random Destination Connection ID makes the connection ID 2819 appear to be the result of moving to a new connection ID that was 2820 provided using a NEW_CONNECTION_ID frame (Section 19.15). 2822 Using a randomized connection ID results in two problems: 2824 o The packet might not reach the peer. If the Destination 2825 Connection ID is critical for routing toward the peer, then this 2826 packet could be incorrectly routed. This might also trigger 2827 another Stateless Reset in response; see Section 10.4.3. A 2828 Stateless Reset that is not correctly routed is an ineffective 2829 error detection and recovery mechanism. In this case, endpoints 2830 will need to rely on other methods - such as timers - to detect 2831 that the connection has failed. 2833 o The randomly generated connection ID can be used by entities other 2834 than the peer to identify this as a potential stateless reset. An 2835 endpoint that occasionally uses different connection IDs might 2836 introduce some uncertainty about this. 2838 This stateless reset design is specific to QUIC version 1. An 2839 endpoint that supports multiple versions of QUIC needs to generate a 2840 stateless reset that will be accepted by peers that support any 2841 version that the endpoint might support (or might have supported 2842 prior to losing state). Designers of new versions of QUIC need to be 2843 aware of this and either reuse this design, or use a portion of the 2844 packet other than the last 16 bytes for carrying data. 2846 10.4.1. Detecting a Stateless Reset 2848 An endpoint detects a potential stateless reset using the trailing 16 2849 bytes of the UDP datagram. An endpoint remembers all Stateless Reset 2850 Tokens associated with the connection IDs and remote addresses for 2851 datagrams it has recently sent. This includes Stateless Reset Tokens 2852 from NEW_CONNECTION_ID frames and the server's transport parameters 2853 but excludes Stateless Reset Tokens associated with connection IDs 2854 that are either unused or retired. The endpoint identifies a 2855 received datagram as a stateless reset by comparing the last 16 bytes 2856 of the datagram with all Stateless Reset Tokens associated with the 2857 remote address on which the datagram was received. 2859 This comparison can be performed for every inbound datagram. 2860 Endpoints MAY skip this check if any packet from a datagram is 2861 successfully processed. However, the comparison MUST be performed 2862 when the first packet in an incoming datagram either cannot be 2863 associated with a connection, or cannot be decrypted. 2865 An endpoint MUST NOT check for any Stateless Reset Tokens associated 2866 with connection IDs it has not used or for connection IDs that have 2867 been retired. 2869 When comparing a datagram to Stateless Reset Token values, endpoints 2870 MUST perform the comparison without leaking information about the 2871 value of the token. For example, performing this comparison in 2872 constant time protects the value of individual Stateless Reset Tokens 2873 from information leakage through timing side channels. Another 2874 approach would be to store and compare the transformed values of 2875 Stateless Reset Tokens instead of the raw token values, where the 2876 transformation is defined as a cryptographically-secure pseudo-random 2877 function using a secret key (e.g., block cipher, HMAC [RFC2104]). An 2878 endpoint is not expected to protect information about whether a 2879 packet was successfully decrypted, or the number of valid Stateless 2880 Reset Tokens. 2882 If the last 16 bytes of the datagram are identical in value to a 2883 Stateless Reset Token, the endpoint MUST enter the draining period 2884 and not send any further packets on this connection. 2886 10.4.2. Calculating a Stateless Reset Token 2888 The stateless reset token MUST be difficult to guess. In order to 2889 create a Stateless Reset Token, an endpoint could randomly generate 2890 [RFC4086] a secret for every connection that it creates. However, 2891 this presents a coordination problem when there are multiple 2892 instances in a cluster or a storage problem for an endpoint that 2893 might lose state. Stateless reset specifically exists to handle the 2894 case where state is lost, so this approach is suboptimal. 2896 A single static key can be used across all connections to the same 2897 endpoint by generating the proof using a second iteration of a 2898 preimage-resistant function that takes a static key and the 2899 connection ID chosen by the endpoint (see Section 5.1) as input. An 2900 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2901 connection_id)) or HKDF [RFC5869] (for example, using the static key 2902 as input keying material, with the connection ID as salt). The 2903 output of this function is truncated to 16 bytes to produce the 2904 Stateless Reset Token for that connection. 2906 An endpoint that loses state can use the same method to generate a 2907 valid Stateless Reset Token. The connection ID comes from the packet 2908 that the endpoint receives. 2910 This design relies on the peer always sending a connection ID in its 2911 packets so that the endpoint can use the connection ID from a packet 2912 to reset the connection. An endpoint that uses this design MUST 2913 either use the same connection ID length for all connections or 2914 encode the length of the connection ID such that it can be recovered 2915 without state. In addition, it cannot provide a zero-length 2916 connection ID. 2918 Revealing the Stateless Reset Token allows any entity to terminate 2919 the connection, so a value can only be used once. This method for 2920 choosing the Stateless Reset Token means that the combination of 2921 connection ID and static key MUST NOT be used for another connection. 2922 A denial of service attack is possible if the same connection ID is 2923 used by instances that share a static key, or if an attacker can 2924 cause a packet to be routed to an instance that has no state but the 2925 same static key; see Section 21.9. A connection ID from a connection 2926 that is reset by revealing the Stateless Reset Token MUST NOT be 2927 reused for new connections at nodes that share a static key. 2929 The same Stateless Reset Token MUST NOT be used for multiple 2930 connection IDs. Endpoints are not required to compare new values 2931 against all previous values, but a duplicate value MAY be treated as 2932 a connection error of type PROTOCOL_VIOLATION. 2934 Note that Stateless Reset packets do not have any cryptographic 2935 protection. 2937 10.4.3. Looping 2939 The design of a Stateless Reset is such that without knowing the 2940 stateless reset token it is indistinguishable from a valid packet. 2941 For instance, if a server sends a Stateless Reset to another server 2942 it might receive another Stateless Reset in response, which could 2943 lead to an infinite exchange. 2945 An endpoint MUST ensure that every Stateless Reset that it sends is 2946 smaller than the packet which triggered it, unless it maintains state 2947 sufficient to prevent looping. In the event of a loop, this results 2948 in packets eventually being too small to trigger a response. 2950 An endpoint can remember the number of Stateless Reset packets that 2951 it has sent and stop generating new Stateless Reset packets once a 2952 limit is reached. Using separate limits for different remote 2953 addresses will ensure that Stateless Reset packets can be used to 2954 close connections when other peers or connections have exhausted 2955 limits. 2957 Reducing the size of a Stateless Reset below 41 bytes means that the 2958 packet could reveal to an observer that it is a Stateless Reset, 2959 depending upon the length of the peer's connection IDs. Conversely, 2960 refusing to send a Stateless Reset in response to a small packet 2961 might result in Stateless Reset not being useful in detecting cases 2962 of broken connections where only very small packets are sent; such 2963 failures might only be detected by other means, such as timers. 2965 11. Error Handling 2967 An endpoint that detects an error SHOULD signal the existence of that 2968 error to its peer. Both transport-level and application-level errors 2969 can affect an entire connection (see Section 11.1), while only 2970 application-level errors can be isolated to a single stream (see 2971 Section 11.2). 2973 The most appropriate error code (Section 20) SHOULD be included in 2974 the frame that signals the error. Where this specification 2975 identifies error conditions, it also identifies the error code that 2976 is used; though these are worded as requirements, different 2977 implementation strategies might lead to different errors being 2978 reported. In particular, an endpoint MAY use any applicable error 2979 code when it detects an error condition; a generic error code (such 2980 as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place 2981 of specific error codes. 2983 A stateless reset (Section 10.4) is not suitable for any error that 2984 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 2985 stateless reset MUST NOT be used by an endpoint that has the state 2986 necessary to send a frame on the connection. 2988 11.1. Connection Errors 2990 Errors that result in the connection being unusable, such as an 2991 obvious violation of protocol semantics or corruption of state that 2992 affects an entire connection, MUST be signaled using a 2993 CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the 2994 connection in this manner even if the error only affects a single 2995 stream. 2997 Application protocols can signal application-specific protocol errors 2998 using the application-specific variant of the CONNECTION_CLOSE frame. 2999 Errors that are specific to the transport, including all those 3000 described in this document, are carried in the QUIC-specific variant 3001 of the CONNECTION_CLOSE frame. 3003 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 3004 endpoint SHOULD be prepared to retransmit a packet containing a 3005 CONNECTION_CLOSE frame if it receives more packets on a terminated 3006 connection. Limiting the number of retransmissions and the time over 3007 which this final packet is sent limits the effort expended on 3008 terminated connections. 3010 An endpoint that chooses not to retransmit packets containing a 3011 CONNECTION_CLOSE frame risks a peer missing the first such packet. 3012 The only mechanism available to an endpoint that continues to receive 3013 data for a terminated connection is to use the stateless reset 3014 process (Section 10.4). 3016 An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT 3017 signal the existence of the error to its peer. 3019 11.2. Stream Errors 3021 If an application-level error affects a single stream, but otherwise 3022 leaves the connection in a recoverable state, the endpoint can send a 3023 RESET_STREAM frame (Section 19.4) with an appropriate error code to 3024 terminate just the affected stream. 3026 RESET_STREAM MUST be instigated by the protocol using QUIC. 3027 RESET_STREAM carries an application error code. Only the application 3028 protocol is able to cause a stream to be terminated. A local 3029 instance of the application protocol uses a direct API call and a 3030 remote instance uses the STOP_SENDING frame, which triggers an 3031 automatic RESET_STREAM. 3033 Resetting a stream without knowledge of the application protocol 3034 could cause the protocol to enter an unrecoverable state. 3035 Application protocols might require certain streams to be reliably 3036 delivered in order to guarantee consistent state between endpoints. 3037 Application protocols SHOULD define rules for handling streams that 3038 are prematurely cancelled by either endpoint. 3040 12. Packets and Frames 3042 QUIC endpoints communicate by exchanging packets. Packets have 3043 confidentiality and integrity protection (see Section 12.1) and are 3044 carried in UDP datagrams (see Section 12.2). 3046 This version of QUIC uses the long packet header (see Section 17.2) 3047 during connection establishment. Packets with the long header are 3048 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake 3049 (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation 3050 uses a version-independent packet with a long header (see 3051 Section 17.2.1). 3053 Packets with the short header (Section 17.3) are designed for minimal 3054 overhead and are used after a connection is established and 1-RTT 3055 keys are available. 3057 12.1. Protected Packets 3059 All QUIC packets except Version Negotiation and Retry packets use 3060 authenticated encryption with additional data (AEAD) [RFC5116] to 3061 provide confidentiality and integrity protection. Details of packet 3062 protection are found in [QUIC-TLS]; this section includes an overview 3063 of the process. 3065 Initial packets are protected using keys that are statically derived. 3066 This packet protection is not effective confidentiality protection. 3067 Initial protection only exists to ensure that the sender of the 3068 packet is on the network path. Any entity that receives the Initial 3069 packet from a client can recover the keys necessary to remove packet 3070 protection or to generate packets that will be successfully 3071 authenticated. 3073 All other packets are protected with keys derived from the 3074 cryptographic handshake. The type of the packet from the long header 3075 or key phase from the short header are used to identify which 3076 encryption level - and therefore the keys - that are used. Packets 3077 protected with 0-RTT and 1-RTT keys are expected to have 3078 confidentiality and data origin authentication; the cryptographic 3079 handshake ensures that only the communicating endpoints receive the 3080 corresponding keys. 3082 The packet number field contains a packet number, which has 3083 additional confidentiality protection that is applied after packet 3084 protection is applied (see [QUIC-TLS] for details). The underlying 3085 packet number increases with each packet sent in a given packet 3086 number space; see Section 12.3 for details. 3088 12.2. Coalescing Packets 3090 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake 3091 (Section 17.2.4) packets contain a Length field, which determines the 3092 end of the packet. The length includes both the Packet Number and 3093 Payload fields, both of which are confidentiality protected and 3094 initially of unknown length. The length of the Payload field is 3095 learned once header protection is removed. 3097 Using the Length field, a sender can coalesce multiple QUIC packets 3098 into one UDP datagram. This can reduce the number of UDP datagrams 3099 needed to complete the cryptographic handshake and start sending 3100 data. This can also be used to construct PMTU probes (see 3101 Section 14.3.1). Receivers MUST be able to process coalesced 3102 packets. 3104 Coalescing packets in order of increasing encryption levels (Initial, 3105 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 3106 able to process all the packets in a single pass. A packet with a 3107 short header does not include a length, so it can only be the last 3108 packet included in a UDP datagram. An endpoint SHOULD NOT coalesce 3109 multiple packets at the same encryption level. 3111 Senders MUST NOT coalesce QUIC packets for different connections into 3112 a single UDP datagram. Receivers SHOULD ignore any subsequent 3113 packets with a different Destination Connection ID than the first 3114 packet in the datagram. 3116 Every QUIC packet that is coalesced into a single UDP datagram is 3117 separate and complete. The receiver of coalesced QUIC packets MUST 3118 individually process each QUIC packet and separately acknowledge 3119 them, as if they were received as the payload of different UDP 3120 datagrams. For example, if decryption fails (because the keys are 3121 not available or any other reason), the receiver MAY either discard 3122 or buffer the packet for later processing and MUST attempt to process 3123 the remaining packets. 3125 Retry packets (Section 17.2.5), Version Negotiation packets 3126 (Section 17.2.1), and packets with a short header (Section 17.3) do 3127 not contain a Length field and so cannot be followed by other packets 3128 in the same UDP datagram. Note also that there is no situation where 3129 a Retry or Version Negotiation packet is coalesced with another 3130 packet. 3132 12.3. Packet Numbers 3134 The packet number is an integer in the range 0 to 2^62-1. This 3135 number is used in determining the cryptographic nonce for packet 3136 protection. Each endpoint maintains a separate packet number for 3137 sending and receiving. 3139 Packet numbers are limited to this range because they need to be 3140 representable in whole in the Largest Acknowledged field of an ACK 3141 frame (Section 19.3). When present in a long or short header 3142 however, packet numbers are reduced and encoded in 1 to 4 bytes (see 3143 Section 17.1). 3145 Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) 3146 packets do not include a packet number. 3148 Packet numbers are divided into 3 spaces in QUIC: 3150 o Initial space: All Initial packets (Section 17.2.2) are in this 3151 space. 3153 o Handshake space: All Handshake packets (Section 17.2.4) are in 3154 this space. 3156 o Application data space: All 0-RTT and 1-RTT encrypted packets 3157 (Section 12.1) are in this space. 3159 As described in [QUIC-TLS], each packet type uses different 3160 protection keys. 3162 Conceptually, a packet number space is the context in which a packet 3163 can be processed and acknowledged. Initial packets can only be sent 3164 with Initial packet protection keys and acknowledged in packets which 3165 are also Initial packets. Similarly, Handshake packets are sent at 3166 the Handshake encryption level and can only be acknowledged in 3167 Handshake packets. 3169 This enforces cryptographic separation between the data sent in the 3170 different packet sequence number spaces. Packet numbers in each 3171 space start at packet number 0. Subsequent packets sent in the same 3172 packet number space MUST increase the packet number by at least one. 3174 0-RTT and 1-RTT data exist in the same packet number space to make 3175 loss recovery algorithms easier to implement between the two packet 3176 types. 3178 A QUIC endpoint MUST NOT reuse a packet number within the same packet 3179 number space in one connection. If the packet number for sending 3180 reaches 2^62 - 1, the sender MUST close the connection without 3181 sending a CONNECTION_CLOSE frame or any further packets; an endpoint 3182 MAY send a Stateless Reset (Section 10.4) in response to further 3183 packets that it receives. 3185 A receiver MUST discard a newly unprotected packet unless it is 3186 certain that it has not processed another packet with the same packet 3187 number from the same packet number space. Duplicate suppression MUST 3188 happen after removing packet protection for the reasons described in 3189 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 3190 suppression can be found in Section 3.4.3 of [RFC4303]. 3192 Packet number encoding at a sender and decoding at a receiver are 3193 described in Section 17.1. 3195 12.4. Frames and Frame Types 3197 The payload of QUIC packets, after removing packet protection, 3198 consists of a sequence of complete frames, as shown in Figure 7. 3199 Version Negotiation, Stateless Reset, and Retry packets do not 3200 contain frames. 3202 0 1 2 3 3203 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 3204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 | Frame 1 (*) ... 3206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3207 | Frame 2 (*) ... 3208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 ... 3210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3211 | Frame N (*) ... 3212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 Figure 7: QUIC Payload 3216 The payload of a packet that contains frames MUST contain at least 3217 one frame, and MAY contain multiple frames and multiple frame types. 3218 Frames always fit within a single QUIC packet and cannot span 3219 multiple packets. 3221 Each frame begins with a Frame Type, indicating its type, followed by 3222 additional type-dependent fields: 3224 0 1 2 3 3225 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 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | Frame Type (i) ... 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Type-Dependent Fields (*) ... 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3232 Figure 8: Generic Frame Layout 3234 The frame types defined in this specification are listed in Table 3. 3235 The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and 3236 CONNECTION_CLOSE frames is used to carry other frame-specific flags. 3238 For all other frames, the Frame Type field simply identifies the 3239 frame. These frames are explained in more detail in Section 19. 3241 +-------------+----------------------+---------------+ 3242 | Type Value | Frame Type Name | Definition | 3243 +-------------+----------------------+---------------+ 3244 | 0x00 | PADDING | Section 19.1 | 3245 | | | | 3246 | 0x01 | PING | Section 19.2 | 3247 | | | | 3248 | 0x02 - 0x03 | ACK | Section 19.3 | 3249 | | | | 3250 | 0x04 | RESET_STREAM | Section 19.4 | 3251 | | | | 3252 | 0x05 | STOP_SENDING | Section 19.5 | 3253 | | | | 3254 | 0x06 | CRYPTO | Section 19.6 | 3255 | | | | 3256 | 0x07 | NEW_TOKEN | Section 19.7 | 3257 | | | | 3258 | 0x08 - 0x0f | STREAM | Section 19.8 | 3259 | | | | 3260 | 0x10 | MAX_DATA | Section 19.9 | 3261 | | | | 3262 | 0x11 | MAX_STREAM_DATA | Section 19.10 | 3263 | | | | 3264 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | 3265 | | | | 3266 | 0x14 | DATA_BLOCKED | Section 19.12 | 3267 | | | | 3268 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | 3269 | | | | 3270 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | 3271 | | | | 3272 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | 3273 | | | | 3274 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | 3275 | | | | 3276 | 0x1a | PATH_CHALLENGE | Section 19.17 | 3277 | | | | 3278 | 0x1b | PATH_RESPONSE | Section 19.18 | 3279 | | | | 3280 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | 3281 +-------------+----------------------+---------------+ 3283 Table 3: Frame Types 3285 An endpoint MUST treat the receipt of a frame of unknown type as a 3286 connection error of type FRAME_ENCODING_ERROR. 3288 All QUIC frames are idempotent in this version of QUIC. That is, a 3289 valid frame does not cause undesirable side effects or errors when 3290 received more than once. 3292 The Frame Type field uses a variable length integer encoding (see 3293 Section 16) with one exception. To ensure simple and efficient 3294 implementations of frame parsing, a frame type MUST use the shortest 3295 possible encoding. Though a two-, four- or eight-byte encoding of 3296 the frame types defined in this document is possible, the Frame Type 3297 field for these frames is encoded on a single byte. For instance, 3298 though 0x4001 is a legitimate two-byte encoding for a variable-length 3299 integer with a value of 1, PING frames are always encoded as a single 3300 byte with the value 0x01. An endpoint MAY treat the receipt of a 3301 frame type that uses a longer encoding than necessary as a connection 3302 error of type PROTOCOL_VIOLATION. 3304 13. Packetization and Reliability 3306 A sender bundles one or more frames in a QUIC packet (see 3307 Section 12.4). 3309 A sender can minimize per-packet bandwidth and computational costs by 3310 bundling as many frames as possible within a QUIC packet. A sender 3311 MAY wait for a short period of time to bundle multiple frames before 3312 sending a packet that is not maximally packed, to avoid sending out 3313 large numbers of small packets. An implementation MAY use knowledge 3314 about application sending behavior or heuristics to determine whether 3315 and for how long to wait. This waiting period is an implementation 3316 decision, and an implementation should be careful to delay 3317 conservatively, since any delay is likely to increase application- 3318 visible latency. 3320 Stream multiplexing is achieved by interleaving STREAM frames from 3321 multiple streams into one or more QUIC packets. A single QUIC packet 3322 can include multiple STREAM frames from one or more streams. 3324 One of the benefits of QUIC is avoidance of head-of-line blocking 3325 across multiple streams. When a packet loss occurs, only streams 3326 with data in that packet are blocked waiting for a retransmission to 3327 be received, while other streams can continue making progress. Note 3328 that when data from multiple streams is bundled into a single QUIC 3329 packet, loss of that packet blocks all those streams from making 3330 progress. Implementations are advised to bundle as few streams as 3331 necessary in outgoing packets without losing transmission efficiency 3332 to underfilled packets. 3334 13.1. Packet Processing 3336 A packet MUST NOT be acknowledged until packet protection has been 3337 successfully removed and all frames contained in the packet have been 3338 processed. For STREAM frames, this means the data has been enqueued 3339 in preparation to be received by the application protocol, but it 3340 does not require that data is delivered and consumed. 3342 Once the packet has been fully processed, a receiver acknowledges 3343 receipt by sending one or more ACK frames containing the packet 3344 number of the received packet. 3346 13.2. Generating Acknowledgements 3348 Endpoints acknowledge all packets they receive and process. However, 3349 only ack-eliciting packets cause an ACK frame to be sent within the 3350 maximum ack delay. Packets that are not ack-eliciting are only 3351 acknowledged when an ACK frame is sent for other reasons. 3353 When sending a packet for any reason, an endpoint should attempt to 3354 bundle an ACK frame if one has not been sent recently. Doing so 3355 helps with timely loss detection at the peer. 3357 In general, frequent feedback from a receiver improves loss and 3358 congestion response, but this has to be balanced against excessive 3359 load generated by a receiver that sends an ACK frame in response to 3360 every ack-eliciting packet. The guidance offered below seeks to 3361 strike this balance. 3363 13.2.1. Sending ACK Frames 3365 Every packet SHOULD be acknowledged at least once, and ack-eliciting 3366 packets MUST be acknowledged at least once within the maximum ack 3367 delay. An endpoint communicates its maximum delay using the 3368 max_ack_delay transport parameter; see Section 18.2. max_ack_delay 3369 declares an explicit contract: an endpoint promises to never 3370 intentionally delay acknowledgments of an ack-eliciting packet by 3371 more than the indicated value. If it does, any excess accrues to the 3372 RTT estimate and could result in spurious or delayed retransmissions 3373 from the peer. For Initial and Handshake packets, a max_ack_delay of 3374 0 is used. The sender uses the receiver's "max_ack_delay" value in 3375 determining timeouts for timer-based retransmission, as detailed in 3376 Section 5.2.1 of [QUIC-RECOVERY]. 3378 An ACK frame SHOULD be generated for at least every second ack- 3379 eliciting packet. This recommendation is in keeping with standard 3380 practice for TCP [RFC5681]. 3382 In order to assist loss detection at the sender, an endpoint SHOULD 3383 send an ACK frame immediately on receiving an ack-eliciting packet 3384 that is out of order. The endpoint MAY continue sending ACK frames 3385 immediately on each subsequently received packet, but the endpoint 3386 SHOULD return to acknowledging every other packet within a period of 3387 1/8 x RTT, unless more ack-eliciting packets are received out of 3388 order. If every subsequent ack-eliciting packet arrives out of 3389 order, then an ACK frame SHOULD be sent immediately for every 3390 received ack-eliciting packet. 3392 Similarly, packets marked with the ECN Congestion Experienced (CE) 3393 codepoint in the IP header SHOULD be acknowledged immediately, to 3394 reduce the peer's response time to congestion events. 3396 As an optimization, a receiver MAY process multiple packets before 3397 sending any ACK frames in response. In this case the receiver can 3398 determine whether an immediate or delayed acknowledgement should be 3399 generated after processing incoming packets. 3401 Packets containing PADDING frames are considered to be in flight for 3402 congestion control purposes [QUIC-RECOVERY]. Sending only PADDING 3403 frames might cause the sender to become limited by the congestion 3404 controller with no acknowledgments forthcoming from the receiver. 3405 Therefore, a sender SHOULD ensure that other frames are sent in 3406 addition to PADDING frames to elicit acknowledgments from the 3407 receiver. 3409 An endpoint that is only sending ACK frames will not receive 3410 acknowledgments from its peer unless those acknowledgements are 3411 included in packets with ack-eliciting frames. An endpoint SHOULD 3412 bundle ACK frames with other frames when there are new ack-eliciting 3413 packets to acknowledge. When only non-ack-eliciting packets need to 3414 be acknowledged, an endpoint MAY wait until an ack-eliciting packet 3415 has been received to bundle an ACK frame with outgoing frames. 3417 The algorithms in [QUIC-RECOVERY] are resilient to receivers that do 3418 not follow guidance offered above. However, an implementor should 3419 only deviate from these requirements after careful consideration of 3420 the performance implications of doing so. 3422 Packets containing only ACK frames are not congestion controlled, so 3423 there are limits on how frequently they can be sent. An endpoint 3424 MUST NOT send more than one ACK-frame-only packet in response to 3425 receiving an ack-eliciting packet. An endpoint MUST NOT send a non- 3426 ack-eliciting packet in response to a non-ack-eliciting packet, even 3427 if there are packet gaps which precede the received packet. Limiting 3428 ACK frames avoids an infinite feedback loop of acknowledgements, 3429 which could prevent the connection from ever becoming idle. However, 3430 the endpoint acknowledges non-ACK-eliciting packets when it sends an 3431 ACK frame. 3433 An endpoint SHOULD treat receipt of an acknowledgment for a packet it 3434 did not send as a connection error of type PROTOCOL_VIOLATION, if it 3435 is able to detect the condition. 3437 13.2.2. Managing ACK Ranges 3439 When an ACK frame is sent, one or more ranges of acknowledged packets 3440 are included. Including older packets reduces the chance of spurious 3441 retransmits caused by losing previously sent ACK frames, at the cost 3442 of larger ACK frames. 3444 ACK frames SHOULD always acknowledge the most recently received 3445 packets, and the more out-of-order the packets are, the more 3446 important it is to send an updated ACK frame quickly, to prevent the 3447 peer from declaring a packet as lost and spuriously retransmitting 3448 the frames it contains. 3450 Section 13.2.3 and Section 13.2.4 describe an exemplary approach for 3451 determining what packets to acknowledge in each ACK frame. 3453 13.2.3. Receiver Tracking of ACK Frames 3455 When a packet containing an ACK frame is sent, the largest 3456 acknowledged in that frame may be saved. When a packet containing an 3457 ACK frame is acknowledged, the receiver can stop acknowledging 3458 packets less than or equal to the largest acknowledged in the sent 3459 ACK frame. 3461 In cases without ACK frame loss, this algorithm allows for a minimum 3462 of 1 RTT of reordering. In cases with ACK frame loss and reordering, 3463 this approach does not guarantee that every acknowledgement is seen 3464 by the sender before it is no longer included in the ACK frame. 3465 Packets could be received out of order and all subsequent ACK frames 3466 containing them could be lost. In this case, the loss recovery 3467 algorithm could cause spurious retransmits, but the sender will 3468 continue making forward progress. 3470 13.2.4. Limiting ACK Ranges 3472 To limit ACK Ranges (see Section 19.3.1) to those that have not yet 3473 been received by the sender, the receiver SHOULD track which ACK 3474 frames have been acknowledged by its peer. The receiver SHOULD 3475 exclude already acknowledged packets from future ACK frames whenever 3476 these packets would unnecessarily contribute to the ACK frame size. 3477 When the receiver is only sending non-ack-eliciting packets, it can 3478 bundle a PING or other small ack-eliciting frame with a fraction of 3479 them, such as once per round trip, to enable dropping unnecessary ACK 3480 ranges and any state for previously sent packets. The receiver MUST 3481 NOT bundle an ack-eliciting frame, such as a PING, with all packets 3482 that would otherwise be non-ack-eliciting, in order to avoid an 3483 infinite feedback loop of acknowledgements. 3485 To limit receiver state or the size of ACK frames, a receiver MAY 3486 limit the number of ACK Ranges it sends. A receiver can do this even 3487 without receiving acknowledgment of its ACK frames, with the 3488 knowledge this could cause the sender to unnecessarily retransmit 3489 some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare 3490 packets lost after sufficiently newer packets are acknowledged. 3491 Therefore, the receiver SHOULD repeatedly acknowledge newly received 3492 packets in preference to packets received in the past. 3494 13.2.5. Measuring and Reporting Host Delay 3496 An endpoint measures the delays intentionally introduced between when 3497 an ack-eliciting packet is received and the corresponding 3498 acknowledgment is sent. The endpoint encodes this delay for the 3499 largest acknowledged packet in the Ack Delay field of an ACK frame 3500 (see Section 19.3). This allows the receiver of the ACK to adjust 3501 for any intentional delays, which is important for getting a better 3502 estimate of the path RTT when acknowledgments are delayed. A packet 3503 might be held in the OS kernel or elsewhere on the host before being 3504 processed. An endpoint MUST NOT include delays that is does not 3505 control when populating the Ack Delay field in an ACK frame. 3507 13.2.6. ACK Frames and Packet Protection 3509 ACK frames MUST only be carried in a packet that has the same packet 3510 number space as the packet being ACKed (see Section 12.1). For 3511 instance, packets that are protected with 1-RTT keys MUST be 3512 acknowledged in packets that are also protected with 1-RTT keys. 3514 Packets that a client sends with 0-RTT packet protection MUST be 3515 acknowledged by the server in packets protected by 1-RTT keys. This 3516 can mean that the client is unable to use these acknowledgments if 3517 the server cryptographic handshake messages are delayed or lost. 3518 Note that the same limitation applies to other data sent by the 3519 server protected by the 1-RTT keys. 3521 13.3. Retransmission of Information 3523 QUIC packets that are determined to be lost are not retransmitted 3524 whole. The same applies to the frames that are contained within lost 3525 packets. Instead, the information that might be carried in frames is 3526 sent again in new frames as needed. 3528 New frames and packets are used to carry information that is 3529 determined to have been lost. In general, information is sent again 3530 when a packet containing that information is determined to be lost 3531 and sending ceases when a packet containing that information is 3532 acknowledged. 3534 o Data sent in CRYPTO frames is retransmitted according to the rules 3535 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 3536 CRYPTO frames for Initial and Handshake packets is discarded when 3537 keys for the corresponding encryption level are discarded. 3539 o Application data sent in STREAM frames is retransmitted in new 3540 STREAM frames unless the endpoint has sent a RESET_STREAM for that 3541 stream. Once an endpoint sends a RESET_STREAM frame, no further 3542 STREAM frames are needed. 3544 o ACK frames carry the most recent set of acknowledgements and the 3545 Ack Delay from the largest acknowledged packet, as described in 3546 Section 13.2.1. Delaying the transmission of packets containing 3547 ACK frames or sending old ACK frames can cause the peer to 3548 generate an inflated RTT sample or unnecessarily disable ECN. 3550 o Cancellation of stream transmission, as carried in a RESET_STREAM 3551 frame, is sent until acknowledged or until all stream data is 3552 acknowledged by the peer (that is, either the "Reset Recvd" or 3553 "Data Recvd" state is reached on the sending part of the stream). 3554 The content of a RESET_STREAM frame MUST NOT change when it is 3555 sent again. 3557 o Similarly, a request to cancel stream transmission, as encoded in 3558 a STOP_SENDING frame, is sent until the receiving part of the 3559 stream enters either a "Data Recvd" or "Reset Recvd" state; see 3560 Section 3.5. 3562 o Connection close signals, including packets that contain 3563 CONNECTION_CLOSE frames, are not sent again when packet loss is 3564 detected, but as described in Section 10. 3566 o The current connection maximum data is sent in MAX_DATA frames. 3567 An updated value is sent in a MAX_DATA frame if the packet 3568 containing the most recently sent MAX_DATA frame is declared lost, 3569 or when the endpoint decides to update the limit. Care is 3570 necessary to avoid sending this frame too often as the limit can 3571 increase frequently and cause an unnecessarily large number of 3572 MAX_DATA frames to be sent. 3574 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3575 frames. Like MAX_DATA, an updated value is sent when the packet 3576 containing the most recent MAX_STREAM_DATA frame for a stream is 3577 lost or when the limit is updated, with care taken to prevent the 3578 frame from being sent too often. An endpoint SHOULD stop sending 3579 MAX_STREAM_DATA frames when the receiving part of the stream 3580 enters a "Size Known" state. 3582 o The limit on streams of a given type is sent in MAX_STREAMS 3583 frames. Like MAX_DATA, an updated value is sent when a packet 3584 containing the most recent MAX_STREAMS for a stream type frame is 3585 declared lost or when the limit is updated, with care taken to 3586 prevent the frame from being sent too often. 3588 o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 3589 and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection 3590 scope, STREAM_DATA_BLOCKED frames have stream scope, and 3591 STREAMS_BLOCKED frames are scoped to a specific stream type. New 3592 frames are sent if packets containing the most recent frame for a 3593 scope is lost, but only while the endpoint is blocked on the 3594 corresponding limit. These frames always include the limit that 3595 is causing blocking at the time that they are transmitted. 3597 o A liveness or path validation check using PATH_CHALLENGE frames is 3598 sent periodically until a matching PATH_RESPONSE frame is received 3599 or until there is no remaining need for liveness or path 3600 validation checking. PATH_CHALLENGE frames include a different 3601 payload each time they are sent. 3603 o Responses to path validation using PATH_RESPONSE frames are sent 3604 just once. The peer is expected to send more PATH_CHALLENGE 3605 frames as necessary to evoke additional PATH_RESPONSE frames. 3607 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3608 retransmitted if the packet containing them is lost. 3609 Retransmissions of this frame carry the same sequence number 3610 value. Likewise, retired connection IDs are sent in 3611 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3612 containing them is lost. 3614 o NEW_TOKEN frames are retransmitted if the packet containing them 3615 is lost. No special support is made for detecting reordered and 3616 duplicated NEW_TOKEN frames other than a direct comparison of the 3617 frame contents. 3619 o PING and PADDING frames contain no information, so lost PING or 3620 PADDING frames do not require repair. 3622 Endpoints SHOULD prioritize retransmission of data over sending new 3623 data, unless priorities specified by the application indicate 3624 otherwise (see Section 2.3). 3626 Even though a sender is encouraged to assemble frames containing up- 3627 to-date information every time it sends a packet, it is not forbidden 3628 to retransmit copies of frames from lost packets. A receiver MUST 3629 accept packets containing an outdated frame, such as a MAX_DATA frame 3630 carrying a smaller maximum data than one found in an older packet. 3632 Upon detecting losses, a sender MUST take appropriate congestion 3633 control action. The details of loss detection and congestion control 3634 are described in [QUIC-RECOVERY]. 3636 13.4. Explicit Congestion Notification 3638 QUIC endpoints can use Explicit Congestion Notification (ECN) 3639 [RFC3168] to detect and respond to network congestion. ECN allows a 3640 network node to indicate congestion in the network by setting a 3641 codepoint in the IP header of a packet instead of dropping it. 3642 Endpoints react to congestion by reducing their sending rate in 3643 response, as described in [QUIC-RECOVERY]. 3645 To use ECN, QUIC endpoints first determine whether a path supports 3646 ECN marking and the peer is able to access the ECN codepoint in the 3647 IP header. A network path does not support ECN if ECN marked packets 3648 get dropped or ECN markings are rewritten on the path. An endpoint 3649 validates the use of ECN on the path, both during connection 3650 establishment and when migrating to a new path (Section 9). 3652 13.4.1. ECN Counts 3654 On receiving a QUIC packet with an ECT or CE codepoint, an ECN- 3655 enabled endpoint that can access the ECN codepoints from the 3656 enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE 3657 count, and includes these counts in subsequent ACK frames (see 3658 Section 13.2 and Section 19.3). Note that this requires being able 3659 to read the ECN codepoints from the enclosing IP packet, which is not 3660 possible on all platforms. 3662 A packet detected by a receiver as a duplicate does not affect the 3663 receiver's local ECN codepoint counts; see (Section 21.8) for 3664 relevant security concerns. 3666 If an endpoint receives a QUIC packet without an ECT or CE codepoint 3667 in the IP packet header, it responds per Section 13.2 with an ACK 3668 frame without increasing any ECN counts. If an endpoint does not 3669 implement ECN support or does not have access to received ECN 3670 codepoints, it does not increase ECN counts. 3672 Coalesced packets (see Section 12.2) mean that several packets can 3673 share the same IP header. The ECN counter for the ECN codepoint 3674 received in the associated IP header are incremented once for each 3675 QUIC packet, not per enclosing IP packet or UDP datagram. 3677 Each packet number space maintains separate acknowledgement state and 3678 separate ECN counts. For example, if one each of an Initial, 0-RTT, 3679 Handshake, and 1-RTT QUIC packet are coalesced, the corresponding 3680 counts for the Initial and Handshake packet number space will be 3681 incremented by one and the counts for the 1-RTT packet number space 3682 will be increased by two. 3684 13.4.2. ECN Validation 3686 It is possible for faulty network devices to corrupt or erroneously 3687 drop packets with ECN markings. To provide robust connectivity in 3688 the presence of such devices, each endpoint independently validates 3689 ECN counts and disables ECN if errors are detected. 3691 Endpoints validate ECN for packets sent on each network path 3692 independently. An endpoint thus validates ECN on new connection 3693 establishment, when switching to a new server preferred address, and 3694 on active connection migration to a new path. 3696 Even if an endpoint does not use ECN markings on packets it 3697 transmits, the endpoint MUST provide feedback about ECN markings 3698 received from the peer if they are accessible. Failing to report ECN 3699 counts will cause the peer to disable ECN marking. 3701 13.4.2.1. Sending ECN Markings 3703 To start ECN validation, an endpoint SHOULD do the following when 3704 sending packets on a new path to a peer: 3706 o Set the ECT(0) codepoint in the IP header of early outgoing 3707 packets sent on a new path to the peer [RFC8311]. 3709 o If all packets that were sent with the ECT(0) codepoint are 3710 eventually deemed lost [QUIC-RECOVERY], validation is deemed to 3711 have failed. 3713 To reduce the chances of misinterpreting congestive loss as packets 3714 dropped by a faulty network element, an endpoint could set the ECT(0) 3715 codepoint in the first ten outgoing packets on a path, or for a 3716 period of three RTTs, whichever occurs first. 3718 Implementations MAY experiment with and use other strategies for use 3719 of ECN. Other methods of probing paths for ECN support are possible, 3720 as are different marking strategies. Implementations can also use 3721 the ECT(1) codepoint, as specified in [RFC8311]. 3723 13.4.2.2. Receiving ACK Frames 3725 An endpoint that sets ECT(0) or ECT(1) codepoints on packets it 3726 transmits MUST use the following steps on receiving an ACK frame to 3727 validate ECN. 3729 o If this ACK frame newly acknowledges a packet that the endpoint 3730 sent with either ECT(0) or ECT(1) codepoints set, and if no ECN 3731 feedback is present in the ACK frame, validation fails. This step 3732 protects against both a network element that zeroes out ECN bits 3733 and a peer that is unable to access ECN markings, since the peer 3734 could respond without ECN feedback in these cases. 3736 o For validation to succeed, the total increase in ECT(0), ECT(1), 3737 and CE counts MUST be no smaller than the total number of QUIC 3738 packets sent with an ECT codepoint that are newly acknowledged in 3739 this ACK frame. This step detects any network remarking from 3740 ECT(0), ECT(1), or CE codepoints to Not-ECT. 3742 o Any increase in either ECT(0) or ECT(1) counts, plus any increase 3743 in the CE count, MUST be no smaller than the number of packets 3744 sent with the corresponding ECT codepoint that are newly 3745 acknowledged in this ACK frame. This step detects any erroneous 3746 network remarking from ECT(0) to ECT(1) (or vice versa). 3748 Processing ECN counts out of order can result in validation failure. 3749 An endpoint SHOULD NOT perform this validation if this ACK frame does 3750 not advance the largest packet number acknowledged in this 3751 connection. 3753 An endpoint could miss acknowledgements for a packet when ACK frames 3754 are lost. It is therefore possible for the total increase in ECT(0), 3755 ECT(1), and CE counts to be greater than the number of packets 3756 acknowledged in an ACK frame. When this happens, and if validation 3757 succeeds, the local reference counts MUST be increased to match the 3758 counts in the ACK frame. 3760 13.4.2.3. Validation Outcomes 3762 If validation fails, then the endpoint stops sending ECN markings in 3763 subsequent IP packets with the expectation that either the network 3764 path or the peer does not support ECN. 3766 Upon successful validation, an endpoint can continue to set ECT 3767 codepoints in subsequent packets with the expectation that the path 3768 is ECN-capable. Network routing and path elements can change mid- 3769 connection however; an endpoint MUST disable ECN if validation fails 3770 at any point in the connection. 3772 Even if validation fails, an endpoint MAY revalidate ECN on the same 3773 path at any later time in the connection. 3775 14. Packet Size 3777 The QUIC packet size includes the QUIC header and protected payload, 3778 but not the UDP or IP header. 3780 Clients MUST ensure they send the first Initial packet in a single IP 3781 packet. Similarly, the first Initial packet sent after receiving a 3782 Retry packet MUST be sent in a single IP packet. 3784 The payload of a UDP datagram carrying the first Initial packet MUST 3785 be expanded to at least 1200 bytes, by adding PADDING frames to the 3786 Initial packet and/or by coalescing the Initial packet (see 3787 Section 12.2). Sending a UDP datagram of this size ensures that the 3788 network path supports a reasonable Maximum Transmission Unit (MTU), 3789 and helps reduce the amplitude of amplification attacks caused by 3790 server responses toward an unverified client address; see Section 8. 3792 The datagram containing the first Initial packet from a client MAY 3793 exceed 1200 bytes if the client believes that the Path Maximum 3794 Transmission Unit (PMTU) supports the size that it chooses. 3796 A server MAY send a CONNECTION_CLOSE frame with error code 3797 PROTOCOL_VIOLATION in response to the first Initial packet it 3798 receives from a client if the UDP datagram is smaller than 1200 3799 bytes. It MUST NOT send any other frame type in response, or 3800 otherwise behave as if any part of the offending packet was processed 3801 as valid. 3803 The server MUST also limit the number of bytes it sends before 3804 validating the address of the client; see Section 8. 3806 14.1. Path Maximum Transmission Unit (PMTU) 3808 The PMTU is the maximum size of the entire IP packet including the IP 3809 header, UDP header, and UDP payload. The UDP payload includes the 3810 QUIC packet header, protected payload, and any authentication fields. 3811 The PMTU can depend upon the current path characteristics. 3812 Therefore, the current largest UDP payload an implementation will 3813 send is referred to as the QUIC maximum packet size. 3815 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 3816 minimum size [RFC8200] and is also supported by most modern IPv4 3817 networks. All QUIC packets (except for PMTU probe packets) SHOULD be 3818 sized to fit within the maximum packet size to avoid the packet being 3819 fragmented or dropped [RFC8085]. 3821 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery 3822 ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] 3823 [RFC8201] to determine whether the path to a destination will support 3824 a desired message size without fragmentation. 3826 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3827 packets larger than 1280 bytes. Assuming the minimum IP header size, 3828 this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 3829 1252 bytes for IPv4. A QUIC implementation MAY be more conservative 3830 in computing the QUIC maximum packet size to allow for unknown tunnel 3831 overheads or IP header options/extensions. 3833 Each pair of local and remote addresses could have a different PMTU. 3834 QUIC implementations that implement any kind of PMTU discovery 3835 therefore SHOULD maintain a maximum packet size for each combination 3836 of local and remote IP addresses. 3838 If a QUIC endpoint determines that the PMTU between any pair of local 3839 and remote IP addresses has fallen below the size needed to support 3840 the smallest allowed maximum packet size, it MUST immediately cease 3841 sending QUIC packets, except for PMTU probe packets, on the affected 3842 path. An endpoint MAY terminate the connection if an alternative 3843 path cannot be found. 3845 14.2. ICMP Packet Too Big Messages 3847 PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP 3848 messages (e.g., IPv6 Packet Too Big messages) that indicate when a 3849 packet is dropped because it is larger than the local router MTU. 3850 DPLPMTUD can also optionally use these messages. This use of ICMP 3851 messages is potentially vulnerable to off-path attacks that 3852 successfully guess the addresses used on the path and reduce the PMTU 3853 to a bandwidth-inefficient value. 3855 An endpoint MUST ignore an ICMP message that claims the PMTU has 3856 decreased below 1280 bytes. 3858 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 3859 that the quoted packet should contain as much of the original packet 3860 as possible without exceeding the minimum MTU for the IP version. 3861 The size of the quoted packet can actually be smaller, or the 3862 information unintelligible, as described in Section 1.1 of 3863 [DPLPMTUD]. 3865 QUIC endpoints SHOULD validate ICMP messages to protect from off-path 3866 injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. 3867 This validation SHOULD use the quoted packet supplied in the payload 3868 of an ICMP message to associate the message with a corresponding 3869 transport connection [DPLPMTUD]. 3871 ICMP message validation MUST include matching IP addresses and UDP 3872 ports [RFC8085] and, when possible, connection IDs to an active QUIC 3873 session. 3875 Further validation can also be provided: 3877 o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small 3878 proportion of packets, so that most invalid ICMP messages arrive 3879 when there are no DF packets outstanding, and can therefore be 3880 identified as spurious. 3882 o An endpoint could store additional information from the IP or UDP 3883 headers to use for validation (for example, the IP ID or UDP 3884 checksum). 3886 The endpoint SHOULD ignore all ICMP messages that fail validation. 3888 An endpoint MUST NOT increase PMTU based on ICMP messages. Any 3889 reduction in the QUIC maximum packet size MAY be provisional until 3890 QUIC's loss detection algorithm determines that the quoted packet has 3891 actually been lost. 3893 14.3. Datagram Packetization Layer PMTU Discovery 3895 Section 6.4 of [DPLPMTUD] provides considerations for implementing 3896 Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. 3898 When implementing the algorithm in Section 5.3 of [DPLPMTUD], the 3899 initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC 3900 packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). 3902 PING and PADDING frames can be used to generate PMTU probe packets. 3903 These frames might not be retransmitted if a probe packet containing 3904 them is lost. However, these frames do consume congestion window, 3905 which could delay the transmission of subsequent application data. 3907 A PING frame can be included in a PMTU probe to ensure that a valid 3908 probe is acknowledged. 3910 The considerations for processing ICMP messages in the previous 3911 section also apply if these messages are used by DPLPMTUD. 3913 14.3.1. PMTU Probes Containing Source Connection ID 3915 Endpoints that rely on the destination connection ID for routing QUIC 3916 packets are likely to require that the connection ID be included in 3917 PMTU probe packets to route any resulting ICMP messages 3918 (Section 14.2) back to the correct endpoint. However, only long 3919 header packets (Section 17.2) contain source connection IDs, and long 3920 header packets are not decrypted or acknowledged by the peer once the 3921 handshake is complete. One way to construct a PMTU probe is to 3922 coalesce (see Section 12.2) a Handshake packet (Section 17.2.4) with 3923 a short header packet in a single UDP datagram. If the UDP datagram 3924 reaches the endpoint, the Handshake packet will be ignored, but the 3925 short header packet will be acknowledged. If the UDP datagram 3926 elicits an ICMP message, that message will likely contain the source 3927 connection ID within the quoted portion of the UDP datagram. 3929 15. Versions 3931 QUIC versions are identified using a 32-bit unsigned number. 3933 The version 0x00000000 is reserved to represent version negotiation. 3934 This version of the specification is identified by the number 3935 0x00000001. 3937 Other versions of QUIC might have different properties to this 3938 version. The properties of QUIC that are guaranteed to be consistent 3939 across all versions of the protocol are described in 3940 [QUIC-INVARIANTS]. 3942 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 3943 protocol, as described in [QUIC-TLS]. 3945 Versions with the most significant 16 bits of the version number 3946 cleared are reserved for use in future IETF consensus documents. 3948 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 3949 forcing version negotiation to be exercised. That is, any version 3950 number where the low four bits of all bytes is 1010 (in binary). A 3951 client or server MAY advertise support for any of these reserved 3952 versions. 3954 Reserved version numbers will probably never represent a real 3955 protocol; a client MAY use one of these version numbers with the 3956 expectation that the server will initiate version negotiation; a 3957 server MAY advertise support for one of these versions and can expect 3958 that clients ignore the value. 3960 [[RFC editor: please remove the remainder of this section before 3961 publication.]] 3963 The version number for the final version of this specification 3964 (0x00000001), is reserved for the version of the protocol that is 3965 published as an RFC. 3967 Version numbers used to identify IETF drafts are created by adding 3968 the draft number to 0xff000000. For example, draft-ietf-quic- 3969 transport-13 would be identified as 0xff00000D. 3971 Implementors are encouraged to register version numbers of QUIC that 3972 they are using for private experimentation on the GitHub wiki at 3973 . 3975 16. Variable-Length Integer Encoding 3977 QUIC packets and frames commonly use a variable-length encoding for 3978 non-negative integer values. This encoding ensures that smaller 3979 integer values need fewer bytes to encode. 3981 The QUIC variable-length integer encoding reserves the two most 3982 significant bits of the first byte to encode the base 2 logarithm of 3983 the integer encoding length in bytes. The integer value is encoded 3984 on the remaining bits, in network byte order. 3986 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 3987 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3988 the encoding properties. 3990 +------+--------+-------------+-----------------------+ 3991 | 2Bit | Length | Usable Bits | Range | 3992 +------+--------+-------------+-----------------------+ 3993 | 00 | 1 | 6 | 0-63 | 3994 | | | | | 3995 | 01 | 2 | 14 | 0-16383 | 3996 | | | | | 3997 | 10 | 4 | 30 | 0-1073741823 | 3998 | | | | | 3999 | 11 | 8 | 62 | 0-4611686018427387903 | 4000 +------+--------+-------------+-----------------------+ 4002 Table 4: Summary of Integer Encodings 4004 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 4005 hexadecimal) decodes to the decimal value 151288809941952652; the 4006 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 4007 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 4008 (as does the two byte sequence 40 25). 4010 Error codes (Section 20) and versions (Section 15) are described 4011 using integers, but do not use this encoding. 4013 17. Packet Formats 4015 All numeric values are encoded in network byte order (that is, big- 4016 endian) and all field sizes are in bits. Hexadecimal notation is 4017 used for describing the value of fields. 4019 17.1. Packet Number Encoding and Decoding 4021 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). 4022 When present in long or short packet headers, they are encoded in 1 4023 to 4 bytes. The number of bits required to represent the packet 4024 number is reduced by including the least significant bits of the 4025 packet number. 4027 The encoded packet number is protected as described in Section 5.4 of 4028 [QUIC-TLS]. 4030 The sender MUST use a packet number size able to represent more than 4031 twice as large a range than the difference between the largest 4032 acknowledged packet and packet number being sent. A peer receiving 4033 the packet will then correctly decode the packet number, unless the 4034 packet is delayed in transit such that it arrives after many higher- 4035 numbered packets have been received. An endpoint SHOULD use a large 4036 enough packet number encoding to allow the packet number to be 4037 recovered even if the packet arrives after packets that are sent 4038 afterwards. 4040 As a result, the size of the packet number encoding is at least one 4041 bit more than the base-2 logarithm of the number of contiguous 4042 unacknowledged packet numbers, including the new packet. 4044 For example, if an endpoint has received an acknowledgment for packet 4045 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 4046 packet number encoding with 16 bits or more; whereas the 24-bit 4047 packet number encoding is needed to send a packet with a number of 4048 0xace8fe. 4050 At a receiver, protection of the packet number is removed prior to 4051 recovering the full packet number. The full packet number is then 4052 reconstructed based on the number of significant bits present, the 4053 value of those bits, and the largest packet number received on a 4054 successfully authenticated packet. Recovering the full packet number 4055 is necessary to successfully remove packet protection. 4057 Once header protection is removed, the packet number is decoded by 4058 finding the packet number value that is closest to the next expected 4059 packet. The next expected packet is the highest received packet 4060 number plus one. For example, if the highest successfully 4061 authenticated packet had a packet number of 0xa82f30ea, then a packet 4062 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 4063 Example pseudo-code for packet number decoding can be found in 4064 Appendix A. 4066 17.2. Long Header Packets 4068 0 1 2 3 4069 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 4070 +-+-+-+-+-+-+-+-+ 4071 |1|1|T T|X X X X| 4072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4073 | Version (32) | 4074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4075 | DCID Len (8) | 4076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4077 | Destination Connection ID (0..160) ... 4078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4079 | SCID Len (8) | 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 | Source Connection ID (0..160) ... 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4084 Figure 9: Long Header Packet Format 4086 Long headers are used for packets that are sent prior to the 4087 establishment of 1-RTT keys. Once both conditions are met, a sender 4088 switches to sending packets using the short header (Section 17.3). 4089 The long form allows for special packets - such as the Version 4090 Negotiation packet - to be represented in this uniform fixed-length 4091 packet format. Packets that use the long header contain the 4092 following fields: 4094 Header Form: The most significant bit (0x80) of byte 0 (the first 4095 byte) is set to 1 for long headers. 4097 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4098 containing a zero value for this bit are not valid packets in this 4099 version and MUST be discarded. 4101 Long Packet Type (T): The next two bits (those with a mask of 0x30) 4102 of byte 0 contain a packet type. Packet types are listed in 4103 Table 5. 4105 Type-Specific Bits (X): The lower four bits (those with a mask of 4106 0x0f) of byte 0 are type-specific. 4108 Version: The QUIC Version is a 32-bit field that follows the first 4109 byte. This field indicates which version of QUIC is in use and 4110 determines how the rest of the protocol fields are interpreted. 4112 DCID Len: The byte following the version contains the length in 4113 bytes of the Destination Connection ID field that follows it. 4114 This length is encoded as an 8-bit unsigned integer. In QUIC 4115 version 1, this value MUST NOT exceed 20. Endpoints that receive 4116 a version 1 long header with a value larger than 20 MUST drop the 4117 packet. Servers SHOULD be able to read longer connection IDs from 4118 other QUIC versions in order to properly form a version 4119 negotiation packet. 4121 Destination Connection ID: The Destination Connection ID field 4122 follows the DCID Len and is between 0 and 20 bytes in length. 4123 Section 7.2 describes the use of this field in more detail. 4125 SCID Len: The byte following the Destination Connection ID contains 4126 the length in bytes of the Source Connection ID field that follows 4127 it. This length is encoded as a 8-bit unsigned integer. In QUIC 4128 version 1, this value MUST NOT exceed 20 bytes. Endpoints that 4129 receive a version 1 long header with a value larger than 20 MUST 4130 drop the packet. Servers SHOULD be able to read longer connection 4131 IDs from other QUIC versions in order to properly form a version 4132 negotiation packet. 4134 Source Connection ID: The Source Connection ID field follows the 4135 SCID Len and is between 0 and 20 bytes in length. Section 7.2 4136 describes the use of this field in more detail. 4138 In this version of QUIC, the following packet types with the long 4139 header are defined: 4141 +------+-----------+----------------+ 4142 | Type | Name | Section | 4143 +------+-----------+----------------+ 4144 | 0x0 | Initial | Section 17.2.2 | 4145 | | | | 4146 | 0x1 | 0-RTT | Section 17.2.3 | 4147 | | | | 4148 | 0x2 | Handshake | Section 17.2.4 | 4149 | | | | 4150 | 0x3 | Retry | Section 17.2.5 | 4151 +------+-----------+----------------+ 4153 Table 5: Long Header Packet Types 4155 The header form bit, connection ID lengths byte, Destination and 4156 Source Connection ID fields, and Version fields of a long header 4157 packet are version-independent. The other fields in the first byte 4158 are version-specific. See [QUIC-INVARIANTS] for details on how 4159 packets from different versions of QUIC are interpreted. 4161 The interpretation of the fields and the payload are specific to a 4162 version and packet type. While type-specific semantics for this 4163 version are described in the following sections, several long-header 4164 packets in this version of QUIC contain these additional fields: 4166 Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 4167 are reserved across multiple packet types. These bits are 4168 protected using header protection (see Section 5.4 of [QUIC-TLS]). 4169 The value included prior to protection MUST be set to 0. An 4170 endpoint MUST treat receipt of a packet that has a non-zero value 4171 for these bits, after removing both packet and header protection, 4172 as a connection error of type PROTOCOL_VIOLATION. Discarding such 4173 a packet after only removing header protection can expose the 4174 endpoint to attacks (see Section 9.3 of [QUIC-TLS]). 4176 Packet Number Length (P): In packet types which contain a Packet 4177 Number field, the least significant two bits (those with a mask of 4178 0x03) of byte 0 contain the length of the packet number, encoded 4179 as an unsigned, two-bit integer that is one less than the length 4180 of the packet number field in bytes. That is, the length of the 4181 packet number field is the value of this field, plus one. These 4182 bits are protected using header protection (see Section 5.4 of 4183 [QUIC-TLS]). 4185 Length: The length of the remainder of the packet (that is, the 4186 Packet Number and Payload fields) in bytes, encoded as a variable- 4187 length integer (Section 16). 4189 Packet Number: The packet number field is 1 to 4 bytes long. The 4190 packet number has confidentiality protection separate from packet 4191 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4192 of the packet number field is encoded in the Packet Number Length 4193 bits of byte 0 (see above). 4195 17.2.1. Version Negotiation Packet 4197 A Version Negotiation packet is inherently not version-specific. 4198 Upon receipt by a client, it will be identified as a Version 4199 Negotiation packet based on the Version field having a value of 0. 4201 The Version Negotiation packet is a response to a client packet that 4202 contains a version that is not supported by the server, and is only 4203 sent by servers. 4205 The layout of a Version Negotiation packet is: 4207 0 1 2 3 4208 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 4209 +-+-+-+-+-+-+-+-+ 4210 |1| Unused (7) | 4211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4212 | Version (32) | 4213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4214 | DCID Len (8) | 4215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4216 | Destination Connection ID (0..2040) ... 4217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4218 | SCID Len (8) | 4219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4220 | Source Connection ID (0..2040) ... 4221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4222 | Supported Version 1 (32) ... 4223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4224 | [Supported Version 2 (32)] ... 4225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4226 ... 4227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4228 | [Supported Version N (32)] ... 4229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4231 Figure 10: Version Negotiation Packet 4233 The value in the Unused field is selected randomly by the server. 4234 Clients MUST ignore the value of this field. Servers SHOULD set the 4235 most significant bit of this field (0x40) to 1 so that Version 4236 Negotiation packets appear to have the Fixed Bit field. 4238 The Version field of a Version Negotiation packet MUST be set to 4239 0x00000000. 4241 The server MUST include the value from the Source Connection ID field 4242 of the packet it receives in the Destination Connection ID field. 4243 The value for Source Connection ID MUST be copied from the 4244 Destination Connection ID of the received packet, which is initially 4245 randomly selected by a client. Echoing both connection IDs gives 4246 clients some assurance that the server received the packet and that 4247 the Version Negotiation packet was not generated by an off-path 4248 attacker. 4250 As future versions of QUIC may support Connection IDs larger than the 4251 version 1 limit, Version Negotiation packets could carry Connection 4252 IDs that are longer than 20 bytes. 4254 The remainder of the Version Negotiation packet is a list of 32-bit 4255 versions which the server supports. 4257 A Version Negotiation packet cannot be explicitly acknowledged in an 4258 ACK frame by a client. Receiving another Initial packet implicitly 4259 acknowledges a Version Negotiation packet. 4261 The Version Negotiation packet does not include the Packet Number and 4262 Length fields present in other packets that use the long header form. 4263 Consequently, a Version Negotiation packet consumes an entire UDP 4264 datagram. 4266 A server MUST NOT send more than one Version Negotiation packet in 4267 response to a single UDP datagram. 4269 See Section 6 for a description of the version negotiation process. 4271 17.2.2. Initial Packet 4273 An Initial packet uses long headers with a type value of 0x0. It 4274 carries the first CRYPTO frames sent by the client and server to 4275 perform key exchange, and carries ACKs in either direction. 4277 +-+-+-+-+-+-+-+-+ 4278 |1|1| 0 |R R|P P| 4279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4280 | Version (32) | 4281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4282 | DCID Len (8) | 4283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4284 | Destination Connection ID (0..160) ... 4285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4286 | SCID Len (8) | 4287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4288 | Source Connection ID (0..160) ... 4289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4290 | Token Length (i) ... 4291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4292 | Token (*) ... 4293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4294 | Length (i) ... 4295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4296 | Packet Number (8/16/24/32) ... 4297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4298 | Payload (*) ... 4299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4301 Figure 11: Initial Packet 4303 The Initial packet contains a long header as well as the Length and 4304 Packet Number fields. The first byte contains the Reserved and 4305 Packet Number Length bits. Between the SCID and Length fields, there 4306 are two additional field specific to the Initial packet. 4308 Token Length: A variable-length integer specifying the length of the 4309 Token field, in bytes. This value is zero if no token is present. 4310 Initial packets sent by the server MUST set the Token Length field 4311 to zero; clients that receive an Initial packet with a non-zero 4312 Token Length field MUST either discard the packet or generate a 4313 connection error of type PROTOCOL_VIOLATION. 4315 Token: The value of the token that was previously provided in a 4316 Retry packet or NEW_TOKEN frame. 4318 Payload: The payload of the packet. 4320 In order to prevent tampering by version-unaware middleboxes, Initial 4321 packets are protected with connection- and version-specific keys 4322 (Initial keys) as described in [QUIC-TLS]. This protection does not 4323 provide confidentiality or integrity against on-path attackers, but 4324 provides some level of protection against off-path attackers. 4326 The client and server use the Initial packet type for any packet that 4327 contains an initial cryptographic handshake message. This includes 4328 all cases where a new packet containing the initial cryptographic 4329 message needs to be created, such as the packets sent after receiving 4330 a Retry packet (Section 17.2.5). 4332 A server sends its first Initial packet in response to a client 4333 Initial. A server may send multiple Initial packets. The 4334 cryptographic key exchange could require multiple round trips or 4335 retransmissions of this data. 4337 The payload of an Initial packet includes a CRYPTO frame (or frames) 4338 containing a cryptographic handshake message, ACK frames, or both. 4339 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 4340 that receives an Initial packet containing other frames can either 4341 discard the packet as spurious or treat it as a connection error. 4343 The first packet sent by a client always includes a CRYPTO frame that 4344 contains the start or all of the first cryptographic handshake 4345 message. The first CRYPTO frame sent always begins at an offset of 0 4346 (see Section 7). 4348 Note that if the server sends a HelloRetryRequest, the client will 4349 send another series of Initial packets. These Initial packets will 4350 continue the cryptographic handshake and will contain CRYPTO frames 4351 starting at an offset matching the size of the CRYPTO frames sent in 4352 the first flight of Initial packets. 4354 17.2.2.1. Abandoning Initial Packets 4356 A client stops both sending and processing Initial packets when it 4357 sends its first Handshake packet. A server stops sending and 4358 processing Initial packets when it receives its first Handshake 4359 packet. Though packets might still be in flight or awaiting 4360 acknowledgment, no further Initial packets need to be exchanged 4361 beyond this point. Initial packet protection keys are discarded (see 4362 Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and 4363 congestion control state (see Section 6.5 of [QUIC-RECOVERY]). 4365 Any data in CRYPTO frames is discarded - and no longer retransmitted 4366 - when Initial keys are discarded. 4368 17.2.3. 0-RTT 4370 A 0-RTT packet uses long headers with a type value of 0x1, followed 4371 by the Length and Packet Number fields. The first byte contains the 4372 Reserved and Packet Number Length bits. It is used to carry "early" 4373 data from the client to the server as part of the first flight, prior 4374 to handshake completion. As part of the TLS handshake, the server 4375 can accept or reject this early data. 4377 See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its 4378 limitations. 4380 +-+-+-+-+-+-+-+-+ 4381 |1|1| 1 |R R|P P| 4382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4383 | Version (32) | 4384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4385 | DCID Len (8) | 4386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4387 | Destination Connection ID (0..160) ... 4388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4389 | SCID Len (8) | 4390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4391 | Source Connection ID (0..160) ... 4392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4393 | Length (i) ... 4394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4395 | Packet Number (8/16/24/32) ... 4396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4397 | Payload (*) ... 4398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4400 0-RTT Packet 4402 Packet numbers for 0-RTT protected packets use the same space as 4403 1-RTT protected packets. 4405 After a client receives a Retry packet, 0-RTT packets are likely to 4406 have been lost or discarded by the server. A client SHOULD attempt 4407 to resend data in 0-RTT packets after it sends a new Initial packet. 4409 A client MUST NOT reset the packet number it uses for 0-RTT packets, 4410 since the keys used to protect 0-RTT packets will not change as a 4411 result of responding to a Retry packet. Sending packets with the 4412 same packet number in that case is likely to compromise the packet 4413 protection for all 0-RTT packets because the same key and nonce could 4414 be used to protect different content. 4416 A client only receives acknowledgments for its 0-RTT packets once the 4417 handshake is complete. Consequently, a server might expect 0-RTT 4418 packets to start with a packet number of 0. Therefore, in 4419 determining the length of the packet number encoding for 0-RTT 4420 packets, a client MUST assume that all packets up to the current 4421 packet number are in flight, starting from a packet number of 0. 4423 Thus, 0-RTT packets could need to use a longer packet number 4424 encoding. 4426 A client MUST NOT send 0-RTT packets once it starts processing 1-RTT 4427 packets from the server. This means that 0-RTT packets cannot 4428 contain any response to frames from 1-RTT packets. For instance, a 4429 client cannot send an ACK frame in a 0-RTT packet, because that can 4430 only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT 4431 packet MUST be carried in a 1-RTT packet. 4433 A server SHOULD treat a violation of remembered limits as a 4434 connection error of an appropriate type (for instance, a 4435 FLOW_CONTROL_ERROR for exceeding stream data limits). 4437 17.2.4. Handshake Packet 4439 A Handshake packet uses long headers with a type value of 0x2, 4440 followed by the Length and Packet Number fields. The first byte 4441 contains the Reserved and Packet Number Length bits. It is used to 4442 carry acknowledgments and cryptographic handshake messages from the 4443 server and client. 4445 +-+-+-+-+-+-+-+-+ 4446 |1|1| 2 |R R|P P| 4447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4448 | Version (32) | 4449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4450 | DCID Len (8) | 4451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4452 | Destination Connection ID (0..160) ... 4453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4454 | SCID Len (8) | 4455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 | Source Connection ID (0..160) ... 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4458 | Length (i) ... 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4460 | Packet Number (8/16/24/32) ... 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 | Payload (*) ... 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4465 Figure 12: Handshake Protected Packet 4467 Once a client has received a Handshake packet from a server, it uses 4468 Handshake packets to send subsequent cryptographic handshake messages 4469 and acknowledgments to the server. 4471 The Destination Connection ID field in a Handshake packet contains a 4472 connection ID that is chosen by the recipient of the packet; the 4473 Source Connection ID includes the connection ID that the sender of 4474 the packet wishes to use (see Section 7.2). 4476 Handshake packets are their own packet number space, and thus the 4477 first Handshake packet sent by a server contains a packet number of 4478 0. 4480 The payload of this packet contains CRYPTO frames and could contain 4481 PADDING, or ACK frames. Handshake packets MAY contain 4482 CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake 4483 packets with other frames as a connection error. 4485 Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at 4486 the Handshake encryption level is discarded - and no longer 4487 retransmitted - when Handshake protection keys are discarded. 4489 17.2.5. Retry Packet 4491 A Retry packet uses a long packet header with a type value of 0x3. 4492 It carries an address validation token created by the server. It is 4493 used by a server that wishes to perform a retry (see Section 8.1). 4495 0 1 2 3 4496 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 4497 +-+-+-+-+-+-+-+-+ 4498 |1|1| 3 | Unused| 4499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4500 | Version (32) | 4501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4502 | DCID Len (8) | 4503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4504 | Destination Connection ID (0..160) ... 4505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4506 | SCID Len (8) | 4507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 | Source Connection ID (0..160) ... 4509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4510 | ODCID Len (8) | 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4512 | Original Destination Connection ID (0..160) ... 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4514 | Retry Token (*) ... 4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4517 Figure 13: Retry Packet 4519 A Retry packet (shown in Figure 13) does not contain any protected 4520 fields. The value in the Unused field is selected randomly by the 4521 server. In addition to the long header, it contains these additional 4522 fields: 4524 ODCID Len: The ODCID Len contains the length in bytes of the 4525 Original Destination Connection ID field that follows it. This 4526 length is encoded as a 8-bit unsigned integer. In QUIC version 1, 4527 this value MUST NOT exceed 20 bytes. Clients that receive a 4528 version 1 Retry Packet with a value larger than 20 MUST drop the 4529 packet. 4531 Original Destination Connection ID: The Original Destination 4532 Connection ID contains the value of the Destination Connection ID 4533 from the Initial packet that this Retry is in response to. The 4534 length of this field is given in ODCID Len. 4536 Retry Token: An opaque token that the server can use to validate the 4537 client's address. 4539 The server populates the Destination Connection ID with the 4540 connection ID that the client included in the Source Connection ID of 4541 the Initial packet. 4543 The server includes a connection ID of its choice in the Source 4544 Connection ID field. This value MUST not be equal to the Destination 4545 Connection ID field of the packet sent by the client. A client MUST 4546 discard a Retry packet that contains a Source Connection ID field 4547 that is identical to the Destination Connection ID field of its 4548 Initial packet. The client MUST use the value from the Source 4549 Connection ID field of the Retry packet in the Destination Connection 4550 ID field of subsequent packets that it sends. 4552 A server MAY send Retry packets in response to Initial and 0-RTT 4553 packets. A server can either discard or buffer 0-RTT packets that it 4554 receives. A server can send multiple Retry packets as it receives 4555 Initial or 0-RTT packets. A server MUST NOT send more than one Retry 4556 packet in response to a single UDP datagram. 4558 A client MUST accept and process at most one Retry packet for each 4559 connection attempt. After the client has received and processed an 4560 Initial or Retry packet from the server, it MUST discard any 4561 subsequent Retry packets that it receives. 4563 Clients MUST discard Retry packets that contain an Original 4564 Destination Connection ID field that does not match the Destination 4565 Connection ID from its Initial packet. This prevents an off-path 4566 attacker from injecting a Retry packet. 4568 The client responds to a Retry packet with an Initial packet that 4569 includes the provided Retry Token to continue connection 4570 establishment. 4572 A client sets the Destination Connection ID field of this Initial 4573 packet to the value from the Source Connection ID in the Retry 4574 packet. Changing Destination Connection ID also results in a change 4575 to the keys used to protect the Initial packet. It also sets the 4576 Token field to the token provided in the Retry. The client MUST NOT 4577 change the Source Connection ID because the server could include the 4578 connection ID as part of its token validation logic (see 4579 Section 8.1.3). 4581 The next Initial packet from the client uses the connection ID and 4582 token values from the Retry packet (see Section 7.2). Aside from 4583 this, the Initial packet sent by the client is subject to the same 4584 restrictions as the first Initial packet. A client MUST use the same 4585 cryptographic handshake message it includes in this packet. A server 4586 MAY treat a packet that contains a different cryptographic handshake 4587 message as a connection error or discard it. 4589 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4590 0-RTT packets to the connection ID provided by the server. A client 4591 MUST NOT change the cryptographic handshake message it sends in 4592 response to receiving a Retry. 4594 A client MUST NOT reset the packet number for any packet number space 4595 after processing a Retry packet; Section 17.2.3 contains more 4596 information on this. 4598 A server acknowledges the use of a Retry packet for a connection 4599 using the original_connection_id transport parameter (see 4600 Section 18.2). If the server sends a Retry packet, it MUST include 4601 the value of the Original Destination Connection ID field of the 4602 Retry packet (that is, the Destination Connection ID field from the 4603 client's first Initial packet) in the transport parameter. 4605 If the client received and processed a Retry packet, it MUST validate 4606 that the original_connection_id transport parameter is present and 4607 correct; otherwise, it MUST validate that the transport parameter is 4608 absent. A client MUST treat a failed validation as a connection 4609 error of type TRANSPORT_PARAMETER_ERROR. 4611 A Retry packet does not include a packet number and cannot be 4612 explicitly acknowledged by a client. 4614 17.3. Short Header Packets 4616 This version of QUIC defines a single packet type which uses the 4617 short packet header. 4619 0 1 2 3 4620 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 4621 +-+-+-+-+-+-+-+-+ 4622 |0|1|S|R|R|K|P P| 4623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4624 | Destination Connection ID (0..160) ... 4625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4626 | Packet Number (8/16/24/32) ... 4627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4628 | Protected Payload (*) ... 4629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4631 Figure 14: Short Header Packet Format 4633 The short header can be used after the version and 1-RTT keys are 4634 negotiated. Packets that use the short header contain the following 4635 fields: 4637 Header Form: The most significant bit (0x80) of byte 0 is set to 0 4638 for the short header. 4640 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4641 containing a zero value for this bit are not valid packets in this 4642 version and MUST be discarded. 4644 Spin Bit (S): The third most significant bit (0x20) of byte 0 is the 4645 latency spin bit, set as described in Section 17.3.1. 4647 Reserved Bits (R): The next two bits (those with a mask of 0x18) of 4648 byte 0 are reserved. These bits are protected using header 4649 protection (see Section 5.4 of [QUIC-TLS]). The value included 4650 prior to protection MUST be set to 0. An endpoint MUST treat 4651 receipt of a packet that has a non-zero value for these bits, 4652 after removing both packet and header protection, as a connection 4653 error of type PROTOCOL_VIOLATION. Discarding such a packet after 4654 only removing header protection can expose the endpoint to attacks 4655 (see Section 9.3 of [QUIC-TLS]). 4657 Key Phase (K): The next bit (0x04) of byte 0 indicates the key 4658 phase, which allows a recipient of a packet to identify the packet 4659 protection keys that are used to protect the packet. See 4660 [QUIC-TLS] for details. This bit is protected using header 4661 protection (see Section 5.4 of [QUIC-TLS]). 4663 Packet Number Length (P): The least significant two bits (those with 4664 a mask of 0x03) of byte 0 contain the length of the packet number, 4665 encoded as an unsigned, two-bit integer that is one less than the 4666 length of the packet number field in bytes. That is, the length 4667 of the packet number field is the value of this field, plus one. 4668 These bits are protected using header protection (see Section 5.4 4669 of [QUIC-TLS]). 4671 Destination Connection ID: The Destination Connection ID is a 4672 connection ID that is chosen by the intended recipient of the 4673 packet. See Section 5.1 for more details. 4675 Packet Number: The packet number field is 1 to 4 bytes long. The 4676 packet number has confidentiality protection separate from packet 4677 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4678 of the packet number field is encoded in Packet Number Length 4679 field. See Section 17.1 for details. 4681 Protected Payload: Packets with a short header always include a 4682 1-RTT protected payload. 4684 The header form bit and the connection ID field of a short header 4685 packet are version-independent. The remaining fields are specific to 4686 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 4687 packets from different versions of QUIC are interpreted. 4689 17.3.1. Latency Spin Bit 4691 The latency spin bit enables passive latency monitoring from 4692 observation points on the network path throughout the duration of a 4693 connection. The spin bit is only present in the short packet header, 4694 since it is possible to measure the initial RTT of a connection by 4695 observing the handshake. Therefore, the spin bit is available after 4696 version negotiation and connection establishment are completed. On- 4697 path measurement and use of the latency spin bit is further discussed 4698 in [QUIC-MANAGEABILITY]. 4700 The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that 4701 chooses to support the spin bit MUST implement it as specified in 4702 this section. 4704 Each endpoint unilaterally decides if the spin bit is enabled or 4705 disabled for a connection. Implementations MUST allow administrators 4706 of clients and servers to disable the spin bit either globally or on 4707 a per-connection basis. Even when the spin bit is not disabled by 4708 the administrator, implementations MUST disable the spin bit for a 4709 given connection with a certain likelihood. The random selection 4710 process SHOULD be designed such that on average the spin bit is 4711 disabled for at least one eighth of network paths. The selection 4712 process performed at the beginning of the connection SHOULD be 4713 applied for all paths used by the connection. 4715 When the spin bit is disabled, endpoints MAY set the spin bit to any 4716 value, and MUST ignore any incoming value. It is RECOMMENDED that 4717 endpoints set the spin bit to a random value either chosen 4718 independently for each packet or chosen independently for each 4719 connection ID. 4721 If the spin bit is enabled for the connection, the endpoint maintains 4722 a spin value and sets the spin bit in the short header to the 4723 currently stored value when a packet with a short header is sent out. 4724 The spin value is initialized to 0 in the endpoint at connection 4725 start. Each endpoint also remembers the highest packet number seen 4726 from its peer on the connection. 4728 When a server receives a short header packet that increments the 4729 highest packet number seen by the server from the client, it sets the 4730 spin value to be equal to the spin bit in the received packet. 4732 When a client receives a short header packet that increments the 4733 highest packet number seen by the client from the server, it sets the 4734 spin value to the inverse of the spin bit in the received packet. 4736 An endpoint resets its spin value to zero when sending the first 4737 packet of a given connection with a new connection ID. This reduces 4738 the risk that transient spin bit state can be used to link flows 4739 across connection migration or ID change. 4741 With this mechanism, the server reflects the spin value received, 4742 while the client 'spins' it after one RTT. On-path observers can 4743 measure the time between two spin bit toggle events to estimate the 4744 end-to-end RTT of a connection. 4746 18. Transport Parameter Encoding 4748 The "extension_data" field of the quic_transport_parameters extension 4749 defined in [QUIC-TLS] contains the QUIC transport parameters. They 4750 are encoded as a length-prefixed sequence of transport parameters, as 4751 shown in Figure 15: 4753 0 1 2 3 4754 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4756 | Sequence Length (16) | 4757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4758 | Transport Parameter 1 (*) ... 4759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 | Transport Parameter 2 (*) ... 4761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4762 ... 4763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4764 | Transport Parameter N (*) ... 4765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4767 Figure 15: Sequence of Transport Parameters 4769 The Sequence Length field contains the length of the sequence of 4770 transport parameters, in bytes. Each transport parameter is encoded 4771 as an (identifier, length, value) tuple, as shown in Figure 16: 4773 0 1 2 3 4774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4776 | Transport Parameter ID (16) | Transport Param Length (16) | 4777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4778 | Transport Parameter Value (*) ... 4779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4781 Figure 16: Transport Parameter Encoding 4783 The Transport Param Length field contains the length of the Transport 4784 Parameter Value field. 4786 QUIC encodes transport parameters into a sequence of bytes, which are 4787 then included in the cryptographic handshake. 4789 18.1. Reserved Transport Parameters 4791 Transport parameters with an identifier of the form "31 * N + 27" for 4792 integer values of N are reserved to exercise the requirement that 4793 unknown transport parameters be ignored. These transport parameters 4794 have no semantics, and may carry arbitrary values. 4796 18.2. Transport Parameter Definitions 4798 This section details the transport parameters defined in this 4799 document. 4801 Many transport parameters listed here have integer values. Those 4802 transport parameters that are identified as integers use a variable- 4803 length integer encoding (see Section 16) and have a default value of 4804 0 if the transport parameter is absent, unless otherwise stated. 4806 The following transport parameters are defined: 4808 original_connection_id (0x0000): The value of the Destination 4809 Connection ID field from the first Initial packet sent by the 4810 client. This transport parameter is only sent by a server. This 4811 is the same value sent in the "Original Destination Connection ID" 4812 field of a Retry packet (see Section 17.2.5). A server MUST 4813 include the original_connection_id transport parameter if it sent 4814 a Retry packet. 4816 idle_timeout (0x0001): The idle timeout is a value in milliseconds 4817 that is encoded as an integer; see (Section 10.2). If this 4818 parameter is absent or zero then the idle timeout is disabled. 4820 stateless_reset_token (0x0002): A stateless reset token is used in 4821 verifying a stateless reset; see Section 10.4. This parameter is 4822 a sequence of 16 bytes. This transport parameter MUST NOT be sent 4823 by a client, but MAY be sent by a server. A server that does not 4824 send this transport parameter cannot use stateless reset 4825 (Section 10.4) for the connection ID negotiated during the 4826 handshake. 4828 max_packet_size (0x0003): The maximum packet size parameter is an 4829 integer value that limits the size of packets that the endpoint is 4830 willing to receive. This indicates that packets larger than this 4831 limit will be dropped. The default for this parameter is the 4832 maximum permitted UDP payload of 65527. Values below 1200 are 4833 invalid. This limit only applies to protected packets 4834 (Section 12.1). 4836 initial_max_data (0x0004): The initial maximum data parameter is an 4837 integer value that contains the initial value for the maximum 4838 amount of data that can be sent on the connection. This is 4839 equivalent to sending a MAX_DATA (Section 19.9) for the connection 4840 immediately after completing the handshake. 4842 initial_max_stream_data_bidi_local (0x0005): This parameter is an 4843 integer value specifying the initial flow control limit for 4844 locally-initiated bidirectional streams. This limit applies to 4845 newly created bidirectional streams opened by the endpoint that 4846 sends the transport parameter. In client transport parameters, 4847 this applies to streams with an identifier with the least 4848 significant two bits set to 0x0; in server transport parameters, 4849 this applies to streams with the least significant two bits set to 4850 0x1. 4852 initial_max_stream_data_bidi_remote (0x0006): This parameter is an 4853 integer value specifying the initial flow control limit for peer- 4854 initiated bidirectional streams. This limit applies to newly 4855 created bidirectional streams opened by the endpoint that receives 4856 the transport parameter. In client transport parameters, this 4857 applies to streams with an identifier with the least significant 4858 two bits set to 0x1; in server transport parameters, this applies 4859 to streams with the least significant two bits set to 0x0. 4861 initial_max_stream_data_uni (0x0007): This parameter is an integer 4862 value specifying the initial flow control limit for unidirectional 4863 streams. This limit applies to newly created unidirectional 4864 streams opened by the endpoint that receives the transport 4865 parameter. In client transport parameters, this applies to 4866 streams with an identifier with the least significant two bits set 4867 to 0x3; in server transport parameters, this applies to streams 4868 with the least significant two bits set to 0x2. 4870 initial_max_streams_bidi (0x0008): The initial maximum bidirectional 4871 streams parameter is an integer value that contains the initial 4872 maximum number of bidirectional streams the peer may initiate. If 4873 this parameter is absent or zero, the peer cannot open 4874 bidirectional streams until a MAX_STREAMS frame is sent. Setting 4875 this parameter is equivalent to sending a MAX_STREAMS 4876 (Section 19.11) of the corresponding type with the same value. 4878 initial_max_streams_uni (0x0009): The initial maximum unidirectional 4879 streams parameter is an integer value that contains the initial 4880 maximum number of unidirectional streams the peer may initiate. 4881 If this parameter is absent or zero, the peer cannot open 4882 unidirectional streams until a MAX_STREAMS frame is sent. Setting 4883 this parameter is equivalent to sending a MAX_STREAMS 4884 (Section 19.11) of the corresponding type with the same value. 4886 ack_delay_exponent (0x000a): The ACK delay exponent is an integer 4887 value indicating an exponent used to decode the ACK Delay field in 4888 the ACK frame (Section 19.3). If this value is absent, a default 4889 value of 3 is assumed (indicating a multiplier of 8). Values 4890 above 20 are invalid. 4892 max_ack_delay (0x000b): The maximum ACK delay is an integer value 4893 indicating the maximum amount of time in milliseconds by which the 4894 endpoint will delay sending acknowledgments. This value SHOULD 4895 include the receiver's expected delays in alarms firing. For 4896 example, if a receiver sets a timer for 5ms and alarms commonly 4897 fire up to 1ms late, then it should send a max_ack_delay of 6ms. 4898 If this value is absent, a default of 25 milliseconds is assumed. 4899 Values of 2^14 or greater are invalid. 4901 disable_active_migration (0x000c): The disable active migration 4902 transport parameter is included if the endpoint does not support 4903 active connection migration (Section 9). Peers of an endpoint 4904 that sets this transport parameter MUST NOT send any packets, 4905 including probing packets (Section 9.1), from a local address or 4906 port other than that used to perform the handshake. This 4907 parameter is a zero-length value. 4909 preferred_address (0x000d): The server's preferred address is used 4910 to effect a change in server address at the end of the handshake, 4911 as described in Section 9.6. The format of this transport 4912 parameter is shown in Figure 17. This transport parameter is only 4913 sent by a server. Servers MAY choose to only send a preferred 4914 address of one address family by sending an all-zero address and 4915 port (0.0.0.0:0 or ::.0) for the other family. IP addresses are 4916 encoded in network byte order. The CID Length field contains the 4917 length of the Connection ID field. 4919 0 1 2 3 4920 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 4921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4922 | IPv4 Address (32) | 4923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4924 | IPv4 Port (16) | 4925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4926 | | 4927 + + 4928 | | 4929 + IPv6 Address (128) + 4930 | | 4931 + + 4932 | | 4933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4934 | IPv6 Port (16) | 4935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4936 | CID Length (8)| 4937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4938 | Connection ID (*) ... 4939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4940 | | 4941 + + 4942 | | 4943 + Stateless Reset Token (128) + 4944 | | 4945 + + 4946 | | 4947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4949 Figure 17: Preferred Address format 4951 active_connection_id_limit (0x000e): The maximum number of 4952 connection IDs from the peer that an endpoint is willing to store. 4953 This value includes only connection IDs sent in NEW_CONNECTION_ID 4954 frames. If this parameter is absent, a default of 0 is assumed. 4956 If present, transport parameters that set initial flow control limits 4957 (initial_max_stream_data_bidi_local, 4958 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 4959 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 4960 every stream of the corresponding type immediately after opening. If 4961 the transport parameter is absent, streams of that type start with a 4962 flow control limit of 0. 4964 A client MUST NOT include server-only transport parameters 4965 (original_connection_id, stateless_reset_token, or 4966 preferred_address). A server MUST treat receipt of any of these 4967 transport parameters as a connection error of type 4968 TRANSPORT_PARAMETER_ERROR. 4970 19. Frame Types and Formats 4972 As described in Section 12.4, packets contain one or more frames. 4973 This section describes the format and semantics of the core QUIC 4974 frame types. 4976 19.1. PADDING Frame 4978 The PADDING frame (type=0x00) has no semantic value. PADDING frames 4979 can be used to increase the size of a packet. Padding can be used to 4980 increase an initial client packet to the minimum required size, or to 4981 provide protection against traffic analysis for protected packets. 4983 A PADDING frame has no content. That is, a PADDING frame consists of 4984 the single byte that identifies the frame as a PADDING frame. 4986 19.2. PING Frame 4988 Endpoints can use PING frames (type=0x01) to verify that their peers 4989 are still alive or to check reachability to the peer. The PING frame 4990 contains no additional fields. 4992 The receiver of a PING frame simply needs to acknowledge the packet 4993 containing this frame. 4995 The PING frame can be used to keep a connection alive when an 4996 application or application protocol wishes to prevent the connection 4997 from timing out. An application protocol SHOULD provide guidance 4998 about the conditions under which generating a PING is recommended. 4999 This guidance SHOULD indicate whether it is the client or the server 5000 that is expected to send the PING. Having both endpoints send PING 5001 frames without coordination can produce an excessive number of 5002 packets and poor performance. 5004 A connection will time out if no packets are sent or received for a 5005 period longer than the time specified in the idle_timeout transport 5006 parameter (see Section 10). However, state in middleboxes might time 5007 out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 5008 minute timeout interval, experience shows that sending packets every 5009 15 to 30 seconds is necessary to prevent the majority of middleboxes 5010 from losing state for UDP flows. 5012 19.3. ACK Frames 5014 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 5015 packets they have received and processed. The ACK frame contains one 5016 or more ACK Ranges. ACK Ranges identify acknowledged packets. If 5017 the frame type is 0x03, ACK frames also contain the sum of QUIC 5018 packets with associated ECN marks received on the connection up until 5019 this point. QUIC implementations MUST properly handle both types 5020 and, if they have enabled ECN for packets they send, they SHOULD use 5021 the information in the ECN section to manage their congestion state. 5023 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 5024 remains acknowledged, even if it does not appear in a future ACK 5025 frame. This is unlike TCP SACKs ([RFC2018]). 5027 It is expected that a sender will reuse the same packet number across 5028 different packet number spaces. ACK frames only acknowledge the 5029 packet numbers that were transmitted by the sender in the same packet 5030 number space of the packet that the ACK was received in. 5032 Version Negotiation and Retry packets cannot be acknowledged because 5033 they do not contain a packet number. Rather than relying on ACK 5034 frames, these packets are implicitly acknowledged by the next Initial 5035 packet sent by the client. 5037 An ACK frame is as follows: 5039 0 1 2 3 5040 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 5041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5042 | Largest Acknowledged (i) ... 5043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5044 | ACK Delay (i) ... 5045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5046 | ACK Range Count (i) ... 5047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5048 | First ACK Range (i) ... 5049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5050 | ACK Ranges (*) ... 5051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5052 | [ECN Counts] ... 5053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5055 Figure 18: ACK Frame Format 5057 ACK frames contain the following fields: 5059 Largest Acknowledged: A variable-length integer representing the 5060 largest packet number the peer is acknowledging; this is usually 5061 the largest packet number that the peer has received prior to 5062 generating the ACK frame. Unlike the packet number in the QUIC 5063 long or short header, the value in an ACK frame is not truncated. 5065 ACK Delay: A variable-length integer representing the time delta in 5066 microseconds between when this ACK was sent and when the largest 5067 acknowledged packet, as indicated in the Largest Acknowledged 5068 field, was received by this peer. The value of the ACK Delay 5069 field is scaled by multiplying the encoded value by 2 to the power 5070 of the value of the "ack_delay_exponent" transport parameter set 5071 by the sender of the ACK frame (see Section 18.2). Scaling in 5072 this fashion allows for a larger range of values with a shorter 5073 encoding at the cost of lower resolution. Because the receiver 5074 doesn't use the ACK Delay for Initial and Handshake packets, a 5075 sender SHOULD send a value of 0. 5077 ACK Range Count: A variable-length integer specifying the number of 5078 Gap and ACK Range fields in the frame. 5080 First ACK Range: A variable-length integer indicating the number of 5081 contiguous packets preceding the Largest Acknowledged that are 5082 being acknowledged. The First ACK Range is encoded as an ACK 5083 Range (see Section 19.3.1) starting from the Largest Acknowledged. 5084 That is, the smallest packet acknowledged in the range is 5085 determined by subtracting the First ACK Range value from the 5086 Largest Acknowledged. 5088 ACK Ranges: Contains additional ranges of packets which are 5089 alternately not acknowledged (Gap) and acknowledged (ACK Range); 5090 see Section 19.3.1. 5092 ECN Counts: The three ECN Counts; see Section 19.3.2. 5094 19.3.1. ACK Ranges 5096 The ACK Ranges field consists of alternating Gap and ACK Range values 5097 in descending packet number order. The number of Gap and ACK Range 5098 values is determined by the ACK Range Count field; one of each value 5099 is present for each value in the ACK Range Count field. 5101 ACK Ranges are structured as follows: 5103 0 1 2 3 5104 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 5105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5106 | [Gap (i)] ... 5107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5108 | [ACK Range (i)] ... 5109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5110 | [Gap (i)] ... 5111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5112 | [ACK Range (i)] ... 5113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5114 ... 5115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5116 | [Gap (i)] ... 5117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5118 | [ACK Range (i)] ... 5119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5121 Figure 19: ACK Ranges 5123 The fields that form the ACK Ranges are: 5125 Gap (repeated): A variable-length integer indicating the number of 5126 contiguous unacknowledged packets preceding the packet number one 5127 lower than the smallest in the preceding ACK Range. 5129 ACK Range (repeated): A variable-length integer indicating the 5130 number of contiguous acknowledged packets preceding the largest 5131 packet number, as determined by the preceding Gap. 5133 Gap and ACK Range value use a relative integer encoding for 5134 efficiency. Though each encoded value is positive, the values are 5135 subtracted, so that each ACK Range describes progressively lower- 5136 numbered packets. 5138 Each ACK Range acknowledges a contiguous range of packets by 5139 indicating the number of acknowledged packets that precede the 5140 largest packet number in that range. A value of zero indicates that 5141 only the largest packet number is acknowledged. Larger ACK Range 5142 values indicate a larger range, with corresponding lower values for 5143 the smallest packet number in the range. Thus, given a largest 5144 packet number for the range, the smallest value is determined by the 5145 formula: 5147 smallest = largest - ack_range 5149 An ACK Range acknowledges all packets between the smallest packet 5150 number and the largest, inclusive. 5152 The largest value for an ACK Range is determined by cumulatively 5153 subtracting the size of all preceding ACK Ranges and Gaps. 5155 Each Gap indicates a range of packets that are not being 5156 acknowledged. The number of packets in the gap is one higher than 5157 the encoded value of the Gap field. 5159 The value of the Gap field establishes the largest packet number 5160 value for the subsequent ACK Range using the following formula: 5162 largest = previous_smallest - gap - 2 5164 If any computed packet number is negative, an endpoint MUST generate 5165 a connection error of type FRAME_ENCODING_ERROR. 5167 19.3.2. ECN Counts 5169 The ACK frame uses the least significant bit (that is, type 0x03) to 5170 indicate ECN feedback and report receipt of QUIC packets with 5171 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 5172 header. ECN Counts are only present when the ACK frame type is 0x03. 5174 ECN Counts are only parsed when the ACK frame type is 0x03. There 5175 are 3 ECN counts, as follows: 5177 0 1 2 3 5178 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 5179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5180 | ECT(0) Count (i) ... 5181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5182 | ECT(1) Count (i) ... 5183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5184 | ECN-CE Count (i) ... 5185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5187 The three ECN Counts are: 5189 ECT(0) Count: A variable-length integer representing the total 5190 number of packets received with the ECT(0) codepoint in the packet 5191 number space of the ACK frame. 5193 ECT(1) Count: A variable-length integer representing the total 5194 number of packets received with the ECT(1) codepoint in the packet 5195 number space of the ACK frame. 5197 CE Count: A variable-length integer representing the total number of 5198 packets received with the CE codepoint in the packet number space 5199 of the ACK frame. 5201 ECN counts are maintained separately for each packet number space. 5203 19.4. RESET_STREAM Frame 5205 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 5206 terminate the sending part of a stream. 5208 After sending a RESET_STREAM, an endpoint ceases transmission and 5209 retransmission of STREAM frames on the identified stream. A receiver 5210 of RESET_STREAM can discard any data that it already received on that 5211 stream. 5213 An endpoint that receives a RESET_STREAM frame for a send-only stream 5214 MUST terminate the connection with error STREAM_STATE_ERROR. 5216 The RESET_STREAM frame is as follows: 5218 0 1 2 3 5219 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 5220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5221 | Stream ID (i) ... 5222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5223 | Application Error Code (i) ... 5224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5225 | Final Size (i) ... 5226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5228 RESET_STREAM frames contain the following fields: 5230 Stream ID: A variable-length integer encoding of the Stream ID of 5231 the stream being terminated. 5233 Application Protocol Error Code: A variable-length integer 5234 containing the application protocol error code (see Section 20.1) 5235 which indicates why the stream is being closed. 5237 Final Size: A variable-length integer indicating the final size of 5238 the stream by the RESET_STREAM sender, in unit of bytes. 5240 19.5. STOP_SENDING Frame 5242 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 5243 incoming data is being discarded on receipt at application request. 5244 STOP_SENDING requests that a peer cease transmission on a stream. 5246 A STOP_SENDING frame can be sent for streams in the Recv or Size 5247 Known states (see Section 3.1). Receiving a STOP_SENDING frame for a 5248 locally-initiated stream that has not yet been created MUST be 5249 treated as a connection error of type STREAM_STATE_ERROR. An 5250 endpoint that receives a STOP_SENDING frame for a receive-only stream 5251 MUST terminate the connection with error STREAM_STATE_ERROR. 5253 The STOP_SENDING 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 | Application Error Code (i) ... 5261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5263 STOP_SENDING frames contain the following fields: 5265 Stream ID: A variable-length integer carrying the Stream ID of the 5266 stream being ignored. 5268 Application Error Code: A variable-length integer containing the 5269 application-specified reason the sender is ignoring the stream 5270 (see Section 20.1). 5272 19.6. CRYPTO Frame 5274 The CRYPTO frame (type=0x06) is used to transmit cryptographic 5275 handshake messages. It can be sent in all packet types except 0-RTT. 5276 The CRYPTO frame offers the cryptographic protocol an in-order stream 5277 of bytes. CRYPTO frames are functionally identical to STREAM frames, 5278 except that they do not bear a stream identifier; they are not flow 5279 controlled; and they do not carry markers for optional offset, 5280 optional length, and the end of the stream. 5282 The CRYPTO frame is as follows: 5284 0 1 2 3 5285 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 5286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5287 | Offset (i) ... 5288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5289 | Length (i) ... 5290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5291 | Crypto Data (*) ... 5292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5294 Figure 20: CRYPTO Frame Format 5296 CRYPTO frames contain the following fields: 5298 Offset: A variable-length integer specifying the byte offset in the 5299 stream for the data in this CRYPTO frame. 5301 Length: A variable-length integer specifying the length of the 5302 Crypto Data field in this CRYPTO frame. 5304 Crypto Data: The cryptographic message data. 5306 There is a separate flow of cryptographic handshake data in each 5307 encryption level, each of which starts at an offset of 0. This 5308 implies that each encryption level is treated as a separate CRYPTO 5309 stream of data. 5311 The largest offset delivered on a stream - the sum of the offset and 5312 data length - cannot exceed 2^62-1. Receipt of a frame that exceeds 5313 this limit MUST be treated as a connection error of type 5314 FRAME_ENCODING_ERROR. 5316 Unlike STREAM frames, which include a Stream ID indicating to which 5317 stream the data belongs, the CRYPTO frame carries data for a single 5318 stream per encryption level. The stream does not have an explicit 5319 end, so CRYPTO frames do not have a FIN bit. 5321 19.7. NEW_TOKEN Frame 5323 A server sends a NEW_TOKEN frame (type=0x07) to provide the client 5324 with a token to send in the header of an Initial packet for a future 5325 connection. 5327 The NEW_TOKEN frame is as follows: 5329 0 1 2 3 5330 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 5331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5332 | Token Length (i) ... 5333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5334 | Token (*) ... 5335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5337 NEW_TOKEN frames contain the following fields: 5339 Token Length: A variable-length integer specifying the length of the 5340 token in bytes. 5342 Token: An opaque blob that the client may use with a future Initial 5343 packet. The token MUST NOT be empty. An endpoint MUST treat 5344 receipt of a NEW_TOKEN frame with an empty Token field as a 5345 connection error of type FRAME_ENCODING_ERROR. 5347 An endpoint might receive multiple NEW_TOKEN frames that contain the 5348 same token value. Endpoints are responsible for discarding duplicate 5349 values, which might be used to link connection attempts; see 5350 Section 8.1.2. 5352 Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt 5353 of a NEW_TOKEN frame as a connection error of type 5354 PROTOCOL_VIOLATION. 5356 19.8. STREAM Frames 5358 STREAM frames implicitly create a stream and carry stream data. The 5359 STREAM frame takes the form 0b00001XXX (or the set of values from 5360 0x08 to 0x0f). The value of the three low-order bits of the frame 5361 type determines the fields that are present in the frame. 5363 o The OFF bit (0x04) in the frame type is set to indicate that there 5364 is an Offset field present. When set to 1, the Offset field is 5365 present. When set to 0, the Offset field is absent and the Stream 5366 Data starts at an offset of 0 (that is, the frame contains the 5367 first bytes of the stream, or the end of a stream that includes no 5368 data). 5370 o The LEN bit (0x02) in the frame type is set to indicate that there 5371 is a Length field present. If this bit is set to 0, the Length 5372 field is absent and the Stream Data field extends to the end of 5373 the packet. If this bit is set to 1, the Length field is present. 5375 o The FIN bit (0x01) of the frame type is set only on frames that 5376 contain the final size of the stream. Setting this bit indicates 5377 that the frame marks the end of the stream. 5379 An endpoint that receives a STREAM frame for a send-only stream MUST 5380 terminate the connection with error STREAM_STATE_ERROR. 5382 The STREAM frames are as follows: 5384 0 1 2 3 5385 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 5386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5387 | Stream ID (i) ... 5388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5389 | [Offset (i)] ... 5390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5391 | [Length (i)] ... 5392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5393 | Stream Data (*) ... 5394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5396 Figure 21: STREAM Frame Format 5398 STREAM frames contain the following fields: 5400 Stream ID: A variable-length integer indicating the stream ID of the 5401 stream (see Section 2.1). 5403 Offset: A variable-length integer specifying the byte offset in the 5404 stream for the data in this STREAM frame. This field is present 5405 when the OFF bit is set to 1. When the Offset field is absent, 5406 the offset is 0. 5408 Length: A variable-length integer specifying the length of the 5409 Stream Data field in this STREAM frame. This field is present 5410 when the LEN bit is set to 1. When the LEN bit is set to 0, the 5411 Stream Data field consumes all the remaining bytes in the packet. 5413 Stream Data: The bytes from the designated stream to be delivered. 5415 When a Stream Data field has a length of 0, the offset in the STREAM 5416 frame is the offset of the next byte that would be sent. 5418 The first byte in the stream has an offset of 0. The largest offset 5419 delivered on a stream - the sum of the offset and data length - 5420 cannot exceed 2^62-1, as it is not possible to provide flow control 5421 credit for that data. Receipt of a frame that exceeds this limit 5422 MUST be treated as a connection error of type FRAME_ENCODING_ERROR or 5423 FLOW_CONTROL_ERROR. 5425 19.9. MAX_DATA Frame 5427 The MAX_DATA frame (type=0x10) is used in flow control to inform the 5428 peer of the maximum amount of data that can be sent on the connection 5429 as a whole. 5431 The MAX_DATA frame is as follows: 5433 0 1 2 3 5434 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 5435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5436 | Maximum Data (i) ... 5437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5439 MAX_DATA frames contain the following fields: 5441 Maximum Data: A variable-length integer indicating the maximum 5442 amount of data that can be sent on the entire connection, in units 5443 of bytes. 5445 All data sent in STREAM frames counts toward this limit. The sum of 5446 the largest received offsets on all streams - including streams in 5447 terminal states - MUST NOT exceed the value advertised by a receiver. 5448 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 5449 error if it receives more data than the maximum data value that it 5450 has sent, unless this is a result of a change in the initial limits 5451 (see Section 7.3.1). 5453 19.10. MAX_STREAM_DATA Frame 5455 The MAX_STREAM_DATA frame (type=0x11) is used in flow control to 5456 inform a peer of the maximum amount of data that can be sent on a 5457 stream. 5459 A MAX_STREAM_DATA frame can be sent for streams in the Recv state 5460 (see Section 3.1). Receiving a MAX_STREAM_DATA frame for a locally- 5461 initiated stream that has not yet been created MUST be treated as a 5462 connection error of type STREAM_STATE_ERROR. An endpoint that 5463 receives a MAX_STREAM_DATA frame for a receive-only stream MUST 5464 terminate the connection with error STREAM_STATE_ERROR. 5466 The MAX_STREAM_DATA frame is as follows: 5468 0 1 2 3 5469 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 5470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5471 | Stream ID (i) ... 5472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5473 | Maximum Stream Data (i) ... 5474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5476 MAX_STREAM_DATA frames contain the following fields: 5478 Stream ID: The stream ID of the stream that is affected encoded as a 5479 variable-length integer. 5481 Maximum Stream Data: A variable-length integer indicating the 5482 maximum amount of data that can be sent on the identified stream, 5483 in units of bytes. 5485 When counting data toward this limit, an endpoint accounts for the 5486 largest received offset of data that is sent or received on the 5487 stream. Loss or reordering can mean that the largest received offset 5488 on a stream can be greater than the total size of data received on 5489 that stream. Receiving STREAM frames might not increase the largest 5490 received offset. 5492 The data sent on a stream MUST NOT exceed the largest maximum stream 5493 data value advertised by the receiver. An endpoint MUST terminate a 5494 connection with a FLOW_CONTROL_ERROR error if it receives more data 5495 than the largest maximum stream data that it has sent for the 5496 affected stream, unless this is a result of a change in the initial 5497 limits (see Section 7.3.1). 5499 19.11. MAX_STREAMS Frames 5501 The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the 5502 cumulative number of streams of a given type it is permitted to open. 5503 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 5504 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 5505 unidirectional streams. 5507 The MAX_STREAMS frames are as follows: 5509 0 1 2 3 5510 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 5511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5512 | Maximum Streams (i) ... 5513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5515 MAX_STREAMS frames contain the following fields: 5517 Maximum Streams: A count of the cumulative number of streams of the 5518 corresponding type that can be opened over the lifetime of the 5519 connection. Stream IDs cannot exceed 2^62-1, as it is not 5520 possible to encode stream IDs larger than this value. Receipt of 5521 a frame that permits opening of a stream larger than this limit 5522 MUST be treated as a FRAME_ENCODING_ERROR. 5524 Loss or reordering can cause a MAX_STREAMS frame to be received which 5525 states a lower stream limit than an endpoint has previously received. 5526 MAX_STREAMS frames which do not increase the stream limit MUST be 5527 ignored. 5529 An endpoint MUST NOT open more streams than permitted by the current 5530 stream limit set by its peer. For instance, a server that receives a 5531 unidirectional stream limit of 3 is permitted to open stream 3, 7, 5532 and 11, but not stream 15. An endpoint MUST terminate a connection 5533 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 5534 permitted. 5536 Note that these frames (and the corresponding transport parameters) 5537 do not describe the number of streams that can be opened 5538 concurrently. The limit includes streams that have been closed as 5539 well as those that are open. 5541 19.12. DATA_BLOCKED Frame 5543 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 5544 to send data, but is unable to due to connection-level flow control 5545 (see Section 4). DATA_BLOCKED frames can be used as input to tuning 5546 of flow control algorithms (see Section 4.2). 5548 The DATA_BLOCKED frame is as follows: 5550 0 1 2 3 5551 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 5552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5553 | Data Limit (i) ... 5554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5556 DATA_BLOCKED frames contain the following fields: 5558 Data Limit: A variable-length integer indicating the connection- 5559 level limit at which blocking occurred. 5561 19.13. STREAM_DATA_BLOCKED Frame 5563 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 5564 wishes to send data, but is unable to due to stream-level flow 5565 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 5567 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 5568 stream MUST terminate the connection with error STREAM_STATE_ERROR. 5570 The STREAM_DATA_BLOCKED frame is as follows: 5572 0 1 2 3 5573 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 5574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5575 | Stream ID (i) ... 5576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5577 | Stream Data Limit (i) ... 5578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5580 STREAM_DATA_BLOCKED frames contain the following fields: 5582 Stream ID: A variable-length integer indicating the stream which is 5583 flow control blocked. 5585 Stream Data Limit: A variable-length integer indicating the offset 5586 of the stream at which the blocking occurred. 5588 19.14. STREAMS_BLOCKED Frames 5590 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 5591 it wishes to open a stream, but is unable to due to the maximum 5592 stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED 5593 frame of type 0x16 is used to indicate reaching the bidirectional 5594 stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates 5595 reaching the unidirectional stream limit. 5597 A STREAMS_BLOCKED frame does not open the stream, but informs the 5598 peer that a new stream was needed and the stream limit prevented the 5599 creation of the stream. 5601 The STREAMS_BLOCKED frames are as follows: 5603 0 1 2 3 5604 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 5605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5606 | Stream Limit (i) ... 5607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5609 STREAMS_BLOCKED frames contain the following fields: 5611 Stream Limit: A variable-length integer indicating the stream limit 5612 at the time the frame was sent. Stream IDs cannot exceed 2^62-1, 5613 as it is not possible to encode stream IDs larger than this value. 5614 Receipt of a frame that encodes a larger stream ID MUST be treated 5615 as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. 5617 19.15. NEW_CONNECTION_ID Frame 5619 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 5620 its peer with alternative connection IDs that can be used to break 5621 linkability when migrating connections (see Section 9.5). 5623 The NEW_CONNECTION_ID frame is as follows: 5625 0 1 2 3 5626 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 5627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5628 | Sequence Number (i) ... 5629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5630 | Retire Prior To (i) ... 5631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5632 | Length (8) | | 5633 +-+-+-+-+-+-+-+-+ Connection ID (8..160) + 5634 | ... 5635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5636 | | 5637 + + 5638 | | 5639 + Stateless Reset Token (128) + 5640 | | 5641 + + 5642 | | 5643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5645 NEW_CONNECTION_ID frames contain the following fields: 5647 Sequence Number: The sequence number assigned to the connection ID 5648 by the sender. See Section 5.1.1. 5650 Retire Prior To: A variable-length integer indicating which 5651 connection IDs should be retired. See Section 5.1.2. 5653 Length: An 8-bit unsigned integer containing the length of the 5654 connection ID. Values less than 1 and greater than 20 are invalid 5655 and MUST be treated as a connection error of type 5656 FRAME_ENCODING_ERROR. 5658 Connection ID: A connection ID of the specified length. 5660 Stateless Reset Token: A 128-bit value that will be used for a 5661 stateless reset when the associated connection ID is used (see 5662 Section 10.4). 5664 An endpoint MUST NOT send this frame if it currently requires that 5665 its peer send packets with a zero-length Destination Connection ID. 5666 Changing the length of a connection ID to or from zero-length makes 5667 it difficult to identify when the value of the connection ID changed. 5668 An endpoint that is sending packets with a zero-length Destination 5669 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 5670 connection error of type PROTOCOL_VIOLATION. 5672 Transmission errors, timeouts and retransmissions might cause the 5673 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 5674 of the same frame multiple times MUST NOT be treated as a connection 5675 error. A receiver can use the sequence number supplied in the 5676 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 5678 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 5679 previously issued connection ID with a different Stateless Reset 5680 Token or a different sequence number, or if a sequence number is used 5681 for different connection IDs, the endpoint MAY treat that receipt as 5682 a connection error of type PROTOCOL_VIOLATION. 5684 The Retire Prior To field is a request for the peer to retire all 5685 connection IDs with a sequence number less than the specified value. 5686 This includes the initial and preferred_address transport parameter 5687 connection IDs. The peer SHOULD retire the corresponding connection 5688 IDs and send the corresponding RETIRE_CONNECTION_ID frames in a 5689 timely manner. 5691 The Retire Prior To field MUST be less than or equal to the Sequence 5692 Number field. Receiving a value greater than the Sequence Number 5693 MUST be treated as a connection error of type FRAME_ENCODING_ERROR. 5695 Once a sender indicates a Retire Prior To value, smaller values sent 5696 in subsequent NEW_CONNECTION_ID frames have no effect. A receiver 5697 MUST ignore any Retire Prior To fields that do not increase the 5698 largest received Retire Prior To value. 5700 19.16. RETIRE_CONNECTION_ID Frame 5702 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 5703 indicate that it will no longer use a connection ID that was issued 5704 by its peer. This may include the connection ID provided during the 5705 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 5706 request to the peer to send additional connection IDs for future use 5707 (see Section 5.1). New connection IDs can be delivered to a peer 5708 using the NEW_CONNECTION_ID frame (Section 19.15). 5710 Retiring a connection ID invalidates the stateless reset token 5711 associated with that connection ID. 5713 The RETIRE_CONNECTION_ID frame is as follows: 5715 0 1 2 3 5716 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 5717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5718 | Sequence Number (i) ... 5719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5721 RETIRE_CONNECTION_ID frames contain the following fields: 5723 Sequence Number: The sequence number of the connection ID being 5724 retired. See Section 5.1.2. 5726 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 5727 greater than any previously sent to the peer MAY be treated as a 5728 connection error of type PROTOCOL_VIOLATION. 5730 The sequence number specified in a RETIRE_CONNECTION_ID frame MUST 5731 NOT refer to the Destination Connection ID field of the packet in 5732 which the frame is contained. The peer MAY treat this as a 5733 connection error of type FRAME_ENCODING_ERROR. 5735 An endpoint cannot send this frame if it was provided with a zero- 5736 length connection ID by its peer. An endpoint that provides a zero- 5737 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 5738 frame as a connection error of type PROTOCOL_VIOLATION. 5740 19.17. PATH_CHALLENGE Frame 5742 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 5743 reachability to the peer and for path validation during connection 5744 migration. 5746 The PATH_CHALLENGE frames are as follows: 5748 0 1 2 3 5749 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 5750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5751 | | 5752 + Data (64) + 5753 | | 5754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5756 PATH_CHALLENGE frames contain the following fields: 5758 Data: This 8-byte field contains arbitrary data. 5760 A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is 5761 sufficient to ensure that it is easier to receive the packet than it 5762 is to guess the value correctly. 5764 The recipient of this frame MUST generate a PATH_RESPONSE frame 5765 (Section 19.18) containing the same Data. 5767 19.18. PATH_RESPONSE Frame 5769 The PATH_RESPONSE frame (type=0x1b) is sent in response to a 5770 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 5771 frame (Section 19.17). 5773 If the content of a PATH_RESPONSE frame does not match the content of 5774 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 5775 MAY generate a connection error of type PROTOCOL_VIOLATION. 5777 19.19. CONNECTION_CLOSE Frames 5779 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 5780 notify its peer that the connection is being closed. The 5781 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 5782 at only the QUIC layer, or the absence of errors (with the NO_ERROR 5783 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 5784 signal an error with the application that uses QUIC. 5786 If there are open streams that haven't been explicitly closed, they 5787 are implicitly closed when the connection is closed. 5789 The CONNECTION_CLOSE frames are as follows: 5791 0 1 2 3 5792 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 5793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5794 | Error Code (i) ... 5795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5796 | [ Frame Type (i) ] ... 5797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5798 | Reason Phrase Length (i) ... 5799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5800 | Reason Phrase (*) ... 5801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5803 CONNECTION_CLOSE frames contain the following fields: 5805 Error Code: A variable length integer error code which indicates the 5806 reason for closing this connection. A CONNECTION_CLOSE frame of 5807 type 0x1c uses codes from the space defined in Section 20. A 5808 CONNECTION_CLOSE frame of type 0x1d uses codes from the 5809 application protocol error code space; see Section 20.1 5811 Frame Type: A variable-length integer encoding the type of frame 5812 that triggered the error. A value of 0 (equivalent to the mention 5813 of the PADDING frame) is used when the frame type is unknown. The 5814 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 5815 not include this field. 5817 Reason Phrase Length: A variable-length integer specifying the 5818 length of the reason phrase in bytes. Because a CONNECTION_CLOSE 5819 frame cannot be split between packets, any limits on packet size 5820 will also limit the space available for a reason phrase. 5822 Reason Phrase: A human-readable explanation for why the connection 5823 was closed. This can be zero length if the sender chooses to not 5824 give details beyond the Error Code. This SHOULD be a UTF-8 5825 encoded string [RFC3629]. 5827 19.20. Extension Frames 5829 QUIC frames do not use a self-describing encoding. An endpoint 5830 therefore needs to understand the syntax of all frames before it can 5831 successfully process a packet. This allows for efficient encoding of 5832 frames, but it means that an endpoint cannot send a frame of a type 5833 that is unknown to its peer. 5835 An extension to QUIC that wishes to use a new type of frame MUST 5836 first ensure that a peer is able to understand the frame. An 5837 endpoint can use a transport parameter to signal its willingness to 5838 receive one or more extension frame types with the one transport 5839 parameter. 5841 Extension frames MUST be congestion controlled and MUST cause an ACK 5842 frame to be sent. The exception is extension frames that replace or 5843 supplement the ACK frame. Extension frames are not included in flow 5844 control unless specified in the extension. 5846 An IANA registry is used to manage the assignment of frame types; see 5847 Section 22.2. 5849 20. Transport Error Codes 5851 QUIC error codes are 62-bit unsigned integers. 5853 This section lists the defined QUIC transport error codes that may be 5854 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5855 connection. 5857 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5858 signal that the connection is being closed abruptly in the absence 5859 of any error. 5861 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5862 cannot continue with the connection. 5864 SERVER_BUSY (0x2): The server is currently busy and does not accept 5865 any new connections. 5867 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5868 permitted in its advertised data limits (see Section 4). 5870 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 5871 identifier that exceeded its advertised stream limit for the 5872 corresponding stream type. 5874 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5875 that was not in a state that permitted that frame (see Section 3). 5877 FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame 5878 containing data that exceeded the previously established final 5879 size. Or an endpoint received a STREAM frame or a RESET_STREAM 5880 frame containing a final size that was lower than the size of 5881 stream data that was already received. Or an endpoint received a 5882 STREAM frame or a RESET_STREAM frame containing a different final 5883 size to the one already established. 5885 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5886 badly formatted. For instance, a frame of an unknown type, or an 5887 ACK frame that has more acknowledgment ranges than the remainder 5888 of the packet could carry. 5890 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5891 parameters that were badly formatted, included an invalid value, 5892 was absent even though it is mandatory, was present though it is 5893 forbidden, or is otherwise in error. 5895 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5896 protocol compliance that was not covered by more specific error 5897 codes. 5899 CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in 5900 CRYPTO frames than it can buffer. 5902 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5903 of 256 values is reserved for carrying error codes specific to the 5904 cryptographic handshake that is used. Codes for errors occurring 5905 when TLS is used for the crypto handshake are described in 5906 Section 4.8 of [QUIC-TLS]. 5908 See Section 22.3 for details of registering new error codes. 5910 In defining these error codes, several principles are applied. Error 5911 conditions that might require specific action on the part of a 5912 recipient are given unique codes. Errors that represent common 5913 conditions are given specific codes. Absent either of these 5914 conditions, error codes are used to identify a general function of 5915 the stack, like flow control or transport parameter handling. 5916 Finally, generic errors are provided for conditions where 5917 implementations are unable or unwilling to use more specific codes. 5919 20.1. Application Protocol Error Codes 5921 Application protocol error codes are 62-bit unsigned integers, but 5922 the management of application error codes is left to application 5923 protocols. Application protocol error codes are used for the 5924 RESET_STREAM frame (Section 19.4), the STOP_SENDING frame 5925 (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d 5926 (Section 19.19). 5928 21. Security Considerations 5930 21.1. Handshake Denial of Service 5932 As an encrypted and authenticated transport QUIC provides a range of 5933 protections against denial of service. Once the cryptographic 5934 handshake is complete, QUIC endpoints discard most packets that are 5935 not authenticated, greatly limiting the ability of an attacker to 5936 interfere with existing connections. 5938 Once a connection is established QUIC endpoints might accept some 5939 unauthenticated ICMP packets (see Section 14.2), but the use of these 5940 packets is extremely limited. The only other type of packet that an 5941 endpoint might accept is a stateless reset (Section 10.4) which 5942 relies on the token being kept secret until it is used. 5944 During the creation of a connection, QUIC only provides protection 5945 against attack from off the network path. All QUIC packets contain 5946 proof that the recipient saw a preceding packet from its peer. 5948 The first mechanism used is the source and destination connection 5949 IDs, which are required to match those set by a peer. Except for an 5950 Initial and stateless reset packets, an endpoint only accepts packets 5951 that include a destination connection that matches a connection ID 5952 the endpoint previously chose. This is the only protection offered 5953 for Version Negotiation packets. 5955 The destination connection ID in an Initial packet is selected by a 5956 client to be unpredictable, which serves an additional purpose. The 5957 packets that carry the cryptographic handshake are protected with a 5958 key that is derived from this connection ID and salt specific to the 5959 QUIC version. This allows endpoints to use the same process for 5960 authenticating packets that they receive as they use after the 5961 cryptographic handshake completes. Packets that cannot be 5962 authenticated are discarded. Protecting packets in this fashion 5963 provides a strong assurance that the sender of the packet saw the 5964 Initial packet and understood it. 5966 These protections are not intended to be effective against an 5967 attacker that is able to receive QUIC packets prior to the connection 5968 being established. Such an attacker can potentially send packets 5969 that will be accepted by QUIC endpoints. This version of QUIC 5970 attempts to detect this sort of attack, but it expects that endpoints 5971 will fail to establish a connection rather than recovering. For the 5972 most part, the cryptographic handshake protocol [QUIC-TLS] is 5973 responsible for detecting tampering during the handshake. 5975 Endpoints are permitted to use other methods to detect and attempt to 5976 recover from interference with the handshake. Invalid packets may be 5977 identified and discarded using other methods, but no specific method 5978 is mandated in this document. 5980 21.2. Amplification Attack 5982 An attacker might be able to receive an address validation token 5983 (Section 8) from a server and then release the IP address it used to 5984 acquire that token. At a later time, the attacker may initiate a 5985 0-RTT connection with a server by spoofing this same address, which 5986 might now address a different (victim) endpoint. The attacker can 5987 thus potentially cause the server to send an initial congestion 5988 window's worth of data towards the victim. 5990 Servers SHOULD provide mitigations for this attack by limiting the 5991 usage and lifetime of address validation tokens (see Section 8.1.2). 5993 21.3. Optimistic ACK Attack 5995 An endpoint that acknowledges packets it has not received might cause 5996 a congestion controller to permit sending at rates beyond what the 5997 network supports. An endpoint MAY skip packet numbers when sending 5998 packets to detect this behavior. An endpoint can then immediately 5999 close the connection with a connection error of type 6000 PROTOCOL_VIOLATION (see Section 10.3). 6002 21.4. Slowloris Attacks 6004 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 6005 connections to the target endpoint open and hold them open as long as 6006 possible. These attacks can be executed against a QUIC endpoint by 6007 generating the minimum amount of activity necessary to avoid being 6008 closed for inactivity. This might involve sending small amounts of 6009 data, gradually opening flow control windows in order to control the 6010 sender rate, or manufacturing ACK frames that simulate a high loss 6011 rate. 6013 QUIC deployments SHOULD provide mitigations for the Slowloris 6014 attacks, such as increasing the maximum number of clients the server 6015 will allow, limiting the number of connections a single IP address is 6016 allowed to make, imposing restrictions on the minimum transfer speed 6017 a connection is allowed to have, and restricting the length of time 6018 an endpoint is allowed to stay connected. 6020 21.5. Stream Fragmentation and Reassembly Attacks 6022 An adversarial sender might intentionally send fragments of stream 6023 data in order to cause disproportionate receive buffer memory 6024 commitment and/or creation of a large and inefficient data structure. 6026 An adversarial receiver might intentionally not acknowledge packets 6027 containing stream data in order to force the sender to store the 6028 unacknowledged stream data for retransmission. 6030 The attack on receivers is mitigated if flow control windows 6031 correspond to available memory. However, some receivers will over- 6032 commit memory and advertise flow control offsets in the aggregate 6033 that exceed actual available memory. The over-commitment strategy 6034 can lead to better performance when endpoints are well behaved, but 6035 renders endpoints vulnerable to the stream fragmentation attack. 6037 QUIC deployments SHOULD provide mitigations against stream 6038 fragmentation attacks. Mitigations could consist of avoiding over- 6039 committing memory, limiting the size of tracking data structures, 6040 delaying reassembly of STREAM frames, implementing heuristics based 6041 on the age and duration of reassembly holes, or some combination. 6043 21.6. Stream Commitment Attack 6045 An adversarial endpoint can open lots of streams, exhausting state on 6046 an endpoint. The adversarial endpoint could repeat the process on a 6047 large number of connections, in a manner similar to SYN flooding 6048 attacks in TCP. 6050 Normally, clients will open streams sequentially, as explained in 6051 Section 2.1. However, when several streams are initiated at short 6052 intervals, loss or reordering may cause STREAM frames that open 6053 streams to be received out of sequence. On receiving a higher- 6054 numbered stream ID, a receiver is required to open all intervening 6055 streams of the same type (see Section 3.2). Thus, on a new 6056 connection, opening stream 4000000 opens 1 million and 1 client- 6057 initiated bidirectional streams. 6059 The number of active streams is limited by the 6060 initial_max_streams_bidi and initial_max_streams_uni transport 6061 parameters, as explained in Section 4.5. If chosen judiciously, 6062 these limits mitigate the effect of the stream commitment attack. 6063 However, setting the limit too low could affect performance when 6064 applications expect to open large number of streams. 6066 21.7. Peer Denial of Service 6068 QUIC and TLS both contain messages that have legitimate uses in some 6069 contexts, but that can be abused to cause a peer to expend processing 6070 resources without having any observable impact on the state of the 6071 connection. 6073 Messages can also be used to change and revert state in small or 6074 inconsequential ways, such as by sending small increments to flow 6075 control limits. 6077 If processing costs are disproportionately large in comparison to 6078 bandwidth consumption or effect on state, then this could allow a 6079 malicious peer to exhaust processing capacity. 6081 While there are legitimate uses for all messages, implementations 6082 SHOULD track cost of processing relative to progress and treat 6083 excessive quantities of any non-productive packets as indicative of 6084 an attack. Endpoints MAY respond to this condition with a connection 6085 error, or by dropping packets. 6087 21.8. Explicit Congestion Notification Attacks 6089 An on-path attacker could manipulate the value of ECN codepoints in 6090 the IP header to influence the sender's rate. [RFC3168] discusses 6091 manipulations and their effects in more detail. 6093 An on-the-side attacker can duplicate and send packets with modified 6094 ECN codepoints to affect the sender's rate. If duplicate packets are 6095 discarded by a receiver, an off-path attacker will need to race the 6096 duplicate packet against the original to be successful in this 6097 attack. Therefore, QUIC endpoints ignore the ECN codepoint field on 6098 an IP packet unless at least one QUIC packet in that IP packet is 6099 successfully processed; see Section 13.4. 6101 21.9. Stateless Reset Oracle 6103 Stateless resets create a possible denial of service attack analogous 6104 to a TCP reset injection. This attack is possible if an attacker is 6105 able to cause a stateless reset token to be generated for a 6106 connection with a selected connection ID. An attacker that can cause 6107 this token to be generated can reset an active connection with the 6108 same connection ID. 6110 If a packet can be routed to different instances that share a static 6111 key, for example by changing an IP address or port, then an attacker 6112 can cause the server to send a stateless reset. To defend against 6113 this style of denial service, endpoints that share a static key for 6114 stateless reset (see Section 10.4.2) MUST be arranged so that packets 6115 with a given connection ID always arrive at an instance that has 6116 connection state, unless that connection is no longer active. 6118 In the case of a cluster that uses dynamic load balancing, it's 6119 possible that a change in load balancer configuration could happen 6120 while an active instance retains connection state; even if an 6121 instance retains connection state, the change in routing and 6122 resulting stateless reset will result in the connection being 6123 terminated. If there is no chance in the packet being routed to the 6124 correct instance, it is better to send a stateless reset than wait 6125 for connections to time out. However, this is acceptable only if the 6126 routing cannot be influenced by an attacker. 6128 21.10. Version Downgrade 6130 This document defines QUIC Version Negotiation packets Section 6, 6131 which can be used to negotiate the QUIC version used between two 6132 endpoints. However, this document does not specify how this 6133 negotiation will be performed between this version and subsequent 6134 future versions. In particular, Version Negotiation packets do not 6135 contain any mechanism to prevent version downgrade attacks. Future 6136 versions of QUIC that use Version Negotiation packets MUST define a 6137 mechanism that is robust against version downgrade attacks. 6139 21.11. Targeted Attacks by Routing 6141 Deployments should limit the ability of an attacker to target a new 6142 connection to a particular server instance. This means that client- 6143 controlled fields, such as the initial Destination Connection ID used 6144 on Initial and 0-RTT packets SHOULD NOT be used by themselves to make 6145 routing decisions. Ideally, routing decisions are made independently 6146 of client-selected values; a Source Connection ID can be selected to 6147 route later packets to the same server. 6149 22. IANA Considerations 6151 22.1. QUIC Transport Parameter Registry 6153 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 6154 under a "QUIC Protocol" heading. 6156 The "QUIC Transport Parameters" registry governs a 16-bit space. 6157 This space is split into two spaces that are governed by different 6158 policies. Values with the first byte in the range 0x00 to 0xfe (in 6159 hexadecimal) are assigned via the Specification Required policy 6160 [RFC8126]. Values with the first byte 0xff are reserved for Private 6161 Use [RFC8126]. 6163 Registrations MUST include the following fields: 6165 Value: The numeric value of the assignment (registrations will be 6166 between 0x0000 and 0xfeff). 6168 Parameter Name: A short mnemonic for the parameter. 6170 Specification: A reference to a publicly available specification for 6171 the value. 6173 The nominated expert(s) verify that a specification exists and is 6174 readily accessible. Expert(s) are encouraged to be biased towards 6175 approving registrations unless they are abusive, frivolous, or 6176 actively harmful (not merely aesthetically displeasing, or 6177 architecturally dubious). 6179 The initial contents of this registry are shown in Table 6. 6181 +--------+-------------------------------------+---------------+ 6182 | Value | Parameter Name | Specification | 6183 +--------+-------------------------------------+---------------+ 6184 | 0x0000 | original_connection_id | Section 18.2 | 6185 | | | | 6186 | 0x0001 | idle_timeout | Section 18.2 | 6187 | | | | 6188 | 0x0002 | stateless_reset_token | Section 18.2 | 6189 | | | | 6190 | 0x0003 | max_packet_size | Section 18.2 | 6191 | | | | 6192 | 0x0004 | initial_max_data | Section 18.2 | 6193 | | | | 6194 | 0x0005 | initial_max_stream_data_bidi_local | Section 18.2 | 6195 | | | | 6196 | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.2 | 6197 | | | | 6198 | 0x0007 | initial_max_stream_data_uni | Section 18.2 | 6199 | | | | 6200 | 0x0008 | initial_max_streams_bidi | Section 18.2 | 6201 | | | | 6202 | 0x0009 | initial_max_streams_uni | Section 18.2 | 6203 | | | | 6204 | 0x000a | ack_delay_exponent | Section 18.2 | 6205 | | | | 6206 | 0x000b | max_ack_delay | Section 18.2 | 6207 | | | | 6208 | 0x000c | disable_active_migration | Section 18.2 | 6209 | | | | 6210 | 0x000d | preferred_address | Section 18.2 | 6211 | | | | 6212 | 0x000e | active_connection_id_limit | Section 18.2 | 6213 +--------+-------------------------------------+---------------+ 6215 Table 6: Initial QUIC Transport Parameters Entries 6217 Additionally, each value of the format "31 * N + 27" for integer 6218 values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by 6219 IANA. 6221 22.2. QUIC Frame Type Registry 6223 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 6224 "QUIC Protocol" heading. 6226 The "QUIC Frame Types" registry governs a 62-bit space. This space 6227 is split into three spaces that are governed by different policies. 6228 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 6229 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 6230 to 0x3fff operate on the Specification Required policy [RFC8126]. 6231 All other values are assigned to Private Use [RFC8126]. 6233 Registrations MUST include the following fields: 6235 Value: The numeric value of the assignment (registrations will be 6236 between 0x00 and 0x3fff). A range of values MAY be assigned. 6238 Frame Name: A short mnemonic for the frame type. 6240 Specification: A reference to a publicly available specification for 6241 the value. 6243 The nominated expert(s) verify that a specification exists and is 6244 readily accessible. Specifications for new registrations need to 6245 describe the means by which an endpoint might determine that it can 6246 send the identified type of frame. An accompanying transport 6247 parameter registration (see Section 22.1) is expected for most 6248 registrations. The specification needs to describe the format and 6249 assigned semantics of any fields in the frame. 6251 Expert(s) are encouraged to be biased towards approving registrations 6252 unless they are abusive, frivolous, or actively harmful (not merely 6253 aesthetically displeasing, or architecturally dubious). 6255 The initial contents of this registry are tabulated in Table 3. 6257 22.3. QUIC Transport Error Codes Registry 6259 IANA [SHALL add/has added] a registry for "QUIC Transport Error 6260 Codes" under a "QUIC Protocol" heading. 6262 The "QUIC Transport Error Codes" registry governs a 62-bit space. 6263 This space is split into three spaces that are governed by different 6264 policies. Values between 0x00 and 0x3f (in hexadecimal) are assigned 6265 via the Standards Action or IESG Review policies [RFC8126]. Values 6266 from 0x40 to 0x3fff operate on the Specification Required policy 6267 [RFC8126]. All other values are assigned to Private Use [RFC8126]. 6269 Registrations MUST include the following fields: 6271 Value: The numeric value of the assignment (registrations will be 6272 between 0x0000 and 0x3fff). 6274 Code: A short mnemonic for the parameter. 6276 Description: A brief description of the error code semantics, which 6277 MAY be a summary if a specification reference is provided. 6279 Specification: A reference to a publicly available specification for 6280 the value. 6282 The nominated expert(s) verify that a specification exists and is 6283 readily accessible. Expert(s) are encouraged to be biased towards 6284 approving registrations unless they are abusive, frivolous, or 6285 actively harmful (not merely aesthetically displeasing, or 6286 architecturally dubious). 6288 The initial contents of this registry are shown in Table 7. 6290 +------+---------------------------+----------------+---------------+ 6291 | Valu | Error | Description | Specification | 6292 | e | | | | 6293 +------+---------------------------+----------------+---------------+ 6294 | 0x0 | NO_ERROR | No error | Section 20 | 6295 | | | | | 6296 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 6297 | | | error | | 6298 | | | | | 6299 | 0x2 | SERVER_BUSY | Server | Section 20 | 6300 | | | currently busy | | 6301 | | | | | 6302 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 6303 | | | error | | 6304 | | | | | 6305 | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | 6306 | | | streams opened | | 6307 | | | | | 6308 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 6309 | | | in invalid | | 6310 | | | stream state | | 6311 | | | | | 6312 | 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 | 6313 | | | final size | | 6314 | | | | | 6315 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 6316 | | | error | | 6317 | | | | | 6318 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 6319 | | | transport | | 6320 | | | parameters | | 6321 | | | | | 6322 | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | 6323 | | | protocol | | 6324 | | | violation | | 6325 | | | | | 6326 | 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | 6327 | | | buffer | | 6328 | | | overflowed | | 6329 +------+---------------------------+----------------+---------------+ 6331 Table 7: Initial QUIC Transport Error Codes Entries 6333 23. References 6334 23.1. Normative References 6336 [DPLPMTUD] 6337 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 6338 T. Voelker, "Packetization Layer Path MTU Discovery for 6339 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 6340 (work in progress), June 2019. 6342 [QUIC-RECOVERY] 6343 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 6344 and Congestion Control", draft-ietf-quic-recovery-24 (work 6345 in progress), November 2019. 6347 [QUIC-TLS] 6348 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 6349 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 6350 tls-24 (work in progress), November 2019. 6352 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6353 DOI 10.17487/RFC1191, November 1990, 6354 . 6356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6357 Requirement Levels", BCP 14, RFC 2119, 6358 DOI 10.17487/RFC2119, March 1997, 6359 . 6361 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 6362 of Explicit Congestion Notification (ECN) to IP", 6363 RFC 3168, DOI 10.17487/RFC3168, September 2001, 6364 . 6366 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6367 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 6368 2003, . 6370 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 6371 "Randomness Requirements for Security", BCP 106, RFC 4086, 6372 DOI 10.17487/RFC4086, June 2005, 6373 . 6375 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 6376 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 6377 . 6379 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 6380 "IPv6 Flow Label Specification", RFC 6437, 6381 DOI 10.17487/RFC6437, November 2011, 6382 . 6384 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 6385 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 6386 March 2017, . 6388 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6389 Writing an IANA Considerations Section in RFCs", BCP 26, 6390 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6391 . 6393 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6394 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6395 May 2017, . 6397 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 6398 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 6399 DOI 10.17487/RFC8201, July 2017, 6400 . 6402 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 6403 Notification (ECN) Experimentation", RFC 8311, 6404 DOI 10.17487/RFC8311, January 2018, 6405 . 6407 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 6408 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 6409 . 6411 23.2. Informative References 6413 [EARLY-DESIGN] 6414 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 6415 December 2013, . 6417 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 6418 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 6419 DOI 10.17487/RFC7540, May 2015, 6420 . 6422 [QUIC-INVARIANTS] 6423 Thomson, M., "Version-Independent Properties of QUIC", 6424 draft-ietf-quic-invariants-07 (work in progress), November 6425 2019. 6427 [QUIC-MANAGEABILITY] 6428 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 6429 Transport Protocol", draft-ietf-quic-manageability-05 6430 (work in progress), July 2019. 6432 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 6433 RFC 1812, DOI 10.17487/RFC1812, June 1995, 6434 . 6436 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 6437 Selective Acknowledgment Options", RFC 2018, 6438 DOI 10.17487/RFC2018, October 1996, 6439 . 6441 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 6442 Hashing for Message Authentication", RFC 2104, 6443 DOI 10.17487/RFC2104, February 1997, 6444 . 6446 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 6447 RFC 2360, DOI 10.17487/RFC2360, June 1998, 6448 . 6450 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 6451 RFC 4303, DOI 10.17487/RFC4303, December 2005, 6452 . 6454 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 6455 Control Message Protocol (ICMPv6) for the Internet 6456 Protocol Version 6 (IPv6) Specification", STD 89, 6457 RFC 4443, DOI 10.17487/RFC4443, March 2006, 6458 . 6460 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 6461 Translation (NAT) Behavioral Requirements for Unicast 6462 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 6463 2007, . 6465 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 6466 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 6467 . 6469 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 6470 Key Derivation Function (HKDF)", RFC 5869, 6471 DOI 10.17487/RFC5869, May 2010, 6472 . 6474 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 6475 "Transport Layer Security (TLS) Application-Layer Protocol 6476 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 6477 July 2014, . 6479 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6480 (IPv6) Specification", STD 86, RFC 8200, 6481 DOI 10.17487/RFC8200, July 2017, 6482 . 6484 [SLOWLORIS] 6485 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 6486 . 6489 Appendix A. Sample Packet Number Decoding Algorithm 6491 The following pseudo-code shows how an implementation can decode 6492 packet numbers after header protection has been removed. 6494 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 6495 expected_pn = largest_pn + 1 6496 pn_win = 1 << pn_nbits 6497 pn_hwin = pn_win / 2 6498 pn_mask = pn_win - 1 6499 // The incoming packet number should be greater than 6500 // expected_pn - pn_hwin and less than or equal to 6501 // expected_pn + pn_hwin 6502 // 6503 // This means we can't just strip the trailing bits from 6504 // expected_pn and add the truncated_pn because that might 6505 // yield a value outside the window. 6506 // 6507 // The following code calculates a candidate value and 6508 // makes sure it's within the packet number window. 6509 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 6510 if candidate_pn <= expected_pn - pn_hwin: 6511 return candidate_pn + pn_win 6512 // Note the extra check for underflow when candidate_pn 6513 // is near zero. 6514 if candidate_pn > expected_pn + pn_hwin and 6515 candidate_pn > pn_win: 6516 return candidate_pn - pn_win 6517 return candidate_pn 6519 Appendix B. Change Log 6521 *RFC Editor's Note:* Please remove this section prior to 6522 publication of a final version of this document. 6524 Issue and pull request numbers are listed with a leading octothorp. 6526 B.1. Since draft-ietf-quic-transport-23 6528 o Client Initial size constraints apply to UDP datagram payload 6529 (#3053, #3051) 6531 o Stateless reset changes (#2152, #2993) 6533 * tokens need to be compared in constant time 6535 * detection uses UDP datagrams, not packets 6537 * tokens cannot be reused (#2785, #2968) 6539 o Clearer rules for sharing of UDP ports and use of connection IDs 6540 when doing so (#2844, #2851) 6542 o A new connection ID is necessary when responding to migration 6543 (#2778, #2969) 6545 o Stronger requirements for connection ID retirement (#3046, #3096) 6547 o NEW_TOKEN cannot be empty (#2978, #2977) 6549 o PING can be sent at any encryption level (#3034, #3035) 6551 o CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) 6553 o Frame encoding error conditions updated (#3027, #3042) 6555 o Non-ack-eliciting packets cannot be sent in response to non-ack- 6556 eliciting packets (#3100, #3104) 6558 B.2. Since draft-ietf-quic-transport-22 6560 o Rules for preventing correlation by connection ID tightened 6561 (#2084, #2929) 6563 o Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, 6564 #2541, #2688) 6566 o Discourage regressions of largest acknowledged in ACK (#2205, 6567 #2752) 6569 o Improved robustness of validation process for ECN counts (#2534, 6570 #2752) 6572 o Require endpoints to ignore spurious migration attempts (#2342, 6573 #2893) 6575 o Transport parameter for disabling migration clarified to allow NAT 6576 rebinding (#2389, #2893) 6578 o Document principles for defining new error codes (#2388, #2880) 6580 o Reserve transport parameters for greasing (#2550, #2873) 6582 o A maximum ACK delay of 0 is used for handshake packet number 6583 spaces (#2646, #2638) 6585 o Improved rules for use of congestion control state on new paths 6586 (#2685, #2918) 6588 o Removed recommendation to coordinate spin for multiple connections 6589 that share a path (#2763, #2882) 6591 o Allow smaller stateless resets and recommend a smaller minimum on 6592 packets that might trigger a stateless reset (#2770, #2869, #2927, 6593 #3007). 6595 o Provide guidance around the interface to QUIC as used by 6596 application protocols (#2805, #2857) 6598 o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, 6599 #2826) 6601 o Tighter rules about processing of rejected 0-RTT packets (#2829, 6602 #2840, #2841) 6604 o Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) 6606 o Cryptographic handshake needs to provide server transport 6607 parameter encryption (#2920, #2921) 6609 o Moved ACK generation guidance from recovery draft to transport 6610 draft (#1860, #2916). 6612 B.3. Since draft-ietf-quic-transport-21 6614 o Connection ID lengths are now one octet, but limited in version 1 6615 to 20 octets of length (#2736, #2749) 6617 B.4. Since draft-ietf-quic-transport-20 6619 o Error codes are encoded as variable-length integers (#2672, #2680) 6621 o NEW_CONNECTION_ID includes a request to retire old connection IDs 6622 (#2645, #2769) 6624 o Tighter rules for generating and explicitly eliciting ACK frames 6625 (#2546, #2794) 6627 o Recommend having only one packet per encryption level in a 6628 datagram (#2308, #2747) 6630 o More normative language about use of stateless reset (#2471, 6631 #2574) 6633 o Allow reuse of stateless reset tokens (#2732, #2733) 6635 o Allow, but not require, enforcing non-duplicate transport 6636 parameters (#2689, #2691) 6638 o Added an active_connection_id_limit transport parameter (#1994, 6639 #1998) 6641 o max_ack_delay transport parameter defaults to 0 (#2638, #2646) 6643 o When sending 0-RTT, only remembered transport parameters apply 6644 (#2458, #2360, #2466, #2461) 6646 o Define handshake completion and confirmation; define clearer rules 6647 when it encryption keys should be discarded (#2214, #2267, #2673) 6649 o Prohibit path migration prior to handshake confirmation (#2309, 6650 #2370) 6652 o PATH_RESPONSE no longer needs to be received on the validated path 6653 (#2582, #2580, #2579, #2637) 6655 o PATH_RESPONSE frames are not stored and retransmitted (#2724, 6656 #2729) 6658 o Document hack for enabling routing of ICMP when doing PMTU probing 6659 (#1243, #2402) 6661 B.5. Since draft-ietf-quic-transport-19 6663 o Refine discussion of 0-RTT transport parameters (#2467, #2464) 6665 o Fewer transport parameters need to be remembered for 0-RTT (#2624, 6666 #2467) 6668 o Spin bit text incorporated (#2564) 6670 o Close the connection when maximum stream ID in MAX_STREAMS exceeds 6671 2^62 - 1 (#2499, #2487) 6673 o New connection ID required for intentional migration (#2414, 6674 #2413) 6676 o Connection ID issuance can be rate-limited (#2436, #2428) 6678 o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) 6680 o Initial packets from clients need to be padded to 1200 unless a 6681 Handshake packet is sent as well (#2522, #2523) 6683 o CRYPTO frames can be discarded if too much data is buffered 6684 (#1834, #2524) 6686 o Stateless reset uses a short header packet (#2599, #2600) 6688 B.6. Since draft-ietf-quic-transport-18 6690 o Removed version negotiation; version negotiation, including 6691 authentication of the result, will be addressed in the next 6692 version of QUIC (#1773, #2313) 6694 o Added discussion of the use of IPv6 flow labels (#2348, #2399) 6696 o A connection ID can't be retired in a packet that uses that 6697 connection ID (#2101, #2420) 6699 o Idle timeout transport parameter is in milliseconds (from seconds) 6700 (#2453, #2454) 6702 o Endpoints are required to use new connection IDs when they use new 6703 network paths (#2413, #2414) 6705 o Increased the set of permissible frames in 0-RTT (#2344, #2355) 6707 B.7. Since draft-ietf-quic-transport-17 6709 o Stream-related errors now use STREAM_STATE_ERROR (#2305) 6711 o Endpoints discard initial keys as soon as handshake keys are 6712 available (#1951, #2045) 6714 o Expanded conditions for ignoring ICMP packet too big messages 6715 (#2108, #2161) 6717 o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, 6718 #2241) 6720 o Endpoints are permitted to discard malformed initial packets 6721 (#2141) 6723 o Clarified ECN implementation and usage requirements (#2156, #2201) 6725 o Disable ECN count verification for packets that arrive out of 6726 order (#2198, #2215) 6728 o Use Probe Timeout (PTO) instead of RTO (#2206, #2238) 6730 o Loosen constraints on retransmission of ACK ranges (#2199, #2245) 6732 o Limit Retry and Version Negotiation to once per datagram (#2259, 6733 #2303) 6735 o Set a maximum value for max_ack_delay transport parameter (#2282, 6736 #2301) 6738 o Allow server preferred address for both IPv4 and IPv6 (#2122, 6739 #2296) 6741 o Corrected requirements for migration to a preferred address 6742 (#2146, #2349) 6744 o ACK of non-existent packet is illegal (#2298, #2302) 6746 B.8. Since draft-ietf-quic-transport-16 6748 o Stream limits are defined as counts, not maximums (#1850, #1906) 6750 o Require amplification attack defense after closing (#1905, #1911) 6752 o Remove reservation of application error code 0 for STOPPING 6753 (#1804, #1922) 6755 o Renumbered frames (#1945) 6757 o Renumbered transport parameters (#1946) 6759 o Numeric transport parameters are expressed as varints (#1608, 6760 #1947, #1955) 6762 o Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 6764 o Rework the first byte (#2006) 6766 * Fix the 0x40 bit 6768 * Change type values for long header 6770 * Add spin bit to short header (#631, #1988) 6772 * Encrypt the remainder of the first byte (#1322) 6774 * Move packet number length to first byte 6776 * Move ODCIL to first byte of retry packets 6778 * Simplify packet number protection (#1575) 6780 o Allow STOP_SENDING to open a remote bidirectional stream (#1797, 6781 #2013) 6783 o Added mitigation for off-path migration attacks (#1278, #1749, 6784 #2033) 6786 o Don't let the PMTU to drop below 1280 (#2063, #2069) 6788 o Require peers to replace retired connection IDs (#2085) 6790 o Servers are required to ignore Version Negotiation packets (#2088) 6792 o Tokens are repeated in all Initial packets (#2089) 6794 o Clarified how PING frames are sent after loss (#2094) 6796 o Initial keys are discarded once Handshake are available (#1951, 6797 #2045) 6799 o ICMP PTB validation clarifications (#2161, #2109, #2108) 6801 B.9. Since draft-ietf-quic-transport-15 6803 Substantial editorial reorganization; no technical changes. 6805 B.10. Since draft-ietf-quic-transport-14 6807 o Merge ACK and ACK_ECN (#1778, #1801) 6809 o Explicitly communicate max_ack_delay (#981, #1781) 6811 o Validate original connection ID after Retry packets (#1710, #1486, 6812 #1793) 6814 o Idle timeout is optional and has no specified maximum (#1765) 6816 o Update connection ID handling; add RETIRE_CONNECTION_ID type 6817 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 6818 #1821) 6820 o Include a Token in all Initial packets (#1649, #1794) 6822 o Prevent handshake deadlock (#1764, #1824) 6824 B.11. Since draft-ietf-quic-transport-13 6826 o Streams open when higher-numbered streams of the same type open 6827 (#1342, #1549) 6829 o Split initial stream flow control limit into 3 transport 6830 parameters (#1016, #1542) 6832 o All flow control transport parameters are optional (#1610) 6834 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 6836 o Permit stateless reset in response to any packet (#1348, #1553) 6838 o Recommended defense against stateless reset spoofing (#1386, 6839 #1554) 6841 o Prevent infinite stateless reset exchanges (#1443, #1627) 6843 o Forbid processing of the same packet number twice (#1405, #1624) 6845 o Added a packet number decoding example (#1493) 6847 o More precisely define idle timeout (#1429, #1614, #1652) 6848 o Corrected format of Retry packet and prevented looping (#1492, 6849 #1451, #1448, #1498) 6851 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 6852 #1514, #1621) 6854 o Permit Retry in response to 0-RTT (#1547, #1552) 6856 o Looser verification of ECN counters to account for ACK loss 6857 (#1555, #1481, #1565) 6859 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 6861 B.12. Since draft-ietf-quic-transport-12 6863 o Changes to integration of the TLS handshake (#829, #1018, #1094, 6864 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 6866 * The cryptographic handshake uses CRYPTO frames, not stream 0 6868 * QUIC packet protection is used in place of TLS record 6869 protection 6871 * Separate QUIC packet number spaces are used for the handshake 6873 * Changed Retry to be independent of the cryptographic handshake 6875 * Added NEW_TOKEN frame and Token fields to Initial packet 6877 * Limit the use of HelloRetryRequest to address TLS needs (like 6878 key shares) 6880 o Enable server to transition connections to a preferred address 6881 (#560, #1251, #1373) 6883 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 6884 (#804, #805, #1372) 6886 o Changed rules and recommendations for use of new connection IDs 6887 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 6889 o Added a transport parameter to disable intentional connection 6890 migration (#1271, #1447) 6892 o Packets from different connection ID can't be coalesced (#1287, 6893 #1423) 6895 o Fixed sampling method for packet number encryption; the length 6896 field in long headers includes the packet number field in addition 6897 to the packet payload (#1387, #1389) 6899 o Stateless Reset is now symmetric and subject to size constraints 6900 (#466, #1346) 6902 o Added frame type extension mechanism (#58, #1473) 6904 B.13. Since draft-ietf-quic-transport-11 6906 o Enable server to transition connections to a preferred address 6907 (#560, #1251) 6909 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 6910 #990, #734, #1317, #1267, #1079) 6912 o Packet numbers use a variable-length encoding (#989, #1334) 6914 o STREAM frames can now be empty (#1350) 6916 B.14. Since draft-ietf-quic-transport-10 6918 o Swap payload length and packed number fields in long header 6919 (#1294) 6921 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 6922 (#1274) 6924 o Spin bit reserved (#1283) 6926 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 6928 o A more complete connection migration (#1249) 6930 o Refine opportunistic ACK defense text (#305, #1030, #1185) 6932 o A Stateless Reset Token isn't mandatory (#818, #1191) 6934 o Removed implicit stream opening (#896, #1193) 6936 o An empty STREAM frame can be used to open a stream without sending 6937 data (#901, #1194) 6939 o Define stream counts in transport parameters rather than a maximum 6940 stream ID (#1023, #1065) 6942 o STOP_SENDING is now prohibited before streams are used (#1050) 6943 o Recommend including ACK in Retry packets and allow PADDING (#1067, 6944 #882) 6946 o Endpoints now become closing after an idle timeout (#1178, #1179) 6948 o Remove implication that Version Negotiation is sent when a packet 6949 of the wrong version is received (#1197) 6951 B.15. Since draft-ietf-quic-transport-09 6953 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 6954 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 6955 (#1091, #725, #1086) 6957 o A server can now only send 3 packets without validating the client 6958 address (#38, #1090) 6960 o Delivery order of stream data is no longer strongly specified 6961 (#252, #1070) 6963 o Rework of packet handling and version negotiation (#1038) 6965 o Stream 0 is now exempt from flow control until the handshake 6966 completes (#1074, #725, #825, #1082) 6968 o Improved retransmission rules for all frame types: information is 6969 retransmitted, not packets or frames (#463, #765, #1095, #1053) 6971 o Added an error code for server busy signals (#1137) 6973 o Endpoints now set the connection ID that their peer uses. 6974 Connection IDs are variable length. Removed the 6975 omit_connection_id transport parameter and the corresponding short 6976 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 6978 B.16. Since draft-ietf-quic-transport-08 6980 o Clarified requirements for BLOCKED usage (#65, #924) 6982 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 6983 #928) 6985 o GAP limitation in ACK Frame (#613) 6987 o Improved PMTUD description (#614, #1036) 6989 o Clarified stream state machine (#634, #662, #743, #894) 6990 o Reserved versions don't need to be generated deterministically 6991 (#831, #931) 6993 o You don't always need the draining period (#871) 6995 o Stateless reset clarified as version-specific (#930, #986) 6997 o initial_max_stream_id_x transport parameters are optional (#970, 6998 #971) 7000 o Ack Delay assumes a default value during the handshake (#1007, 7001 #1009) 7003 o Removed transport parameters from NewSessionTicket (#1015) 7005 B.17. Since draft-ietf-quic-transport-07 7007 o The long header now has version before packet number (#926, #939) 7009 o Rename and consolidate packet types (#846, #822, #847) 7011 o Packet types are assigned new codepoints and the Connection ID 7012 Flag is inverted (#426, #956) 7014 o Removed type for Version Negotiation and use Version 0 (#963, 7015 #968) 7017 o Streams are split into unidirectional and bidirectional (#643, 7018 #656, #720, #872, #175, #885) 7020 * Stream limits now have separate uni- and bi-directional 7021 transport parameters (#909, #958) 7023 * Stream limit transport parameters are now optional and default 7024 to 0 (#970, #971) 7026 o The stream state machine has been split into read and write (#634, 7027 #894) 7029 o Employ variable-length integer encodings throughout (#595) 7031 o Improvements to connection close 7033 * Added distinct closing and draining states (#899, #871) 7035 * Draining period can terminate early (#869, #870) 7037 * Clarifications about stateless reset (#889, #890) 7039 o Address validation for connection migration (#161, #732, #878) 7041 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 7043 o negotiated_version is sent in server transport parameters (#710, 7044 #959) 7046 o Increased the range over which packet numbers are randomized 7047 (#864, #850, #964) 7049 B.18. Since draft-ietf-quic-transport-06 7051 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 7053 o Split error code space between application and transport (#485) 7055 o Stateless reset token moved to end (#820) 7057 o 1-RTT-protected long header types removed (#848) 7059 o No acknowledgments during draining period (#852) 7061 o Remove "application close" as a separate close type (#854) 7063 o Remove timestamps from the ACK frame (#841) 7065 o Require transport parameters to only appear once (#792) 7067 B.19. Since draft-ietf-quic-transport-05 7069 o Stateless token is server-only (#726) 7071 o Refactor section on connection termination (#733, #748, #328, 7072 #177) 7074 o Limit size of Version Negotiation packet (#585) 7076 o Clarify when and what to ack (#736) 7078 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 7080 o Clarify Keep-alive requirements (#729) 7082 B.20. Since draft-ietf-quic-transport-04 7084 o Introduce STOP_SENDING frame, RESET_STREAM only resets in one 7085 direction (#165) 7087 o Removed GOAWAY; application protocols are responsible for graceful 7088 shutdown (#696) 7090 o Reduced the number of error codes (#96, #177, #184, #211) 7092 o Version validation fields can't move or change (#121) 7094 o Removed versions from the transport parameters in a 7095 NewSessionTicket message (#547) 7097 o Clarify the meaning of "bytes in flight" (#550) 7099 o Public reset is now stateless reset and not visible to the path 7100 (#215) 7102 o Reordered bits and fields in STREAM frame (#620) 7104 o Clarifications to the stream state machine (#572, #571) 7106 o Increased the maximum length of the Largest Acknowledged field in 7107 ACK frames to 64 bits (#629) 7109 o truncate_connection_id is renamed to omit_connection_id (#659) 7111 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 7112 #328) 7114 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 7116 B.21. Since draft-ietf-quic-transport-03 7118 o Change STREAM and RESET_STREAM layout 7120 o Add MAX_STREAM_ID settings 7122 B.22. Since draft-ietf-quic-transport-02 7124 o The size of the initial packet payload has a fixed minimum (#267, 7125 #472) 7127 o Define when Version Negotiation packets are ignored (#284, #294, 7128 #241, #143, #474) 7130 o The 64-bit FNV-1a algorithm is used for integrity protection of 7131 unprotected packets (#167, #480, #481, #517) 7133 o Rework initial packet types to change how the connection ID is 7134 chosen (#482, #442, #493) 7136 o No timestamps are forbidden in unprotected packets (#542, #429) 7138 o Cryptographic handshake is now on stream 0 (#456) 7140 o Remove congestion control exemption for cryptographic handshake 7141 (#248, #476) 7143 o Version 1 of QUIC uses TLS; a new version is needed to use a 7144 different handshake protocol (#516) 7146 o STREAM frames have a reduced number of offset lengths (#543, #430) 7148 o Split some frames into separate connection- and stream- level 7149 frames (#443) 7151 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 7153 * BLOCKED split to match WINDOW_UPDATE split (#454) 7155 * Define STREAM_ID_NEEDED frame (#455) 7157 o A NEW_CONNECTION_ID frame supports connection migration without 7158 linkability (#232, #491, #496) 7160 o Transport parameters for 0-RTT are retained from a previous 7161 connection (#405, #513, #512) 7163 * A client in 0-RTT no longer required to reset excess streams 7164 (#425, #479) 7166 o Expanded security considerations (#440, #444, #445, #448) 7168 B.23. Since draft-ietf-quic-transport-01 7170 o Defined short and long packet headers (#40, #148, #361) 7172 o Defined a versioning scheme and stable fields (#51, #361) 7174 o Define reserved version values for "greasing" negotiation (#112, 7175 #278) 7177 o The initial packet number is randomized (#35, #283) 7179 o Narrow the packet number encoding range requirement (#67, #286, 7180 #299, #323, #356) 7182 o Defined client address validation (#52, #118, #120, #275) 7183 o Define transport parameters as a TLS extension (#49, #122) 7185 o SCUP and COPT parameters are no longer valid (#116, #117) 7187 o Transport parameters for 0-RTT are either remembered from before, 7188 or assume default values (#126) 7190 o The server chooses connection IDs in its final flight (#119, #349, 7191 #361) 7193 o The server echoes the Connection ID and packet number fields when 7194 sending a Version Negotiation packet (#133, #295, #244) 7196 o Defined a minimum packet size for the initial handshake packet 7197 from the client (#69, #136, #139, #164) 7199 o Path MTU Discovery (#64, #106) 7201 o The initial handshake packet from the client needs to fit in a 7202 single packet (#338) 7204 o Forbid acknowledgment of packets containing only ACK and PADDING 7205 (#291) 7207 o Require that frames are processed when packets are acknowledged 7208 (#381, #341) 7210 o Removed the STOP_WAITING frame (#66) 7212 o Don't require retransmission of old timestamps for lost ACK frames 7213 (#308) 7215 o Clarified that frames are not retransmitted, but the information 7216 in them can be (#157, #298) 7218 o Error handling definitions (#335) 7220 o Split error codes into four sections (#74) 7222 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 7223 (#289) 7225 o Define packet protection rules (#336) 7227 o Require that stream be entirely delivered or reset, including 7228 acknowledgment of all STREAM frames or the RESET_STREAM, before it 7229 closes (#381) 7231 o Remove stream reservation from state machine (#174, #280) 7233 o Only stream 1 does not contribute to connection-level flow control 7234 (#204) 7236 o Stream 1 counts towards the maximum concurrent stream limit (#201, 7237 #282) 7239 o Remove connection-level flow control exclusion for some streams 7240 (except 1) (#246) 7242 o RESET_STREAM affects connection-level flow control (#162, #163) 7244 o Flow control accounting uses the maximum data offset on each 7245 stream, rather than bytes received (#378) 7247 o Moved length-determining fields to the start of STREAM and ACK 7248 (#168, #277) 7250 o Added the ability to pad between frames (#158, #276) 7252 o Remove error code and reason phrase from GOAWAY (#352, #355) 7254 o GOAWAY includes a final stream number for both directions (#347) 7256 o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 7257 consistent offset (#249) 7259 o Defined priority as the responsibility of the application protocol 7260 (#104, #303) 7262 B.24. Since draft-ietf-quic-transport-00 7264 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 7266 o Defined versioning 7268 o Reworked description of packet and frame layout 7270 o Error code space is divided into regions for each component 7272 o Use big endian for all numeric values 7274 B.25. Since draft-hamilton-quic-transport-protocol-01 7276 o Adopted as base for draft-ietf-quic-tls 7278 o Updated authors/editors list 7279 o Added IANA Considerations section 7281 o Moved Contributors and Acknowledgments to appendices 7283 Acknowledgments 7285 Special thanks are due to the following for helping shape pre-IETF 7286 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 7287 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 7289 This document has benefited immensely from various private 7290 discussions and public ones on the quic@ietf.org and proto- 7291 quic@chromium.org mailing lists. Our thanks to all. 7293 Contributors 7295 The original authors of this specification were Ryan Hamilton, Jana 7296 Iyengar, Ian Swett, and Alyssa Wilk. 7298 The original design and rationale behind this protocol draw 7299 significantly from work by Jim Roskind [EARLY-DESIGN]. In 7300 alphabetical order, the contributors to the pre-IETF QUIC project at 7301 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 7302 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 7303 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 7304 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 7305 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 7307 Authors' Addresses 7309 Jana Iyengar (editor) 7310 Fastly 7312 Email: jri.ietf@gmail.com 7314 Martin Thomson (editor) 7315 Mozilla 7317 Email: mt@lowentropy.net