idnits 2.17.1 draft-ietf-quic-transport-26.txt: -(8071): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (21 February 2020) is 1498 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 1979 == Missing Reference: 'CH' is mentioned on line 1975, but not defined == Missing Reference: 'SH' is mentioned on line 1977, but not defined == Missing Reference: 'EE' is mentioned on line 1978, but not defined == Missing Reference: 'CERT' is mentioned on line 1978, but not defined == Missing Reference: 'CV' is mentioned on line 1978, but not defined == Missing Reference: 'FIN' is mentioned on line 1978, but not defined -- Looks like a reference, but probably isn't: '1' on line 1977 == 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-26 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-26 -- 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 (~~), 15 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: 24 August 2020 Mozilla 6 21 February 2020 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-26 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 24 August 2020. 44 Copyright Notice 46 Copyright (c) 2020 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 62 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8 63 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 64 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 10 66 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 11 67 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 68 2.4. Required Operations on Streams . . . . . . . . . . . . . 12 69 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12 70 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 13 71 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 15 72 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 18 73 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 18 74 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19 75 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 21 76 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 21 77 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 22 78 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 23 79 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 24 80 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 24 81 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 25 83 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 26 84 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 27 85 5.2. Matching Packets to Connections . . . . . . . . . . . . . 28 86 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 29 87 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29 88 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 30 89 5.4. Required Operations on Connections . . . . . . . . . . . 31 90 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 32 91 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 32 92 6.2. Handling Version Negotiation Packets . . . . . . . . . . 33 93 6.2.1. Version Negotiation Between Draft Versions . . . . . 33 94 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 33 95 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 34 96 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 35 97 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 36 98 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 37 99 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 38 100 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 39 101 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 40 102 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 40 103 8.1. Address Validation During Connection Establishment . . . 41 104 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 42 105 8.1.2. Address Validation using Retry Packets . . . . . . . 42 106 8.1.3. Address Validation for Future Connections . . . . . . 43 107 8.1.4. Address Validation Token Integrity . . . . . . . . . 45 108 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 46 109 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 46 110 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 47 111 8.5. Successful Path Validation . . . . . . . . . . . . . . . 47 112 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 47 113 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 48 114 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 49 115 9.2. Initiating Connection Migration . . . . . . . . . . . . . 49 116 9.3. Responding to Connection Migration . . . . . . . . . . . 50 117 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 50 118 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 51 119 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 52 120 9.4. Loss Detection and Congestion Control . . . . . . . . . . 53 121 9.5. Privacy Implications of Connection Migration . . . . . . 54 122 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 55 123 9.6.1. Communicating a Preferred Address . . . . . . . . . . 55 124 9.6.2. Responding to Connection Migration . . . . . . . . . 56 125 9.6.3. Interaction of Client Migration and Preferred 126 Address . . . . . . . . . . . . . . . . . . . . . . . 56 127 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 57 128 10. Connection Termination . . . . . . . . . . . . . . . . . . . 57 129 10.1. Closing and Draining Connection States . . . . . . . . . 57 130 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 59 131 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 59 132 10.3.1. Immediate Close During the Handshake . . . . . . . . 60 133 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 61 134 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 64 135 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 65 136 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 66 137 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67 138 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 67 139 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 68 140 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 68 141 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 69 142 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 69 143 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 70 144 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 71 146 13. Packetization and Reliability . . . . . . . . . . . . . . . . 74 147 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 75 148 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 75 149 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 76 150 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 77 151 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 78 152 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 78 153 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 78 154 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 79 155 13.3. Retransmission of Information . . . . . . . . . . . . . 79 156 13.4. Explicit Congestion Notification . . . . . . . . . . . . 82 157 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 82 158 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 83 159 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 84 160 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 85 161 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 86 162 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 87 163 14.3.1. PMTU Probes Containing Source Connection ID . . . . 87 164 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 88 165 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 89 166 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 89 167 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 90 168 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 91 169 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 93 170 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 95 171 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 97 172 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 99 173 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 100 174 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 102 175 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 104 176 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 105 177 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 106 178 18.2. Transport Parameter Definitions . . . . . . . . . . . . 106 179 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 111 180 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 111 181 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 111 182 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 112 183 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 113 184 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 115 185 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 116 186 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 117 187 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 117 188 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 118 189 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 119 190 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 121 191 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 121 192 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 122 193 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 123 194 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 124 195 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 124 196 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 125 197 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 127 198 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 128 199 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 128 200 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 128 201 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 130 202 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 130 203 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 130 204 20.1. Application Protocol Error Codes . . . . . . . . . . . . 132 205 21. Security Considerations . . . . . . . . . . . . . . . . . . . 132 206 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 132 207 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 134 208 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 134 209 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 134 210 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 134 211 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 135 212 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 135 213 21.8. Explicit Congestion Notification Attacks . . . . . . . . 136 214 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 136 215 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 137 216 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 137 217 21.12. Overview of Security Properties . . . . . . . . . . . . 137 218 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 138 219 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 139 220 21.12.3. Connection Migration . . . . . . . . . . . . . . . 140 221 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144 222 22.1. Registration Policies for QUIC Registries . . . . . . . 144 223 22.1.1. Provisional Registrations . . . . . . . . . . . . . 144 224 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 145 225 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 146 226 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 146 227 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 147 228 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 148 229 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 149 230 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 151 231 23.1. Normative References . . . . . . . . . . . . . . . . . . 151 232 23.2. Informative References . . . . . . . . . . . . . . . . . 152 233 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 154 234 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 155 235 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 156 236 C.1. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 156 237 C.2. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 157 238 C.3. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 158 239 C.4. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 159 240 C.5. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 159 241 C.6. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 160 242 C.7. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 161 243 C.8. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 161 244 C.9. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 162 245 C.10. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 163 246 C.11. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 163 247 C.12. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 164 248 C.13. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 164 249 C.14. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 165 250 C.15. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 165 251 C.16. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 166 252 C.17. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 167 253 C.18. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 167 254 C.19. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 168 255 C.20. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 169 256 C.21. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 169 257 C.22. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 170 258 C.23. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 170 259 C.24. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 171 260 C.25. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 173 261 C.26. Since draft-hamilton-quic-transport-protocol-01 . . . . . 173 262 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 173 263 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174 265 1. Introduction 267 QUIC is a multiplexed and secure general-purpose transport protocol 268 that provides: 270 * Stream multiplexing 272 * Stream and connection-level flow control 274 * Low-latency connection establishment 276 * Connection migration and resilience to NAT rebinding 278 * Authenticated and encrypted header and payload 280 QUIC uses UDP as a substrate to avoid requiring changes to legacy 281 client operating systems and middleboxes. QUIC authenticates all of 282 its headers and encrypts most of the data it exchanges, including its 283 signaling, to avoid incurring a dependency on middleboxes. 285 1.1. Document Structure 287 This document describes the core QUIC protocol and is structured as 288 follows: 290 * Streams are the basic service abstraction that QUIC provides. 292 - Section 2 describes core concepts related to streams, 294 - Section 3 provides a reference model for stream states, and 296 - Section 4 outlines the operation of flow control. 298 * Connections are the context in which QUIC endpoints communicate. 300 - Section 5 describes core concepts related to connections, 302 - Section 6 describes version negotiation, 304 - Section 7 details the process for establishing connections, 306 - Section 8 specifies critical denial of service mitigation 307 mechanisms, 309 - Section 9 describes how endpoints migrate a connection to a new 310 network path, 312 - Section 10 lists the options for terminating an open 313 connection, and 315 - Section 11 provides general guidance for error handling. 317 * Packets and frames are the basic unit used by QUIC to communicate. 319 - Section 12 describes concepts related to packets and frames, 321 - Section 13 defines models for the transmission, retransmission, 322 and acknowledgement of data, and 324 - Section 14 specifies rules for managing the size of packets. 326 * Finally, encoding details of QUIC protocol elements are described 327 in: 329 - Section 15 (Versions), 331 - Section 16 (Integer Encoding), 333 - Section 17 (Packet Headers), 335 - Section 18 (Transport Parameters), 337 - Section 19 (Frames), and 338 - Section 20 (Errors). 340 Accompanying documents describe QUIC's loss detection and congestion 341 control [QUIC-RECOVERY], and the use of TLS for key negotiation 342 [QUIC-TLS]. 344 This document defines QUIC version 1, which conforms to the protocol 345 invariants in [QUIC-INVARIANTS]. 347 1.2. Terms and Definitions 349 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 350 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 351 "OPTIONAL" in this document are to be interpreted as described in BCP 352 14 [RFC2119] [RFC8174] when, and only when, they appear in all 353 capitals, as shown here. 355 Commonly used terms in the document are described below. 357 QUIC: The transport protocol described by this document. QUIC is a 358 name, not an acronym. 360 QUIC packet: A complete processable unit of QUIC that can be 361 encapsulated in a UDP datagram. Multiple QUIC packets can be 362 encapsulated in a single UDP datagram. 364 Ack-eliciting Packet: A QUIC packet that contains frames other than 365 ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to 366 send an acknowledgment (see Section 13.2.1). 368 Out-of-order packet: A packet that does not increase the largest 369 received packet number for its packet number space (Section 12.3) 370 by exactly one. A packet can arrive out of order if it is delayed 371 or if earlier packets are lost or delayed. 373 Endpoint: An entity that can participate in a QUIC connection by 374 generating, receiving, and processing QUIC packets. There are 375 only two types of endpoint in QUIC: client and server. 377 Client: The endpoint initiating a QUIC connection. 379 Server: The endpoint accepting incoming QUIC connections. 381 Address: When used without qualification, the tuple of IP version, 382 IP address, UDP protocol, and UDP port number that represents one 383 end of a network path. 385 Connection ID: An opaque identifier that is used to identify a QUIC 386 connection at an endpoint. Each endpoint sets a value for its 387 peer to include in packets sent towards the endpoint. 389 Stream: A unidirectional or bidirectional channel of ordered bytes 390 within a QUIC connection. A QUIC connection can carry multiple 391 simultaneous streams. 393 Application: An entity that uses QUIC to send and receive data. 395 1.3. Notational Conventions 397 Packet and frame diagrams in this document use the format described 398 in Section 3.1 of [RFC2360], with the following additional 399 conventions: 401 [x]: Indicates that x is optional 403 x (A): Indicates that x is A bits long 405 x (A/B/C) ...: Indicates that x is one of A, B, or C bits long 407 x (i) ...: Indicates that x uses the variable-length encoding in 408 Section 16 410 x (*) ...: Indicates that x is variable-length 412 2. Streams 414 Streams in QUIC provide a lightweight, ordered byte-stream 415 abstraction to an application. Streams can be unidirectional or 416 bidirectional. An alternative view of QUIC unidirectional streams is 417 a "message" abstraction of practically unlimited length. 419 Streams can be created by sending data. Other processes associated 420 with stream management - ending, cancelling, and managing flow 421 control - are all designed to impose minimal overheads. For 422 instance, a single STREAM frame (Section 19.8) can open, carry data 423 for, and close a stream. Streams can also be long-lived and can last 424 the entire duration of a connection. 426 Streams can be created by either endpoint, can concurrently send data 427 interleaved with other streams, and can be cancelled. QUIC does not 428 provide any means of ensuring ordering between bytes on different 429 streams. 431 QUIC allows for an arbitrary number of streams to operate 432 concurrently and for an arbitrary amount of data to be sent on any 433 stream, subject to flow control constraints (see Section 4) and 434 stream limits. 436 2.1. Stream Types and Identifiers 438 Streams can be unidirectional or bidirectional. Unidirectional 439 streams carry data in one direction: from the initiator of the stream 440 to its peer. Bidirectional streams allow for data to be sent in both 441 directions. 443 Streams are identified within a connection by a numeric value, 444 referred to as the stream ID. A stream ID is a 62-bit integer (0 to 445 2^62-1) that is unique for all streams on a connection. Stream IDs 446 are encoded as variable-length integers (see Section 16). A QUIC 447 endpoint MUST NOT reuse a stream ID within a connection. 449 The least significant bit (0x1) of the stream ID identifies the 450 initiator of the stream. Client-initiated streams have even-numbered 451 stream IDs (with the bit set to 0), and server-initiated streams have 452 odd-numbered stream IDs (with the bit set to 1). 454 The second least significant bit (0x2) of the stream ID distinguishes 455 between bidirectional streams (with the bit set to 0) and 456 unidirectional streams (with the bit set to 1). 458 The least significant two bits from a stream ID therefore identify a 459 stream as one of four types, as summarized in Table 1. 461 +------+----------------------------------+ 462 | Bits | Stream Type | 463 +======+==================================+ 464 | 0x0 | Client-Initiated, Bidirectional | 465 +------+----------------------------------+ 466 | 0x1 | Server-Initiated, Bidirectional | 467 +------+----------------------------------+ 468 | 0x2 | Client-Initiated, Unidirectional | 469 +------+----------------------------------+ 470 | 0x3 | Server-Initiated, Unidirectional | 471 +------+----------------------------------+ 473 Table 1: Stream ID Types 475 Within each type, streams are created with numerically increasing 476 stream IDs. A stream ID that is used out of order results in all 477 streams of that type with lower-numbered stream IDs also being 478 opened. 480 The first bidirectional stream opened by the client has a stream ID 481 of 0. 483 2.2. Sending and Receiving Data 485 STREAM frames (Section 19.8) encapsulate data sent by an application. 486 An endpoint uses the Stream ID and Offset fields in STREAM frames to 487 place data in order. 489 Endpoints MUST be able to deliver stream data to an application as an 490 ordered byte-stream. Delivering an ordered byte-stream requires that 491 an endpoint buffer any data that is received out of order, up to the 492 advertised flow control limit. 494 QUIC makes no specific allowances for delivery of stream data out of 495 order. However, implementations MAY choose to offer the ability to 496 deliver data out of order to a receiving application. 498 An endpoint could receive data for a stream at the same stream offset 499 multiple times. Data that has already been received can be 500 discarded. The data at a given offset MUST NOT change if it is sent 501 multiple times; an endpoint MAY treat receipt of different data at 502 the same offset within a stream as a connection error of type 503 PROTOCOL_VIOLATION. 505 Streams are an ordered byte-stream abstraction with no other 506 structure visible to QUIC. STREAM frame boundaries are not expected 507 to be preserved when data is transmitted, retransmitted after packet 508 loss, or delivered to the application at a receiver. 510 An endpoint MUST NOT send data on any stream without ensuring that it 511 is within the flow control limits set by its peer. Flow control is 512 described in detail in Section 4. 514 2.3. Stream Prioritization 516 Stream multiplexing can have a significant effect on application 517 performance if resources allocated to streams are correctly 518 prioritized. 520 QUIC does not provide a mechanism for exchanging prioritization 521 information. Instead, it relies on receiving priority information 522 from the application that uses QUIC. 524 A QUIC implementation SHOULD provide ways in which an application can 525 indicate the relative priority of streams. When deciding which 526 streams to dedicate resources to, the implementation SHOULD use the 527 information provided by the application. 529 2.4. Required Operations on Streams 531 There are certain operations which an application MUST be able to 532 perform when interacting with QUIC streams. This document does not 533 specify an API, but any implementation of this version of QUIC MUST 534 expose the ability to perform the operations described in this 535 section on a QUIC stream. 537 On the sending part of a stream, application protocols need to be 538 able to: 540 * write data, understanding when stream flow control credit 541 (Section 4.1) has successfully been reserved to send the written 542 data; 544 * end the stream (clean termination), resulting in a STREAM frame 545 (Section 19.8) with the FIN bit set; and 547 * reset the stream (abrupt termination), resulting in a RESET_STREAM 548 frame (Section 19.4), if the stream was not already in a terminal 549 state. 551 On the receiving part of a stream, application protocols need to be 552 able to: 554 * read data; and 556 * abort reading of the stream and request closure, possibly 557 resulting in a STOP_SENDING frame (Section 19.5). 559 Applications also need to be informed of state changes on streams, 560 including when the peer has opened or reset a stream, when a peer 561 aborts reading on a stream, when new data is available, and when data 562 can or cannot be written to the stream due to flow control. 564 3. Stream States 566 This section describes streams in terms of their send or receive 567 components. Two state machines are described: one for the streams on 568 which an endpoint transmits data (Section 3.1), and another for 569 streams on which an endpoint receives data (Section 3.2). 571 Unidirectional streams use the applicable state machine directly. 572 Bidirectional streams use both state machines. For the most part, 573 the use of these state machines is the same whether the stream is 574 unidirectional or bidirectional. The conditions for opening a stream 575 are slightly more complex for a bidirectional stream because the 576 opening of either send or receive sides causes the stream to open in 577 both directions. 579 An endpoint MUST open streams of the same type in increasing order of 580 stream ID. 582 Note: These states are largely informative. This document uses 583 stream states to describe rules for when and how different types 584 of frames can be sent and the reactions that are expected when 585 different types of frames are received. Though these state 586 machines are intended to be useful in implementing QUIC, these 587 states aren't intended to constrain implementations. An 588 implementation can define a different state machine as long as its 589 behavior is consistent with an implementation that implements 590 these states. 592 3.1. Sending Stream States 594 Figure 1 shows the states for the part of a stream that sends data to 595 a peer. 597 o 598 | Create Stream (Sending) 599 | Peer Creates Bidirectional Stream 600 v 601 +-------+ 602 | Ready | Send RESET_STREAM 603 | |-----------------------. 604 +-------+ | 605 | | 606 | Send STREAM / | 607 | STREAM_DATA_BLOCKED | 608 | | 609 | Peer Creates | 610 | Bidirectional Stream | 611 v | 612 +-------+ | 613 | Send | Send RESET_STREAM | 614 | |---------------------->| 615 +-------+ | 616 | | 617 | Send STREAM + FIN | 618 v v 619 +-------+ +-------+ 620 | Data | Send RESET_STREAM | Reset | 621 | Sent |------------------>| Sent | 622 +-------+ +-------+ 623 | | 624 | Recv All ACKs | Recv ACK 625 v v 626 +-------+ +-------+ 627 | Data | | Reset | 628 | Recvd | | Recvd | 629 +-------+ +-------+ 631 Figure 1: States for Sending Parts of Streams 633 The sending part of stream that the endpoint initiates (types 0 and 2 634 for clients, 1 and 3 for servers) is opened by the application. The 635 "Ready" state represents a newly created stream that is able to 636 accept data from the application. Stream data might be buffered in 637 this state in preparation for sending. 639 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a 640 sending part of a stream to enter the "Send" state. An 641 implementation might choose to defer allocating a stream ID to a 642 stream until it sends the first STREAM frame and enters this state, 643 which can allow for better stream prioritization. 645 The sending part of a bidirectional stream initiated by a peer (type 646 0 for a server, type 1 for a client) starts in the "Ready" state when 647 the receiving part is created. 649 In the "Send" state, an endpoint transmits - and retransmits as 650 necessary - stream data in STREAM frames. The endpoint respects the 651 flow control limits set by its peer, and continues to accept and 652 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 653 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 654 stream or connection flow control limits Section 4.1. 656 After the application indicates that all stream data has been sent 657 and a STREAM frame containing the FIN bit is sent, the sending part 658 of the stream enters the "Data Sent" state. From this state, the 659 endpoint only retransmits stream data as necessary. The endpoint 660 does not need to check flow control limits or send 661 STREAM_DATA_BLOCKED frames for a stream in this state. 662 MAX_STREAM_DATA frames might be received until the peer receives the 663 final stream offset. The endpoint can safely ignore any 664 MAX_STREAM_DATA frames it receives from its peer for a stream in this 665 state. 667 Once all stream data has been successfully acknowledged, the sending 668 part of the stream enters the "Data Recvd" state, which is a terminal 669 state. 671 From any of the "Ready", "Send", or "Data Sent" states, an 672 application can signal that it wishes to abandon transmission of 673 stream data. Alternatively, an endpoint might receive a STOP_SENDING 674 frame from its peer. In either case, the endpoint sends a 675 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 676 state. 678 An endpoint MAY send a RESET_STREAM as the first frame that mentions 679 a stream; this causes the sending part of that stream to open and 680 then immediately transition to the "Reset Sent" state. 682 Once a packet containing a RESET_STREAM has been acknowledged, the 683 sending part of the stream enters the "Reset Recvd" state, which is a 684 terminal state. 686 3.2. Receiving Stream States 688 Figure 2 shows the states for the part of a stream that receives data 689 from a peer. The states for a receiving part of a stream mirror only 690 some of the states of the sending part of the stream at the peer. 691 The receiving part of a stream does not track states on the sending 692 part that cannot be observed, such as the "Ready" state. Instead, 693 the receiving part of a stream tracks the delivery of data to the 694 application, some of which cannot be observed by the sender. 696 o 697 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 698 | Create Bidirectional Stream (Sending) 699 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 700 | Create Higher-Numbered Stream 701 v 702 +-------+ 703 | Recv | Recv RESET_STREAM 704 | |-----------------------. 705 +-------+ | 706 | | 707 | Recv STREAM + FIN | 708 v | 709 +-------+ | 710 | Size | Recv RESET_STREAM | 711 | Known |---------------------->| 712 +-------+ | 713 | | 714 | Recv All Data | 715 v v 716 +-------+ Recv RESET_STREAM +-------+ 717 | Data |--- (optional) --->| Reset | 718 | Recvd | Recv All Data | Recvd | 719 +-------+<-- (optional) ----+-------+ 720 | | 721 | App Read All Data | App Read RST 722 v v 723 +-------+ +-------+ 724 | Data | | Reset | 725 | Read | | Read | 726 +-------+ +-------+ 728 Figure 2: States for Receiving Parts of Streams 730 The receiving part of a stream initiated by a peer (types 1 and 3 for 731 a client, or 0 and 2 for a server) is created when the first STREAM, 732 STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. 733 For bidirectional streams initiated by a peer, receipt of a 734 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 735 stream also creates the receiving part. The initial state for the 736 receiving part of stream is "Recv". 738 The receiving part of a stream enters the "Recv" state when the 739 sending part of a bidirectional stream initiated by the endpoint 740 (type 0 for a client, type 1 for a server) enters the "Ready" state. 742 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 743 STOP_SENDING frame is received from the peer for that stream. 744 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 745 that the remote peer has opened the stream and is providing flow 746 control credit. Receiving a STOP_SENDING frame for an unopened 747 stream indicates that the remote peer no longer wishes to receive 748 data on this stream. Either frame might arrive before a STREAM or 749 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 751 Before a stream is created, all streams of the same type with lower- 752 numbered stream IDs MUST be created. This ensures that the creation 753 order for streams is consistent on both endpoints. 755 In the "Recv" state, the endpoint receives STREAM and 756 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 757 reassembled into the correct order for delivery to the application. 758 As data is consumed by the application and buffer space becomes 759 available, the endpoint sends MAX_STREAM_DATA frames to allow the 760 peer to send more data. 762 When a STREAM frame with a FIN bit is received, the final size of the 763 stream is known (see Section 4.4). The receiving part of the stream 764 then enters the "Size Known" state. In this state, the endpoint no 765 longer needs to send MAX_STREAM_DATA frames, it only receives any 766 retransmissions of stream data. 768 Once all data for the stream has been received, the receiving part 769 enters the "Data Recvd" state. This might happen as a result of 770 receiving the same STREAM frame that causes the transition to "Size 771 Known". After all data has been received, any STREAM or 772 STREAM_DATA_BLOCKED frames for the stream can be discarded. 774 The "Data Recvd" state persists until stream data has been delivered 775 to the application. Once stream data has been delivered, the stream 776 enters the "Data Read" state, which is a terminal state. 778 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 779 causes the stream to enter the "Reset Recvd" state. This might cause 780 the delivery of stream data to the application to be interrupted. 782 It is possible that all stream data is received when a RESET_STREAM 783 is received (that is, from the "Data Recvd" state). Similarly, it is 784 possible for remaining stream data to arrive after receiving a 785 RESET_STREAM frame (the "Reset Recvd" state). An implementation is 786 free to manage this situation as it chooses. 788 Sending RESET_STREAM means that an endpoint cannot guarantee delivery 789 of stream data; however there is no requirement that stream data not 790 be delivered if a RESET_STREAM is received. An implementation MAY 791 interrupt delivery of stream data, discard any data that was not 792 consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM 793 signal might be suppressed or withheld if stream data is completely 794 received and is buffered to be read by the application. If the 795 RESET_STREAM is suppressed, the receiving part of the stream remains 796 in "Data Recvd". 798 Once the application receives the signal indicating that the stream 799 was reset, the receiving part of the stream transitions to the "Reset 800 Read" state, which is a terminal state. 802 3.3. Permitted Frame Types 804 The sender of a stream sends just three frame types that affect the 805 state of a stream at either sender or receiver: STREAM 806 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 807 (Section 19.4). 809 A sender MUST NOT send any of these frames from a terminal state 810 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 811 STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the 812 terminal states and in the "Reset Sent" state. A receiver could 813 receive any of these three frames in any state, due to the 814 possibility of delayed delivery of packets carrying them. 816 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 817 STOP_SENDING frames (Section 19.5). 819 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 820 receiver can send STOP_SENDING in any state where it has not received 821 a RESET_STREAM frame; that is states other than "Reset Recvd" or 822 "Reset Read". However there is little value in sending a 823 STOP_SENDING frame in the "Data Recvd" state, since all stream data 824 has been received. A sender could receive either of these two frames 825 in any state as a result of delayed delivery of packets. 827 3.4. Bidirectional Stream States 829 A bidirectional stream is composed of sending and receiving parts. 830 Implementations may represent states of the bidirectional stream as 831 composites of sending and receiving stream states. The simplest 832 model presents the stream as "open" when either sending or receiving 833 parts are in a non-terminal state and "closed" when both sending and 834 receiving streams are in terminal states. 836 Table 2 shows a more complex mapping of bidirectional stream states 837 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 838 shows that multiple states on sending or receiving parts of streams 839 are mapped to the same composite state. Note that this is just one 840 possibility for such a mapping; this mapping requires that data is 841 acknowledged before the transition to a "closed" or "half-closed" 842 state. 844 +----------------------+----------------------+-----------------+ 845 | Sending Part | Receiving Part | Composite State | 846 +======================+======================+=================+ 847 | No Stream/Ready | No Stream/Recv *1 | idle | 848 +----------------------+----------------------+-----------------+ 849 | Ready/Send/Data Sent | Recv/Size Known | open | 850 +----------------------+----------------------+-----------------+ 851 | Ready/Send/Data Sent | Data Recvd/Data Read | half-closed | 852 | | | (remote) | 853 +----------------------+----------------------+-----------------+ 854 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 855 | | Read | (remote) | 856 +----------------------+----------------------+-----------------+ 857 | Data Recvd | Recv/Size Known | half-closed | 858 | | | (local) | 859 +----------------------+----------------------+-----------------+ 860 | Reset Sent/Reset | Recv/Size Known | half-closed | 861 | Recvd | | (local) | 862 +----------------------+----------------------+-----------------+ 863 | Reset Sent/Reset | Data Recvd/Data Read | closed | 864 | Recvd | | | 865 +----------------------+----------------------+-----------------+ 866 | Reset Sent/Reset | Reset Recvd/Reset | closed | 867 | Recvd | Read | | 868 +----------------------+----------------------+-----------------+ 869 | Data Recvd | Data Recvd/Data Read | closed | 870 +----------------------+----------------------+-----------------+ 871 | Data Recvd | Reset Recvd/Reset | closed | 872 | | Read | | 873 +----------------------+----------------------+-----------------+ 875 Table 2: Possible Mapping of Stream States to HTTP/2 877 Note (*1): A stream is considered "idle" if it has not yet been 878 created, or if the receiving part of the stream is in the "Recv" 879 state without yet having received any frames. 881 3.5. Solicited State Transitions 883 If an application is no longer interested in the data it is receiving 884 on a stream, it can abort reading the stream and specify an 885 application error code. 887 If the stream is in the "Recv" or "Size Known" states, the transport 888 SHOULD signal this by sending a STOP_SENDING frame to prompt closure 889 of the stream in the opposite direction. This typically indicates 890 that the receiving application is no longer reading data it receives 891 from the stream, but it is not a guarantee that incoming data will be 892 ignored. 894 STREAM frames received after sending STOP_SENDING are still counted 895 toward connection and stream flow control, even though these frames 896 can be discarded upon receipt. 898 A STOP_SENDING frame requests that the receiving endpoint send a 899 RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame 900 MUST send a RESET_STREAM frame if the stream is in the Ready or Send 901 state. If the stream is in the Data Sent state and any outstanding 902 data is declared lost, an endpoint SHOULD send a RESET_STREAM frame 903 in lieu of a retransmission. 905 An endpoint SHOULD copy the error code from the STOP_SENDING frame to 906 the RESET_STREAM frame it sends, but MAY use any application error 907 code. The endpoint that sends a STOP_SENDING frame MAY ignore the 908 error code carried in any RESET_STREAM frame it receives. 910 If the STOP_SENDING frame is received on a stream that is already in 911 the "Data Sent" state, an endpoint that wishes to cease 912 retransmission of previously-sent STREAM frames on that stream MUST 913 first send a RESET_STREAM frame. 915 STOP_SENDING SHOULD only be sent for a stream that has not been reset 916 by the peer. STOP_SENDING is most useful for streams in the "Recv" 917 or "Size Known" states. 919 An endpoint is expected to send another STOP_SENDING frame if a 920 packet containing a previous STOP_SENDING is lost. However, once 921 either all stream data or a RESET_STREAM frame has been received for 922 the stream - that is, the stream is in any state other than "Recv" or 923 "Size Known" - sending a STOP_SENDING frame is unnecessary. 925 An endpoint that wishes to terminate both directions of a 926 bidirectional stream can terminate one direction by sending a 927 RESET_STREAM, and it can encourage prompt termination in the opposite 928 direction by sending a STOP_SENDING frame. 930 4. Flow Control 932 It is necessary to limit the amount of data that a receiver could 933 buffer, to prevent a fast sender from overwhelming a slow receiver, 934 or to prevent a malicious sender from consuming a large amount of 935 memory at a receiver. To enable a receiver to limit memory 936 commitment to a connection and to apply back pressure on the sender, 937 streams are flow controlled both individually and as an aggregate. A 938 QUIC receiver controls the maximum amount of data the sender can send 939 on a stream at any time, as described in Section 4.1 and Section 4.2 941 Similarly, to limit concurrency within a connection, a QUIC endpoint 942 controls the maximum cumulative number of streams that its peer can 943 initiate, as described in Section 4.5. 945 Data sent in CRYPTO frames is not flow controlled in the same way as 946 stream data. QUIC relies on the cryptographic protocol 947 implementation to avoid excessive buffering of data; see [QUIC-TLS]. 948 The implementation SHOULD provide an interface to QUIC to tell it 949 about its buffering limits so that there is not excessive buffering 950 at multiple layers. 952 4.1. Data Flow Control 954 QUIC employs a credit-based flow-control scheme similar to that in 955 HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is 956 prepared to receive on a given stream and for the entire connection. 957 This leads to two levels of data flow control in QUIC: 959 * Stream flow control, which prevents a single stream from consuming 960 the entire receive buffer for a connection by limiting the amount 961 of data that can be sent on any stream. 963 * Connection flow control, which prevents senders from exceeding a 964 receiver's buffer capacity for the connection, by limiting the 965 total bytes of stream data sent in STREAM frames on all streams. 967 A receiver sets initial credits for all streams by sending transport 968 parameters during the handshake (Section 7.3). A receiver sends 969 MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to 970 the sender to advertise additional credit. 972 A receiver advertises credit for a stream by sending a 973 MAX_STREAM_DATA frame with the Stream ID field set appropriately. A 974 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 975 stream. A receiver could use the current offset of data consumed to 976 determine the flow control offset to be advertised. A receiver MAY 977 send MAX_STREAM_DATA frames in multiple packets in order to make sure 978 that the sender receives an update before running out of flow control 979 credit, even if one of the packets is lost. 981 A receiver advertises credit for a connection by sending a MAX_DATA 982 frame, which indicates the maximum of the sum of the absolute byte 983 offsets of all streams. A receiver maintains a cumulative sum of 984 bytes received on all streams, which is used to check for flow 985 control violations. A receiver might use a sum of bytes consumed on 986 all streams to determine the maximum data limit to be advertised. 988 A receiver can advertise a larger offset by sending MAX_STREAM_DATA 989 or MAX_DATA frames. Once a receiver advertises an offset, it MAY 990 advertise a smaller offset, but this has no effect. 992 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 993 (Section 11) if the sender violates the advertised connection or 994 stream data limits. 996 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 997 not increase flow control limits. 999 If a sender runs out of flow control credit, it will be unable to 1000 send new data and is considered blocked. A sender SHOULD send a 1001 STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to 1002 write but is blocked by flow control limits. If a sender is blocked 1003 for a period longer than the idle timeout (Section 10.2), the 1004 connection might be closed even when data is available for 1005 transmission. To keep the connection from closing, a sender that is 1006 flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED 1007 or DATA_BLOCKED frame when it has no ack-eliciting packets in flight. 1009 4.2. Flow Credit Increments 1011 Implementations decide when and how much credit to advertise in 1012 MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few 1013 considerations. 1015 To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or 1016 MAX_DATA frame multiple times within a round trip or send it early 1017 enough to allow for recovery from loss of the frame. 1019 Control frames contribute to connection overhead. Therefore, 1020 frequently sending MAX_STREAM_DATA and MAX_DATA frames with small 1021 changes is undesirable. On the other hand, if updates are less 1022 frequent, larger increments to limits are necessary to avoid blocking 1023 a sender, requiring larger resource commitments at the receiver. 1024 There is a trade-off between resource commitment and overhead when 1025 determining how large a limit is advertised. 1027 A receiver can use an autotuning mechanism to tune the frequency and 1028 amount of advertised additional credit based on a round-trip time 1029 estimate and the rate at which the receiving application consumes 1030 data, similar to common TCP implementations. As an optimization, an 1031 endpoint could send frames related to flow control only when there 1032 are other frames to send or when a peer is blocked, ensuring that 1033 flow control does not cause extra packets to be sent. 1035 A blocked sender is not required to send STREAM_DATA_BLOCKED or 1036 DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a 1037 STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a 1038 MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the 1039 sender being blocked for the rest of the connection. Even if the 1040 sender sends these frames, waiting for them will result in the sender 1041 being blocked for at least an entire round trip. 1043 When a sender receives credit after being blocked, it might be able 1044 to send a large amount of data in response, resulting in short-term 1045 congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of 1046 how a sender can avoid this congestion. 1048 4.3. Handling Stream Cancellation 1050 Endpoints need to eventually agree on the amount of flow control 1051 credit that has been consumed, to avoid either exceeding flow control 1052 limits or deadlocking. 1054 On receipt of a RESET_STREAM frame, an endpoint will tear down state 1055 for the matching stream and ignore further data arriving on that 1056 stream. Without the offset included in RESET_STREAM, the two 1057 endpoints could disagree on the number of bytes that count towards 1058 connection flow control. 1060 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes 1061 the final size of data sent on the stream. On receiving a 1062 RESET_STREAM frame, a receiver definitively knows how many bytes were 1063 sent on that stream before the RESET_STREAM frame, and the receiver 1064 MUST use the final size of the stream to account for all bytes sent 1065 on the stream in its connection level flow controller. 1067 RESET_STREAM terminates one direction of a stream abruptly. For a 1068 bidirectional stream, RESET_STREAM has no effect on data flow in the 1069 opposite direction. Both endpoints MUST maintain flow control state 1070 for the stream in the unterminated direction until that direction 1071 enters a terminal state, or until one of the endpoints sends 1072 CONNECTION_CLOSE. 1074 4.4. Stream Final Size 1076 The final size is the amount of flow control credit that is consumed 1077 by a stream. Assuming that every contiguous byte on the stream was 1078 sent once, the final size is the number of bytes sent. More 1079 generally, this is one higher than the offset of the byte with the 1080 largest offset sent on the stream, or zero if no bytes were sent. 1082 For a stream that is reset, the final size is carried explicitly in a 1083 RESET_STREAM frame. Otherwise, the final size is the offset plus the 1084 length of a STREAM frame marked with a FIN flag, or 0 in the case of 1085 incoming unidirectional streams. 1087 An endpoint will know the final size for a stream when the receiving 1088 part of the stream enters the "Size Known" or "Reset Recvd" state 1089 (Section 3). 1091 An endpoint MUST NOT send data on a stream at or beyond the final 1092 size. 1094 Once a final size for a stream is known, it cannot change. If a 1095 RESET_STREAM or STREAM frame is received indicating a change in the 1096 final size for the stream, an endpoint SHOULD respond with a 1097 FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat 1098 receipt of data at or beyond the final size as a FINAL_SIZE_ERROR 1099 error, even after a stream is closed. Generating these errors is not 1100 mandatory, but only because requiring that an endpoint generate these 1101 errors also means that the endpoint needs to maintain the final size 1102 state for closed streams, which could mean a significant state 1103 commitment. 1105 4.5. Controlling Concurrency 1107 An endpoint limits the cumulative number of incoming streams a peer 1108 can open. Only streams with a stream ID less than (max_stream * 4 + 1109 initial_stream_id_for_type) can be opened (see Table 5). Initial 1110 limits are set in the transport parameters (see Section 18.2) and 1111 subsequently limits are advertised using MAX_STREAMS frames 1112 (Section 19.11). Separate limits apply to unidirectional and 1113 bidirectional streams. 1115 If a max_streams transport parameter or MAX_STREAMS frame is received 1116 with a value greater than 2^60, this would allow a maximum stream ID 1117 that cannot be expressed as a variable-length integer (see 1118 Section 16). If either is received, the connection MUST be closed 1119 immediately with a connection error of type STREAM_LIMIT_ERROR (see 1120 Section 10.3). 1122 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1123 that receives a frame with a stream ID exceeding the limit it has 1124 sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR 1125 (Section 11). 1127 Once a receiver advertises a stream limit using the MAX_STREAMS 1128 frame, advertising a smaller limit has no effect. A receiver MUST 1129 ignore any MAX_STREAMS frame that does not increase the stream limit. 1131 As with stream and connection flow control, this document leaves when 1132 and how many streams to advertise to a peer via MAX_STREAMS to 1133 implementations. Implementations might choose to increase limits as 1134 streams close to keep the number of streams available to peers 1135 roughly consistent. 1137 An endpoint that is unable to open a new stream due to the peer's 1138 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1139 signal is considered useful for debugging. An endpoint MUST NOT wait 1140 to receive this signal before advertising additional credit, since 1141 doing so will mean that the peer will be blocked for at least an 1142 entire round trip, and potentially for longer if the peer chooses to 1143 not send STREAMS_BLOCKED frames. 1145 5. Connections 1147 QUIC's connection establishment combines version negotiation with the 1148 cryptographic and transport handshakes to reduce connection 1149 establishment latency, as described in Section 7. Once established, 1150 a connection may migrate to a different IP or port at either endpoint 1151 as described in Section 9. Finally, a connection may be terminated 1152 by either endpoint, as described in Section 10. 1154 5.1. Connection ID 1156 Each connection possesses a set of connection identifiers, or 1157 connection IDs, each of which can identify the connection. 1158 Connection IDs are independently selected by endpoints; each endpoint 1159 selects the connection IDs that its peer uses. 1161 The primary function of a connection ID is to ensure that changes in 1162 addressing at lower protocol layers (UDP, IP) don't cause packets for 1163 a QUIC connection to be delivered to the wrong endpoint. Each 1164 endpoint selects connection IDs using an implementation-specific (and 1165 perhaps deployment-specific) method which will allow packets with 1166 that connection ID to be routed back to the endpoint and identified 1167 by the endpoint upon receipt. 1169 Connection IDs MUST NOT contain any information that can be used by 1170 an external observer (that is, one that does not cooperate with the 1171 issuer) to correlate them with other connection IDs for the same 1172 connection. As a trivial example, this means the same connection ID 1173 MUST NOT be issued more than once on the same connection. 1175 Packets with long headers include Source Connection ID and 1176 Destination Connection ID fields. These fields are used to set the 1177 connection IDs for new connections; see Section 7.2 for details. 1179 Packets with short headers (Section 17.3) only include the 1180 Destination Connection ID and omit the explicit length. The length 1181 of the Destination Connection ID field is expected to be known to 1182 endpoints. Endpoints using a load balancer that routes based on 1183 connection ID could agree with the load balancer on a fixed length 1184 for connection IDs, or agree on an encoding scheme. A fixed portion 1185 could encode an explicit length, which allows the entire connection 1186 ID to vary in length and still be used by the load balancer. 1188 A Version Negotiation (Section 17.2.1) packet echoes the connection 1189 IDs selected by the client, both to ensure correct routing toward the 1190 client and to allow the client to validate that the packet is in 1191 response to an Initial packet. 1193 A zero-length connection ID can be used when a connection ID is not 1194 needed to route to the correct endpoint. However, multiplexing 1195 connections on the same local IP address and port while using zero- 1196 length connection IDs will cause failures in the presence of peer 1197 connection migration, NAT rebinding, and client port reuse; and 1198 therefore MUST NOT be done unless an endpoint is certain that those 1199 protocol features are not in use. 1201 When an endpoint uses a non-zero-length connection ID, it needs to 1202 ensure that the peer has a supply of connection IDs from which to 1203 choose for packets sent to the endpoint. These connection IDs are 1204 supplied by the endpoint using the NEW_CONNECTION_ID frame 1205 (Section 19.15). 1207 5.1.1. Issuing Connection IDs 1209 Each Connection ID has an associated sequence number to assist in 1210 deduplicating messages. The initial connection ID issued by an 1211 endpoint is sent in the Source Connection ID field of the long packet 1212 header (Section 17.2) during the handshake. The sequence number of 1213 the initial connection ID is 0. If the preferred_address transport 1214 parameter is sent, the sequence number of the supplied connection ID 1215 is 1. 1217 Additional connection IDs are communicated to the peer using 1218 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1219 each newly-issued connection ID MUST increase by 1. The connection 1220 ID randomly selected by the client in the Initial packet and any 1221 connection ID provided by a Retry packet are not assigned sequence 1222 numbers unless a server opts to retain them as its initial connection 1223 ID. 1225 When an endpoint issues a connection ID, it MUST accept packets that 1226 carry this connection ID for the duration of the connection or until 1227 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1228 frame (Section 19.16). Connection IDs that are issued and not 1229 retired are considered active; any active connection ID is valid for 1230 use at any time, in any packet type. This includes the connection ID 1231 issued by the server via the preferred_address transport parameter. 1233 An endpoint SHOULD ensure that its peer has a sufficient number of 1234 available and unused connection IDs. Endpoints store received 1235 connection IDs for future use and advertise the number of connection 1236 IDs they are willing to store with the active_connection_id_limit 1237 transport parameter. An endpoint MUST NOT provide more connection 1238 IDs than the peer's limit. An endpoint that receives more connection 1239 IDs than its advertised active_connection_id_limit MUST close the 1240 connection with an error of type CONNECTION_ID_LIMIT_ERROR. 1242 An endpoint SHOULD supply a new connection ID when the peer retires a 1243 connection ID. If an endpoint provided fewer connection IDs than the 1244 peer's active_connection_id_limit, it MAY supply a new connection ID 1245 when it receives a packet with a previously unused connection ID. An 1246 endpoint MAY limit the frequency or the total number of connection 1247 IDs issued for each connection to avoid the risk of running out of 1248 connection IDs; see Section 10.4.2. 1250 An endpoint that initiates migration and requires non-zero-length 1251 connection IDs SHOULD ensure that the pool of connection IDs 1252 available to its peer allows the peer to use a new connection ID on 1253 migration, as the peer will close the connection if the pool is 1254 exhausted. 1256 5.1.2. Consuming and Retiring Connection IDs 1258 An endpoint can change the connection ID it uses for a peer to 1259 another available one at any time during the connection. An endpoint 1260 consumes connection IDs in response to a migrating peer; see 1261 Section 9.5 for more. 1263 An endpoint maintains a set of connection IDs received from its peer, 1264 any of which it can use when sending packets. When the endpoint 1265 wishes to remove a connection ID from use, it sends a 1266 RETIRE_CONNECTION_ID frame to its peer. Sending a 1267 RETIRE_CONNECTION_ID frame indicates that the connection ID will not 1268 be used again and requests that the peer replace it with a new 1269 connection ID using a NEW_CONNECTION_ID frame. 1271 As discussed in Section 9.5, each connection ID MUST be used on 1272 packets sent from only one local address. An endpoint that migrates 1273 away from a local address SHOULD retire all connection IDs used on 1274 that address once it no longer plans to use that address. 1276 An endpoint can cause its peer to retire connection IDs by sending a 1277 NEW_CONNECTION_ID frame with an increased Retire Prior To field. 1278 Upon receipt, the peer MUST first retire the corresponding connection 1279 IDs using RETIRE_CONNECTION_ID frames and then add the newly provided 1280 connection ID to the set of active connection IDs. Failure to retire 1281 the connection IDs within approximately one PTO can cause packets to 1282 be delayed, lost, or cause the original endpoint to send a stateless 1283 reset in response to a connection ID it can no longer route 1284 correctly. 1286 An endpoint MAY discard a connection ID for which retirement has been 1287 requested once an interval of no less than 3 PTO has elapsed since an 1288 acknowledgement is received for the NEW_CONNECTION_ID frame 1289 requesting that retirement. Until then, the endpoint SHOULD be 1290 prepared to receive packets that contain the connection ID that it 1291 has requested be retired. Subsequent incoming packets using that 1292 connection ID could elicit a response with the corresponding 1293 stateless reset token. 1295 5.2. Matching Packets to Connections 1297 Incoming packets are classified on receipt. Packets can either be 1298 associated with an existing connection, or - for servers - 1299 potentially create a new connection. 1301 Endpoints try to associate a packet with an existing connection. If 1302 the packet has a non-zero-length Destination Connection ID 1303 corresponding to an existing connection, QUIC processes that packet 1304 accordingly. Note that more than one connection ID can be associated 1305 with a connection; see Section 5.1. 1307 If the Destination Connection ID is zero length and the addressing 1308 information in the packet matches the addressing information the 1309 endpoint uses to identify a connection with a zero-length connection 1310 ID, QUIC processes the packet as part of that connection. An 1311 endpoint can use just destination IP and port or both source and 1312 destination addresses for identification, though this makes 1313 connections fragile as described in Section 5.1. 1315 Endpoints can send a Stateless Reset (Section 10.4) for any packets 1316 that cannot be attributed to an existing connection. A stateless 1317 reset allows a peer to more quickly identify when a connection 1318 becomes unusable. 1320 Packets that are matched to an existing connection are discarded if 1321 the packets are inconsistent with the state of that connection. For 1322 example, packets are discarded if they indicate a different protocol 1323 version than that of the connection, or if the removal of packet 1324 protection is unsuccessful once the expected keys are available. 1326 Invalid packets without packet protection, such as Initial, Retry, or 1327 Version Negotiation, MAY be discarded. An endpoint MUST generate a 1328 connection error if it commits changes to state before discovering an 1329 error. 1331 5.2.1. Client Packet Handling 1333 Valid packets sent to clients always include a Destination Connection 1334 ID that matches a value the client selects. Clients that choose to 1335 receive zero-length connection IDs can use the local address and port 1336 to identify a connection. Packets that don't match an existing 1337 connection are discarded. 1339 Due to packet reordering or loss, a client might receive packets for 1340 a connection that are encrypted with a key it has not yet computed. 1341 The client MAY drop these packets, or MAY buffer them in anticipation 1342 of later packets that allow it to compute the key. 1344 If a client receives a packet that has an unsupported version, it 1345 MUST discard that packet. 1347 5.2.2. Server Packet Handling 1349 If a server receives a packet that has an unsupported version, but 1350 the packet is sufficiently large to initiate a new connection for any 1351 version supported by the server, it SHOULD send a Version Negotiation 1352 packet as described in Section 6.1. Servers MAY rate control these 1353 packets to avoid storms of Version Negotiation packets. Otherwise, 1354 servers MUST drop packets that specify unsupported versions. 1356 The first packet for an unsupported version can use different 1357 semantics and encodings for any version-specific field. In 1358 particular, different packet protection keys might be used for 1359 different versions. Servers that do not support a particular version 1360 are unlikely to be able to decrypt the payload of the packet. 1361 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1362 unknown version, but instead send a Version Negotiation packet, 1363 provided that the packet is sufficiently long. 1365 Packets with a supported version, or no version field, are matched to 1366 a connection using the connection ID or - for packets with zero- 1367 length connection IDs - the local address and port. If the packet 1368 doesn't match an existing connection, the server continues below. 1370 If the packet is an Initial packet fully conforming with the 1371 specification, the server proceeds with the handshake (Section 7). 1372 This commits the server to the version that the client selected. 1374 If a server isn't currently accepting any new connections, it SHOULD 1375 send an Initial packet containing a CONNECTION_CLOSE frame with error 1376 code SERVER_BUSY. 1378 If the packet is a 0-RTT packet, the server MAY buffer a limited 1379 number of these packets in anticipation of a late-arriving Initial 1380 packet. Clients are not able to send Handshake packets prior to 1381 receiving a server response, so servers SHOULD ignore any such 1382 packets. 1384 Servers MUST drop incoming packets under all other circumstances. 1386 5.3. Life of a QUIC Connection 1388 A QUIC connection is a stateful interaction between a client and 1389 server, the primary purpose of which is to support the exchange of 1390 data by an application protocol. Streams (Section 2) are the primary 1391 means by which an application protocol exchanges information. 1393 Each connection starts with a handshake phase, during which client 1394 and server establish a shared secret using the cryptographic 1395 handshake protocol [QUIC-TLS] and negotiate the application protocol. 1396 The handshake (Section 7) confirms that both endpoints are willing to 1397 communicate (Section 8.1) and establishes parameters for the 1398 connection (Section 7.3). 1400 An application protocol can also operate in a limited fashion during 1401 the handshake phase. 0-RTT allows application messages to be sent by 1402 a client before receiving any messages from the server. However, 1403 0-RTT lacks certain key security guarantees. In particular, there is 1404 no protection against replay attacks in 0-RTT; see [QUIC-TLS]. 1405 Separately, a server can also send application data to a client 1406 before it receives the final cryptographic handshake messages that 1407 allow it to confirm the identity and liveness of the client. These 1408 capabilities allow an application protocol to offer the option to 1409 trade some security guarantees for reduced latency. 1411 The use of connection IDs (Section 5.1) allows connections to migrate 1412 to a new network path, both as a direct choice of an endpoint and 1413 when forced by a change in a middlebox. Section 9 describes 1414 mitigations for the security and privacy issues associated with 1415 migration. 1417 For connections that are no longer needed or desired, there are 1418 several ways for a client and server to terminate a connection 1419 (Section 10). 1421 5.4. Required Operations on Connections 1423 There are certain operations which an application MUST be able to 1424 perform when interacting with the QUIC transport. This document does 1425 not specify an API, but any implementation of this version of QUIC 1426 MUST expose the ability to perform the operations described in this 1427 section on a QUIC connection. 1429 When implementing the client role, applications need to be able to: 1431 * open a connection, which begins the exchange described in 1432 Section 7; 1434 * enable 0-RTT when available; and 1436 * be informed when 0-RTT has been accepted or rejected by a server. 1438 When implementing the server role, applications need to be able to: 1440 * listen for incoming connections, which prepares for the exchange 1441 described in Section 7; 1443 * if Early Data is supported, embed application-controlled data in 1444 the TLS resumption ticket sent to the client; and 1446 * if Early Data is supported, retrieve application-controlled data 1447 from the client's resumption ticket and enable rejecting Early 1448 Data based on that information. 1450 In either role, applications need to be able to: 1452 * configure minimum values for the initial number of permitted 1453 streams of each type, as communicated in the transport parameters 1454 (Section 7.3); 1456 * control resource allocation of various types, including flow 1457 control and the number of permitted streams of each type; 1459 * identify whether the handshake has completed successfully or is 1460 still ongoing 1462 * keep a connection from silently closing, either by generating PING 1463 frames (Section 19.2) or by requesting that the transport send 1464 additional frames before the idle timeout expires (Section 10.2); 1465 and 1467 * immediately close (Section 10.3) the connection. 1469 6. Version Negotiation 1471 Version negotiation ensures that client and server agree to a QUIC 1472 version that is mutually supported. A server sends a Version 1473 Negotiation packet in response to each packet that might initiate a 1474 new connection; see Section 5.2 for details. 1476 The size of the first packet sent by a client will determine whether 1477 a server sends a Version Negotiation packet. Clients that support 1478 multiple QUIC versions SHOULD pad the first packet they send to the 1479 largest of the minimum packet sizes across all versions they support. 1480 This ensures that the server responds if there is a mutually 1481 supported version. 1483 6.1. Sending Version Negotiation Packets 1485 If the version selected by the client is not acceptable to the 1486 server, the server responds with a Version Negotiation packet (see 1487 Section 17.2.1). This includes a list of versions that the server 1488 will accept. An endpoint MUST NOT send a Version Negotiation packet 1489 in response to receiving a Version Negotiation packet. 1491 This system allows a server to process packets with unsupported 1492 versions without retaining state. Though either the Initial packet 1493 or the Version Negotiation packet that is sent in response could be 1494 lost, the client will send new packets until it successfully receives 1495 a response or it abandons the connection attempt. As a result, the 1496 client discards all state for the connection and does not send any 1497 more packets on the connection. 1499 A server MAY limit the number of Version Negotiation packets it 1500 sends. For instance, a server that is able to recognize packets as 1501 0-RTT might choose not to send Version Negotiation packets in 1502 response to 0-RTT packets with the expectation that it will 1503 eventually receive an Initial packet. 1505 6.2. Handling Version Negotiation Packets 1507 When a client receives a Version Negotiation packet, it MUST abandon 1508 the current connection attempt. Version Negotiation packets are 1509 designed to allow future versions of QUIC to negotiate the version in 1510 use between endpoints. Future versions of QUIC might change how 1511 implementations that support multiple versions of QUIC react to 1512 Version Negotiation packets when attempting to establish a connection 1513 using this version. How to perform version negotiation is left as 1514 future work defined by future versions of QUIC. In particular, that 1515 future work will need to ensure robustness against version downgrade 1516 attacks; see Section 21.10. 1518 6.2.1. Version Negotiation Between Draft Versions 1520 [[RFC editor: please remove this section before publication.]] 1522 When a draft implementation receives a Version Negotiation packet, it 1523 MAY use it to attempt a new connection with one of the versions 1524 listed in the packet, instead of abandoning the current connection 1525 attempt; see Section 6.2. 1527 The client MUST check that the Destination and Source Connection ID 1528 fields match the Source and Destination Connection ID fields in a 1529 packet that the client sent. If this check fails, the packet MUST be 1530 discarded. 1532 Once the Version Negotiation packet is determined to be valid, the 1533 client then selects an acceptable protocol version from the list 1534 provided by the server. The client then attempts to create a new 1535 connection using that version. The new connection MUST use a new 1536 random Destination Connection ID different from the one it had 1537 previously sent. 1539 Note that this mechanism does not protect against downgrade attacks 1540 and MUST NOT be used outside of draft implementations. 1542 6.3. Using Reserved Versions 1544 For a server to use a new version in the future, clients need to 1545 correctly handle unsupported versions. To help ensure this, a server 1546 SHOULD include a version that is reserved for forcing version 1547 negotiation (0x?a?a?a?a as defined in Section 15) when generating a 1548 Version Negotiation packet. 1550 The design of version negotiation permits a server to avoid 1551 maintaining state for packets that it rejects in this fashion. 1553 A client MAY send a packet using a version that is reserved for 1554 forcing version negotiation. This can be used to solicit a list of 1555 supported versions from a server. 1557 7. Cryptographic and Transport Handshake 1559 QUIC relies on a combined cryptographic and transport handshake to 1560 minimize connection establishment latency. QUIC uses the CRYPTO 1561 frame Section 19.6 to transmit the cryptographic handshake. Version 1562 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 1563 QUIC version number could indicate that a different cryptographic 1564 handshake protocol is in use. 1566 QUIC provides reliable, ordered delivery of the cryptographic 1567 handshake data. QUIC packet protection is used to encrypt as much of 1568 the handshake protocol as possible. The cryptographic handshake MUST 1569 provide the following properties: 1571 * authenticated key exchange, where 1573 - a server is always authenticated, 1575 - a client is optionally authenticated, 1577 - every connection produces distinct and unrelated keys, 1579 - keying material is usable for packet protection for both 0-RTT 1580 and 1-RTT packets, and 1582 - 1-RTT keys have forward secrecy 1584 * authenticated values for transport parameters of both endpoints, 1585 and confidentiality protection for server transport parameters 1586 (see Section 7.3) 1588 * authenticated negotiation of an application protocol (TLS uses 1589 ALPN [RFC7301] for this purpose) 1591 An endpoint can verify support for Explicit Congestion Notification 1592 (ECN) in the first packets it sends, as described in Section 13.4.2. 1594 The CRYPTO frame can be sent in different packet number spaces 1595 (Section 12.3). The sequence numbers used by CRYPTO frames to ensure 1596 ordered delivery of cryptographic handshake data start from zero in 1597 each packet number space. 1599 Endpoints MUST explicitly negotiate an application protocol. This 1600 avoids situations where there is a disagreement about the protocol 1601 that is in use. 1603 7.1. Example Handshake Flows 1605 Details of how TLS is integrated with QUIC are provided in 1606 [QUIC-TLS], but some examples are provided here. An extension of 1607 this exchange to support client address validation is shown in 1608 Section 8.1.2. 1610 Once any address validation exchanges are complete, the cryptographic 1611 handshake is used to agree on cryptographic keys. The cryptographic 1612 handshake is carried in Initial (Section 17.2.2) and Handshake 1613 (Section 17.2.4) packets. 1615 Figure 3 provides an overview of the 1-RTT handshake. Each line 1616 shows a QUIC packet with the packet type and packet number shown 1617 first, followed by the frames that are typically contained in those 1618 packets. So, for instance the first packet is of type Initial, with 1619 packet number 0, and contains a CRYPTO frame carrying the 1620 ClientHello. 1622 Note that multiple QUIC packets - even of different encryption levels 1623 - may be coalesced into a single UDP datagram (see Section 12.2), and 1624 so this handshake may consist of as few as 4 UDP datagrams, or any 1625 number more. For instance, the server's first flight contains 1626 packets from the Initial encryption level (obfuscation), the 1627 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1628 encryption level. 1630 Client Server 1632 Initial[0]: CRYPTO[CH] -> 1634 Initial[0]: CRYPTO[SH] ACK[0] 1635 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1636 <- 1-RTT[0]: STREAM[1, "..."] 1638 Initial[1]: ACK[0] 1639 Handshake[0]: CRYPTO[FIN], ACK[0] 1640 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1642 1-RTT[1]: STREAM[3, "..."], ACK[0] 1643 <- Handshake[1]: ACK[0] 1645 Figure 3: Example 1-RTT Handshake 1647 Figure 4 shows an example of a connection with a 0-RTT handshake and 1648 a single packet of 0-RTT data. Note that as described in 1649 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1650 encryption level, and the client sends 1-RTT packets in the same 1651 packet number space. 1653 Client Server 1655 Initial[0]: CRYPTO[CH] 1656 0-RTT[0]: STREAM[0, "..."] -> 1658 Initial[0]: CRYPTO[SH] ACK[0] 1659 Handshake[0] CRYPTO[EE, FIN] 1660 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1662 Initial[1]: ACK[0] 1663 Handshake[0]: CRYPTO[FIN], ACK[0] 1664 1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1666 1-RTT[1]: STREAM[3, "..."], ACK[1] 1667 <- Handshake[1]: ACK[0] 1669 Figure 4: Example 0-RTT Handshake 1671 7.2. Negotiating Connection IDs 1673 A connection ID is used to ensure consistent routing of packets, as 1674 described in Section 5.1. The long header contains two connection 1675 IDs: the Destination Connection ID is chosen by the recipient of the 1676 packet and is used to provide consistent routing; the Source 1677 Connection ID is used to set the Destination Connection ID used by 1678 the peer. 1680 During the handshake, packets with the long header (Section 17.2) are 1681 used to establish the connection ID that each endpoint uses. Each 1682 endpoint uses the Source Connection ID field to specify the 1683 connection ID that is used in the Destination Connection ID field of 1684 packets being sent to them. Upon receiving a packet, each endpoint 1685 sets the Destination Connection ID it sends to match the value of the 1686 Source Connection ID that they receive. 1688 When an Initial packet is sent by a client that has not previously 1689 received an Initial or Retry packet from the server, it populates the 1690 Destination Connection ID field with an unpredictable value. This 1691 MUST be at least 8 bytes in length. Until a packet is received from 1692 the server, the client MUST use the same value unless it abandons the 1693 connection attempt and starts a new one. The initial Destination 1694 Connection ID is used to determine packet protection keys for Initial 1695 packets. 1697 The client populates the Source Connection ID field with a value of 1698 its choosing and sets the SCID Len field to indicate the length. 1700 The first flight of 0-RTT packets use the same Destination and Source 1701 Connection ID values as the client's first Initial. 1703 Upon first receiving an Initial or Retry packet from the server, the 1704 client uses the Source Connection ID supplied by the server as the 1705 Destination Connection ID for subsequent packets, including any 1706 subsequent 0-RTT packets. That means that a client might change the 1707 Destination Connection ID twice during connection establishment, once 1708 in response to a Retry and once in response to the first Initial 1709 packet from the server. Once a client has received an Initial packet 1710 from the server, it MUST discard any packet it receives with a 1711 different Source Connection ID. 1713 A client MUST only change the value it sends in the Destination 1714 Connection ID in response to the first packet of each type it 1715 receives from the server (Retry or Initial); a server MUST set its 1716 value based on the Initial packet. Any additional changes are not 1717 permitted; if subsequent packets of those types include a different 1718 Source Connection ID, they MUST be discarded. This avoids problems 1719 that might arise from stateless processing of multiple Initial 1720 packets producing different connection IDs. 1722 The connection ID can change over the lifetime of a connection, 1723 especially in response to connection migration (Section 9); see 1724 Section 5.1.1 for details. 1726 7.3. Transport Parameters 1728 During connection establishment, both endpoints make authenticated 1729 declarations of their transport parameters. These declarations are 1730 made unilaterally by each endpoint. Endpoints are required to comply 1731 with the restrictions implied by these parameters; the description of 1732 each parameter includes rules for its handling. 1734 The encoding of the transport parameters is detailed in Section 18. 1736 QUIC includes the encoded transport parameters in the cryptographic 1737 handshake. Once the handshake completes, the transport parameters 1738 declared by the peer are available. Each endpoint validates the 1739 value provided by its peer. 1741 Definitions for each of the defined transport parameters are included 1742 in Section 18.2. 1744 An endpoint MUST treat receipt of a transport parameter with an 1745 invalid value as a connection error of type 1746 TRANSPORT_PARAMETER_ERROR. 1748 An endpoint MUST NOT send a parameter more than once in a given 1749 transport parameters extension. An endpoint SHOULD treat receipt of 1750 duplicate transport parameters as a connection error of type 1751 TRANSPORT_PARAMETER_ERROR. 1753 A server MUST include the original_connection_id transport parameter 1754 (Section 18.2) if it sent a Retry packet to enable validation of the 1755 Retry, as described in Section 17.2.5. 1757 7.3.1. Values of Transport Parameters for 0-RTT 1759 Both endpoints store the value of the server transport parameters 1760 from a connection and apply them to any 0-RTT packets that are sent 1761 in subsequent connections to that peer, except for transport 1762 parameters that are explicitly excluded. Remembered transport 1763 parameters apply to the new connection until the handshake completes 1764 and the client starts sending 1-RTT packets. Once the handshake 1765 completes, the client uses the transport parameters established in 1766 the handshake. 1768 The definition of new transport parameters (Section 7.3.2) MUST 1769 specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A 1770 client need not store a transport parameter it cannot process. 1772 A client MUST NOT use remembered values for the following parameters: 1773 original_connection_id, preferred_address, stateless_reset_token, 1774 ack_delay_exponent and active_connection_id_limit. The client MUST 1775 use the server's new values in the handshake instead, and absent new 1776 values from the server, the default value. 1778 A client that attempts to send 0-RTT data MUST remember all other 1779 transport parameters used by the server. The server can remember 1780 these transport parameters, or store an integrity-protected copy of 1781 the values in the ticket and recover the information when accepting 1782 0-RTT data. A server uses the transport parameters in determining 1783 whether to accept 0-RTT data. 1785 If 0-RTT data is accepted by the server, the server MUST NOT reduce 1786 any limits or alter any values that might be violated by the client 1787 with its 0-RTT data. In particular, a server that accepts 0-RTT data 1788 MUST NOT set values for the following parameters (Section 18.2) that 1789 are smaller than the remembered value of the parameters. 1791 * initial_max_data 1793 * initial_max_stream_data_bidi_local 1795 * initial_max_stream_data_bidi_remote 1797 * initial_max_stream_data_uni 1799 * initial_max_streams_bidi 1801 * initial_max_streams_uni 1803 Omitting or setting a zero value for certain transport parameters can 1804 result in 0-RTT data being enabled, but not usable. The applicable 1805 subset of transport parameters that permit sending of application 1806 data SHOULD be set to non-zero values for 0-RTT. This includes 1807 initial_max_data and either initial_max_streams_bidi and 1808 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 1809 initial_max_stream_data_uni. 1811 A server MUST either reject 0-RTT data or abort a handshake if the 1812 implied values for transport parameters cannot be supported. 1814 When sending frames in 0-RTT packets, a client MUST only use 1815 remembered transport parameters; importantly, it MUST NOT use updated 1816 values that it learns from the server's updated transport parameters 1817 or from frames received in 1-RTT packets. Updated values of 1818 transport parameters from the handshake apply only to 1-RTT packets. 1819 For instance, flow control limits from remembered transport 1820 parameters apply to all 0-RTT packets even if those values are 1821 increased by the handshake or by frames sent in 1-RTT packets. A 1822 server MAY treat use of updated transport parameters in 0-RTT as a 1823 connection error of type PROTOCOL_VIOLATION. 1825 7.3.2. New Transport Parameters 1827 New transport parameters can be used to negotiate new protocol 1828 behavior. An endpoint MUST ignore transport parameters that it does 1829 not support. Absence of a transport parameter therefore disables any 1830 optional protocol feature that is negotiated using the parameter. As 1831 described in Section 18.1, some identifiers are reserved in order to 1832 exercise this requirement. 1834 New transport parameters can be registered according to the rules in 1835 Section 22.2. 1837 7.4. Cryptographic Message Buffering 1839 Implementations need to maintain a buffer of CRYPTO data received out 1840 of order. Because there is no flow control of CRYPTO frames, an 1841 endpoint could potentially force its peer to buffer an unbounded 1842 amount of data. 1844 Implementations MUST support buffering at least 4096 bytes of data 1845 received in CRYPTO frames out of order. Endpoints MAY choose to 1846 allow more data to be buffered during the handshake. A larger limit 1847 during the handshake could allow for larger keys or credentials to be 1848 exchanged. An endpoint's buffer size does not need to remain 1849 constant during the life of the connection. 1851 Being unable to buffer CRYPTO frames during the handshake can lead to 1852 a connection failure. If an endpoint's buffer is exceeded during the 1853 handshake, it can expand its buffer temporarily to complete the 1854 handshake. If an endpoint does not expand its buffer, it MUST close 1855 the connection with a CRYPTO_BUFFER_EXCEEDED error code. 1857 Once the handshake completes, if an endpoint is unable to buffer all 1858 data in a CRYPTO frame, it MAY discard that CRYPTO frame and all 1859 CRYPTO frames received in the future, or it MAY close the connection 1860 with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing 1861 discarded CRYPTO frames MUST be acknowledged because the packet has 1862 been received and processed by the transport even though the CRYPTO 1863 frame was discarded. 1865 8. Address Validation 1867 Address validation is used by QUIC to avoid being used for a traffic 1868 amplification attack. In such an attack, a packet is sent to a 1869 server with spoofed source address information that identifies a 1870 victim. If a server generates more or larger packets in response to 1871 that packet, the attacker can use the server to send more data toward 1872 the victim than it would be able to send on its own. 1874 The primary defense against amplification attack is verifying that an 1875 endpoint is able to receive packets at the transport address that it 1876 claims. Address validation is performed both during connection 1877 establishment (see Section 8.1) and during connection migration (see 1878 Section 8.2). 1880 8.1. Address Validation During Connection Establishment 1882 Connection establishment implicitly provides address validation for 1883 both endpoints. In particular, receipt of a packet protected with 1884 Handshake keys confirms that the client received the Initial packet 1885 from the server. Once the server has successfully processed a 1886 Handshake packet from the client, it can consider the client address 1887 to have been validated. 1889 Prior to validating the client address, servers MUST NOT send more 1890 than three times as many bytes as the number of bytes they have 1891 received. This limits the magnitude of any amplification attack that 1892 can be mounted using spoofed source addresses. In determining this 1893 limit, servers only count the size of successfully processed packets. 1895 Clients MUST ensure that UDP datagrams containing Initial packets 1896 have UDP payloads of at least 1200 bytes, adding padding to packets 1897 in the datagram as necessary. Sending padded datagrams ensures that 1898 the server is not overly constrained by the amplification 1899 restriction. 1901 Packet loss, in particular loss of a Handshake packet from the 1902 server, can cause a situation in which the server cannot send when 1903 the client has no data to send and the anti-amplification limit is 1904 reached. In order to avoid this causing a handshake deadlock, 1905 clients MUST send a packet upon a probe timeout, as described in 1906 [QUIC-RECOVERY]. If the client has no data to retransmit and does 1907 not have Handshake keys, it MUST send an Initial packet in a UDP 1908 datagram of at least 1200 bytes. If the client has Handshake keys, 1909 it SHOULD send a Handshake packet. 1911 A server might wish to validate the client address before starting 1912 the cryptographic handshake. QUIC uses a token in the Initial packet 1913 to provide address validation prior to completing the handshake. 1914 This token is delivered to the client during connection establishment 1915 with a Retry packet (see Section 8.1.2) or in a previous connection 1916 using the NEW_TOKEN frame (see Section 8.1.3). 1918 In addition to sending limits imposed prior to address validation, 1919 servers are also constrained in what they can send by the limits set 1920 by the congestion controller. Clients are only constrained by the 1921 congestion controller. 1923 8.1.1. Token Construction 1925 A token sent in a NEW_TOKEN frames or a Retry packet MUST be 1926 constructed in a way that allows the server to identity how it was 1927 provided to a client. These tokens are carried in the same field, 1928 but require different handling from servers. 1930 8.1.2. Address Validation using Retry Packets 1932 Upon receiving the client's Initial packet, the server can request 1933 address validation by sending a Retry packet (Section 17.2.5) 1934 containing a token. This token MUST be repeated by the client in all 1935 Initial packets it sends for that connection after it receives the 1936 Retry packet. In response to processing an Initial containing a 1937 token, a server can either abort the connection or permit it to 1938 proceed. 1940 As long as it is not possible for an attacker to generate a valid 1941 token for its own address (see Section 8.1.4) and the client is able 1942 to return that token, it proves to the server that it received the 1943 token. 1945 A server can also use a Retry packet to defer the state and 1946 processing costs of connection establishment. Requiring the server 1947 to provide a different connection ID, along with the 1948 original_connection_id transport parameter defined in Section 18.2, 1949 forces the server to demonstrate that it, or an entity it cooperates 1950 with, received the original Initial packet from the client. 1951 Providing a different connection ID also grants a server some control 1952 over how subsequent packets are routed. This can be used to direct 1953 connections to a different server instance. 1955 If a server receives a client Initial that can be unprotected but 1956 contains an invalid Retry token, it knows the client will not accept 1957 another Retry token. The server can discard such a packet and allow 1958 the client to time out to detect handshake failure, but that could 1959 impose a significant latency penalty on the client. A server MAY 1960 proceed with the connection without verifying the token, though the 1961 server MUST NOT consider the client address validated. If a server 1962 chooses not to proceed with the handshake, it SHOULD immediately 1963 close (Section 10.3) the connection with an INVALID_TOKEN error. 1964 Note that a server has not established any state for the connection 1965 at this point and so does not enter the closing period. 1967 A flow showing the use of a Retry packet is shown in Figure 5. 1969 Client Server 1971 Initial[0]: CRYPTO[CH] -> 1973 <- Retry+Token 1975 Initial+Token[1]: CRYPTO[CH] -> 1977 Initial[0]: CRYPTO[SH] ACK[1] 1978 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1979 <- 1-RTT[0]: STREAM[1, "..."] 1981 Figure 5: Example Handshake with Retry 1983 8.1.3. Address Validation for Future Connections 1985 A server MAY provide clients with an address validation token during 1986 one connection that can be used on a subsequent connection. Address 1987 validation is especially important with 0-RTT because a server 1988 potentially sends a significant amount of data to a client in 1989 response to 0-RTT data. 1991 The server uses the NEW_TOKEN frame Section 19.7 to provide the 1992 client with an address validation token that can be used to validate 1993 future connections. The client includes this token in Initial 1994 packets to provide address validation in a future connection. The 1995 client MUST include the token in all Initial packets it sends, unless 1996 a Retry replaces the token with a newer one. The client MUST NOT use 1997 the token provided in a Retry for future connections. Servers MAY 1998 discard any Initial packet that does not carry the expected token. 2000 Unlike the token that is created for a Retry packet, which is used 2001 immediately, the token sent in the NEW_TOKEN frame might be used 2002 after some period of time has passed. Thus, a token SHOULD have an 2003 expiration time, which could be either an explicit expiration time or 2004 an issued timestamp that can be used to dynamically calculate the 2005 expiration time. A server can store the expiration time or include 2006 it in an encrypted form in the token. 2008 A token issued with NEW_TOKEN MUST NOT include information that would 2009 allow values to be linked by an on-path observer to the connection on 2010 which it was issued, unless the values are encrypted. For example, 2011 it cannot include the previous connection ID or addressing 2012 information. A server MUST ensure that every NEW_TOKEN frame it 2013 sends is unique across all clients, with the exception of those sent 2014 to repair losses of previously sent NEW_TOKEN frames. Information 2015 that allows the server to distinguish between tokens from Retry and 2016 NEW_TOKEN MAY be accessible to entities other than the server. 2018 It is unlikely that the client port number is the same on two 2019 different connections; validating the port is therefore unlikely to 2020 be successful. 2022 A token received in a NEW_TOKEN frame is applicable to any server 2023 that the connection is considered authoritative for (e.g., server 2024 names included in the certificate). When connecting to a server for 2025 which the client retains an applicable and unused token, it SHOULD 2026 include that token in the Token field of its Initial packet. 2027 Including a token might allow the server to validate the client 2028 address without an additional round trip. A client MUST NOT include 2029 a token that is not applicable to the server that it is connecting 2030 to, unless the client has the knowledge that the server that issued 2031 the token and the server the client is connecting to are jointly 2032 managing the tokens. A client MAY use a token from any previous 2033 connection to that server. 2035 A token allows a server to correlate activity between the connection 2036 where the token was issued and any connection where it is used. 2037 Clients that want to break continuity of identity with a server MAY 2038 discard tokens provided using the NEW_TOKEN frame. In comparison, a 2039 token obtained in a Retry packet MUST be used immediately during the 2040 connection attempt and cannot be used in subsequent connection 2041 attempts. 2043 A client SHOULD NOT reuse a NEW_TOKEN token for different connection 2044 attempts. Reusing a token allows connections to be linked by 2045 entities on the network path; see Section 9.5. 2047 Clients might receive multiple tokens on a single connection. Aside 2048 from preventing linkability, any token can be used in any connection 2049 attempt. Servers can send additional tokens to either enable address 2050 validation for multiple connection attempts or to replace older 2051 tokens that might become invalid. For a client, this ambiguity means 2052 that sending the most recent unused token is most likely to be 2053 effective. Though saving and using older tokens has no negative 2054 consequences, clients can regard older tokens as being less likely be 2055 useful to the server for address validation. 2057 When a server receives an Initial packet with an address validation 2058 token, it MUST attempt to validate the token, unless it has already 2059 completed address validation. If the token is invalid then the 2060 server SHOULD proceed as if the client did not have a validated 2061 address, including potentially sending a Retry. If the validation 2062 succeeds, the server SHOULD then allow the handshake to proceed. 2064 Note: The rationale for treating the client as unvalidated rather 2065 than discarding the packet is that the client might have received 2066 the token in a previous connection using the NEW_TOKEN frame, and 2067 if the server has lost state, it might be unable to validate the 2068 token at all, leading to connection failure if the packet is 2069 discarded. A server SHOULD encode tokens provided with NEW_TOKEN 2070 frames and Retry packets differently, and validate the latter more 2071 strictly. 2073 In a stateless design, a server can use encrypted and authenticated 2074 tokens to pass information to clients that the server can later 2075 recover and use to validate a client address. Tokens are not 2076 integrated into the cryptographic handshake and so they are not 2077 authenticated. For instance, a client might be able to reuse a 2078 token. To avoid attacks that exploit this property, a server can 2079 limit its use of tokens to only the information needed to validate 2080 client addresses. 2082 Clients MAY use tokens obtained on one connection for any connection 2083 attempt using the same version. When selecting a token to use, 2084 clients do not need to consider other properties of the connection 2085 that is being attempted, including the choice of possible application 2086 protocols, session tickets, or other connection properties. 2088 Attackers could replay tokens to use servers as amplifiers in DDoS 2089 attacks. To protect against such attacks, servers SHOULD ensure that 2090 tokens sent in Retry packets are only accepted for a short time. 2091 Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need 2092 to be valid for longer, but SHOULD NOT be accepted multiple times in 2093 a short period. Servers are encouraged to allow tokens to be used 2094 only once, if possible. 2096 8.1.4. Address Validation Token Integrity 2098 An address validation token MUST be difficult to guess. Including a 2099 large enough random value in the token would be sufficient, but this 2100 depends on the server remembering the value it sends to clients. 2102 A token-based scheme allows the server to offload any state 2103 associated with validation to the client. For this design to work, 2104 the token MUST be covered by integrity protection against 2105 modification or falsification by clients. Without integrity 2106 protection, malicious clients could generate or guess values for 2107 tokens that would be accepted by the server. Only the server 2108 requires access to the integrity protection key for tokens. 2110 There is no need for a single well-defined format for the token 2111 because the server that generates the token also consumes it. A 2112 token could include information about the claimed client address (IP 2113 and port), a timestamp, and any other supplementary information the 2114 server will need to validate the token in the future. 2116 8.2. Path Validation 2118 Path validation is used during connection migration (see Section 9 2119 and Section 9.6) by the migrating endpoint to verify reachability of 2120 a peer from a new local address. In path validation, endpoints test 2121 reachability between a specific local address and a specific peer 2122 address, where an address is the two-tuple of IP address and port. 2124 Path validation tests that packets (PATH_CHALLENGE) can be both sent 2125 to and received (PATH_RESPONSE) from a peer on the path. 2126 Importantly, it validates that the packets received from the 2127 migrating endpoint do not carry a spoofed source address. 2129 Path validation can be used at any time by either endpoint. For 2130 instance, an endpoint might check that a peer is still in possession 2131 of its address after a period of quiescence. 2133 Path validation is not designed as a NAT traversal mechanism. Though 2134 the mechanism described here might be effective for the creation of 2135 NAT bindings that support NAT traversal, the expectation is that one 2136 or other peer is able to receive packets without first having sent a 2137 packet on that path. Effective NAT traversal needs additional 2138 synchronization mechanisms that are not provided here. 2140 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 2141 are used for path validation with other frames. In particular, an 2142 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 2143 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 2144 PATH_CHALLENGE. 2146 When probing a new path, an endpoint might want to ensure that its 2147 peer has an unused connection ID available for responses. The 2148 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 2149 same packet. This ensures that an unused connection ID will be 2150 available to the peer when sending a response. 2152 8.3. Initiating Path Validation 2154 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 2155 containing a random payload on the path to be validated. 2157 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 2158 packet loss. However, an endpoint SHOULD NOT send multiple 2159 PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT 2160 send a PATH_CHALLENGE more frequently than it would an Initial 2161 packet, ensuring that connection migration is no more load on a new 2162 path than establishing a new connection. 2164 The endpoint MUST use unpredictable data in every PATH_CHALLENGE 2165 frame so that it can associate the peer's response with the 2166 corresponding PATH_CHALLENGE. 2168 8.4. Path Validation Responses 2170 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 2171 immediately by echoing the data contained in the PATH_CHALLENGE frame 2172 in a PATH_RESPONSE frame. 2174 An endpoint MUST NOT send more than one PATH_RESPONSE frame in 2175 response to one PATH_CHALLENGE frame (see Section 13.3). The peer is 2176 expected to send more PATH_CHALLENGE frames as necessary to evoke 2177 additional PATH_RESPONSE frames. 2179 8.5. Successful Path Validation 2181 A new address is considered valid when a PATH_RESPONSE frame is 2182 received that contains the data that was sent in a previous 2183 PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing 2184 a PATH_CHALLENGE frame is not adequate validation, since the 2185 acknowledgment can be spoofed by a malicious peer. 2187 Note that receipt on a different local address does not result in 2188 path validation failure, as it might be a result of a forwarded 2189 packet (see Section 9.3.3) or misrouting. It is possible that a 2190 valid PATH_RESPONSE might be received in the future. 2192 8.6. Failed Path Validation 2194 Path validation only fails when the endpoint attempting to validate 2195 the path abandons its attempt to validate the path. 2197 Endpoints SHOULD abandon path validation based on a timer. When 2198 setting this timer, implementations are cautioned that the new path 2199 could have a longer round-trip time than the original. A value of 2200 three times the larger of the current Probe Timeout (PTO) or the 2201 initial timeout (that is, 2*kInitialRtt) as defined in 2202 [QUIC-RECOVERY] is RECOMMENDED. That is: 2204 validation_timeout = max(3*PTO, 6*kInitialRtt) 2206 Note that the endpoint might receive packets containing other frames 2207 on the new path, but a PATH_RESPONSE frame with appropriate data is 2208 required for path validation to succeed. 2210 When an endpoint abandons path validation, it determines that the 2211 path is unusable. This does not necessarily imply a failure of the 2212 connection - endpoints can continue sending packets over other paths 2213 as appropriate. If no paths are available, an endpoint can wait for 2214 a new path to become available or close the connection. 2216 A path validation might be abandoned for other reasons besides 2217 failure. Primarily, this happens if a connection migration to a new 2218 path is initiated while a path validation on the old path is in 2219 progress. 2221 9. Connection Migration 2223 The use of a connection ID allows connections to survive changes to 2224 endpoint addresses (IP address and port), such as those caused by an 2225 endpoint migrating to a new network. This section describes the 2226 process by which an endpoint migrates to a new address. 2228 The design of QUIC relies on endpoints retaining a stable address for 2229 the duration of the handshake. An endpoint MUST NOT initiate 2230 connection migration before the handshake is confirmed, as defined in 2231 section 4.1.2 of [QUIC-TLS]. 2233 An endpoint also MUST NOT send packets from a different local 2234 address, actively initiating migration, if the peer sent the 2235 "disable_active_migration" transport parameter during the handshake. 2236 An endpoint which has sent this transport parameter, but detects that 2237 a peer has nonetheless migrated to a different network MUST either 2238 drop the incoming packets on that path without generating a stateless 2239 reset or proceed with path validation and allow the peer to migrate. 2240 Generating a stateless reset or closing the connection would allow 2241 third parties in the network to cause connections to close by 2242 spoofing or otherwise manipulating observed traffic. 2244 Not all changes of peer address are intentional, or active, 2245 migrations. The peer could experience NAT rebinding: a change of 2246 address due to a middlebox, usually a NAT, allocating a new outgoing 2247 port or even a new outgoing IP address for a flow. An endpoint MUST 2248 perform path validation (Section 8.2) if it detects any change to a 2249 peer's address, unless it has previously validated that address. 2251 When an endpoint has no validated path on which to send packets, it 2252 MAY discard connection state. An endpoint capable of connection 2253 migration MAY wait for a new path to become available before 2254 discarding connection state. 2256 This document limits migration of connections to new client 2257 addresses, except as described in Section 9.6. Clients are 2258 responsible for initiating all migrations. Servers do not send non- 2259 probing packets (see Section 9.1) toward a client address until they 2260 see a non-probing packet from that address. If a client receives 2261 packets from an unknown server address, the client MUST discard these 2262 packets. 2264 9.1. Probing a New Path 2266 An endpoint MAY probe for peer reachability from a new local address 2267 using path validation Section 8.2 prior to migrating the connection 2268 to the new local address. Failure of path validation simply means 2269 that the new path is not usable for this connection. Failure to 2270 validate a path does not cause the connection to end unless there are 2271 no valid alternative paths available. 2273 An endpoint uses a new connection ID for probes sent from a new local 2274 address; see Section 9.5 for further discussion. An endpoint that 2275 uses a new local address needs to ensure that at least one new 2276 connection ID is available at the peer. That can be achieved by 2277 including a NEW_CONNECTION_ID frame in the probe. 2279 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2280 is probing for reachability on a path. An endpoint sends a 2281 PATH_RESPONSE in response as per Section 8.2. 2283 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2284 are "probing frames", and all other frames are "non-probing frames". 2285 A packet containing only probing frames is a "probing packet", and a 2286 packet containing any other frame is a "non-probing packet". 2288 9.2. Initiating Connection Migration 2290 An endpoint can migrate a connection to a new local address by 2291 sending packets containing non-probing frames from that address. 2293 Each endpoint validates its peer's address during connection 2294 establishment. Therefore, a migrating endpoint can send to its peer 2295 knowing that the peer is willing to receive at the peer's current 2296 address. Thus an endpoint can migrate to a new local address without 2297 first validating the peer's address. 2299 When migrating, the new path might not support the endpoint's current 2300 sending rate. Therefore, the endpoint resets its congestion 2301 controller, as described in Section 9.4. 2303 The new path might not have the same ECN capability. Therefore, the 2304 endpoint verifies ECN capability as described in Section 13.4. 2306 Receiving acknowledgments for data sent on the new path serves as 2307 proof of the peer's reachability from the new address. Note that 2308 since acknowledgments may be received on any path, return 2309 reachability on the new path is not established. To establish return 2310 reachability on the new path, an endpoint MAY concurrently initiate 2311 path validation Section 8.2 on the new path. 2313 9.3. Responding to Connection Migration 2315 Receiving a packet from a new peer address containing a non-probing 2316 frame indicates that the peer has migrated to that address. 2318 In response to such a packet, an endpoint MUST start sending 2319 subsequent packets to the new peer address and MUST initiate path 2320 validation (Section 8.2) to verify the peer's ownership of the 2321 unvalidated address. 2323 An endpoint MAY send data to an unvalidated peer address, but it MUST 2324 protect against potential attacks as described in Section 9.3.1 and 2325 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2326 that address has been seen recently. In particular, if an endpoint 2327 returns to a previously-validated path after detecting some form of 2328 spurious migration, skipping address validation and restoring loss 2329 detection and congestion state can reduce the performance impact of 2330 the attack. 2332 An endpoint only changes the address that it sends packets to in 2333 response to the highest-numbered non-probing packet. This ensures 2334 that an endpoint does not send packets to an old peer address in the 2335 case that it receives reordered packets. 2337 After changing the address to which it sends non-probing packets, an 2338 endpoint could abandon any path validation for other addresses. 2340 Receiving a packet from a new peer address might be the result of a 2341 NAT rebinding at the peer. 2343 After verifying a new client address, the server SHOULD send new 2344 address validation tokens (Section 8) to the client. 2346 9.3.1. Peer Address Spoofing 2348 It is possible that a peer is spoofing its source address to cause an 2349 endpoint to send excessive amounts of data to an unwilling host. If 2350 the endpoint sends significantly more data than the spoofing peer, 2351 connection migration might be used to amplify the volume of data that 2352 an attacker can generate toward a victim. 2354 As described in Section 9.3, an endpoint is required to validate a 2355 peer's new address to confirm the peer's possession of the new 2356 address. Until a peer's address is deemed valid, an endpoint MUST 2357 limit the rate at which it sends data to this address. The endpoint 2358 MUST NOT send more than a minimum congestion window's worth of data 2359 per estimated round-trip time (kMinimumWindow, as defined in 2360 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2361 being used for a denial of service attack against an unsuspecting 2362 victim. Note that since the endpoint will not have any round-trip 2363 time measurements to this address, the estimate SHOULD be the default 2364 initial value (see [QUIC-RECOVERY]). 2366 If an endpoint skips validation of a peer address as described in 2367 Section 9.3, it does not need to limit its sending rate. 2369 9.3.2. On-Path Address Spoofing 2371 An on-path attacker could cause a spurious connection migration by 2372 copying and forwarding a packet with a spoofed address such that it 2373 arrives before the original packet. The packet with the spoofed 2374 address will be seen to come from a migrating connection, and the 2375 original packet will be seen as a duplicate and dropped. After a 2376 spurious migration, validation of the source address will fail 2377 because the entity at the source address does not have the necessary 2378 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2379 that is sent to it even if it wanted to. 2381 To protect the connection from failing due to such a spurious 2382 migration, an endpoint MUST revert to using the last validated peer 2383 address when validation of a new peer address fails. 2385 If an endpoint has no state about the last validated peer address, it 2386 MUST close the connection silently by discarding all connection 2387 state. This results in new packets on the connection being handled 2388 generically. For instance, an endpoint MAY send a stateless reset in 2389 response to any further incoming packets. 2391 Note that receipt of packets with higher packet numbers from the 2392 legitimate peer address will trigger another connection migration. 2393 This will cause the validation of the address of the spurious 2394 migration to be abandoned. 2396 9.3.3. Off-Path Packet Forwarding 2398 An off-path attacker that can observe packets might forward copies of 2399 genuine packets to endpoints. If the copied packet arrives before 2400 the genuine packet, this will appear as a NAT rebinding. Any genuine 2401 packet will be discarded as a duplicate. If the attacker is able to 2402 continue forwarding packets, it might be able to cause migration to a 2403 path via the attacker. This places the attacker on path, giving it 2404 the ability to observe or drop all subsequent packets. 2406 Unlike the attack described in Section 9.3.2, the attacker can ensure 2407 that the new path is successfully validated. 2409 This style of attack relies on the attacker using a path that is 2410 approximately as fast as the direct path between endpoints. The 2411 attack is more reliable if relatively few packets are sent or if 2412 packet loss coincides with the attempted attack. 2414 A non-probing packet received on the original path that increases the 2415 maximum received packet number will cause the endpoint to move back 2416 to that path. Eliciting packets on this path increases the 2417 likelihood that the attack is unsuccessful. Therefore, mitigation of 2418 this attack relies on triggering the exchange of packets. 2420 In response to an apparent migration, endpoints MUST validate the 2421 previously active path using a PATH_CHALLENGE frame. This induces 2422 the sending of new packets on that path. If the path is no longer 2423 viable, the validation attempt will time out and fail; if the path is 2424 viable, but no longer desired, the validation will succeed, but only 2425 results in probing packets being sent on the path. 2427 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2428 send a non-probing packet in response. If the non-probing packet 2429 arrives before any copy made by an attacker, this results in the 2430 connection being migrated back to the original path. Any subsequent 2431 migration to another path restarts this entire process. 2433 This defense is imperfect, but this is not considered a serious 2434 problem. If the path via the attack is reliably faster than the 2435 original path despite multiple attempts to use that original path, it 2436 is not possible to distinguish between attack and an improvement in 2437 routing. 2439 An endpoint could also use heuristics to improve detection of this 2440 style of attack. For instance, NAT rebinding is improbable if 2441 packets were recently received on the old path, similarly rebinding 2442 is rare on IPv6 paths. Endpoints can also look for duplicated 2443 packets. Conversely, a change in connection ID is more likely to 2444 indicate an intentional migration rather than an attack. 2446 9.4. Loss Detection and Congestion Control 2448 The capacity available on the new path might not be the same as the 2449 old path. Packets sent on the old path MUST NOT contribute to 2450 congestion control or RTT estimation for the new path. 2452 On confirming a peer's ownership of its new address, an endpoint MUST 2453 immediately reset the congestion controller and round-trip time 2454 estimator for the new path to initial values (see Sections A.3 and 2455 B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send 2456 rate or round-trip time estimate is valid for the new path. For 2457 instance, an endpoint might infer that a change in only the client's 2458 port number is indicative of a NAT rebinding, meaning that the new 2459 path is likely to have similar bandwidth and round-trip time. 2460 However, this determination will be imperfect. If the determination 2461 is incorrect, the congestion controller and the RTT estimator are 2462 expected to adapt to the new path. Generally, implementations are 2463 advised to be cautious when using previous values on a new path. 2465 There may be apparent reordering at the receiver when an endpoint 2466 sends data and probes from/to multiple addresses during the migration 2467 period, since the two resulting paths may have different round-trip 2468 times. A receiver of packets on multiple paths will still send ACK 2469 frames covering all received packets. 2471 While multiple paths might be used during connection migration, a 2472 single congestion control context and a single loss recovery context 2473 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2474 endpoint might delay switching to a new congestion control context 2475 until it is confirmed that an old path is no longer needed (such as 2476 the case in Section 9.3.3). 2478 A sender can make exceptions for probe packets so that their loss 2479 detection is independent and does not unduly cause the congestion 2480 controller to reduce its sending rate. An endpoint might set a 2481 separate timer when a PATH_CHALLENGE is sent, which is cancelled if 2482 the corresponding PATH_RESPONSE is received. If the timer fires 2483 before the PATH_RESPONSE is received, the endpoint might send a new 2484 PATH_CHALLENGE, and restart the timer for a longer period of time. 2485 This timer SHOULD be set as described in Section 5.3 of 2486 [QUIC-RECOVERY] and MUST NOT be more aggressive. 2488 9.5. Privacy Implications of Connection Migration 2490 Using a stable connection ID on multiple network paths allows a 2491 passive observer to correlate activity between those paths. An 2492 endpoint that moves between networks might not wish to have their 2493 activity correlated by any entity other than their peer, so different 2494 connection IDs are used when sending from different local addresses, 2495 as discussed in Section 5.1. For this to be effective endpoints need 2496 to ensure that connection IDs they provide cannot be linked by any 2497 other entity. 2499 At any time, endpoints MAY change the Destination Connection ID they 2500 send to a value that has not been used on another path. 2502 An endpoint MUST use a new connection ID if it initiates connection 2503 migration as described in Section 9.2 or probes a new network path as 2504 described in Section 9.1. An endpoint MUST use a new connection ID 2505 in response to a change in the address of a peer if the packet with 2506 the new peer address uses an active connection ID that has not been 2507 previously used by the peer. 2509 Using different connection IDs for packets sent in both directions on 2510 each new network path eliminates the use of the connection ID for 2511 linking packets from the same connection across different network 2512 paths. Header protection ensures that packet numbers cannot be used 2513 to correlate activity. This does not prevent other properties of 2514 packets, such as timing and size, from being used to correlate 2515 activity. 2517 Unintentional changes in path without a change in connection ID are 2518 possible. For example, after a period of network inactivity, NAT 2519 rebinding might cause packets to be sent on a new path when the 2520 client resumes sending. 2522 A client might wish to reduce linkability by employing a new 2523 connection ID and source UDP port when sending traffic after a period 2524 of inactivity. Changing the UDP port from which it sends packets at 2525 the same time might cause the packet to appear as a connection 2526 migration. This ensures that the mechanisms that support migration 2527 are exercised even for clients that don't experience NAT rebindings 2528 or genuine migrations. Changing port number can cause a peer to 2529 reset its congestion state (see Section 9.4), so the port SHOULD only 2530 be changed infrequently. 2532 An endpoint that exhausts available connection IDs cannot probe new 2533 paths or initiate migration, nor can it respond to probes or attempts 2534 by its peer to migrate. To ensure that migration is possible and 2535 packets sent on different paths cannot be correlated, endpoints 2536 SHOULD provide new connection IDs before peers migrate; see 2537 Section 5.1.1. If a peer might have exhausted available connection 2538 IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in 2539 all packets sent on a new network path. 2541 9.6. Server's Preferred Address 2543 QUIC allows servers to accept connections on one IP address and 2544 attempt to transfer these connections to a more preferred address 2545 shortly after the handshake. This is particularly useful when 2546 clients initially connect to an address shared by multiple servers 2547 but would prefer to use a unicast address to ensure connection 2548 stability. This section describes the protocol for migrating a 2549 connection to a preferred server address. 2551 Migrating a connection to a new server address mid-connection is left 2552 for future work. If a client receives packets from a new server 2553 address not indicated by the preferred_address transport parameter, 2554 the client SHOULD discard these packets. 2556 9.6.1. Communicating a Preferred Address 2558 A server conveys a preferred address by including the 2559 preferred_address transport parameter in the TLS handshake. 2561 Servers MAY communicate a preferred address of each address family 2562 (IPv4 and IPv6) to allow clients to pick the one most suited to their 2563 network attachment. 2565 Once the handshake is finished, the client SHOULD select one of the 2566 two server's preferred addresses and initiate path validation (see 2567 Section 8.2) of that address using the connection ID provided in the 2568 preferred_address transport parameter. 2570 If path validation succeeds, the client SHOULD immediately begin 2571 sending all future packets to the new server address using the new 2572 connection ID and discontinue use of the old server address. If path 2573 validation fails, the client MUST continue sending all future packets 2574 to the server's original IP address. 2576 9.6.2. Responding to Connection Migration 2578 A server might receive a packet addressed to its preferred IP address 2579 at any time after it accepts a connection. If this packet contains a 2580 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2581 Section 8.2. The server MUST send other non-probing frames from its 2582 original address until it receives a non-probing packet from the 2583 client at its preferred address and until the server has validated 2584 the new path. 2586 The server MUST probe on the path toward the client from its 2587 preferred address. This helps to guard against spurious migration 2588 initiated by an attacker. 2590 Once the server has completed its path validation and has received a 2591 non-probing packet with a new largest packet number on its preferred 2592 address, the server begins sending non-probing packets to the client 2593 exclusively from its preferred IP address. It SHOULD drop packets 2594 for this connection received on the old IP address, but MAY continue 2595 to process delayed packets. 2597 9.6.3. Interaction of Client Migration and Preferred Address 2599 A client might need to perform a connection migration before it has 2600 migrated to the server's preferred address. In this case, the client 2601 SHOULD perform path validation to both the original and preferred 2602 server address from the client's new address concurrently. 2604 If path validation of the server's preferred address succeeds, the 2605 client MUST abandon validation of the original address and migrate to 2606 using the server's preferred address. If path validation of the 2607 server's preferred address fails but validation of the server's 2608 original address succeeds, the client MAY migrate to its new address 2609 and continue sending to the server's original address. 2611 If the connection to the server's preferred address is not from the 2612 same client address, the server MUST protect against potential 2613 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2614 to intentional simultaneous migration, this might also occur because 2615 the client's access network used a different NAT binding for the 2616 server's preferred address. 2618 Servers SHOULD initiate path validation to the client's new address 2619 upon receiving a probe packet from a different address. Servers MUST 2620 NOT send more than a minimum congestion window's worth of non-probing 2621 packets to the new address before path validation is complete. 2623 A client that migrates to a new address SHOULD use a preferred 2624 address from the same address family for the server. 2626 9.7. Use of IPv6 Flow-Label and Migration 2628 Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label 2629 in compliance with [RFC6437], unless the local API does not allow 2630 setting IPv6 flow labels. 2632 The IPv6 flow label SHOULD be a pseudo-random function of the source 2633 and destination addresses, source and destination UDP ports, and the 2634 destination CID. The flow label generation MUST be designed to 2635 minimize the chances of linkability with a previously used flow 2636 label, as this would enable correlating activity on multiple paths 2637 (see Section 9.5). 2639 A possible implementation is to compute the flow label as a 2640 cryptographic hash function of the source and destination addresses, 2641 source and destination UDP ports, destination CID, and a local 2642 secret. 2644 10. Connection Termination 2646 An established QUIC connection can be terminated in one of three 2647 ways: 2649 * idle timeout (Section 10.2) 2651 * immediate close (Section 10.3) 2653 * stateless reset (Section 10.4) 2655 An endpoint MAY discard connection state if it does not have a 2656 validated path on which it can send packets (see Section 8.2). 2658 10.1. Closing and Draining Connection States 2660 The closing and draining connection states exist to ensure that 2661 connections close cleanly and that delayed or reordered packets are 2662 properly discarded. These states SHOULD persist for at least three 2663 times the current Probe Timeout (PTO) interval as defined in 2664 [QUIC-RECOVERY]. 2666 An endpoint enters a closing period after initiating an immediate 2667 close (Section 10.3). While closing, an endpoint MUST NOT send 2668 packets unless they contain a CONNECTION_CLOSE frame (see 2669 Section 10.3 for details). An endpoint retains only enough 2670 information to generate a packet containing a CONNECTION_CLOSE frame 2671 and to identify packets as belonging to the connection. The 2672 endpoint's selected connection ID and the QUIC version are sufficient 2673 information to identify packets for a closing connection; an endpoint 2674 can discard all other connection state. An endpoint MAY retain 2675 packet protection keys for incoming packets to allow it to read and 2676 process a CONNECTION_CLOSE frame. 2678 The draining state is entered once an endpoint receives a signal that 2679 its peer is closing or draining. While otherwise identical to the 2680 closing state, an endpoint in the draining state MUST NOT send any 2681 packets. Retaining packet protection keys is unnecessary once a 2682 connection is in the draining state. 2684 An endpoint MAY transition from the closing period to the draining 2685 period if it receives a CONNECTION_CLOSE frame or stateless reset, 2686 both of which indicate that the peer is also closing or draining. 2687 The draining period SHOULD end when the closing period would have 2688 ended. In other words, the endpoint can use the same end time, but 2689 cease retransmission of the closing packet. 2691 Disposing of connection state prior to the end of the closing or 2692 draining period could cause delayed or reordered packets to generate 2693 an unnecessary stateless reset. Endpoints that have some alternative 2694 means to ensure that late-arriving packets on the connection do not 2695 induce a response, such as those that are able to close the UDP 2696 socket, MAY use an abbreviated draining period which can allow for 2697 faster resource recovery. Servers that retain an open socket for 2698 accepting new connections SHOULD NOT exit the closing or draining 2699 period early. 2701 Once the closing or draining period has ended, an endpoint SHOULD 2702 discard all connection state. This results in new packets on the 2703 connection being handled generically. For instance, an endpoint MAY 2704 send a stateless reset in response to any further incoming packets. 2706 The draining and closing periods do not apply when a stateless reset 2707 (Section 10.4) is sent. 2709 An endpoint is not expected to handle key updates when it is closing 2710 or draining. A key update might prevent the endpoint from moving 2711 from the closing state to draining, but it otherwise has no impact. 2713 While in the closing period, an endpoint could receive packets from a 2714 new source address, indicating a connection migration (Section 9). 2715 An endpoint in the closing state MUST strictly limit the number of 2716 packets it sends to this new address until the address is validated 2717 (see Section 8.2). A server in the closing state MAY instead choose 2718 to discard packets received from a new source address. 2720 10.2. Idle Timeout 2722 If the idle timeout is enabled by either peer, a connection is 2723 silently closed and its state is discarded when it remains idle for 2724 longer than the minimum of the max_idle_timeouts (see Section 18.2) 2725 and three times the current Probe Timeout (PTO). 2727 Each endpoint advertises a max_idle_timeout, but the effective value 2728 at an endpoint is computed as the minimum of the two advertised 2729 values. By announcing a max_idle_timeout, an endpoint commits to 2730 initiating an immediate close (Section 10.3) if it abandons the 2731 connection prior to the effective value. 2733 An endpoint restarts its idle timer when a packet from its peer is 2734 received and processed successfully. The idle timer is also 2735 restarted when sending an ack-eliciting packet (see [QUIC-RECOVERY]), 2736 but only if no other ack-eliciting packets have been sent since last 2737 receiving a packet. Restarting when sending packets ensures that 2738 connections do not prematurely time out when initiating new activity. 2739 An endpoint might need to send packets to avoid an idle timeout if it 2740 is unable to send application data due to being blocked on flow 2741 control limits; see Section 4. 2743 An endpoint that sends packets near the end of the idle timeout 2744 period risks having those packets discarded if its peer enters the 2745 draining state before the packets arrive. If a peer could time out 2746 within a Probe Timeout (PTO; see Section 6.6 of [QUIC-RECOVERY]), it 2747 is advisable to test for liveness before sending any data that cannot 2748 be retried safely. Note that it is likely that only applications or 2749 application protocols will know what information can be retried. 2751 10.3. Immediate Close 2753 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 2754 terminate the connection immediately. A CONNECTION_CLOSE frame 2755 causes all streams to immediately become closed; open streams can be 2756 assumed to be implicitly reset. 2758 After sending a CONNECTION_CLOSE frame, an endpoint immediately 2759 enters the closing state. 2761 During the closing period, an endpoint that sends a CONNECTION_CLOSE 2762 frame SHOULD respond to any incoming packet that can be decrypted 2763 with another packet containing a CONNECTION_CLOSE frame. Such an 2764 endpoint SHOULD limit the number of packets it generates containing a 2765 CONNECTION_CLOSE frame. For instance, an endpoint could wait for a 2766 progressively increasing number of received packets or amount of time 2767 before responding to a received packet. 2769 An endpoint is allowed to drop the packet protection keys when 2770 entering the closing period (Section 10.1) and send a packet 2771 containing a CONNECTION_CLOSE in response to any UDP datagram that is 2772 received. However, an endpoint without the packet protection keys 2773 cannot identify and discard invalid packets. To avoid creating an 2774 unwitting amplification attack, such endpoints MUST reduce the 2775 frequency with which it sends packets containing a CONNECTION_CLOSE 2776 frame. To minimize the state that an endpoint maintains for a 2777 closing connection, endpoints MAY send the exact same packet. 2779 Note: Allowing retransmission of a closing packet contradicts other 2780 advice in this document that recommends the creation of new packet 2781 numbers for every packet. Sending new packet numbers is primarily 2782 of advantage to loss recovery and congestion control, which are 2783 not expected to be relevant for a closed connection. 2784 Retransmitting the final packet requires less state. 2786 New packets from unverified addresses could be used to create an 2787 amplification attack (see Section 8). To avoid this, endpoints MUST 2788 either limit transmission of CONNECTION_CLOSE frames to validated 2789 addresses or drop packets without response if the response would be 2790 more than three times larger than the received packet. 2792 After receiving a CONNECTION_CLOSE frame, endpoints enter the 2793 draining state. An endpoint that receives a CONNECTION_CLOSE frame 2794 MAY send a single packet containing a CONNECTION_CLOSE frame before 2795 entering the draining state, using a CONNECTION_CLOSE frame and a 2796 NO_ERROR code if appropriate. An endpoint MUST NOT send further 2797 packets, which could result in a constant exchange of 2798 CONNECTION_CLOSE frames until the closing period on either peer 2799 ended. 2801 An immediate close can be used after an application protocol has 2802 arranged to close a connection. This might be after the application 2803 protocols negotiates a graceful shutdown. The application protocol 2804 exchanges whatever messages that are needed to cause both endpoints 2805 to agree to close the connection, after which the application 2806 requests that the connection be closed. The application protocol can 2807 use a CONNECTION_CLOSE frame with an appropriate error code to signal 2808 closure. 2810 10.3.1. Immediate Close During the Handshake 2812 When sending CONNECTION_CLOSE, the goal is to ensure that the peer 2813 will process the frame. Generally, this means sending the frame in a 2814 packet with the highest level of packet protection to avoid the 2815 packet being discarded. After the handshake is confirmed (see 2816 Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any 2817 CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to 2818 confirming the handshake, it is possible that more advanced packet 2819 protection keys are not available to the peer, so the frame MAY be 2820 replicated in a packet that uses a lower packet protection level. 2822 A client will always know whether the server has Handshake keys (see 2823 Section 17.2.2.1), but it is possible that a server does not know 2824 whether the client has Handshake keys. Under these circumstances, a 2825 server SHOULD send a CONNECTION_CLOSE frame in both Handshake and 2826 Initial packets to ensure that at least one of them is processable by 2827 the client. Similarly, a peer might be unable to read 1-RTT packets, 2828 so an endpoint SHOULD send CONNECTION_CLOSE in Handshake and 1-RTT 2829 packets prior to confirming the handshake. These packets can be 2830 coalesced into a single UDP datagram; see Section 12.2. 2832 An endpoint might send a CONNECTION_CLOSE frame in an Initial packet 2833 or in response to unauthenticated information received in Initial or 2834 Handshake packets. Such an immediate close might expose legitimate 2835 connections to a denial of service. QUIC does not include defensive 2836 measures for on-path attacks during the handshake; see Section 21.1. 2837 However, at the cost of reducing feedback about errors for legitimate 2838 peers, some forms of denial of service can be made more difficult for 2839 an attacker if endpoints discard illegal packets rather than 2840 terminating a connection with CONNECTION_CLOSE. For this reason, 2841 endpoints MAY discard packets rather than immediately close if errors 2842 are detected in packets that lack authentication. 2844 An endpoint that has not established state, such as a server that 2845 detects an error in an Initial packet, does not enter the closing 2846 state. An endpoint that has no state for the connection does not 2847 enter a closing or draining period on sending a CONNECTION_CLOSE 2848 frame. 2850 10.4. Stateless Reset 2852 A stateless reset is provided as an option of last resort for an 2853 endpoint that does not have access to the state of a connection. A 2854 crash or outage might result in peers continuing to send data to an 2855 endpoint that is unable to properly continue the connection. An 2856 endpoint MAY send a stateless reset in response to receiving a packet 2857 that it cannot associate with an active connection. 2859 A stateless reset is not appropriate for signaling error conditions. 2860 An endpoint that wishes to communicate a fatal connection error MUST 2861 use a CONNECTION_CLOSE frame if it has sufficient state to do so. 2863 To support this process, a token is sent by endpoints. The token is 2864 carried in the Stateless Reset Token field of a NEW_CONNECTION_ID 2865 frame. Servers can also specify a stateless_reset_token transport 2866 parameter during the handshake that applies to the connection ID that 2867 it selected during the handshake; clients cannot use this transport 2868 parameter because their transport parameters don't have 2869 confidentiality protection. These tokens are protected by 2870 encryption, so only client and server know their value. Tokens are 2871 invalidated when their associated connection ID is retired via a 2872 RETIRE_CONNECTION_ID frame (Section 19.16). 2874 An endpoint that receives packets that it cannot process sends a 2875 packet in the following layout: 2877 0 1 2 3 2878 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 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 |0|1| Unpredictable Bits (38 ..) ... 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 | | 2883 + + 2884 | | 2885 + Stateless Reset Token (128) + 2886 | | 2887 + + 2888 | | 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 Figure 6: Stateless Reset Packet 2893 This design ensures that a stateless reset packet is - to the extent 2894 possible - indistinguishable from a regular packet with a short 2895 header. 2897 A stateless reset uses an entire UDP datagram, starting with the 2898 first two bits of the packet header. The remainder of the first byte 2899 and an arbitrary number of bytes following it that are set to 2900 unpredictable values. The last 16 bytes of the datagram contain a 2901 Stateless Reset Token. 2903 To entities other than its intended recipient, a stateless reset will 2904 appear to be a packet with a short header. For the stateless reset 2905 to appear as a valid QUIC packet, the Unpredictable Bits field needs 2906 to include at least 38 bits of data (or 5 bytes, less the two fixed 2907 bits). 2909 A minimum size of 21 bytes does not guarantee that a stateless reset 2910 is difficult to distinguish from other packets if the recipient 2911 requires the use of a connection ID. To prevent a resulting 2912 stateless reset from being trivially distinguishable from a valid 2913 packet, all packets sent by an endpoint SHOULD be padded to at least 2914 22 bytes longer than the minimum connection ID that the endpoint 2915 might use. An endpoint that sends a stateless reset in response to 2916 packet that is 43 bytes or less in length SHOULD send a stateless 2917 reset that is one byte shorter than the packet it responds to. 2919 These values assume that the Stateless Reset Token is the same as the 2920 minimum expansion of the packet protection AEAD. Additional 2921 unpredictable bytes are necessary if the endpoint could have 2922 negotiated a packet protection scheme with a larger minimum 2923 expansion. 2925 An endpoint MUST NOT send a stateless reset that is three times or 2926 more larger than the packet it receives to avoid being used for 2927 amplification. Section 10.4.3 describes additional limits on 2928 stateless reset size. 2930 Endpoints MUST discard packets that are too small to be valid QUIC 2931 packets. With the set of AEAD functions defined in [QUIC-TLS], 2932 packets that are smaller than 21 bytes are never valid. 2934 Endpoints MUST send stateless reset packets formatted as a packet 2935 with a short header. However, endpoints MUST treat any packet ending 2936 in a valid stateless reset token as a stateless reset, as other QUIC 2937 versions might allow the use of a long header. 2939 An endpoint MAY send a stateless reset in response to a packet with a 2940 long header. Sending a stateless reset is not effective prior to the 2941 stateless reset token being available to a peer. In this QUIC 2942 version, packets with a long header are only used during connection 2943 establishment. Because the stateless reset token is not available 2944 until connection establishment is complete or near completion, 2945 ignoring an unknown packet with a long header might be as effective 2946 as sending a stateless reset. 2948 An endpoint cannot determine the Source Connection ID from a packet 2949 with a short header, therefore it cannot set the Destination 2950 Connection ID in the stateless reset packet. The Destination 2951 Connection ID will therefore differ from the value used in previous 2952 packets. A random Destination Connection ID makes the connection ID 2953 appear to be the result of moving to a new connection ID that was 2954 provided using a NEW_CONNECTION_ID frame (Section 19.15). 2956 Using a randomized connection ID results in two problems: 2958 * The packet might not reach the peer. If the Destination 2959 Connection ID is critical for routing toward the peer, then this 2960 packet could be incorrectly routed. This might also trigger 2961 another Stateless Reset in response; see Section 10.4.3. A 2962 Stateless Reset that is not correctly routed is an ineffective 2963 error detection and recovery mechanism. In this case, endpoints 2964 will need to rely on other methods - such as timers - to detect 2965 that the connection has failed. 2967 * The randomly generated connection ID can be used by entities other 2968 than the peer to identify this as a potential stateless reset. An 2969 endpoint that occasionally uses different connection IDs might 2970 introduce some uncertainty about this. 2972 This stateless reset design is specific to QUIC version 1. An 2973 endpoint that supports multiple versions of QUIC needs to generate a 2974 stateless reset that will be accepted by peers that support any 2975 version that the endpoint might support (or might have supported 2976 prior to losing state). Designers of new versions of QUIC need to be 2977 aware of this and either reuse this design, or use a portion of the 2978 packet other than the last 16 bytes for carrying data. 2980 10.4.1. Detecting a Stateless Reset 2982 An endpoint detects a potential stateless reset using the trailing 16 2983 bytes of the UDP datagram. An endpoint remembers all Stateless Reset 2984 Tokens associated with the connection IDs and remote addresses for 2985 datagrams it has recently sent. This includes Stateless Reset Tokens 2986 from NEW_CONNECTION_ID frames and the server's transport parameters 2987 but excludes Stateless Reset Tokens associated with connection IDs 2988 that are either unused or retired. The endpoint identifies a 2989 received datagram as a stateless reset by comparing the last 16 bytes 2990 of the datagram with all Stateless Reset Tokens associated with the 2991 remote address on which the datagram was received. 2993 This comparison can be performed for every inbound datagram. 2994 Endpoints MAY skip this check if any packet from a datagram is 2995 successfully processed. However, the comparison MUST be performed 2996 when the first packet in an incoming datagram either cannot be 2997 associated with a connection, or cannot be decrypted. 2999 An endpoint MUST NOT check for any Stateless Reset Tokens associated 3000 with connection IDs it has not used or for connection IDs that have 3001 been retired. 3003 When comparing a datagram to Stateless Reset Token values, endpoints 3004 MUST perform the comparison without leaking information about the 3005 value of the token. For example, performing this comparison in 3006 constant time protects the value of individual Stateless Reset Tokens 3007 from information leakage through timing side channels. Another 3008 approach would be to store and compare the transformed values of 3009 Stateless Reset Tokens instead of the raw token values, where the 3010 transformation is defined as a cryptographically-secure pseudo-random 3011 function using a secret key (e.g., block cipher, HMAC [RFC2104]). An 3012 endpoint is not expected to protect information about whether a 3013 packet was successfully decrypted, or the number of valid Stateless 3014 Reset Tokens. 3016 If the last 16 bytes of the datagram are identical in value to a 3017 Stateless Reset Token, the endpoint MUST enter the draining period 3018 and not send any further packets on this connection. 3020 10.4.2. Calculating a Stateless Reset Token 3022 The stateless reset token MUST be difficult to guess. In order to 3023 create a Stateless Reset Token, an endpoint could randomly generate 3024 [RFC4086] a secret for every connection that it creates. However, 3025 this presents a coordination problem when there are multiple 3026 instances in a cluster or a storage problem for an endpoint that 3027 might lose state. Stateless reset specifically exists to handle the 3028 case where state is lost, so this approach is suboptimal. 3030 A single static key can be used across all connections to the same 3031 endpoint by generating the proof using a second iteration of a 3032 preimage-resistant function that takes a static key and the 3033 connection ID chosen by the endpoint (see Section 5.1) as input. An 3034 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 3035 connection_id)) or HKDF [RFC5869] (for example, using the static key 3036 as input keying material, with the connection ID as salt). The 3037 output of this function is truncated to 16 bytes to produce the 3038 Stateless Reset Token for that connection. 3040 An endpoint that loses state can use the same method to generate a 3041 valid Stateless Reset Token. The connection ID comes from the packet 3042 that the endpoint receives. 3044 This design relies on the peer always sending a connection ID in its 3045 packets so that the endpoint can use the connection ID from a packet 3046 to reset the connection. An endpoint that uses this design MUST 3047 either use the same connection ID length for all connections or 3048 encode the length of the connection ID such that it can be recovered 3049 without state. In addition, it cannot provide a zero-length 3050 connection ID. 3052 Revealing the Stateless Reset Token allows any entity to terminate 3053 the connection, so a value can only be used once. This method for 3054 choosing the Stateless Reset Token means that the combination of 3055 connection ID and static key MUST NOT be used for another connection. 3056 A denial of service attack is possible if the same connection ID is 3057 used by instances that share a static key, or if an attacker can 3058 cause a packet to be routed to an instance that has no state but the 3059 same static key; see Section 21.9. A connection ID from a connection 3060 that is reset by revealing the Stateless Reset Token MUST NOT be 3061 reused for new connections at nodes that share a static key. 3063 The same Stateless Reset Token MUST NOT be used for multiple 3064 connection IDs. Endpoints are not required to compare new values 3065 against all previous values, but a duplicate value MAY be treated as 3066 a connection error of type PROTOCOL_VIOLATION. 3068 Note that Stateless Reset packets do not have any cryptographic 3069 protection. 3071 10.4.3. Looping 3073 The design of a Stateless Reset is such that without knowing the 3074 stateless reset token it is indistinguishable from a valid packet. 3075 For instance, if a server sends a Stateless Reset to another server 3076 it might receive another Stateless Reset in response, which could 3077 lead to an infinite exchange. 3079 An endpoint MUST ensure that every Stateless Reset that it sends is 3080 smaller than the packet which triggered it, unless it maintains state 3081 sufficient to prevent looping. In the event of a loop, this results 3082 in packets eventually being too small to trigger a response. 3084 An endpoint can remember the number of Stateless Reset packets that 3085 it has sent and stop generating new Stateless Reset packets once a 3086 limit is reached. Using separate limits for different remote 3087 addresses will ensure that Stateless Reset packets can be used to 3088 close connections when other peers or connections have exhausted 3089 limits. 3091 Reducing the size of a Stateless Reset below 41 bytes means that the 3092 packet could reveal to an observer that it is a Stateless Reset, 3093 depending upon the length of the peer's connection IDs. Conversely, 3094 refusing to send a Stateless Reset in response to a small packet 3095 might result in Stateless Reset not being useful in detecting cases 3096 of broken connections where only very small packets are sent; such 3097 failures might only be detected by other means, such as timers. 3099 11. Error Handling 3101 An endpoint that detects an error SHOULD signal the existence of that 3102 error to its peer. Both transport-level and application-level errors 3103 can affect an entire connection (see Section 11.1), while only 3104 application-level errors can be isolated to a single stream (see 3105 Section 11.2). 3107 The most appropriate error code (Section 20) SHOULD be included in 3108 the frame that signals the error. Where this specification 3109 identifies error conditions, it also identifies the error code that 3110 is used; though these are worded as requirements, different 3111 implementation strategies might lead to different errors being 3112 reported. In particular, an endpoint MAY use any applicable error 3113 code when it detects an error condition; a generic error code (such 3114 as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place 3115 of specific error codes. 3117 A stateless reset (Section 10.4) is not suitable for any error that 3118 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 3119 stateless reset MUST NOT be used by an endpoint that has the state 3120 necessary to send a frame on the connection. 3122 11.1. Connection Errors 3124 Errors that result in the connection being unusable, such as an 3125 obvious violation of protocol semantics or corruption of state that 3126 affects an entire connection, MUST be signaled using a 3127 CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the 3128 connection in this manner even if the error only affects a single 3129 stream. 3131 Application protocols can signal application-specific protocol errors 3132 using the application-specific variant of the CONNECTION_CLOSE frame. 3133 Errors that are specific to the transport, including all those 3134 described in this document, are carried in the QUIC-specific variant 3135 of the CONNECTION_CLOSE frame. 3137 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 3138 endpoint SHOULD be prepared to retransmit a packet containing a 3139 CONNECTION_CLOSE frame if it receives more packets on a terminated 3140 connection. Limiting the number of retransmissions and the time over 3141 which this final packet is sent limits the effort expended on 3142 terminated connections. 3144 An endpoint that chooses not to retransmit packets containing a 3145 CONNECTION_CLOSE frame risks a peer missing the first such packet. 3146 The only mechanism available to an endpoint that continues to receive 3147 data for a terminated connection is to use the stateless reset 3148 process (Section 10.4). 3150 11.2. Stream Errors 3152 If an application-level error affects a single stream, but otherwise 3153 leaves the connection in a recoverable state, the endpoint can send a 3154 RESET_STREAM frame (Section 19.4) with an appropriate error code to 3155 terminate just the affected stream. 3157 Resetting a stream without the involvement of the application 3158 protocol could cause the application protocol to enter an 3159 unrecoverable state. RESET_STREAM MUST only be instigated by the 3160 application protocol that uses QUIC. 3162 The semantics of the application error code carried in RESET_STREAM 3163 are defined by the application protocol. Only the application 3164 protocol is able to cause a stream to be terminated. A local 3165 instance of the application protocol uses a direct API call and a 3166 remote instance uses the STOP_SENDING frame, which triggers an 3167 automatic RESET_STREAM. 3169 Application protocols SHOULD define rules for handling streams that 3170 are prematurely cancelled by either endpoint. 3172 12. Packets and Frames 3174 QUIC endpoints communicate by exchanging packets. Packets have 3175 confidentiality and integrity protection (see Section 12.1) and are 3176 carried in UDP datagrams (see Section 12.2). 3178 This version of QUIC uses the long packet header (see Section 17.2) 3179 during connection establishment. Packets with the long header are 3180 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake 3181 (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation 3182 uses a version-independent packet with a long header (see 3183 Section 17.2.1). 3185 Packets with the short header (Section 17.3) are designed for minimal 3186 overhead and are used after a connection is established and 1-RTT 3187 keys are available. 3189 12.1. Protected Packets 3191 All QUIC packets except Version Negotiation packets use authenticated 3192 encryption with additional data (AEAD) [RFC5116] to provide 3193 confidentiality and integrity protection. Retry packets use AEAD to 3194 provide integrity protection. Details of packet protection are found 3195 in [QUIC-TLS]; this section includes an overview of the process. 3197 Initial packets are protected using keys that are statically derived. 3198 This packet protection is not effective confidentiality protection. 3199 Initial protection only exists to ensure that the sender of the 3200 packet is on the network path. Any entity that receives the Initial 3201 packet from a client can recover the keys necessary to remove packet 3202 protection or to generate packets that will be successfully 3203 authenticated. 3205 All other packets are protected with keys derived from the 3206 cryptographic handshake. The type of the packet from the long header 3207 or key phase from the short header are used to identify which 3208 encryption level - and therefore the keys - that are used. Packets 3209 protected with 0-RTT and 1-RTT keys are expected to have 3210 confidentiality and data origin authentication; the cryptographic 3211 handshake ensures that only the communicating endpoints receive the 3212 corresponding keys. 3214 The packet number field contains a packet number, which has 3215 additional confidentiality protection that is applied after packet 3216 protection is applied (see [QUIC-TLS] for details). The underlying 3217 packet number increases with each packet sent in a given packet 3218 number space; see Section 12.3 for details. 3220 12.2. Coalescing Packets 3222 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake 3223 (Section 17.2.4) packets contain a Length field, which determines the 3224 end of the packet. The length includes both the Packet Number and 3225 Payload fields, both of which are confidentiality protected and 3226 initially of unknown length. The length of the Payload field is 3227 learned once header protection is removed. 3229 Using the Length field, a sender can coalesce multiple QUIC packets 3230 into one UDP datagram. This can reduce the number of UDP datagrams 3231 needed to complete the cryptographic handshake and start sending 3232 data. This can also be used to construct PMTU probes (see 3233 Section 14.3.1). Receivers MUST be able to process coalesced 3234 packets. 3236 Coalescing packets in order of increasing encryption levels (Initial, 3237 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 3238 able to process all the packets in a single pass. A packet with a 3239 short header does not include a length, so it can only be the last 3240 packet included in a UDP datagram. An endpoint SHOULD NOT coalesce 3241 multiple packets at the same encryption level. 3243 Senders MUST NOT coalesce QUIC packets for different connections into 3244 a single UDP datagram. Receivers SHOULD ignore any subsequent 3245 packets with a different Destination Connection ID than the first 3246 packet in the datagram. 3248 Every QUIC packet that is coalesced into a single UDP datagram is 3249 separate and complete. The receiver of coalesced QUIC packets MUST 3250 individually process each QUIC packet and separately acknowledge 3251 them, as if they were received as the payload of different UDP 3252 datagrams. For example, if decryption fails (because the keys are 3253 not available or any other reason), the receiver MAY either discard 3254 or buffer the packet for later processing and MUST attempt to process 3255 the remaining packets. 3257 Retry packets (Section 17.2.5), Version Negotiation packets 3258 (Section 17.2.1), and packets with a short header (Section 17.3) do 3259 not contain a Length field and so cannot be followed by other packets 3260 in the same UDP datagram. Note also that there is no situation where 3261 a Retry or Version Negotiation packet is coalesced with another 3262 packet. 3264 12.3. Packet Numbers 3266 The packet number is an integer in the range 0 to 2^62-1. This 3267 number is used in determining the cryptographic nonce for packet 3268 protection. Each endpoint maintains a separate packet number for 3269 sending and receiving. 3271 Packet numbers are limited to this range because they need to be 3272 representable in whole in the Largest Acknowledged field of an ACK 3273 frame (Section 19.3). When present in a long or short header 3274 however, packet numbers are reduced and encoded in 1 to 4 bytes (see 3275 Section 17.1). 3277 Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) 3278 packets do not include a packet number. 3280 Packet numbers are divided into 3 spaces in QUIC: 3282 * Initial space: All Initial packets (Section 17.2.2) are in this 3283 space. 3285 * Handshake space: All Handshake packets (Section 17.2.4) are in 3286 this space. 3288 * Application data space: All 0-RTT and 1-RTT encrypted packets 3289 (Section 12.1) are in this space. 3291 As described in [QUIC-TLS], each packet type uses different 3292 protection keys. 3294 Conceptually, a packet number space is the context in which a packet 3295 can be processed and acknowledged. Initial packets can only be sent 3296 with Initial packet protection keys and acknowledged in packets which 3297 are also Initial packets. Similarly, Handshake packets are sent at 3298 the Handshake encryption level and can only be acknowledged in 3299 Handshake packets. 3301 This enforces cryptographic separation between the data sent in the 3302 different packet sequence number spaces. Packet numbers in each 3303 space start at packet number 0. Subsequent packets sent in the same 3304 packet number space MUST increase the packet number by at least one. 3306 0-RTT and 1-RTT data exist in the same packet number space to make 3307 loss recovery algorithms easier to implement between the two packet 3308 types. 3310 A QUIC endpoint MUST NOT reuse a packet number within the same packet 3311 number space in one connection. If the packet number for sending 3312 reaches 2^62 - 1, the sender MUST close the connection without 3313 sending a CONNECTION_CLOSE frame or any further packets; an endpoint 3314 MAY send a Stateless Reset (Section 10.4) in response to further 3315 packets that it receives. 3317 A receiver MUST discard a newly unprotected packet unless it is 3318 certain that it has not processed another packet with the same packet 3319 number from the same packet number space. Duplicate suppression MUST 3320 happen after removing packet protection for the reasons described in 3321 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 3322 suppression can be found in Section 3.4.3 of [RFC4303]. 3324 Packet number encoding at a sender and decoding at a receiver are 3325 described in Section 17.1. 3327 12.4. Frames and Frame Types 3329 The payload of QUIC packets, after removing packet protection, 3330 consists of a sequence of complete frames, as shown in Figure 7. 3331 Version Negotiation, Stateless Reset, and Retry packets do not 3332 contain frames. 3334 0 1 2 3 3335 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 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | Frame 1 (*) ... 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | Frame 2 (*) ... 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 ... 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Frame N (*) ... 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3346 Figure 7: QUIC Payload 3348 The payload of a packet that contains frames MUST contain at least 3349 one frame, and MAY contain multiple frames and multiple frame types. 3350 Frames always fit within a single QUIC packet and cannot span 3351 multiple packets. 3353 Each frame begins with a Frame Type, indicating its type, followed by 3354 additional type-dependent fields: 3356 0 1 2 3 3357 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 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3359 | Frame Type (i) ... 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 | Type-Dependent Fields (*) ... 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3364 Figure 8: Generic Frame Layout 3366 The frame types defined in this specification are listed in Table 3. 3367 The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and 3368 CONNECTION_CLOSE frames is used to carry other frame-specific flags. 3369 For all other frames, the Frame Type field simply identifies the 3370 frame. These frames are explained in more detail in Section 19. 3372 +-------------+----------------------+---------------+---------+ 3373 | Type Value | Frame Type Name | Definition | Packets | 3374 +=============+======================+===============+=========+ 3375 | 0x00 | PADDING | Section 19.1 | IH01 | 3376 +-------------+----------------------+---------------+---------+ 3377 | 0x01 | PING | Section 19.2 | IH01 | 3378 +-------------+----------------------+---------------+---------+ 3379 | 0x02 - 0x03 | ACK | Section 19.3 | IH_1 | 3380 +-------------+----------------------+---------------+---------+ 3381 | 0x04 | RESET_STREAM | Section 19.4 | __01 | 3382 +-------------+----------------------+---------------+---------+ 3383 | 0x05 | STOP_SENDING | Section 19.5 | __01 | 3384 +-------------+----------------------+---------------+---------+ 3385 | 0x06 | CRYPTO | Section 19.6 | IH_1 | 3386 +-------------+----------------------+---------------+---------+ 3387 | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | 3388 +-------------+----------------------+---------------+---------+ 3389 | 0x08 - 0x0f | STREAM | Section 19.8 | __01 | 3390 +-------------+----------------------+---------------+---------+ 3391 | 0x10 | MAX_DATA | Section 19.9 | __01 | 3392 +-------------+----------------------+---------------+---------+ 3393 | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | 3394 +-------------+----------------------+---------------+---------+ 3395 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | __01 | 3396 +-------------+----------------------+---------------+---------+ 3397 | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | 3398 +-------------+----------------------+---------------+---------+ 3399 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | 3400 +-------------+----------------------+---------------+---------+ 3401 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | 3402 +-------------+----------------------+---------------+---------+ 3403 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | 3404 +-------------+----------------------+---------------+---------+ 3405 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | 3406 +-------------+----------------------+---------------+---------+ 3407 | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | 3408 +-------------+----------------------+---------------+---------+ 3409 | 0x1b | PATH_RESPONSE | Section 19.18 | __01 | 3410 +-------------+----------------------+---------------+---------+ 3411 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* | 3412 +-------------+----------------------+---------------+---------+ 3413 | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | 3414 +-------------+----------------------+---------------+---------+ 3416 Table 3: Frame Types 3418 The "Packets" column in Table 3 does not form part of the IANA 3419 registry (see Section 22.3). This column lists the types of packets 3420 that each frame type can appear in, indicated by the following 3421 characters: 3423 I: Initial (Section 17.2.2) 3425 H: Handshake (Section 17.2.4) 3427 0: 0-RTT (Section 17.2.3) 3429 1: 1-RTT (Section 17.3) 3431 *: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, 3432 Handshake, and 1-RTT packets, whereas a CONNECTION_CLOSE of type 3433 0x1d can only appear in a 1-RTT packet. 3435 Section 4 of [QUIC-TLS] provides more detail about these 3436 restrictions. Note that all frames can appear in 1-RTT packets. 3438 An endpoint MUST treat the receipt of a frame of unknown type as a 3439 connection error of type FRAME_ENCODING_ERROR. 3441 All QUIC frames are idempotent in this version of QUIC. That is, a 3442 valid frame does not cause undesirable side effects or errors when 3443 received more than once. 3445 The Frame Type field uses a variable length integer encoding (see 3446 Section 16) with one exception. To ensure simple and efficient 3447 implementations of frame parsing, a frame type MUST use the shortest 3448 possible encoding. For frame types defined in this document, this 3449 means a single-byte encoding, even though it is possible to encode 3450 these values as a two-, four- or eight-byte variable length integer. 3451 For instance, though 0x4001 is a legitimate two-byte encoding for a 3452 variable-length integer with a value of 1, PING frames are always 3453 encoded as a single byte with the value 0x01. This rule applies to 3454 all current and future QUIC frame types. An endpoint MAY treat the 3455 receipt of a frame type that uses a longer encoding than necessary as 3456 a connection error of type PROTOCOL_VIOLATION. 3458 13. Packetization and Reliability 3460 A sender bundles one or more frames in a QUIC packet (see 3461 Section 12.4). 3463 A sender can minimize per-packet bandwidth and computational costs by 3464 bundling as many frames as possible within a QUIC packet. A sender 3465 MAY wait for a short period of time to bundle multiple frames before 3466 sending a packet that is not maximally packed, to avoid sending out 3467 large numbers of small packets. An implementation MAY use knowledge 3468 about application sending behavior or heuristics to determine whether 3469 and for how long to wait. This waiting period is an implementation 3470 decision, and an implementation should be careful to delay 3471 conservatively, since any delay is likely to increase application- 3472 visible latency. 3474 Stream multiplexing is achieved by interleaving STREAM frames from 3475 multiple streams into one or more QUIC packets. A single QUIC packet 3476 can include multiple STREAM frames from one or more streams. 3478 One of the benefits of QUIC is avoidance of head-of-line blocking 3479 across multiple streams. When a packet loss occurs, only streams 3480 with data in that packet are blocked waiting for a retransmission to 3481 be received, while other streams can continue making progress. Note 3482 that when data from multiple streams is bundled into a single QUIC 3483 packet, loss of that packet blocks all those streams from making 3484 progress. Implementations are advised to bundle as few streams as 3485 necessary in outgoing packets without losing transmission efficiency 3486 to underfilled packets. 3488 13.1. Packet Processing 3490 A packet MUST NOT be acknowledged until packet protection has been 3491 successfully removed and all frames contained in the packet have been 3492 processed. For STREAM frames, this means the data has been enqueued 3493 in preparation to be received by the application protocol, but it 3494 does not require that data is delivered and consumed. 3496 Once the packet has been fully processed, a receiver acknowledges 3497 receipt by sending one or more ACK frames containing the packet 3498 number of the received packet. 3500 13.2. Generating Acknowledgements 3502 Endpoints acknowledge all packets they receive and process. However, 3503 only ack-eliciting packets cause an ACK frame to be sent within the 3504 maximum ack delay. Packets that are not ack-eliciting are only 3505 acknowledged when an ACK frame is sent for other reasons. 3507 When sending a packet for any reason, an endpoint should attempt to 3508 bundle an ACK frame if one has not been sent recently. Doing so 3509 helps with timely loss detection at the peer. 3511 In general, frequent feedback from a receiver improves loss and 3512 congestion response, but this has to be balanced against excessive 3513 load generated by a receiver that sends an ACK frame in response to 3514 every ack-eliciting packet. The guidance offered below seeks to 3515 strike this balance. 3517 13.2.1. Sending ACK Frames 3519 Every packet SHOULD be acknowledged at least once, and ack-eliciting 3520 packets MUST be acknowledged at least once within the maximum ack 3521 delay. An endpoint communicates its maximum delay using the 3522 max_ack_delay transport parameter; see Section 18.2. max_ack_delay 3523 declares an explicit contract: an endpoint promises to never 3524 intentionally delay acknowledgments of an ack-eliciting packet by 3525 more than the indicated value. If it does, any excess accrues to the 3526 RTT estimate and could result in spurious or delayed retransmissions 3527 from the peer. For Initial and Handshake packets, a max_ack_delay of 3528 0 is used. The sender uses the receiver's "max_ack_delay" value in 3529 determining timeouts for timer-based retransmission, as detailed in 3530 Section 5.2.1 of [QUIC-RECOVERY]. 3532 An ACK frame SHOULD be generated for at least every second ack- 3533 eliciting packet. This recommendation is in keeping with standard 3534 practice for TCP [RFC5681]. 3536 In order to assist loss detection at the sender, an endpoint SHOULD 3537 send an ACK frame immediately on receiving an ack-eliciting packet 3538 that is out of order. The endpoint MAY continue sending ACK frames 3539 immediately on each subsequently received packet, but the endpoint 3540 SHOULD return to acknowledging every other packet within a period of 3541 1/8 x RTT, unless more ack-eliciting packets are received out of 3542 order. If every subsequent ack-eliciting packet arrives out of 3543 order, then an ACK frame SHOULD be sent immediately for every 3544 received ack-eliciting packet. 3546 Similarly, packets marked with the ECN Congestion Experienced (CE) 3547 codepoint in the IP header SHOULD be acknowledged immediately, to 3548 reduce the peer's response time to congestion events. 3550 As an optimization, a receiver MAY process multiple packets before 3551 sending any ACK frames in response. In this case the receiver can 3552 determine whether an immediate or delayed acknowledgement should be 3553 generated after processing incoming packets. 3555 Packets containing PADDING frames are considered to be in flight for 3556 congestion control purposes [QUIC-RECOVERY]. Sending only PADDING 3557 frames might cause the sender to become limited by the congestion 3558 controller with no acknowledgments forthcoming from the receiver. 3559 Therefore, a sender SHOULD ensure that other frames are sent in 3560 addition to PADDING frames to elicit acknowledgments from the 3561 receiver. 3563 An endpoint that is only sending ACK frames will not receive 3564 acknowledgments from its peer unless those acknowledgements are 3565 included in packets with ack-eliciting frames. An endpoint SHOULD 3566 bundle ACK frames with other frames when there are new ack-eliciting 3567 packets to acknowledge. When only non-ack-eliciting packets need to 3568 be acknowledged, an endpoint MAY wait until an ack-eliciting packet 3569 has been received to bundle an ACK frame with outgoing frames. 3571 The algorithms in [QUIC-RECOVERY] are resilient to receivers that do 3572 not follow guidance offered above. However, an implementor should 3573 only deviate from these requirements after careful consideration of 3574 the performance implications of doing so. 3576 Packets containing only ACK frames are not congestion controlled, so 3577 there are limits on how frequently they can be sent. An endpoint 3578 MUST NOT send more than one ACK-frame-only packet in response to 3579 receiving an ack-eliciting packet. An endpoint MUST NOT send a non- 3580 ack-eliciting packet in response to a non-ack-eliciting packet, even 3581 if there are packet gaps which precede the received packet. Limiting 3582 ACK frames avoids an infinite feedback loop of acknowledgements, 3583 which could prevent the connection from ever becoming idle. However, 3584 the endpoint acknowledges non-ACK-eliciting packets when it sends an 3585 ACK frame. 3587 An endpoint SHOULD treat receipt of an acknowledgment for a packet it 3588 did not send as a connection error of type PROTOCOL_VIOLATION, if it 3589 is able to detect the condition. 3591 13.2.2. Managing ACK Ranges 3593 When an ACK frame is sent, one or more ranges of acknowledged packets 3594 are included. Including older packets reduces the chance of spurious 3595 retransmits caused by losing previously sent ACK frames, at the cost 3596 of larger ACK frames. 3598 ACK frames SHOULD always acknowledge the most recently received 3599 packets, and the more out-of-order the packets are, the more 3600 important it is to send an updated ACK frame quickly, to prevent the 3601 peer from declaring a packet as lost and spuriously retransmitting 3602 the frames it contains. An ACK frame is expected to fit within a 3603 single QUIC packet. If it does not, then older ranges (those with 3604 the smallest packet numbers) are omitted. 3606 Section 13.2.3 and Section 13.2.4 describe an exemplary approach for 3607 determining what packets to acknowledge in each ACK frame. 3609 13.2.3. Receiver Tracking of ACK Frames 3611 When a packet containing an ACK frame is sent, the largest 3612 acknowledged in that frame may be saved. When a packet containing an 3613 ACK frame is acknowledged, the receiver can stop acknowledging 3614 packets less than or equal to the largest acknowledged in the sent 3615 ACK frame. 3617 In cases without ACK frame loss, this algorithm allows for a minimum 3618 of 1 RTT of reordering. In cases with ACK frame loss and reordering, 3619 this approach does not guarantee that every acknowledgement is seen 3620 by the sender before it is no longer included in the ACK frame. 3621 Packets could be received out of order and all subsequent ACK frames 3622 containing them could be lost. In this case, the loss recovery 3623 algorithm could cause spurious retransmits, but the sender will 3624 continue making forward progress. 3626 13.2.4. Limiting ACK Ranges 3628 To limit ACK Ranges (see Section 19.3.1) to those that have not yet 3629 been received by the sender, the receiver SHOULD track which ACK 3630 frames have been acknowledged by its peer. The receiver SHOULD 3631 exclude already acknowledged packets from future ACK frames whenever 3632 these packets would unnecessarily contribute to the ACK frame size. 3633 When the receiver is only sending non-ack-eliciting packets, it can 3634 bundle a PING or other small ack-eliciting frame with a fraction of 3635 them, such as once per round trip, to enable dropping unnecessary ACK 3636 ranges and any state for previously sent packets. The receiver MUST 3637 NOT bundle an ack-eliciting frame, such as a PING, with all packets 3638 that would otherwise be non-ack-eliciting, in order to avoid an 3639 infinite feedback loop of acknowledgements. 3641 To limit receiver state or the size of ACK frames, a receiver MAY 3642 limit the number of ACK Ranges it sends. A receiver can do this even 3643 without receiving acknowledgment of its ACK frames, with the 3644 knowledge this could cause the sender to unnecessarily retransmit 3645 some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare 3646 packets lost after sufficiently newer packets are acknowledged. 3647 Therefore, the receiver SHOULD repeatedly acknowledge newly received 3648 packets in preference to packets received in the past. 3650 13.2.5. Measuring and Reporting Host Delay 3652 An endpoint measures the delays intentionally introduced between the 3653 time the packet with the largest packet number is received and the 3654 time an acknowledgment is sent. The endpoint encodes this delay in 3655 the Ack Delay field of an ACK frame (see Section 19.3). This allows 3656 the receiver of the ACK to adjust for any intentional delays, which 3657 is important for getting a better estimate of the path RTT when 3658 acknowledgments are delayed. A packet might be held in the OS kernel 3659 or elsewhere on the host before being processed. An endpoint MUST 3660 NOT include delays that it does not control when populating the Ack 3661 Delay field in an ACK frame. 3663 13.2.6. ACK Frames and Packet Protection 3665 ACK frames MUST only be carried in a packet that has the same packet 3666 number space as the packet being ACKed (see Section 12.1). For 3667 instance, packets that are protected with 1-RTT keys MUST be 3668 acknowledged in packets that are also protected with 1-RTT keys. 3670 Packets that a client sends with 0-RTT packet protection MUST be 3671 acknowledged by the server in packets protected by 1-RTT keys. This 3672 can mean that the client is unable to use these acknowledgments if 3673 the server cryptographic handshake messages are delayed or lost. 3674 Note that the same limitation applies to other data sent by the 3675 server protected by the 1-RTT keys. 3677 13.3. Retransmission of Information 3679 QUIC packets that are determined to be lost are not retransmitted 3680 whole. The same applies to the frames that are contained within lost 3681 packets. Instead, the information that might be carried in frames is 3682 sent again in new frames as needed. 3684 New frames and packets are used to carry information that is 3685 determined to have been lost. In general, information is sent again 3686 when a packet containing that information is determined to be lost 3687 and sending ceases when a packet containing that information is 3688 acknowledged. 3690 * Data sent in CRYPTO frames is retransmitted according to the rules 3691 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 3692 CRYPTO frames for Initial and Handshake packets is discarded when 3693 keys for the corresponding encryption level are discarded. 3695 * Application data sent in STREAM frames is retransmitted in new 3696 STREAM frames unless the endpoint has sent a RESET_STREAM for that 3697 stream. Once an endpoint sends a RESET_STREAM frame, no further 3698 STREAM frames are needed. 3700 * ACK frames carry the most recent set of acknowledgements and the 3701 Ack Delay from the largest acknowledged packet, as described in 3702 Section 13.2.1. Delaying the transmission of packets containing 3703 ACK frames or sending old ACK frames can cause the peer to 3704 generate an inflated RTT sample or unnecessarily disable ECN. 3706 * Cancellation of stream transmission, as carried in a RESET_STREAM 3707 frame, is sent until acknowledged or until all stream data is 3708 acknowledged by the peer (that is, either the "Reset Recvd" or 3709 "Data Recvd" state is reached on the sending part of the stream). 3710 The content of a RESET_STREAM frame MUST NOT change when it is 3711 sent again. 3713 * Similarly, a request to cancel stream transmission, as encoded in 3714 a STOP_SENDING frame, is sent until the receiving part of the 3715 stream enters either a "Data Recvd" or "Reset Recvd" state; see 3716 Section 3.5. 3718 * Connection close signals, including packets that contain 3719 CONNECTION_CLOSE frames, are not sent again when packet loss is 3720 detected, but as described in Section 10. 3722 * The current connection maximum data is sent in MAX_DATA frames. 3723 An updated value is sent in a MAX_DATA frame if the packet 3724 containing the most recently sent MAX_DATA frame is declared lost, 3725 or when the endpoint decides to update the limit. Care is 3726 necessary to avoid sending this frame too often as the limit can 3727 increase frequently and cause an unnecessarily large number of 3728 MAX_DATA frames to be sent. 3730 * The current maximum stream data offset is sent in MAX_STREAM_DATA 3731 frames. Like MAX_DATA, an updated value is sent when the packet 3732 containing the most recent MAX_STREAM_DATA frame for a stream is 3733 lost or when the limit is updated, with care taken to prevent the 3734 frame from being sent too often. An endpoint SHOULD stop sending 3735 MAX_STREAM_DATA frames when the receiving part of the stream 3736 enters a "Size Known" state. 3738 * The limit on streams of a given type is sent in MAX_STREAMS 3739 frames. Like MAX_DATA, an updated value is sent when a packet 3740 containing the most recent MAX_STREAMS for a stream type frame is 3741 declared lost or when the limit is updated, with care taken to 3742 prevent the frame from being sent too often. 3744 * Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 3745 and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection 3746 scope, STREAM_DATA_BLOCKED frames have stream scope, and 3747 STREAMS_BLOCKED frames are scoped to a specific stream type. New 3748 frames are sent if packets containing the most recent frame for a 3749 scope is lost, but only while the endpoint is blocked on the 3750 corresponding limit. These frames always include the limit that 3751 is causing blocking at the time that they are transmitted. 3753 * A liveness or path validation check using PATH_CHALLENGE frames is 3754 sent periodically until a matching PATH_RESPONSE frame is received 3755 or until there is no remaining need for liveness or path 3756 validation checking. PATH_CHALLENGE frames include a different 3757 payload each time they are sent. 3759 * Responses to path validation using PATH_RESPONSE frames are sent 3760 just once. The peer is expected to send more PATH_CHALLENGE 3761 frames as necessary to evoke additional PATH_RESPONSE frames. 3763 * New connection IDs are sent in NEW_CONNECTION_ID frames and 3764 retransmitted if the packet containing them is lost. 3765 Retransmissions of this frame carry the same sequence number 3766 value. Likewise, retired connection IDs are sent in 3767 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3768 containing them is lost. 3770 * NEW_TOKEN frames are retransmitted if the packet containing them 3771 is lost. No special support is made for detecting reordered and 3772 duplicated NEW_TOKEN frames other than a direct comparison of the 3773 frame contents. 3775 * PING and PADDING frames contain no information, so lost PING or 3776 PADDING frames do not require repair. 3778 * The HANDSHAKE_DONE frame MUST be retransmitted until it is 3779 acknowledged. 3781 Endpoints SHOULD prioritize retransmission of data over sending new 3782 data, unless priorities specified by the application indicate 3783 otherwise (see Section 2.3). 3785 Even though a sender is encouraged to assemble frames containing up- 3786 to-date information every time it sends a packet, it is not forbidden 3787 to retransmit copies of frames from lost packets. A sender that 3788 retransmits copies of frames needs to handle decreases in available 3789 payload size due to change in packet number length, connection ID 3790 length, and path MTU. A receiver MUST accept packets containing an 3791 outdated frame, such as a MAX_DATA frame carrying a smaller maximum 3792 data than one found in an older packet. 3794 Upon detecting losses, a sender MUST take appropriate congestion 3795 control action. The details of loss detection and congestion control 3796 are described in [QUIC-RECOVERY]. 3798 13.4. Explicit Congestion Notification 3800 QUIC endpoints can use Explicit Congestion Notification (ECN) 3801 [RFC3168] to detect and respond to network congestion. ECN allows a 3802 network node to indicate congestion in the network by setting a 3803 codepoint in the IP header of a packet instead of dropping it. 3804 Endpoints react to congestion by reducing their sending rate in 3805 response, as described in [QUIC-RECOVERY]. 3807 To use ECN, QUIC endpoints first determine whether a path supports 3808 ECN marking and the peer is able to access the ECN codepoint in the 3809 IP header. A network path does not support ECN if ECN marked packets 3810 get dropped or ECN markings are rewritten on the path. An endpoint 3811 validates the use of ECN on the path, both during connection 3812 establishment and when migrating to a new path (Section 9). 3814 13.4.1. ECN Counts 3816 On receiving a QUIC packet with an ECT or CE codepoint, an ECN- 3817 enabled endpoint that can access the ECN codepoints from the 3818 enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE 3819 count, and includes these counts in subsequent ACK frames (see 3820 Section 13.2 and Section 19.3). Note that this requires being able 3821 to read the ECN codepoints from the enclosing IP packet, which is not 3822 possible on all platforms. 3824 A packet detected by a receiver as a duplicate does not affect the 3825 receiver's local ECN codepoint counts; see (Section 21.8) for 3826 relevant security concerns. 3828 If an endpoint receives a QUIC packet without an ECT or CE codepoint 3829 in the IP packet header, it responds per Section 13.2 with an ACK 3830 frame without increasing any ECN counts. If an endpoint does not 3831 implement ECN support or does not have access to received ECN 3832 codepoints, it does not increase ECN counts. 3834 Coalesced packets (see Section 12.2) mean that several packets can 3835 share the same IP header. The ECN counter for the ECN codepoint 3836 received in the associated IP header are incremented once for each 3837 QUIC packet, not per enclosing IP packet or UDP datagram. 3839 Each packet number space maintains separate acknowledgement state and 3840 separate ECN counts. For example, if one each of an Initial, 0-RTT, 3841 Handshake, and 1-RTT QUIC packet are coalesced, the corresponding 3842 counts for the Initial and Handshake packet number space will be 3843 incremented by one and the counts for the 1-RTT packet number space 3844 will be increased by two. 3846 13.4.2. ECN Validation 3848 It is possible for faulty network devices to corrupt or erroneously 3849 drop packets with ECN markings. To provide robust connectivity in 3850 the presence of such devices, each endpoint independently validates 3851 ECN counts and disables ECN if errors are detected. 3853 Endpoints validate ECN for packets sent on each network path 3854 independently. An endpoint thus validates ECN on new connection 3855 establishment, when switching to a new server preferred address, and 3856 on active connection migration to a new path. Appendix B describes 3857 one possible algorithm for testing paths for ECN support. 3859 Even if an endpoint does not use ECN markings on packets it 3860 transmits, the endpoint MUST provide feedback about ECN markings 3861 received from the peer if they are accessible. Failing to report ECN 3862 counts will cause the peer to disable ECN marking. 3864 13.4.2.1. Sending ECN Markings 3866 To start ECN validation, an endpoint SHOULD do the following when 3867 sending packets on a new path to a peer: 3869 * Set the ECT(0) codepoint in the IP header of early outgoing 3870 packets sent on a new path to the peer [RFC8311]. 3872 * If all packets that were sent with the ECT(0) codepoint are 3873 eventually deemed lost [QUIC-RECOVERY], validation is deemed to 3874 have failed. 3876 To reduce the chances of misinterpreting congestive loss as packets 3877 dropped by a faulty network element, an endpoint could set the ECT(0) 3878 codepoint in the first ten outgoing packets on a path, or for a 3879 period of three RTTs, whichever occurs first. 3881 Implementations MAY experiment with and use other strategies for use 3882 of ECN. Other methods of probing paths for ECN support are possible, 3883 as are different marking strategies. Implementations can also use 3884 the ECT(1) codepoint, as specified in [RFC8311]. 3886 13.4.2.2. Receiving ACK Frames 3888 An endpoint that sets ECT(0) or ECT(1) codepoints on packets it 3889 transmits MUST use the following steps on receiving an ACK frame to 3890 validate ECN. 3892 * If this ACK frame newly acknowledges a packet that the endpoint 3893 sent with either ECT(0) or ECT(1) codepoints set, and if no ECN 3894 feedback is present in the ACK frame, validation fails. This step 3895 protects against both a network element that zeroes out ECN bits 3896 and a peer that is unable to access ECN markings, since the peer 3897 could respond without ECN feedback in these cases. 3899 * For validation to succeed, the total increase in ECT(0), ECT(1), 3900 and CE counts MUST be no smaller than the total number of QUIC 3901 packets sent with an ECT codepoint that are newly acknowledged in 3902 this ACK frame. This step detects any network remarking from 3903 ECT(0), ECT(1), or CE codepoints to Not-ECT. 3905 * Any increase in either ECT(0) or ECT(1) counts, plus any increase 3906 in the CE count, MUST be no smaller than the number of packets 3907 sent with the corresponding ECT codepoint that are newly 3908 acknowledged in this ACK frame. This step detects any erroneous 3909 network remarking from ECT(0) to ECT(1) (or vice versa). 3911 Processing ECN counts out of order can result in validation failure. 3912 An endpoint SHOULD NOT perform this validation if this ACK frame does 3913 not advance the largest packet number acknowledged in this 3914 connection. 3916 An endpoint could miss acknowledgements for a packet when ACK frames 3917 are lost. It is therefore possible for the total increase in ECT(0), 3918 ECT(1), and CE counts to be greater than the number of packets 3919 acknowledged in an ACK frame. When this happens, and if validation 3920 succeeds, the local reference counts MUST be increased to match the 3921 counts in the ACK frame. 3923 13.4.2.3. Validation Outcomes 3925 If validation fails, then the endpoint stops sending ECN markings in 3926 subsequent IP packets with the expectation that either the network 3927 path or the peer does not support ECN. 3929 Upon successful validation, an endpoint can continue to set ECT 3930 codepoints in subsequent packets with the expectation that the path 3931 is ECN-capable. Network routing and path elements can change mid- 3932 connection however; an endpoint MUST disable ECN if validation fails 3933 at any point in the connection. 3935 Even if validation fails, an endpoint MAY revalidate ECN on the same 3936 path at any later time in the connection. 3938 14. Packet Size 3940 The QUIC packet size includes the QUIC header and protected payload, 3941 but not the UDP or IP header. 3943 A client MUST expand the payload of all UDP datagrams carrying 3944 Initial packets to at least 1200 bytes, by adding PADDING frames to 3945 the Initial packet or by coalescing the Initial packet (see 3946 Section 12.2). Sending a UDP datagram of this size ensures that the 3947 network path from the client to the server supports a reasonable 3948 Maximum Transmission Unit (MTU). Padding datagrams also helps reduce 3949 the amplitude of amplification attacks caused by server responses 3950 toward an unverified client address; see Section 8. 3952 Datagrams containing Initial packets MAY exceed 1200 bytes if the 3953 client believes that the Path Maximum Transmission Unit (PMTU) 3954 supports the size that it chooses. 3956 UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 3957 [IPv4], the DF bit MUST be set to prevent fragmentation on the path. 3959 A server MUST discard an Initial packet that is carried in a UDP 3960 datagram that is smaller than 1200 bytes. A server MAY also 3961 immediately close the connection by sending a CONNECTION_CLOSE frame 3962 with an error code of PROTOCOL_VIOLATION; see Section 10.3.1. 3964 The server MUST also limit the number of bytes it sends before 3965 validating the address of the client; see Section 8. 3967 14.1. Path Maximum Transmission Unit (PMTU) 3969 The PMTU is the maximum size of the entire IP packet including the IP 3970 header, UDP header, and UDP payload. The UDP payload includes the 3971 QUIC packet header, protected payload, and any authentication fields. 3972 The PMTU can depend upon the current path characteristics. 3973 Therefore, the current largest UDP payload an implementation will 3974 send is referred to as the QUIC maximum packet size. 3976 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 3977 minimum size [RFC8200] and is also supported by most modern IPv4 3978 networks. All QUIC packets (except for PMTU probe packets) SHOULD be 3979 sized to fit within the maximum packet size to avoid the packet being 3980 fragmented or dropped [RFC8085]. 3982 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery 3983 ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] 3984 [RFC8201] to determine whether the path to a destination will support 3985 a desired message size without fragmentation. 3987 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3988 packets larger than 1280 bytes. Assuming the minimum IP header size, 3989 this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 3990 1252 bytes for IPv4. A QUIC implementation MAY be more conservative 3991 in computing the QUIC maximum packet size to allow for unknown tunnel 3992 overheads or IP header options/extensions. 3994 Each pair of local and remote addresses could have a different PMTU. 3995 QUIC implementations that implement any kind of PMTU discovery 3996 therefore SHOULD maintain a maximum packet size for each combination 3997 of local and remote IP addresses. 3999 If a QUIC endpoint determines that the PMTU between any pair of local 4000 and remote IP addresses has fallen below the size needed to support 4001 the smallest allowed maximum packet size, it MUST immediately cease 4002 sending QUIC packets, except for PMTU probe packets, on the affected 4003 path. An endpoint MAY terminate the connection if an alternative 4004 path cannot be found. 4006 14.2. ICMP Packet Too Big Messages 4008 PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP 4009 messages (e.g., IPv6 Packet Too Big messages) that indicate when a 4010 packet is dropped because it is larger than the local router MTU. 4011 DPLPMTUD can also optionally use these messages. This use of ICMP 4012 messages is potentially vulnerable to off-path attacks that 4013 successfully guess the addresses used on the path and reduce the PMTU 4014 to a bandwidth-inefficient value. 4016 An endpoint MUST ignore an ICMP message that claims the PMTU has 4017 decreased below 1280 bytes. 4019 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 4020 that the quoted packet should contain as much of the original packet 4021 as possible without exceeding the minimum MTU for the IP version. 4022 The size of the quoted packet can actually be smaller, or the 4023 information unintelligible, as described in Section 1.1 of 4024 [DPLPMTUD]. 4026 QUIC endpoints SHOULD validate ICMP messages to protect from off-path 4027 injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. 4028 This validation SHOULD use the quoted packet supplied in the payload 4029 of an ICMP message to associate the message with a corresponding 4030 transport connection [DPLPMTUD]. 4032 ICMP message validation MUST include matching IP addresses and UDP 4033 ports [RFC8085] and, when possible, connection IDs to an active QUIC 4034 session. 4036 Further validation can also be provided: 4038 * An IPv4 endpoint could set the Don't Fragment (DF) bit on a small 4039 proportion of packets, so that most invalid ICMP messages arrive 4040 when there are no DF packets outstanding, and can therefore be 4041 identified as spurious. 4043 * An endpoint could store additional information from the IP or UDP 4044 headers to use for validation (for example, the IP ID or UDP 4045 checksum). 4047 The endpoint SHOULD ignore all ICMP messages that fail validation. 4049 An endpoint MUST NOT increase PMTU based on ICMP messages. Any 4050 reduction in the QUIC maximum packet size MAY be provisional until 4051 QUIC's loss detection algorithm determines that the quoted packet has 4052 actually been lost. 4054 14.3. Datagram Packetization Layer PMTU Discovery 4056 Section 6.3 of [DPLPMTUD] provides considerations for implementing 4057 Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. 4059 When implementing the algorithm in Section 5 of [DPLPMTUD], the 4060 initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC 4061 packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). 4063 PING and PADDING frames can be used to generate PMTU probe packets. 4064 These frames might not be retransmitted if a probe packet containing 4065 them is lost. However, these frames do consume congestion window, 4066 which could delay the transmission of subsequent application data. 4068 A PING frame can be included in a PMTU probe to ensure that a valid 4069 probe is acknowledged. 4071 The considerations for processing ICMP messages in the previous 4072 section also apply if these messages are used by DPLPMTUD. 4074 14.3.1. PMTU Probes Containing Source Connection ID 4076 Endpoints that rely on the destination connection ID for routing QUIC 4077 packets are likely to require that the connection ID be included in 4078 PMTU probe packets to route any resulting ICMP messages 4079 (Section 14.2) back to the correct endpoint. However, only long 4080 header packets (Section 17.2) contain source connection IDs, and long 4081 header packets are not decrypted or acknowledged by the peer once the 4082 handshake is complete. One way to construct a PMTU probe is to 4083 coalesce (see Section 12.2) a Handshake packet (Section 17.2.4) with 4084 a short header packet in a single UDP datagram. If the UDP datagram 4085 reaches the endpoint, the Handshake packet will be ignored, but the 4086 short header packet will be acknowledged. If the UDP datagram 4087 elicits an ICMP message, that message will likely contain the source 4088 connection ID within the quoted portion of the UDP datagram. 4090 15. Versions 4092 QUIC versions are identified using a 32-bit unsigned number. 4094 The version 0x00000000 is reserved to represent version negotiation. 4095 This version of the specification is identified by the number 4096 0x00000001. 4098 Other versions of QUIC might have different properties to this 4099 version. The properties of QUIC that are guaranteed to be consistent 4100 across all versions of the protocol are described in 4101 [QUIC-INVARIANTS]. 4103 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 4104 protocol, as described in [QUIC-TLS]. 4106 Versions with the most significant 16 bits of the version number 4107 cleared are reserved for use in future IETF consensus documents. 4109 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 4110 forcing version negotiation to be exercised. That is, any version 4111 number where the low four bits of all bytes is 1010 (in binary). A 4112 client or server MAY advertise support for any of these reserved 4113 versions. 4115 Reserved version numbers will never represent a real protocol; a 4116 client MAY use one of these version numbers with the expectation that 4117 the server will initiate version negotiation; a server MAY advertise 4118 support for one of these versions and can expect that clients ignore 4119 the value. 4121 [[RFC editor: please remove the remainder of this section before 4122 publication.]] 4124 The version number for the final version of this specification 4125 (0x00000001), is reserved for the version of the protocol that is 4126 published as an RFC. 4128 Version numbers used to identify IETF drafts are created by adding 4129 the draft number to 0xff000000. For example, draft-ietf-quic- 4130 transport-13 would be identified as 0xff00000D. 4132 Implementors are encouraged to register version numbers of QUIC that 4133 they are using for private experimentation on the GitHub wiki at 4134 . 4136 16. Variable-Length Integer Encoding 4138 QUIC packets and frames commonly use a variable-length encoding for 4139 non-negative integer values. This encoding ensures that smaller 4140 integer values need fewer bytes to encode. 4142 The QUIC variable-length integer encoding reserves the two most 4143 significant bits of the first byte to encode the base 2 logarithm of 4144 the integer encoding length in bytes. The integer value is encoded 4145 on the remaining bits, in network byte order. 4147 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 4148 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 4149 the encoding properties. 4151 +------+--------+-------------+-----------------------+ 4152 | 2Bit | Length | Usable Bits | Range | 4153 +======+========+=============+=======================+ 4154 | 00 | 1 | 6 | 0-63 | 4155 +------+--------+-------------+-----------------------+ 4156 | 01 | 2 | 14 | 0-16383 | 4157 +------+--------+-------------+-----------------------+ 4158 | 10 | 4 | 30 | 0-1073741823 | 4159 +------+--------+-------------+-----------------------+ 4160 | 11 | 8 | 62 | 0-4611686018427387903 | 4161 +------+--------+-------------+-----------------------+ 4163 Table 4: Summary of Integer Encodings 4165 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 4166 hexadecimal) decodes to the decimal value 151288809941952652; the 4167 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 4168 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 4169 (as does the two byte sequence 40 25). 4171 Error codes (Section 20) and versions (Section 15) are described 4172 using integers, but do not use this encoding. 4174 17. Packet Formats 4176 All numeric values are encoded in network byte order (that is, big- 4177 endian) and all field sizes are in bits. Hexadecimal notation is 4178 used for describing the value of fields. 4180 17.1. Packet Number Encoding and Decoding 4182 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). 4183 When present in long or short packet headers, they are encoded in 1 4184 to 4 bytes. The number of bits required to represent the packet 4185 number is reduced by including the least significant bits of the 4186 packet number. 4188 The encoded packet number is protected as described in Section 5.4 of 4189 [QUIC-TLS]. 4191 The sender MUST use a packet number size able to represent more than 4192 twice as large a range than the difference between the largest 4193 acknowledged packet and packet number being sent. A peer receiving 4194 the packet will then correctly decode the packet number, unless the 4195 packet is delayed in transit such that it arrives after many higher- 4196 numbered packets have been received. An endpoint SHOULD use a large 4197 enough packet number encoding to allow the packet number to be 4198 recovered even if the packet arrives after packets that are sent 4199 afterwards. 4201 As a result, the size of the packet number encoding is at least one 4202 bit more than the base-2 logarithm of the number of contiguous 4203 unacknowledged packet numbers, including the new packet. 4205 For example, if an endpoint has received an acknowledgment for packet 4206 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 4207 packet number encoding with 16 bits or more; whereas the 24-bit 4208 packet number encoding is needed to send a packet with a number of 4209 0xace8fe. 4211 At a receiver, protection of the packet number is removed prior to 4212 recovering the full packet number. The full packet number is then 4213 reconstructed based on the number of significant bits present, the 4214 value of those bits, and the largest packet number received on a 4215 successfully authenticated packet. Recovering the full packet number 4216 is necessary to successfully remove packet protection. 4218 Once header protection is removed, the packet number is decoded by 4219 finding the packet number value that is closest to the next expected 4220 packet. The next expected packet is the highest received packet 4221 number plus one. For example, if the highest successfully 4222 authenticated packet had a packet number of 0xa82f30ea, then a packet 4223 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 4224 Example pseudo-code for packet number decoding can be found in 4225 Appendix A. 4227 17.2. Long Header Packets 4229 0 1 2 3 4230 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 4231 +-+-+-+-+-+-+-+-+ 4232 |1|1|T T|X X X X| 4233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4234 | Version (32) | 4235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4236 | DCID Len (8) | 4237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4238 | Destination Connection ID (0..160) ... 4239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4240 | SCID Len (8) | 4241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4242 | Source Connection ID (0..160) ... 4243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4245 Figure 9: Long Header Packet Format 4247 Long headers are used for packets that are sent prior to the 4248 establishment of 1-RTT keys. Once 1-RTT keys are available, a sender 4249 switches to sending packets using the short header (Section 17.3). 4250 The long form allows for special packets - such as the Version 4251 Negotiation packet - to be represented in this uniform fixed-length 4252 packet format. Packets that use the long header contain the 4253 following fields: 4255 Header Form: The most significant bit (0x80) of byte 0 (the first 4256 byte) is set to 1 for long headers. 4258 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4259 containing a zero value for this bit are not valid packets in this 4260 version and MUST be discarded. 4262 Long Packet Type (T): The next two bits (those with a mask of 0x30) 4263 of byte 0 contain a packet type. Packet types are listed in 4264 Table 5. 4266 Type-Specific Bits (X): The lower four bits (those with a mask of 4267 0x0f) of byte 0 are type-specific. 4269 Version: The QUIC Version is a 32-bit field that follows the first 4270 byte. This field indicates which version of QUIC is in use and 4271 determines how the rest of the protocol fields are interpreted. 4273 DCID Len: The byte following the version contains the length in 4274 bytes of the Destination Connection ID field that follows it. 4276 This length is encoded as an 8-bit unsigned integer. In QUIC 4277 version 1, this value MUST NOT exceed 20. Endpoints that receive 4278 a version 1 long header with a value larger than 20 MUST drop the 4279 packet. Servers SHOULD be able to read longer connection IDs from 4280 other QUIC versions in order to properly form a version 4281 negotiation packet. 4283 Destination Connection ID: The Destination Connection ID field 4284 follows the DCID Len and is between 0 and 20 bytes in length. 4285 Section 7.2 describes the use of this field in more detail. 4287 SCID Len: The byte following the Destination Connection ID contains 4288 the length in bytes of the Source Connection ID field that follows 4289 it. This length is encoded as a 8-bit unsigned integer. In QUIC 4290 version 1, this value MUST NOT exceed 20 bytes. Endpoints that 4291 receive a version 1 long header with a value larger than 20 MUST 4292 drop the packet. Servers SHOULD be able to read longer connection 4293 IDs from other QUIC versions in order to properly form a version 4294 negotiation packet. 4296 Source Connection ID: The Source Connection ID field follows the 4297 SCID Len and is between 0 and 20 bytes in length. Section 7.2 4298 describes the use of this field in more detail. 4300 In this version of QUIC, the following packet types with the long 4301 header are defined: 4303 +------+-----------+----------------+ 4304 | Type | Name | Section | 4305 +======+===========+================+ 4306 | 0x0 | Initial | Section 17.2.2 | 4307 +------+-----------+----------------+ 4308 | 0x1 | 0-RTT | Section 17.2.3 | 4309 +------+-----------+----------------+ 4310 | 0x2 | Handshake | Section 17.2.4 | 4311 +------+-----------+----------------+ 4312 | 0x3 | Retry | Section 17.2.5 | 4313 +------+-----------+----------------+ 4315 Table 5: Long Header Packet Types 4317 The header form bit, connection ID lengths byte, Destination and 4318 Source Connection ID fields, and Version fields of a long header 4319 packet are version-independent. The other fields in the first byte 4320 are version-specific. See [QUIC-INVARIANTS] for details on how 4321 packets from different versions of QUIC are interpreted. 4323 The interpretation of the fields and the payload are specific to a 4324 version and packet type. While type-specific semantics for this 4325 version are described in the following sections, several long-header 4326 packets in this version of QUIC contain these additional fields: 4328 Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 4329 are reserved across multiple packet types. These bits are 4330 protected using header protection (see Section 5.4 of [QUIC-TLS]). 4331 The value included prior to protection MUST be set to 0. An 4332 endpoint MUST treat receipt of a packet that has a non-zero value 4333 for these bits, after removing both packet and header protection, 4334 as a connection error of type PROTOCOL_VIOLATION. Discarding such 4335 a packet after only removing header protection can expose the 4336 endpoint to attacks (see Section 9.3 of [QUIC-TLS]). 4338 Packet Number Length (P): In packet types which contain a Packet 4339 Number field, the least significant two bits (those with a mask of 4340 0x03) of byte 0 contain the length of the packet number, encoded 4341 as an unsigned, two-bit integer that is one less than the length 4342 of the packet number field in bytes. That is, the length of the 4343 packet number field is the value of this field, plus one. These 4344 bits are protected using header protection (see Section 5.4 of 4345 [QUIC-TLS]). 4347 Length: The length of the remainder of the packet (that is, the 4348 Packet Number and Payload fields) in bytes, encoded as a variable- 4349 length integer (Section 16). 4351 Packet Number: The packet number field is 1 to 4 bytes long. The 4352 packet number has confidentiality protection separate from packet 4353 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4354 of the packet number field is encoded in the Packet Number Length 4355 bits of byte 0 (see above). 4357 17.2.1. Version Negotiation Packet 4359 A Version Negotiation packet is inherently not version-specific. 4360 Upon receipt by a client, it will be identified as a Version 4361 Negotiation packet based on the Version field having a value of 0. 4363 The Version Negotiation packet is a response to a client packet that 4364 contains a version that is not supported by the server, and is only 4365 sent by servers. 4367 The layout of a Version Negotiation packet is: 4369 0 1 2 3 4370 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 4371 +-+-+-+-+-+-+-+-+ 4372 |1| Unused (7) | 4373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4374 | Version (32) | 4375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4376 | DCID Len (8) | 4377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4378 | Destination Connection ID (0..2040) ... 4379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4380 | SCID Len (8) | 4381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4382 | Source Connection ID (0..2040) ... 4383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4384 | Supported Version 1 (32) ... 4385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4386 | [Supported Version 2 (32)] ... 4387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4388 ... 4389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4390 | [Supported Version N (32)] ... 4391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4393 Figure 10: Version Negotiation Packet 4395 The value in the Unused field is selected randomly by the server. 4396 Clients MUST ignore the value of this field. Servers SHOULD set the 4397 most significant bit of this field (0x40) to 1 so that Version 4398 Negotiation packets appear to have the Fixed Bit field. 4400 The Version field of a Version Negotiation packet MUST be set to 4401 0x00000000. 4403 The server MUST include the value from the Source Connection ID field 4404 of the packet it receives in the Destination Connection ID field. 4405 The value for Source Connection ID MUST be copied from the 4406 Destination Connection ID of the received packet, which is initially 4407 randomly selected by a client. Echoing both connection IDs gives 4408 clients some assurance that the server received the packet and that 4409 the Version Negotiation packet was not generated by an off-path 4410 attacker. 4412 As future versions of QUIC may support Connection IDs larger than the 4413 version 1 limit, Version Negotiation packets could carry Connection 4414 IDs that are longer than 20 bytes. 4416 The remainder of the Version Negotiation packet is a list of 32-bit 4417 versions which the server supports. 4419 A Version Negotiation packet cannot be explicitly acknowledged in an 4420 ACK frame by a client. Receiving another Initial packet implicitly 4421 acknowledges a Version Negotiation packet. 4423 The Version Negotiation packet does not include the Packet Number and 4424 Length fields present in other packets that use the long header form. 4425 Consequently, a Version Negotiation packet consumes an entire UDP 4426 datagram. 4428 A server MUST NOT send more than one Version Negotiation packet in 4429 response to a single UDP datagram. 4431 See Section 6 for a description of the version negotiation process. 4433 17.2.2. Initial Packet 4435 An Initial packet uses long headers with a type value of 0x0. It 4436 carries the first CRYPTO frames sent by the client and server to 4437 perform key exchange, and carries ACKs in either direction. 4439 +-+-+-+-+-+-+-+-+ 4440 |1|1| 0 |R R|P P| 4441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4442 | Version (32) | 4443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4444 | DCID Len (8) | 4445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4446 | Destination Connection ID (0..160) ... 4447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4448 | SCID Len (8) | 4449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4450 | Source Connection ID (0..160) ... 4451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4452 | Token Length (i) ... 4453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4454 | Token (*) ... 4455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 | Length (i) ... 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4458 | Packet Number (8/16/24/32) ... 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4460 | Payload (*) ... 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4463 Figure 11: Initial Packet 4465 The Initial packet contains a long header as well as the Length and 4466 Packet Number fields. The first byte contains the Reserved and 4467 Packet Number Length bits. Between the SCID and Length fields, there 4468 are two additional field specific to the Initial packet. 4470 Token Length: A variable-length integer specifying the length of the 4471 Token field, in bytes. This value is zero if no token is present. 4472 Initial packets sent by the server MUST set the Token Length field 4473 to zero; clients that receive an Initial packet with a non-zero 4474 Token Length field MUST either discard the packet or generate a 4475 connection error of type PROTOCOL_VIOLATION. 4477 Token: The value of the token that was previously provided in a 4478 Retry packet or NEW_TOKEN frame. 4480 Payload: The payload of the packet. 4482 In order to prevent tampering by version-unaware middleboxes, Initial 4483 packets are protected with connection- and version-specific keys 4484 (Initial keys) as described in [QUIC-TLS]. This protection does not 4485 provide confidentiality or integrity against on-path attackers, but 4486 provides some level of protection against off-path attackers. 4488 The client and server use the Initial packet type for any packet that 4489 contains an initial cryptographic handshake message. This includes 4490 all cases where a new packet containing the initial cryptographic 4491 message needs to be created, such as the packets sent after receiving 4492 a Retry packet (Section 17.2.5). 4494 A server sends its first Initial packet in response to a client 4495 Initial. A server may send multiple Initial packets. The 4496 cryptographic key exchange could require multiple round trips or 4497 retransmissions of this data. 4499 The payload of an Initial packet includes a CRYPTO frame (or frames) 4500 containing a cryptographic handshake message, ACK frames, or both. 4501 PING, PADDING, and CONNECTION_CLOSE frames are also permitted. An 4502 endpoint that receives an Initial packet containing other frames can 4503 either discard the packet as spurious or treat it as a connection 4504 error. 4506 The first packet sent by a client always includes a CRYPTO frame that 4507 contains the start or all of the first cryptographic handshake 4508 message. The first CRYPTO frame sent always begins at an offset of 0 4509 (see Section 7). 4511 Note that if the server sends a HelloRetryRequest, the client will 4512 send another series of Initial packets. These Initial packets will 4513 continue the cryptographic handshake and will contain CRYPTO frames 4514 starting at an offset matching the size of the CRYPTO frames sent in 4515 the first flight of Initial packets. 4517 17.2.2.1. Abandoning Initial Packets 4519 A client stops both sending and processing Initial packets when it 4520 sends its first Handshake packet. A server stops sending and 4521 processing Initial packets when it receives its first Handshake 4522 packet. Though packets might still be in flight or awaiting 4523 acknowledgment, no further Initial packets need to be exchanged 4524 beyond this point. Initial packet protection keys are discarded (see 4525 Section 4.10.1 of [QUIC-TLS]) along with any loss recovery and 4526 congestion control state (see Section 6.5 of [QUIC-RECOVERY]). 4528 Any data in CRYPTO frames is discarded - and no longer retransmitted 4529 - when Initial keys are discarded. 4531 17.2.3. 0-RTT 4533 A 0-RTT packet uses long headers with a type value of 0x1, followed 4534 by the Length and Packet Number fields. The first byte contains the 4535 Reserved and Packet Number Length bits. It is used to carry "early" 4536 data from the client to the server as part of the first flight, prior 4537 to handshake completion. As part of the TLS handshake, the server 4538 can accept or reject this early data. 4540 See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its 4541 limitations. 4543 +-+-+-+-+-+-+-+-+ 4544 |1|1| 1 |R R|P P| 4545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4546 | Version (32) | 4547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4548 | DCID Len (8) | 4549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4550 | Destination Connection ID (0..160) ... 4551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4552 | SCID Len (8) | 4553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4554 | Source Connection ID (0..160) ... 4555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4556 | Length (i) ... 4557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4558 | Packet Number (8/16/24/32) ... 4559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4560 | Payload (*) ... 4561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4563 Figure 12: 0-RTT Packet 4565 Packet numbers for 0-RTT protected packets use the same space as 4566 1-RTT protected packets. 4568 After a client receives a Retry packet, 0-RTT packets are likely to 4569 have been lost or discarded by the server. A client SHOULD attempt 4570 to resend data in 0-RTT packets after it sends a new Initial packet. 4572 A client MUST NOT reset the packet number it uses for 0-RTT packets, 4573 since the keys used to protect 0-RTT packets will not change as a 4574 result of responding to a Retry packet. Sending packets with the 4575 same packet number in that case is likely to compromise the packet 4576 protection for all 0-RTT packets because the same key and nonce could 4577 be used to protect different content. 4579 A client only receives acknowledgments for its 0-RTT packets once the 4580 handshake is complete. Consequently, a server might expect 0-RTT 4581 packets to start with a packet number of 0. Therefore, in 4582 determining the length of the packet number encoding for 0-RTT 4583 packets, a client MUST assume that all packets up to the current 4584 packet number are in flight, starting from a packet number of 0. 4585 Thus, 0-RTT packets could need to use a longer packet number 4586 encoding. 4588 A client MUST NOT send 0-RTT packets once it starts processing 1-RTT 4589 packets from the server. This means that 0-RTT packets cannot 4590 contain any response to frames from 1-RTT packets. For instance, a 4591 client cannot send an ACK frame in a 0-RTT packet, because that can 4592 only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT 4593 packet MUST be carried in a 1-RTT packet. 4595 A server SHOULD treat a violation of remembered limits as a 4596 connection error of an appropriate type (for instance, a 4597 FLOW_CONTROL_ERROR for exceeding stream data limits). 4599 17.2.4. Handshake Packet 4601 A Handshake packet uses long headers with a type value of 0x2, 4602 followed by the Length and Packet Number fields. The first byte 4603 contains the Reserved and Packet Number Length bits. It is used to 4604 carry acknowledgments and cryptographic handshake messages from the 4605 server and client. 4607 +-+-+-+-+-+-+-+-+ 4608 |1|1| 2 |R R|P P| 4609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4610 | Version (32) | 4611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4612 | DCID Len (8) | 4613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4614 | Destination Connection ID (0..160) ... 4615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4616 | SCID Len (8) | 4617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4618 | Source Connection ID (0..160) ... 4619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4620 | Length (i) ... 4621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4622 | Packet Number (8/16/24/32) ... 4623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4624 | Payload (*) ... 4625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4627 Figure 13: Handshake Protected Packet 4629 Once a client has received a Handshake packet from a server, it uses 4630 Handshake packets to send subsequent cryptographic handshake messages 4631 and acknowledgments to the server. 4633 The Destination Connection ID field in a Handshake packet contains a 4634 connection ID that is chosen by the recipient of the packet; the 4635 Source Connection ID includes the connection ID that the sender of 4636 the packet wishes to use (see Section 7.2). 4638 Handshake packets are their own packet number space, and thus the 4639 first Handshake packet sent by a server contains a packet number of 4640 0. 4642 The payload of this packet contains CRYPTO frames and could contain 4643 PING, PADDING, or ACK frames. Handshake packets MAY contain 4644 CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake 4645 packets with other frames as a connection error. 4647 Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at 4648 the Handshake encryption level is discarded - and no longer 4649 retransmitted - when Handshake protection keys are discarded. 4651 17.2.5. Retry Packet 4653 A Retry packet uses a long packet header with a type value of 0x3. 4654 It carries an address validation token created by the server. It is 4655 used by a server that wishes to perform a retry (see Section 8.1). 4657 0 1 2 3 4658 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 4659 +-+-+-+-+-+-+-+-+ 4660 |1|1| 3 | Unused| 4661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4662 | Version (32) | 4663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4664 | DCID Len (8) | 4665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4666 | Destination Connection ID (0..160) ... 4667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4668 | SCID Len (8) | 4669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4670 | Source Connection ID (0..160) ... 4671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4672 | Retry Token (*) ... 4673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4674 | | 4675 + + 4676 | | 4677 + Retry Integrity Tag (128) + 4678 | | 4679 + + 4680 | | 4681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4683 Figure 14: Retry Packet 4685 A Retry packet (shown in Figure 14) does not contain any protected 4686 fields. The value in the Unused field is selected randomly by the 4687 server. In addition to the long header, it contains these additional 4688 fields: 4690 Retry Token: An opaque token that the server can use to validate the 4691 client's address. 4693 Retry Integrity Tag: See the Retry Packet Integrity section of 4694 [QUIC-TLS]. 4696 The server populates the Destination Connection ID with the 4697 connection ID that the client included in the Source Connection ID of 4698 the Initial packet. 4700 The server includes a connection ID of its choice in the Source 4701 Connection ID field. This value MUST not be equal to the Destination 4702 Connection ID field of the packet sent by the client. A client MUST 4703 discard a Retry packet that contains a Source Connection ID field 4704 that is identical to the Destination Connection ID field of its 4705 Initial packet. The client MUST use the value from the Source 4706 Connection ID field of the Retry packet in the Destination Connection 4707 ID field of subsequent packets that it sends. 4709 A server MAY send Retry packets in response to Initial and 0-RTT 4710 packets. A server can either discard or buffer 0-RTT packets that it 4711 receives. A server can send multiple Retry packets as it receives 4712 Initial or 0-RTT packets. A server MUST NOT send more than one Retry 4713 packet in response to a single UDP datagram. 4715 A client MUST accept and process at most one Retry packet for each 4716 connection attempt. After the client has received and processed an 4717 Initial or Retry packet from the server, it MUST discard any 4718 subsequent Retry packets that it receives. 4720 Clients MUST discard Retry packets that have a Retry Integrity Tag 4721 that cannot be validated, see the Retry Packet Integrity section of 4722 [QUIC-TLS]. This diminishes an off-path attacker's ability to inject 4723 a Retry packet and protects against accidental corruption of Retry 4724 packets. A client MUST discard a Retry packet with a zero-length 4725 Retry Token field. 4727 The client responds to a Retry packet with an Initial packet that 4728 includes the provided Retry Token to continue connection 4729 establishment. 4731 A client sets the Destination Connection ID field of this Initial 4732 packet to the value from the Source Connection ID in the Retry 4733 packet. Changing Destination Connection ID also results in a change 4734 to the keys used to protect the Initial packet. It also sets the 4735 Token field to the token provided in the Retry. The client MUST NOT 4736 change the Source Connection ID because the server could include the 4737 connection ID as part of its token validation logic (see 4738 Section 8.1.4). 4740 The next Initial packet from the client uses the connection ID and 4741 token values from the Retry packet (see Section 7.2). Aside from 4742 this, the Initial packet sent by the client is subject to the same 4743 restrictions as the first Initial packet. A client MUST use the same 4744 cryptographic handshake message it includes in this packet. A server 4745 MAY treat a packet that contains a different cryptographic handshake 4746 message as a connection error or discard it. 4748 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4749 0-RTT packets to the connection ID provided by the server. A client 4750 MUST NOT change the cryptographic handshake message it sends in 4751 response to receiving a Retry. 4753 A client MUST NOT reset the packet number for any packet number space 4754 after processing a Retry packet; Section 17.2.3 contains more 4755 information on this. 4757 A server acknowledges the use of a Retry packet for a connection 4758 using the original_connection_id transport parameter (see 4759 Section 18.2). If the server sends a Retry packet, it MUST include 4760 the Destination Connection ID field from the client's first Initial 4761 packet in the transport parameter. 4763 If the client received and processed a Retry packet, it MUST validate 4764 that the original_connection_id transport parameter is present and 4765 correct; otherwise, it MUST validate that the transport parameter is 4766 absent. A client MUST treat a failed validation as a connection 4767 error of type TRANSPORT_PARAMETER_ERROR. 4769 A Retry packet does not include a packet number and cannot be 4770 explicitly acknowledged by a client. 4772 17.3. Short Header Packets 4774 This version of QUIC defines a single packet type which uses the 4775 short packet header. 4777 0 1 2 3 4778 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 4779 +-+-+-+-+-+-+-+-+ 4780 |0|1|S|R|R|K|P P| 4781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4782 | Destination Connection ID (0..160) ... 4783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4784 | Packet Number (8/16/24/32) ... 4785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4786 | Protected Payload (*) ... 4787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4789 Figure 15: Short Header Packet Format 4791 The short header can be used after the version and 1-RTT keys are 4792 negotiated. Packets that use the short header contain the following 4793 fields: 4795 Header Form: The most significant bit (0x80) of byte 0 is set to 0 4796 for the short header. 4798 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4799 containing a zero value for this bit are not valid packets in this 4800 version and MUST be discarded. 4802 Spin Bit (S): The third most significant bit (0x20) of byte 0 is the 4803 latency spin bit, set as described in Section 17.3.1. 4805 Reserved Bits (R): The next two bits (those with a mask of 0x18) of 4806 byte 0 are reserved. These bits are protected using header 4807 protection (see Section 5.4 of [QUIC-TLS]). The value included 4808 prior to protection MUST be set to 0. An endpoint MUST treat 4809 receipt of a packet that has a non-zero value for these bits, 4810 after removing both packet and header protection, as a connection 4811 error of type PROTOCOL_VIOLATION. Discarding such a packet after 4812 only removing header protection can expose the endpoint to attacks 4813 (see Section 9.3 of [QUIC-TLS]). 4815 Key Phase (K): The next bit (0x04) of byte 0 indicates the key 4816 phase, which allows a recipient of a packet to identify the packet 4817 protection keys that are used to protect the packet. See 4818 [QUIC-TLS] for details. This bit is protected using header 4819 protection (see Section 5.4 of [QUIC-TLS]). 4821 Packet Number Length (P): The least significant two bits (those with 4822 a mask of 0x03) of byte 0 contain the length of the packet number, 4823 encoded as an unsigned, two-bit integer that is one less than the 4824 length of the packet number field in bytes. That is, the length 4825 of the packet number field is the value of this field, plus one. 4826 These bits are protected using header protection (see Section 5.4 4827 of [QUIC-TLS]). 4829 Destination Connection ID: The Destination Connection ID is a 4830 connection ID that is chosen by the intended recipient of the 4831 packet. See Section 5.1 for more details. 4833 Packet Number: The packet number field is 1 to 4 bytes long. The 4834 packet number has confidentiality protection separate from packet 4835 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4836 of the packet number field is encoded in Packet Number Length 4837 field. See Section 17.1 for details. 4839 Protected Payload: Packets with a short header always include a 4840 1-RTT protected payload. 4842 The header form bit and the connection ID field of a short header 4843 packet are version-independent. The remaining fields are specific to 4844 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 4845 packets from different versions of QUIC are interpreted. 4847 17.3.1. Latency Spin Bit 4849 The latency spin bit enables passive latency monitoring from 4850 observation points on the network path throughout the duration of a 4851 connection. The spin bit is only present in the short packet header, 4852 since it is possible to measure the initial RTT of a connection by 4853 observing the handshake. Therefore, the spin bit is available after 4854 version negotiation and connection establishment are completed. On- 4855 path measurement and use of the latency spin bit is further discussed 4856 in [QUIC-MANAGEABILITY]. 4858 The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that 4859 chooses to support the spin bit MUST implement it as specified in 4860 this section. 4862 Each endpoint unilaterally decides if the spin bit is enabled or 4863 disabled for a connection. Implementations MUST allow administrators 4864 of clients and servers to disable the spin bit either globally or on 4865 a per-connection basis. Even when the spin bit is not disabled by 4866 the administrator, endpoints MUST disable their use of the spin bit 4867 for a random selection of at least one in every 16 network paths, or 4868 for one in every 16 connection IDs. As each endpoint disables the 4869 spin bit independently, this ensures that the spin bit signal is 4870 disabled on approximately one in eight network paths. 4872 When the spin bit is disabled, endpoints MAY set the spin bit to any 4873 value, and MUST ignore any incoming value. It is RECOMMENDED that 4874 endpoints set the spin bit to a random value either chosen 4875 independently for each packet or chosen independently for each 4876 connection ID. 4878 If the spin bit is enabled for the connection, the endpoint maintains 4879 a spin value and sets the spin bit in the short header to the 4880 currently stored value when a packet with a short header is sent out. 4881 The spin value is initialized to 0 in the endpoint at connection 4882 start. Each endpoint also remembers the highest packet number seen 4883 from its peer on the connection. 4885 When a server receives a short header packet that increments the 4886 highest packet number seen by the server from the client, it sets the 4887 spin value to be equal to the spin bit in the received packet. 4889 When a client receives a short header packet that increments the 4890 highest packet number seen by the client from the server, it sets the 4891 spin value to the inverse of the spin bit in the received packet. 4893 An endpoint resets its spin value to zero when sending the first 4894 packet of a given connection with a new connection ID. This reduces 4895 the risk that transient spin bit state can be used to link flows 4896 across connection migration or ID change. 4898 With this mechanism, the server reflects the spin value received, 4899 while the client 'spins' it after one RTT. On-path observers can 4900 measure the time between two spin bit toggle events to estimate the 4901 end-to-end RTT of a connection. 4903 18. Transport Parameter Encoding 4905 The "extension_data" field of the quic_transport_parameters extension 4906 defined in [QUIC-TLS] contains the QUIC transport parameters. They 4907 are encoded as a length-prefixed sequence of transport parameters, as 4908 shown in Figure 16: 4910 0 1 2 3 4911 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 4912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4913 | Sequence Length (16) | 4914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4915 | Transport Parameter 1 (*) ... 4916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4917 | Transport Parameter 2 (*) ... 4918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4919 ... 4920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4921 | Transport Parameter N (*) ... 4922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4924 Figure 16: Sequence of Transport Parameters 4926 The Sequence Length field contains the length of the sequence of 4927 transport parameters, in bytes. Each transport parameter is encoded 4928 as an (identifier, length, value) tuple, as shown in Figure 17: 4930 0 1 2 3 4931 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 4932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4933 | Transport Parameter ID (16) | Transport Param Length (16) | 4934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4935 | Transport Parameter Value (*) ... 4936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4938 Figure 17: Transport Parameter Encoding 4940 The Transport Param Length field contains the length of the Transport 4941 Parameter Value field. 4943 QUIC encodes transport parameters into a sequence of bytes, which are 4944 then included in the cryptographic handshake. 4946 18.1. Reserved Transport Parameters 4948 Transport parameters with an identifier of the form "31 * N + 27" for 4949 integer values of N are reserved to exercise the requirement that 4950 unknown transport parameters be ignored. These transport parameters 4951 have no semantics, and may carry arbitrary values. 4953 18.2. Transport Parameter Definitions 4955 This section details the transport parameters defined in this 4956 document. 4958 Many transport parameters listed here have integer values. Those 4959 transport parameters that are identified as integers use a variable- 4960 length integer encoding (see Section 16) and have a default value of 4961 0 if the transport parameter is absent, unless otherwise stated. 4963 The following transport parameters are defined: 4965 original_connection_id (0x0000): The value of the Destination 4966 Connection ID field from the first Initial packet sent by the 4967 client. This transport parameter is only sent by a server. This 4968 is the same value sent in the "Original Destination Connection ID" 4969 field of a Retry packet (see Section 17.2.5). A server MUST 4970 include the original_connection_id transport parameter if it sent 4971 a Retry packet. 4973 max_idle_timeout (0x0001): The max idle timeout is a value in 4974 milliseconds that is encoded as an integer; see (Section 10.2). 4975 Idle timeout is disabled when both endpoints omit this transport 4976 parameter or specify a value of 0. 4978 stateless_reset_token (0x0002): A stateless reset token is used in 4979 verifying a stateless reset; see Section 10.4. This parameter is 4980 a sequence of 16 bytes. This transport parameter MUST NOT be sent 4981 by a client, but MAY be sent by a server. A server that does not 4982 send this transport parameter cannot use stateless reset 4983 (Section 10.4) for the connection ID negotiated during the 4984 handshake. 4986 max_packet_size (0x0003): The maximum packet size parameter is an 4987 integer value that limits the size of packets that the endpoint is 4988 willing to receive. This indicates that packets larger than this 4989 limit will be dropped. The default for this parameter is the 4990 maximum permitted UDP payload of 65527. Values below 1200 are 4991 invalid. This limit only applies to protected packets 4992 (Section 12.1). 4994 initial_max_data (0x0004): The initial maximum data parameter is an 4995 integer value that contains the initial value for the maximum 4996 amount of data that can be sent on the connection. This is 4997 equivalent to sending a MAX_DATA (Section 19.9) for the connection 4998 immediately after completing the handshake. 5000 initial_max_stream_data_bidi_local (0x0005): This parameter is an 5001 integer value specifying the initial flow control limit for 5002 locally-initiated bidirectional streams. This limit applies to 5003 newly created bidirectional streams opened by the endpoint that 5004 sends the transport parameter. In client transport parameters, 5005 this applies to streams with an identifier with the least 5006 significant two bits set to 0x0; in server transport parameters, 5007 this applies to streams with the least significant two bits set to 5008 0x1. 5010 initial_max_stream_data_bidi_remote (0x0006): This parameter is an 5011 integer value specifying the initial flow control limit for peer- 5012 initiated bidirectional streams. This limit applies to newly 5013 created bidirectional streams opened by the endpoint that receives 5014 the transport parameter. In client transport parameters, this 5015 applies to streams with an identifier with the least significant 5016 two bits set to 0x1; in server transport parameters, this applies 5017 to streams with the least significant two bits set to 0x0. 5019 initial_max_stream_data_uni (0x0007): This parameter is an integer 5020 value specifying the initial flow control limit for unidirectional 5021 streams. This limit applies to newly created unidirectional 5022 streams opened by the endpoint that receives the transport 5023 parameter. In client transport parameters, this applies to 5024 streams with an identifier with the least significant two bits set 5025 to 0x3; in server transport parameters, this applies to streams 5026 with the least significant two bits set to 0x2. 5028 initial_max_streams_bidi (0x0008): The initial maximum bidirectional 5029 streams parameter is an integer value that contains the initial 5030 maximum number of bidirectional streams the peer may initiate. If 5031 this parameter is absent or zero, the peer cannot open 5032 bidirectional streams until a MAX_STREAMS frame is sent. Setting 5033 this parameter is equivalent to sending a MAX_STREAMS 5034 (Section 19.11) of the corresponding type with the same value. 5036 initial_max_streams_uni (0x0009): The initial maximum unidirectional 5037 streams parameter is an integer value that contains the initial 5038 maximum number of unidirectional streams the peer may initiate. 5039 If this parameter is absent or zero, the peer cannot open 5040 unidirectional streams until a MAX_STREAMS frame is sent. Setting 5041 this parameter is equivalent to sending a MAX_STREAMS 5042 (Section 19.11) of the corresponding type with the same value. 5044 ack_delay_exponent (0x000a): The ACK delay exponent is an integer 5045 value indicating an exponent used to decode the ACK Delay field in 5046 the ACK frame (Section 19.3). If this value is absent, a default 5047 value of 3 is assumed (indicating a multiplier of 8). Values 5048 above 20 are invalid. 5050 max_ack_delay (0x000b): The maximum ACK delay is an integer value 5051 indicating the maximum amount of time in milliseconds by which the 5052 endpoint will delay sending acknowledgments. This value SHOULD 5053 include the receiver's expected delays in alarms firing. For 5054 example, if a receiver sets a timer for 5ms and alarms commonly 5055 fire up to 1ms late, then it should send a max_ack_delay of 6ms. 5056 If this value is absent, a default of 25 milliseconds is assumed. 5057 Values of 2^14 or greater are invalid. 5059 disable_active_migration (0x000c): The disable active migration 5060 transport parameter is included if the endpoint does not support 5061 active connection migration (Section 9). Peers of an endpoint 5062 that sets this transport parameter MUST NOT send any packets, 5063 including probing packets (Section 9.1), from a local address or 5064 port other than that used to perform the handshake. This 5065 parameter is a zero-length value. 5067 preferred_address (0x000d): The server's preferred address is used 5068 to effect a change in server address at the end of the handshake, 5069 as described in Section 9.6. The format of this transport 5070 parameter is shown in Figure 18. This transport parameter is only 5071 sent by a server. Servers MAY choose to only send a preferred 5072 address of one address family by sending an all-zero address and 5073 port (0.0.0.0:0 or ::.0) for the other family. IP addresses are 5074 encoded in network byte order. The CID Length field contains the 5075 length of the Connection ID field. 5077 0 1 2 3 5078 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 5079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5080 | IPv4 Address (32) | 5081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5082 | IPv4 Port (16) | 5083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5084 | | 5085 + + 5086 | | 5087 + IPv6 Address (128) + 5088 | | 5089 + + 5090 | | 5091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5092 | IPv6 Port (16) | 5093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5094 | CID Length (8)| 5095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5096 | Connection ID (*) ... 5097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5098 | | 5099 + + 5100 | | 5101 + Stateless Reset Token (128) + 5102 | | 5103 + + 5104 | | 5105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5107 Figure 18: Preferred Address format 5109 active_connection_id_limit (0x000e): The active connection ID limit 5110 is an integer value specifying the maximum number of connection 5111 IDs from the peer that an endpoint is willing to store. This 5112 value includes the connection ID received during the handshake, 5113 that received in the preferred_address transport parameter, and 5114 those received in NEW_CONNECTION_ID frames. Unless a zero-length 5115 connection ID is being used, the value of the 5116 active_connection_id_limit parameter MUST be no less than 2. If 5117 this transport parameter is absent, a default of 2 is assumed. 5118 When a zero-length connection ID is being used, the 5119 active_connection_id_limit parameter MUST NOT be sent. 5121 If present, transport parameters that set initial flow control limits 5122 (initial_max_stream_data_bidi_local, 5123 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 5124 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 5125 every stream of the corresponding type immediately after opening. If 5126 the transport parameter is absent, streams of that type start with a 5127 flow control limit of 0. 5129 A client MUST NOT include server-only transport parameters 5130 (original_connection_id, stateless_reset_token, or 5131 preferred_address). A server MUST treat receipt of any of these 5132 transport parameters as a connection error of type 5133 TRANSPORT_PARAMETER_ERROR. 5135 19. Frame Types and Formats 5137 As described in Section 12.4, packets contain one or more frames. 5138 This section describes the format and semantics of the core QUIC 5139 frame types. 5141 19.1. PADDING Frame 5143 The PADDING frame (type=0x00) has no semantic value. PADDING frames 5144 can be used to increase the size of a packet. Padding can be used to 5145 increase an initial client packet to the minimum required size, or to 5146 provide protection against traffic analysis for protected packets. 5148 A PADDING frame has no content. That is, a PADDING frame consists of 5149 the single byte that identifies the frame as a PADDING frame. 5151 19.2. PING Frame 5153 Endpoints can use PING frames (type=0x01) to verify that their peers 5154 are still alive or to check reachability to the peer. The PING frame 5155 contains no additional fields. 5157 The receiver of a PING frame simply needs to acknowledge the packet 5158 containing this frame. 5160 The PING frame can be used to keep a connection alive when an 5161 application or application protocol wishes to prevent the connection 5162 from timing out. An application protocol SHOULD provide guidance 5163 about the conditions under which generating a PING is recommended. 5164 This guidance SHOULD indicate whether it is the client or the server 5165 that is expected to send the PING. Having both endpoints send PING 5166 frames without coordination can produce an excessive number of 5167 packets and poor performance. 5169 A connection will time out if no packets are sent or received for a 5170 period longer than the time negotiated using the max_idle_timeout 5171 transport parameter (see Section 10). However, state in middleboxes 5172 might time out earlier than that. Though REQ-5 in [RFC4787] 5173 recommends a 2 minute timeout interval, experience shows that sending 5174 packets every 15 to 30 seconds is necessary to prevent the majority 5175 of middleboxes from losing state for UDP flows. 5177 19.3. ACK Frames 5179 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 5180 packets they have received and processed. The ACK frame contains one 5181 or more ACK Ranges. ACK Ranges identify acknowledged packets. If 5182 the frame type is 0x03, ACK frames also contain the sum of QUIC 5183 packets with associated ECN marks received on the connection up until 5184 this point. QUIC implementations MUST properly handle both types 5185 and, if they have enabled ECN for packets they send, they SHOULD use 5186 the information in the ECN section to manage their congestion state. 5188 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 5189 remains acknowledged, even if it does not appear in a future ACK 5190 frame. This is unlike TCP SACKs ([RFC2018]). 5192 Packets from different packet number spaces can be identified using 5193 the same numeric value. An acknowledgment for a packet needs to 5194 indicate both a packet number and a packet number space. This is 5195 accomplished by having each ACK frame only acknowledge packet numbers 5196 in the same space as the packet in which the ACK frame is contained. 5198 Version Negotiation and Retry packets cannot be acknowledged because 5199 they do not contain a packet number. Rather than relying on ACK 5200 frames, these packets are implicitly acknowledged by the next Initial 5201 packet sent by the client. 5203 An ACK frame is shown in Figure 19. 5205 0 1 2 3 5206 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 5207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5208 | Largest Acknowledged (i) ... 5209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5210 | ACK Delay (i) ... 5211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5212 | ACK Range Count (i) ... 5213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5214 | First ACK Range (i) ... 5215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5216 | ACK Ranges (*) ... 5217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5218 | [ECN Counts] ... 5219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5220 Figure 19: ACK Frame Format 5222 ACK frames contain the following fields: 5224 Largest Acknowledged: A variable-length integer representing the 5225 largest packet number the peer is acknowledging; this is usually 5226 the largest packet number that the peer has received prior to 5227 generating the ACK frame. Unlike the packet number in the QUIC 5228 long or short header, the value in an ACK frame is not truncated. 5230 ACK Delay: A variable-length integer representing the time delta in 5231 microseconds between when this ACK was sent and when the largest 5232 acknowledged packet, as indicated in the Largest Acknowledged 5233 field, was received by this peer. The value of the ACK Delay 5234 field is scaled by multiplying the encoded value by 2 to the power 5235 of the value of the "ack_delay_exponent" transport parameter set 5236 by the sender of the ACK frame (see Section 18.2). Scaling in 5237 this fashion allows for a larger range of values with a shorter 5238 encoding at the cost of lower resolution. Because the receiver 5239 doesn't use the ACK Delay for Initial and Handshake packets, a 5240 sender SHOULD send a value of 0. 5242 ACK Range Count: A variable-length integer specifying the number of 5243 Gap and ACK Range fields in the frame. 5245 First ACK Range: A variable-length integer indicating the number of 5246 contiguous packets preceding the Largest Acknowledged that are 5247 being acknowledged. The First ACK Range is encoded as an ACK 5248 Range (see Section 19.3.1) starting from the Largest Acknowledged. 5249 That is, the smallest packet acknowledged in the range is 5250 determined by subtracting the First ACK Range value from the 5251 Largest Acknowledged. 5253 ACK Ranges: Contains additional ranges of packets which are 5254 alternately not acknowledged (Gap) and acknowledged (ACK Range); 5255 see Section 19.3.1. 5257 ECN Counts: The three ECN Counts; see Section 19.3.2. 5259 19.3.1. ACK Ranges 5261 The ACK Ranges field consists of alternating Gap and ACK Range values 5262 in descending packet number order. The number of Gap and ACK Range 5263 values is determined by the ACK Range Count field; one of each value 5264 is present for each value in the ACK Range Count field. 5266 ACK Ranges are structured as shown in Figure 20. 5268 0 1 2 3 5269 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 5270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5271 | [Gap (i)] ... 5272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5273 | [ACK Range (i)] ... 5274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5275 | [Gap (i)] ... 5276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5277 | [ACK Range (i)] ... 5278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5279 ... 5280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5281 | [Gap (i)] ... 5282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5283 | [ACK Range (i)] ... 5284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5286 Figure 20: ACK Ranges 5288 The fields that form the ACK Ranges are: 5290 Gap (repeated): A variable-length integer indicating the number of 5291 contiguous unacknowledged packets preceding the packet number one 5292 lower than the smallest in the preceding ACK Range. 5294 ACK Range (repeated): A variable-length integer indicating the 5295 number of contiguous acknowledged packets preceding the largest 5296 packet number, as determined by the preceding Gap. 5298 Gap and ACK Range value use a relative integer encoding for 5299 efficiency. Though each encoded value is positive, the values are 5300 subtracted, so that each ACK Range describes progressively lower- 5301 numbered packets. 5303 Each ACK Range acknowledges a contiguous range of packets by 5304 indicating the number of acknowledged packets that precede the 5305 largest packet number in that range. A value of zero indicates that 5306 only the largest packet number is acknowledged. Larger ACK Range 5307 values indicate a larger range, with corresponding lower values for 5308 the smallest packet number in the range. Thus, given a largest 5309 packet number for the range, the smallest value is determined by the 5310 formula: 5312 smallest = largest - ack_range 5314 An ACK Range acknowledges all packets between the smallest packet 5315 number and the largest, inclusive. 5317 The largest value for an ACK Range is determined by cumulatively 5318 subtracting the size of all preceding ACK Ranges and Gaps. 5320 Each Gap indicates a range of packets that are not being 5321 acknowledged. The number of packets in the gap is one higher than 5322 the encoded value of the Gap field. 5324 The value of the Gap field establishes the largest packet number 5325 value for the subsequent ACK Range using the following formula: 5327 largest = previous_smallest - gap - 2 5329 If any computed packet number is negative, an endpoint MUST generate 5330 a connection error of type FRAME_ENCODING_ERROR. 5332 19.3.2. ECN Counts 5334 The ACK frame uses the least significant bit (that is, type 0x03) to 5335 indicate ECN feedback and report receipt of QUIC packets with 5336 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 5337 header. ECN Counts are only present when the ACK frame type is 0x03. 5339 ECN Counts are only parsed when the ACK frame type is 0x03. There 5340 are 3 ECN counts, as shown in Figure 21. 5342 0 1 2 3 5343 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 5344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5345 | ECT(0) Count (i) ... 5346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5347 | ECT(1) Count (i) ... 5348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5349 | ECN-CE Count (i) ... 5350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5352 Figure 21: ECN Count Format 5354 The three ECN Counts are: 5356 ECT(0) Count: A variable-length integer representing the total 5357 number of packets received with the ECT(0) codepoint in the packet 5358 number space of the ACK frame. 5360 ECT(1) Count: A variable-length integer representing the total 5361 number of packets received with the ECT(1) codepoint in the packet 5362 number space of the ACK frame. 5364 CE Count: A variable-length integer representing the total number of 5365 packets received with the CE codepoint in the packet number space 5366 of the ACK frame. 5368 ECN counts are maintained separately for each packet number space. 5370 19.4. RESET_STREAM Frame 5372 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 5373 terminate the sending part of a stream. 5375 After sending a RESET_STREAM, an endpoint ceases transmission and 5376 retransmission of STREAM frames on the identified stream. A receiver 5377 of RESET_STREAM can discard any data that it already received on that 5378 stream. 5380 An endpoint that receives a RESET_STREAM frame for a send-only stream 5381 MUST terminate the connection with error STREAM_STATE_ERROR. 5383 The RESET_STREAM frame is shown in Figure 22. 5385 0 1 2 3 5386 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 5387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5388 | Stream ID (i) ... 5389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5390 | Application Error Code (i) ... 5391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5392 | Final Size (i) ... 5393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5395 Figure 22: RESET_STREAM Frame Format 5397 RESET_STREAM frames contain the following fields: 5399 Stream ID: A variable-length integer encoding of the Stream ID of 5400 the stream being terminated. 5402 Application Protocol Error Code: A variable-length integer 5403 containing the application protocol error code (see Section 20.1) 5404 which indicates why the stream is being closed. 5406 Final Size: A variable-length integer indicating the final size of 5407 the stream by the RESET_STREAM sender, in unit of bytes. 5409 19.5. STOP_SENDING Frame 5411 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 5412 incoming data is being discarded on receipt at application request. 5413 STOP_SENDING requests that a peer cease transmission on a stream. 5415 A STOP_SENDING frame can be sent for streams in the Recv or Size 5416 Known states (see Section 3.1). Receiving a STOP_SENDING frame for a 5417 locally-initiated stream that has not yet been created MUST be 5418 treated as a connection error of type STREAM_STATE_ERROR. An 5419 endpoint that receives a STOP_SENDING frame for a receive-only stream 5420 MUST terminate the connection with error STREAM_STATE_ERROR. 5422 The STOP_SENDING frame is shown in Figure 23. 5424 0 1 2 3 5425 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 5426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5427 | Stream ID (i) ... 5428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5429 | Application Error Code (i) ... 5430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5432 Figure 23: STOP_SENDING Frame Format 5434 STOP_SENDING frames contain the following fields: 5436 Stream ID: A variable-length integer carrying the Stream ID of the 5437 stream being ignored. 5439 Application Error Code: A variable-length integer containing the 5440 application-specified reason the sender is ignoring the stream 5441 (see Section 20.1). 5443 19.6. CRYPTO Frame 5445 The CRYPTO frame (type=0x06) is used to transmit cryptographic 5446 handshake messages. It can be sent in all packet types except 0-RTT. 5447 The CRYPTO frame offers the cryptographic protocol an in-order stream 5448 of bytes. CRYPTO frames are functionally identical to STREAM frames, 5449 except that they do not bear a stream identifier; they are not flow 5450 controlled; and they do not carry markers for optional offset, 5451 optional length, and the end of the stream. 5453 The CRYPTO frame is shown in Figure 24. 5455 0 1 2 3 5456 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 5457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5458 | Offset (i) ... 5459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5460 | Length (i) ... 5461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5462 | Crypto Data (*) ... 5463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5465 Figure 24: CRYPTO Frame Format 5467 CRYPTO frames contain the following fields: 5469 Offset: A variable-length integer specifying the byte offset in the 5470 stream for the data in this CRYPTO frame. 5472 Length: A variable-length integer specifying the length of the 5473 Crypto Data field in this CRYPTO frame. 5475 Crypto Data: The cryptographic message data. 5477 There is a separate flow of cryptographic handshake data in each 5478 encryption level, each of which starts at an offset of 0. This 5479 implies that each encryption level is treated as a separate CRYPTO 5480 stream of data. 5482 The largest offset delivered on a stream - the sum of the offset and 5483 data length - cannot exceed 2^62-1. Receipt of a frame that exceeds 5484 this limit MUST be treated as a connection error of type 5485 FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. 5487 Unlike STREAM frames, which include a Stream ID indicating to which 5488 stream the data belongs, the CRYPTO frame carries data for a single 5489 stream per encryption level. The stream does not have an explicit 5490 end, so CRYPTO frames do not have a FIN bit. 5492 19.7. NEW_TOKEN Frame 5494 A server sends a NEW_TOKEN frame (type=0x07) to provide the client 5495 with a token to send in the header of an Initial packet for a future 5496 connection. 5498 The NEW_TOKEN frame is shown in Figure 25. 5500 0 1 2 3 5501 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 5502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5503 | Token Length (i) ... 5504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5505 | Token (*) ... 5506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5508 Figure 25: NEW_TOKEN Frame Format 5510 NEW_TOKEN frames contain the following fields: 5512 Token Length: A variable-length integer specifying the length of the 5513 token in bytes. 5515 Token: An opaque blob that the client may use with a future Initial 5516 packet. The token MUST NOT be empty. An endpoint MUST treat 5517 receipt of a NEW_TOKEN frame with an empty Token field as a 5518 connection error of type FRAME_ENCODING_ERROR. 5520 An endpoint might receive multiple NEW_TOKEN frames that contain the 5521 same token value if packets containing the frame are incorrectly 5522 determined to be lost. Endpoints are responsible for discarding 5523 duplicate values, which might be used to link connection attempts; 5524 see Section 8.1.3. 5526 Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt 5527 of a NEW_TOKEN frame as a connection error of type 5528 PROTOCOL_VIOLATION. 5530 19.8. STREAM Frames 5532 STREAM frames implicitly create a stream and carry stream data. The 5533 STREAM frame takes the form 0b00001XXX (or the set of values from 5534 0x08 to 0x0f). The value of the three low-order bits of the frame 5535 type determines the fields that are present in the frame. 5537 * The OFF bit (0x04) in the frame type is set to indicate that there 5538 is an Offset field present. When set to 1, the Offset field is 5539 present. When set to 0, the Offset field is absent and the Stream 5540 Data starts at an offset of 0 (that is, the frame contains the 5541 first bytes of the stream, or the end of a stream that includes no 5542 data). 5544 * The LEN bit (0x02) in the frame type is set to indicate that there 5545 is a Length field present. If this bit is set to 0, the Length 5546 field is absent and the Stream Data field extends to the end of 5547 the packet. If this bit is set to 1, the Length field is present. 5549 * The FIN bit (0x01) of the frame type is set only on frames that 5550 contain the final size of the stream. Setting this bit indicates 5551 that the frame marks the end of the stream. 5553 An endpoint that receives a STREAM frame for a send-only stream MUST 5554 terminate the connection with error STREAM_STATE_ERROR. 5556 The STREAM frames are shown in Figure 26. 5558 0 1 2 3 5559 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 5560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5561 | Stream ID (i) ... 5562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5563 | [Offset (i)] ... 5564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5565 | [Length (i)] ... 5566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5567 | Stream Data (*) ... 5568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5570 Figure 26: STREAM Frame Format 5572 STREAM frames contain the following fields: 5574 Stream ID: A variable-length integer indicating the stream ID of the 5575 stream (see Section 2.1). 5577 Offset: A variable-length integer specifying the byte offset in the 5578 stream for the data in this STREAM frame. This field is present 5579 when the OFF bit is set to 1. When the Offset field is absent, 5580 the offset is 0. 5582 Length: A variable-length integer specifying the length of the 5583 Stream Data field in this STREAM frame. This field is present 5584 when the LEN bit is set to 1. When the LEN bit is set to 0, the 5585 Stream Data field consumes all the remaining bytes in the packet. 5587 Stream Data: The bytes from the designated stream to be delivered. 5589 When a Stream Data field has a length of 0, the offset in the STREAM 5590 frame is the offset of the next byte that would be sent. 5592 The first byte in the stream has an offset of 0. The largest offset 5593 delivered on a stream - the sum of the offset and data length - 5594 cannot exceed 2^62-1, as it is not possible to provide flow control 5595 credit for that data. Receipt of a frame that exceeds this limit 5596 MUST be treated as a connection error of type FRAME_ENCODING_ERROR or 5597 FLOW_CONTROL_ERROR. 5599 19.9. MAX_DATA Frame 5601 The MAX_DATA frame (type=0x10) is used in flow control to inform the 5602 peer of the maximum amount of data that can be sent on the connection 5603 as a whole. 5605 The MAX_DATA frame is shown in Figure 27. 5607 0 1 2 3 5608 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 5609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5610 | Maximum Data (i) ... 5611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5613 Figure 27: MAX_DATA Frame Format 5615 MAX_DATA frames contain the following fields: 5617 Maximum Data: A variable-length integer indicating the maximum 5618 amount of data that can be sent on the entire connection, in units 5619 of bytes. 5621 All data sent in STREAM frames counts toward this limit. The sum of 5622 the largest received offsets on all streams - including streams in 5623 terminal states - MUST NOT exceed the value advertised by a receiver. 5624 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 5625 error if it receives more data than the maximum data value that it 5626 has sent, unless this is a result of a change in the initial limits 5627 (see Section 7.3.1). 5629 19.10. MAX_STREAM_DATA Frame 5631 The MAX_STREAM_DATA frame (type=0x11) is used in flow control to 5632 inform a peer of the maximum amount of data that can be sent on a 5633 stream. 5635 A MAX_STREAM_DATA frame can be sent for streams in the Recv state 5636 (see Section 3.1). Receiving a MAX_STREAM_DATA frame for a locally- 5637 initiated stream that has not yet been created MUST be treated as a 5638 connection error of type STREAM_STATE_ERROR. An endpoint that 5639 receives a MAX_STREAM_DATA frame for a receive-only stream MUST 5640 terminate the connection with error STREAM_STATE_ERROR. 5642 The MAX_STREAM_DATA frame is shown in Figure 28. 5644 0 1 2 3 5645 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 5646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5647 | Stream ID (i) ... 5648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5649 | Maximum Stream Data (i) ... 5650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5652 Figure 28: MAX_STREAM_DATA Frame Format 5654 MAX_STREAM_DATA frames contain the following fields: 5656 Stream ID: The stream ID of the stream that is affected encoded as a 5657 variable-length integer. 5659 Maximum Stream Data: A variable-length integer indicating the 5660 maximum amount of data that can be sent on the identified stream, 5661 in units of bytes. 5663 When counting data toward this limit, an endpoint accounts for the 5664 largest received offset of data that is sent or received on the 5665 stream. Loss or reordering can mean that the largest received offset 5666 on a stream can be greater than the total size of data received on 5667 that stream. Receiving STREAM frames might not increase the largest 5668 received offset. 5670 The data sent on a stream MUST NOT exceed the largest maximum stream 5671 data value advertised by the receiver. An endpoint MUST terminate a 5672 connection with a FLOW_CONTROL_ERROR error if it receives more data 5673 than the largest maximum stream data that it has sent for the 5674 affected stream, unless this is a result of a change in the initial 5675 limits (see Section 7.3.1). 5677 19.11. MAX_STREAMS Frames 5679 The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the 5680 cumulative number of streams of a given type it is permitted to open. 5681 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 5682 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 5683 unidirectional streams. 5685 The MAX_STREAMS frames are shown in Figure 29; 5687 0 1 2 3 5688 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 5689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5690 | Maximum Streams (i) ... 5691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5692 Figure 29: MAX_STREAMS Frame Format 5694 MAX_STREAMS frames contain the following fields: 5696 Maximum Streams: A count of the cumulative number of streams of the 5697 corresponding type that can be opened over the lifetime of the 5698 connection. Stream IDs cannot exceed 2^62-1, as it is not 5699 possible to encode stream IDs larger than this value. Receipt of 5700 a frame that permits opening of a stream larger than this limit 5701 MUST be treated as a FRAME_ENCODING_ERROR. 5703 Loss or reordering can cause a MAX_STREAMS frame to be received which 5704 states a lower stream limit than an endpoint has previously received. 5705 MAX_STREAMS frames which do not increase the stream limit MUST be 5706 ignored. 5708 An endpoint MUST NOT open more streams than permitted by the current 5709 stream limit set by its peer. For instance, a server that receives a 5710 unidirectional stream limit of 3 is permitted to open stream 3, 7, 5711 and 11, but not stream 15. An endpoint MUST terminate a connection 5712 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 5713 permitted. 5715 Note that these frames (and the corresponding transport parameters) 5716 do not describe the number of streams that can be opened 5717 concurrently. The limit includes streams that have been closed as 5718 well as those that are open. 5720 19.12. DATA_BLOCKED Frame 5722 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 5723 to send data, but is unable to due to connection-level flow control 5724 (see Section 4). DATA_BLOCKED frames can be used as input to tuning 5725 of flow control algorithms (see Section 4.2). 5727 The DATA_BLOCKED frame is shown in Figure 30. 5729 0 1 2 3 5730 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 5731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5732 | Data Limit (i) ... 5733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5735 Figure 30: DATA_BLOCKED Frame Format 5737 DATA_BLOCKED frames contain the following fields: 5739 Data Limit: A variable-length integer indicating the connection- 5740 level limit at which blocking occurred. 5742 19.13. STREAM_DATA_BLOCKED Frame 5744 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 5745 wishes to send data, but is unable to due to stream-level flow 5746 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 5748 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 5749 stream MUST terminate the connection with error STREAM_STATE_ERROR. 5751 The STREAM_DATA_BLOCKED frame is shown in Figure 31. 5753 0 1 2 3 5754 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 5755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5756 | Stream ID (i) ... 5757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5758 | Stream Data Limit (i) ... 5759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5761 Figure 31: STREAM_DATA_BLOCKED Frame Format 5763 STREAM_DATA_BLOCKED frames contain the following fields: 5765 Stream ID: A variable-length integer indicating the stream which is 5766 flow control blocked. 5768 Stream Data Limit: A variable-length integer indicating the offset 5769 of the stream at which the blocking occurred. 5771 19.14. STREAMS_BLOCKED Frames 5773 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 5774 it wishes to open a stream, but is unable to due to the maximum 5775 stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED 5776 frame of type 0x16 is used to indicate reaching the bidirectional 5777 stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates 5778 reaching the unidirectional stream limit. 5780 A STREAMS_BLOCKED frame does not open the stream, but informs the 5781 peer that a new stream was needed and the stream limit prevented the 5782 creation of the stream. 5784 The STREAMS_BLOCKED frames are shown in Figure 32. 5786 0 1 2 3 5787 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 5788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5789 | Stream Limit (i) ... 5790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5792 Figure 32: STREAMS_BLOCKED Frame Format 5794 STREAMS_BLOCKED frames contain the following fields: 5796 Stream Limit: A variable-length integer indicating the stream limit 5797 at the time the frame was sent. Stream IDs cannot exceed 2^62-1, 5798 as it is not possible to encode stream IDs larger than this value. 5799 Receipt of a frame that encodes a larger stream ID MUST be treated 5800 as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. 5802 19.15. NEW_CONNECTION_ID Frame 5804 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 5805 its peer with alternative connection IDs that can be used to break 5806 linkability when migrating connections (see Section 9.5). 5808 The NEW_CONNECTION_ID frame is shown in Figure 33. 5810 0 1 2 3 5811 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 5812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5813 | Sequence Number (i) ... 5814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5815 | Retire Prior To (i) ... 5816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5817 | Length (8) | | 5818 +-+-+-+-+-+-+-+-+ Connection ID (8..160) + 5819 | ... 5820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5821 | | 5822 + + 5823 | | 5824 + Stateless Reset Token (128) + 5825 | | 5826 + + 5827 | | 5828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5830 Figure 33: NEW_CONNECTION_ID Frame Format 5832 NEW_CONNECTION_ID frames contain the following fields: 5834 Sequence Number: The sequence number assigned to the connection ID 5835 by the sender. See Section 5.1.1. 5837 Retire Prior To: A variable-length integer indicating which 5838 connection IDs should be retired. See Section 5.1.2. 5840 Length: An 8-bit unsigned integer containing the length of the 5841 connection ID. Values less than 1 and greater than 20 are invalid 5842 and MUST be treated as a connection error of type 5843 FRAME_ENCODING_ERROR. 5845 Connection ID: A connection ID of the specified length. 5847 Stateless Reset Token: A 128-bit value that will be used for a 5848 stateless reset when the associated connection ID is used (see 5849 Section 10.4). 5851 An endpoint MUST NOT send this frame if it currently requires that 5852 its peer send packets with a zero-length Destination Connection ID. 5853 Changing the length of a connection ID to or from zero-length makes 5854 it difficult to identify when the value of the connection ID changed. 5855 An endpoint that is sending packets with a zero-length Destination 5856 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 5857 connection error of type PROTOCOL_VIOLATION. 5859 Transmission errors, timeouts and retransmissions might cause the 5860 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 5861 of the same frame multiple times MUST NOT be treated as a connection 5862 error. A receiver can use the sequence number supplied in the 5863 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 5865 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 5866 previously issued connection ID with a different Stateless Reset 5867 Token or a different sequence number, or if a sequence number is used 5868 for different connection IDs, the endpoint MAY treat that receipt as 5869 a connection error of type PROTOCOL_VIOLATION. 5871 The Retire Prior To field counts connection IDs established during 5872 connection setup and the preferred_address transport parameter (see 5873 Section 5.1.2). The Retire Prior To field MUST be less than or equal 5874 to the Sequence Number field. Receiving a value greater than the 5875 Sequence Number MUST be treated as a connection error of type 5876 FRAME_ENCODING_ERROR. 5878 Once a sender indicates a Retire Prior To value, smaller values sent 5879 in subsequent NEW_CONNECTION_ID frames have no effect. A receiver 5880 MUST ignore any Retire Prior To fields that do not increase the 5881 largest received Retire Prior To value. 5883 An endpoint that receives a NEW_CONNECTION_ID frame with a sequence 5884 number smaller than the Retire Prior To field of a previously 5885 received NEW_CONNECTION_ID frame MUST immediately send a 5886 corresponding RETIRE_CONNECTION_ID frame that retires the newly 5887 received connection ID. 5889 19.16. RETIRE_CONNECTION_ID Frame 5891 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 5892 indicate that it will no longer use a connection ID that was issued 5893 by its peer. This may include the connection ID provided during the 5894 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 5895 request to the peer to send additional connection IDs for future use 5896 (see Section 5.1). New connection IDs can be delivered to a peer 5897 using the NEW_CONNECTION_ID frame (Section 19.15). 5899 Retiring a connection ID invalidates the stateless reset token 5900 associated with that connection ID. 5902 The RETIRE_CONNECTION_ID frame is shown in Figure 34. 5904 0 1 2 3 5905 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 5906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5907 | Sequence Number (i) ... 5908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5910 Figure 34: RETIRE_CONNECTION_ID Frame Format 5912 RETIRE_CONNECTION_ID frames contain the following fields: 5914 Sequence Number: The sequence number of the connection ID being 5915 retired. See Section 5.1.2. 5917 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 5918 greater than any previously sent to the peer MUST be treated as a 5919 connection error of type PROTOCOL_VIOLATION. 5921 The sequence number specified in a RETIRE_CONNECTION_ID frame MUST 5922 NOT refer to the Destination Connection ID field of the packet in 5923 which the frame is contained. The peer MAY treat this as a 5924 connection error of type FRAME_ENCODING_ERROR. 5926 An endpoint cannot send this frame if it was provided with a zero- 5927 length connection ID by its peer. An endpoint that provides a zero- 5928 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 5929 frame as a connection error of type PROTOCOL_VIOLATION. 5931 19.17. PATH_CHALLENGE Frame 5933 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 5934 reachability to the peer and for path validation during connection 5935 migration. 5937 The PATH_CHALLENGE frame is shown in Figure 35. 5939 0 1 2 3 5940 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 5941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5942 | | 5943 + Data (64) + 5944 | | 5945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5947 Figure 35: PATH_CHALLENGE Frame Format 5949 PATH_CHALLENGE frames contain the following fields: 5951 Data: This 8-byte field contains arbitrary data. 5953 A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is 5954 sufficient to ensure that it is easier to receive the packet than it 5955 is to guess the value correctly. 5957 The recipient of this frame MUST generate a PATH_RESPONSE frame 5958 (Section 19.18) containing the same Data. 5960 19.18. PATH_RESPONSE Frame 5962 The PATH_RESPONSE frame (type=0x1b) is sent in response to a 5963 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 5964 frame (Section 19.17). 5966 If the content of a PATH_RESPONSE frame does not match the content of 5967 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 5968 MAY generate a connection error of type PROTOCOL_VIOLATION. 5970 19.19. CONNECTION_CLOSE Frames 5972 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 5973 notify its peer that the connection is being closed. The 5974 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 5975 at only the QUIC layer, or the absence of errors (with the NO_ERROR 5976 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 5977 signal an error with the application that uses QUIC. 5979 If there are open streams that haven't been explicitly closed, they 5980 are implicitly closed when the connection is closed. 5982 The CONNECTION_CLOSE frames are shown in Figure 36. 5984 0 1 2 3 5985 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 5986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5987 | Error Code (i) ... 5988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5989 | [ Frame Type (i) ] ... 5990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5991 | Reason Phrase Length (i) ... 5992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5993 | Reason Phrase (*) ... 5994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5996 Figure 36: CONNECTION_CLOSE Frame Format 5998 CONNECTION_CLOSE frames contain the following fields: 6000 Error Code: A variable length integer error code which indicates the 6001 reason for closing this connection. A CONNECTION_CLOSE frame of 6002 type 0x1c uses codes from the space defined in Section 20. A 6003 CONNECTION_CLOSE frame of type 0x1d uses codes from the 6004 application protocol error code space; see Section 20.1 6006 Frame Type: A variable-length integer encoding the type of frame 6007 that triggered the error. A value of 0 (equivalent to the mention 6008 of the PADDING frame) is used when the frame type is unknown. The 6009 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 6010 not include this field. 6012 Reason Phrase Length: A variable-length integer specifying the 6013 length of the reason phrase in bytes. Because a CONNECTION_CLOSE 6014 frame cannot be split between packets, any limits on packet size 6015 will also limit the space available for a reason phrase. 6017 Reason Phrase: A human-readable explanation for why the connection 6018 was closed. This can be zero length if the sender chooses to not 6019 give details beyond the Error Code. This SHOULD be a UTF-8 6020 encoded string [RFC3629]. 6022 The application-specific variant of CONNECTION_CLOSE (type 0x1d) can 6023 only be sent using an 1-RTT packet ([QUIC-TLS], Section 4). When an 6024 application wishes to abandon a connection during the handshake, an 6025 endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error 6026 code of 0x15a ("user_canceled" alert; see [TLS13]) in an Initial or a 6027 Handshake packet. 6029 19.20. HANDSHAKE_DONE frame 6031 The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal 6032 confirmation of the handshake to the client. The HANDSHAKE_DONE 6033 frame contains no additional fields. 6035 This frame can only be sent by the server. Servers MUST NOT send a 6036 HANDSHAKE_DONE frame before completing the handshake. A server MUST 6037 treat receipt of a HANDSHAKE_DONE frame as a connection error of type 6038 PROTOCOL_VIOLATION. 6040 19.21. Extension Frames 6042 QUIC frames do not use a self-describing encoding. An endpoint 6043 therefore needs to understand the syntax of all frames before it can 6044 successfully process a packet. This allows for efficient encoding of 6045 frames, but it means that an endpoint cannot send a frame of a type 6046 that is unknown to its peer. 6048 An extension to QUIC that wishes to use a new type of frame MUST 6049 first ensure that a peer is able to understand the frame. An 6050 endpoint can use a transport parameter to signal its willingness to 6051 receive one or more extension frame types with the one transport 6052 parameter. 6054 Extensions that modify or replace core protocol functionality 6055 (including frame types) will be difficult to combine with other 6056 extensions which modify or replace the same functionality unless the 6057 behavior of the combination is explicitly defined. Such extensions 6058 SHOULD define their interaction with previously-defined extensions 6059 modifying the same protocol components. 6061 Extension frames MUST be congestion controlled and MUST cause an ACK 6062 frame to be sent. The exception is extension frames that replace or 6063 supplement the ACK frame. Extension frames are not included in flow 6064 control unless specified in the extension. 6066 An IANA registry is used to manage the assignment of frame types; see 6067 Section 22.3. 6069 20. Transport Error Codes 6071 QUIC error codes are 62-bit unsigned integers. 6073 This section lists the defined QUIC transport error codes that may be 6074 used in a CONNECTION_CLOSE frame. These errors apply to the entire 6075 connection. 6077 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 6078 signal that the connection is being closed abruptly in the absence 6079 of any error. 6081 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 6082 cannot continue with the connection. 6084 SERVER_BUSY (0x2): The server is currently busy and does not accept 6085 any new connections. 6087 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 6088 permitted in its advertised data limits (see Section 4). 6090 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 6091 identifier that exceeded its advertised stream limit for the 6092 corresponding stream type. 6094 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 6095 that was not in a state that permitted that frame (see Section 3). 6097 FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame 6098 containing data that exceeded the previously established final 6099 size. Or an endpoint received a STREAM frame or a RESET_STREAM 6100 frame containing a final size that was lower than the size of 6101 stream data that was already received. Or an endpoint received a 6102 STREAM frame or a RESET_STREAM frame containing a different final 6103 size to the one already established. 6105 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 6106 badly formatted. For instance, a frame of an unknown type, or an 6107 ACK frame that has more acknowledgment ranges than the remainder 6108 of the packet could carry. 6110 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 6111 parameters that were badly formatted, included an invalid value, 6112 was absent even though it is mandatory, was present though it is 6113 forbidden, or is otherwise in error. 6115 CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs 6116 provided by the peer exceeds the advertised 6117 active_connection_id_limit. 6119 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 6120 protocol compliance that was not covered by more specific error 6121 codes. 6123 INVALID_TOKEN (0xB): A server received a Retry Token in a client 6124 Initial that is invalid. 6126 CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in 6127 CRYPTO frames than it can buffer. 6129 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 6130 of 256 values is reserved for carrying error codes specific to the 6131 cryptographic handshake that is used. Codes for errors occurring 6132 when TLS is used for the crypto handshake are described in 6133 Section 4.8 of [QUIC-TLS]. 6135 See Section 22.4 for details of registering new error codes. 6137 In defining these error codes, several principles are applied. Error 6138 conditions that might require specific action on the part of a 6139 recipient are given unique codes. Errors that represent common 6140 conditions are given specific codes. Absent either of these 6141 conditions, error codes are used to identify a general function of 6142 the stack, like flow control or transport parameter handling. 6143 Finally, generic errors are provided for conditions where 6144 implementations are unable or unwilling to use more specific codes. 6146 20.1. Application Protocol Error Codes 6148 Application protocol error codes are 62-bit unsigned integers, but 6149 the management of application error codes is left to application 6150 protocols. Application protocol error codes are used for the 6151 RESET_STREAM frame (Section 19.4), the STOP_SENDING frame 6152 (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d 6153 (Section 19.19). 6155 21. Security Considerations 6157 21.1. Handshake Denial of Service 6159 As an encrypted and authenticated transport QUIC provides a range of 6160 protections against denial of service. Once the cryptographic 6161 handshake is complete, QUIC endpoints discard most packets that are 6162 not authenticated, greatly limiting the ability of an attacker to 6163 interfere with existing connections. 6165 Once a connection is established QUIC endpoints might accept some 6166 unauthenticated ICMP packets (see Section 14.2), but the use of these 6167 packets is extremely limited. The only other type of packet that an 6168 endpoint might accept is a stateless reset (Section 10.4) which 6169 relies on the token being kept secret until it is used. 6171 During the creation of a connection, QUIC only provides protection 6172 against attack from off the network path. All QUIC packets contain 6173 proof that the recipient saw a preceding packet from its peer. 6175 Addresses cannot change during the handshake, so endpoints can 6176 discard packets that are received on a different network path. 6178 The Source and Destination Connection ID fields are the primary means 6179 of protection against off-path attack during the handshake. These 6180 are required to match those set by a peer. Except for an Initial and 6181 stateless reset packets, an endpoint only accepts packets that 6182 include a Destination Connection ID field that matches a value the 6183 endpoint previously chose. This is the only protection offered for 6184 Version Negotiation packets. 6186 The Destination Connection ID field in an Initial packet is selected 6187 by a client to be unpredictable, which serves an additional purpose. 6188 The packets that carry the cryptographic handshake are protected with 6189 a key that is derived from this connection ID and salt specific to 6190 the QUIC version. This allows endpoints to use the same process for 6191 authenticating packets that they receive as they use after the 6192 cryptographic handshake completes. Packets that cannot be 6193 authenticated are discarded. Protecting packets in this fashion 6194 provides a strong assurance that the sender of the packet saw the 6195 Initial packet and understood it. 6197 These protections are not intended to be effective against an 6198 attacker that is able to receive QUIC packets prior to the connection 6199 being established. Such an attacker can potentially send packets 6200 that will be accepted by QUIC endpoints. This version of QUIC 6201 attempts to detect this sort of attack, but it expects that endpoints 6202 will fail to establish a connection rather than recovering. For the 6203 most part, the cryptographic handshake protocol [QUIC-TLS] is 6204 responsible for detecting tampering during the handshake. 6206 Endpoints are permitted to use other methods to detect and attempt to 6207 recover from interference with the handshake. Invalid packets may be 6208 identified and discarded using other methods, but no specific method 6209 is mandated in this document. 6211 21.2. Amplification Attack 6213 An attacker might be able to receive an address validation token 6214 (Section 8) from a server and then release the IP address it used to 6215 acquire that token. At a later time, the attacker may initiate a 6216 0-RTT connection with a server by spoofing this same address, which 6217 might now address a different (victim) endpoint. The attacker can 6218 thus potentially cause the server to send an initial congestion 6219 window's worth of data towards the victim. 6221 Servers SHOULD provide mitigations for this attack by limiting the 6222 usage and lifetime of address validation tokens (see Section 8.1.3). 6224 21.3. Optimistic ACK Attack 6226 An endpoint that acknowledges packets it has not received might cause 6227 a congestion controller to permit sending at rates beyond what the 6228 network supports. An endpoint MAY skip packet numbers when sending 6229 packets to detect this behavior. An endpoint can then immediately 6230 close the connection with a connection error of type 6231 PROTOCOL_VIOLATION (see Section 10.3). 6233 21.4. Slowloris Attacks 6235 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 6236 connections to the target endpoint open and hold them open as long as 6237 possible. These attacks can be executed against a QUIC endpoint by 6238 generating the minimum amount of activity necessary to avoid being 6239 closed for inactivity. This might involve sending small amounts of 6240 data, gradually opening flow control windows in order to control the 6241 sender rate, or manufacturing ACK frames that simulate a high loss 6242 rate. 6244 QUIC deployments SHOULD provide mitigations for the Slowloris 6245 attacks, such as increasing the maximum number of clients the server 6246 will allow, limiting the number of connections a single IP address is 6247 allowed to make, imposing restrictions on the minimum transfer speed 6248 a connection is allowed to have, and restricting the length of time 6249 an endpoint is allowed to stay connected. 6251 21.5. Stream Fragmentation and Reassembly Attacks 6253 An adversarial sender might intentionally send fragments of stream 6254 data in order to cause disproportionate receive buffer memory 6255 commitment and/or creation of a large and inefficient data structure. 6257 An adversarial receiver might intentionally not acknowledge packets 6258 containing stream data in order to force the sender to store the 6259 unacknowledged stream data for retransmission. 6261 The attack on receivers is mitigated if flow control windows 6262 correspond to available memory. However, some receivers will over- 6263 commit memory and advertise flow control offsets in the aggregate 6264 that exceed actual available memory. The over-commitment strategy 6265 can lead to better performance when endpoints are well behaved, but 6266 renders endpoints vulnerable to the stream fragmentation attack. 6268 QUIC deployments SHOULD provide mitigations against stream 6269 fragmentation attacks. Mitigations could consist of avoiding over- 6270 committing memory, limiting the size of tracking data structures, 6271 delaying reassembly of STREAM frames, implementing heuristics based 6272 on the age and duration of reassembly holes, or some combination. 6274 21.6. Stream Commitment Attack 6276 An adversarial endpoint can open lots of streams, exhausting state on 6277 an endpoint. The adversarial endpoint could repeat the process on a 6278 large number of connections, in a manner similar to SYN flooding 6279 attacks in TCP. 6281 Normally, clients will open streams sequentially, as explained in 6282 Section 2.1. However, when several streams are initiated at short 6283 intervals, loss or reordering may cause STREAM frames that open 6284 streams to be received out of sequence. On receiving a higher- 6285 numbered stream ID, a receiver is required to open all intervening 6286 streams of the same type (see Section 3.2). Thus, on a new 6287 connection, opening stream 4000000 opens 1 million and 1 client- 6288 initiated bidirectional streams. 6290 The number of active streams is limited by the 6291 initial_max_streams_bidi and initial_max_streams_uni transport 6292 parameters, as explained in Section 4.5. If chosen judiciously, 6293 these limits mitigate the effect of the stream commitment attack. 6294 However, setting the limit too low could affect performance when 6295 applications expect to open large number of streams. 6297 21.7. Peer Denial of Service 6299 QUIC and TLS both contain messages that have legitimate uses in some 6300 contexts, but that can be abused to cause a peer to expend processing 6301 resources without having any observable impact on the state of the 6302 connection. 6304 Messages can also be used to change and revert state in small or 6305 inconsequential ways, such as by sending small increments to flow 6306 control limits. 6308 If processing costs are disproportionately large in comparison to 6309 bandwidth consumption or effect on state, then this could allow a 6310 malicious peer to exhaust processing capacity. 6312 While there are legitimate uses for all messages, implementations 6313 SHOULD track cost of processing relative to progress and treat 6314 excessive quantities of any non-productive packets as indicative of 6315 an attack. Endpoints MAY respond to this condition with a connection 6316 error, or by dropping packets. 6318 21.8. Explicit Congestion Notification Attacks 6320 An on-path attacker could manipulate the value of ECN codepoints in 6321 the IP header to influence the sender's rate. [RFC3168] discusses 6322 manipulations and their effects in more detail. 6324 An on-the-side attacker can duplicate and send packets with modified 6325 ECN codepoints to affect the sender's rate. If duplicate packets are 6326 discarded by a receiver, an off-path attacker will need to race the 6327 duplicate packet against the original to be successful in this 6328 attack. Therefore, QUIC endpoints ignore the ECN codepoint field on 6329 an IP packet unless at least one QUIC packet in that IP packet is 6330 successfully processed; see Section 13.4. 6332 21.9. Stateless Reset Oracle 6334 Stateless resets create a possible denial of service attack analogous 6335 to a TCP reset injection. This attack is possible if an attacker is 6336 able to cause a stateless reset token to be generated for a 6337 connection with a selected connection ID. An attacker that can cause 6338 this token to be generated can reset an active connection with the 6339 same connection ID. 6341 If a packet can be routed to different instances that share a static 6342 key, for example by changing an IP address or port, then an attacker 6343 can cause the server to send a stateless reset. To defend against 6344 this style of denial service, endpoints that share a static key for 6345 stateless reset (see Section 10.4.2) MUST be arranged so that packets 6346 with a given connection ID always arrive at an instance that has 6347 connection state, unless that connection is no longer active. 6349 In the case of a cluster that uses dynamic load balancing, it's 6350 possible that a change in load balancer configuration could happen 6351 while an active instance retains connection state; even if an 6352 instance retains connection state, the change in routing and 6353 resulting stateless reset will result in the connection being 6354 terminated. If there is no chance in the packet being routed to the 6355 correct instance, it is better to send a stateless reset than wait 6356 for connections to time out. However, this is acceptable only if the 6357 routing cannot be influenced by an attacker. 6359 21.10. Version Downgrade 6361 This document defines QUIC Version Negotiation packets in Section 6, 6362 which can be used to negotiate the QUIC version used between two 6363 endpoints. However, this document does not specify how this 6364 negotiation will be performed between this version and subsequent 6365 future versions. In particular, Version Negotiation packets do not 6366 contain any mechanism to prevent version downgrade attacks. Future 6367 versions of QUIC that use Version Negotiation packets MUST define a 6368 mechanism that is robust against version downgrade attacks. 6370 21.11. Targeted Attacks by Routing 6372 Deployments should limit the ability of an attacker to target a new 6373 connection to a particular server instance. This means that client- 6374 controlled fields, such as the initial Destination Connection ID used 6375 on Initial and 0-RTT packets SHOULD NOT be used by themselves to make 6376 routing decisions. Ideally, routing decisions are made independently 6377 of client-selected values; a Source Connection ID can be selected to 6378 route later packets to the same server. 6380 21.12. Overview of Security Properties 6382 A complete security analysis of QUIC is outside the scope of this 6383 document. This section provides an informal description of the 6384 desired security properties as an aid to implementors and to help 6385 guide protocol analysis. 6387 QUIC assumes the threat model described in [SEC-CONS] and provides 6388 protections against many of the attacks that arise from that model. 6390 For this purpose, attacks are divided into passive and active 6391 attacks. Passive attackers have the capability to read packets from 6392 the network, while active attackers also have the capability to write 6393 packets into the network. However, a passive attack may involve an 6394 attacker with the ability to cause a routing change or other 6395 modification in the path taken by packets that comprise a connection. 6397 Attackers are additionally categorized as either on-path attackers or 6398 off-path attackers; see Section 3.5 of [SEC-CONS]. An on-path 6399 attacker can read, modify, or remove any packet it observes such that 6400 it no longer reaches its destination, while an off-path attacker 6401 observes the packets, but cannot prevent the original packet from 6402 reaching its intended destination. An off-path attacker can also 6403 transmit arbitrary packets. 6405 Properties of the handshake, protected packets, and connection 6406 migration are considered separately. 6408 21.12.1. Handshake 6410 The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the 6411 cryptographic properties described in Appendix E.1 of [TLS13]. 6413 In addition to those properties, the handshake is intended to provide 6414 some defense against DoS attacks on the handshake, as described 6415 below. 6417 21.12.1.1. Anti-Amplification 6419 Address validation (Section 8) is used to verify that an entity that 6420 claims a given address is able to receive packets at that address. 6421 Address validation limits amplification attack targets to addresses 6422 for which an attacker is either on-path or off-path. 6424 Prior to validation, endpoints are limited in what they are able to 6425 send. During the handshake, a server cannot send more than three 6426 times the data it receives; clients that initiate new connections or 6427 migrate to a new network path are limited. 6429 21.12.1.2. Server-Side DoS 6431 Computing the server's first flight for a full handshake is 6432 potentially expensive, requiring both a signature and a key exchange 6433 computation. In order to prevent computational DoS attacks, the 6434 Retry packet provides a cheap token exchange mechanism which allows 6435 servers to validate a client's IP address prior to doing any 6436 expensive computations at the cost of a single round trip. After a 6437 successful handshake, servers can issue new tokens to a client which 6438 will allow new connection establishment without incurring this cost. 6440 21.12.1.3. On-Path Handshake Termination 6442 An on-path or off-path attacker can force a handshake to fail by 6443 replacing or racing Initial packets. Once valid Initial packets have 6444 been exchanged, subsequent Handshake packets are protected with the 6445 handshake keys and an on-path attacker cannot force handshake failure 6446 other than by dropping packets to cause endpoints to abandon the 6447 attempt. 6449 An on-path attacker can also replace the addresses of packets on 6450 either side and therefore cause the client or server to have an 6451 incorrect view of the remote addresses. Such an attack is 6452 indistinguishable from the functions performed by a NAT. 6454 21.12.1.4. Parameter Negotiation 6456 The entire handshake is cryptographically protected, with the Initial 6457 packets being encrypted with per-version keys and the Handshake and 6458 later packets being encrypted with keys derived from the TLS key 6459 exchange. Further, parameter negotiation is folded into the TLS 6460 transcript and thus provides the same security guarantees as ordinary 6461 TLS negotiation. Thus, an attacker can observe the client's 6462 transport parameters (as long as it knows the version-specific salt) 6463 but cannot observe the server's transport parameters and cannot 6464 influence parameter negotiation. 6466 Connection IDs are unencrypted but integrity protected in all 6467 packets. 6469 This version of QUIC does not incorporate a version negotiation 6470 mechanism; implementations of incompatible versions will simply fail 6471 to establish a connection. 6473 21.12.2. Protected Packets 6475 Packet protection (Section 12.1) provides authentication and 6476 encryption of all packets except Version Negotiation packets, though 6477 Initial and Retry packets have limited encryption and authentication 6478 based on version-specific keys; see [QUIC-TLS] for more details. 6479 This section considers passive and active attacks against protected 6480 packets. 6482 Both on-path and off-path attackers can mount a passive attack in 6483 which they save observed packets for an offline attack against packet 6484 protection at a future time; this is true for any observer of any 6485 packet on any network. 6487 A blind attacker, one who injects packets without being able to 6488 observe valid packets for a connection, is unlikely to be successful, 6489 since packet protection ensures that valid packets are only generated 6490 by endpoints which possess the key material established during the 6491 handshake; see Section 7 and Section 21.12.1. Similarly, any active 6492 attacker that observes packets and attempts to insert new data or 6493 modify existing data in those packets should not be able to generate 6494 packets deemed valid by the receiving endpoint. 6496 A spoofing attack, in which an active attacker rewrites unprotected 6497 parts of a packet that it forwards or injects, such as the source or 6498 destination address, is only effective if the attacker can forward 6499 packets to the original endpoint. Packet protection ensures that the 6500 packet payloads can only be processed by the endpoints that completed 6501 the handshake, and invalid packets are ignored by those endpoints. 6503 An attacker can also modify the boundaries between packets and UDP 6504 datagrams, causing multiple packets to be coalesced into a single 6505 datagram, or splitting coalesced packets into multiple datagrams. 6506 Aside from datagrams containing Initial packets, which require 6507 padding, modification of how packets are arranged in datagrams has no 6508 functional effect on a connection, although it might change some 6509 performance characteristics. 6511 21.12.3. Connection Migration 6513 Connection Migration (Section 9) provides endpoints with the ability 6514 to transition between IP addresses and ports on multiple paths, using 6515 one path at a time for transmission and receipt of non-probing 6516 frames. Path validation (Section 8.2) establishes that a peer is 6517 both willing and able to receive packets sent on a particular path. 6518 This helps reduce the effects of address spoofing by limiting the 6519 number of packets sent to a spoofed address. 6521 This section describes the intended security properties of connection 6522 migration when under various types of DoS attacks. 6524 21.12.3.1. On-Path Active Attacks 6526 An attacker that can cause a packet it observes to no longer reach 6527 its intended destination is considered an on-path attacker. When an 6528 attacker is present between a client and server, endpoints are 6529 required to send packets through the attacker to establish 6530 connectivity on a given path. 6532 An on-path attacker can: 6534 * Inspect packets 6536 * Modify IP and UDP packet headers 6538 * Inject new packets 6540 * Delay packets 6542 * Reorder packets 6543 * Drop packets 6545 * Split and merge datagrams along packet boundaries 6547 An on-path attacker cannot: 6549 * Modify an authenticated portion of a packet and cause the 6550 recipient to accept that packet 6552 An on-path attacker has the opportunity to modify the packets that it 6553 observes, however any modifications to an authenticated portion of a 6554 packet will cause it to be dropped by the receiving endpoint as 6555 invalid, as packet payloads are both authenticated and encrypted. 6557 In the presence of an on-path attacker, QUIC aims to provide the 6558 following properties: 6560 1. An on-path attacker can prevent use of a path for a connection, 6561 causing it to fail if it cannot use a different path that does 6562 not contain the attacker. This can be achieved by dropping all 6563 packets, modifying them so that they fail to decrypt, or other 6564 methods. 6566 2. An on-path attacker can prevent migration to a new path for which 6567 the attacker is also on-path by causing path validation to fail 6568 on the new path. 6570 3. An on-path attacker cannot prevent a client from migrating to a 6571 path for which the attacker is not on-path. 6573 4. An on-path attacker can reduce the throughput of a connection by 6574 delaying packets or dropping them. 6576 5. An on-path attacker cannot cause an endpoint to accept a packet 6577 for which it has modified an authenticated portion of that 6578 packet. 6580 21.12.3.2. Off-Path Active Attacks 6582 An off-path attacker is not directly on the path between a client and 6583 server, but could be able to obtain copies of some or all packets 6584 sent between the client and the server. It is also able to send 6585 copies of those packets to either endpoint. 6587 An off-path attacker can: 6589 * Inspect packets 6590 * Inject new packets 6592 * Reorder injected packets 6594 An off-path attacker cannot: 6596 * Modify any part of a packet 6598 * Delay packets 6600 * Drop packets 6602 * Reorder original packets 6604 An off-path attacker can modify packets that it has observed and 6605 inject them back into the network, potentially with spoofed source 6606 and destination addresses. 6608 For the purposes of this discussion, it is assumed that an off-path 6609 attacker has the ability to observe, modify, and re-inject a packet 6610 into the network that will reach the destination endpoint prior to 6611 the arrival of the original packet observed by the attacker. In 6612 other words, an attacker has the ability to consistently "win" a race 6613 with the legitimate packets between the endpoints, potentially 6614 causing the original packet to be ignored by the recipient. 6616 It is also assumed that an attacker has the resources necessary to 6617 affect NAT state, potentially both causing an endpoint to lose its 6618 NAT binding, and an attacker to obtain the same port for use with its 6619 traffic. 6621 In the presence of an off-path attacker, QUIC aims to provide the 6622 following properties: 6624 1. An off-path attacker can race packets and attempt to become a 6625 "limited" on-path attacker. 6627 2. An off-path attacker can cause path validation to succeed for 6628 forwarded packets with the source address listed as the off-path 6629 attacker as long as it can provide improved connectivity between 6630 the client and the server. 6632 3. An off-path attacker cannot cause a connection to close once the 6633 handshake has completed. 6635 4. An off-path attacker cannot cause migration to a new path to fail 6636 if it cannot observe the new path. 6638 5. An off-path attacker can become a limited on-path attacker during 6639 migration to a new path for which it is also an off-path 6640 attacker. 6642 6. An off-path attacker can become a limited on-path attacker by 6643 affecting shared NAT state such that it sends packets to the 6644 server from the same IP address and port that the client 6645 originally used. 6647 21.12.3.3. Limited On-Path Active Attacks 6649 A limited on-path attacker is an off-path attacker that has offered 6650 improved routing of packets by duplicating and forwarding original 6651 packets between the server and the client, causing those packets to 6652 arrive before the original copies such that the original packets are 6653 dropped by the destination endpoint. 6655 A limited on-path attacker differs from an on-path attacker in that 6656 it is not on the original path between endpoints, and therefore the 6657 original packets sent by an endpoint are still reaching their 6658 destination. This means that a future failure to route copied 6659 packets to the destination faster than their original path will not 6660 prevent the original packets from reaching the destination. 6662 A limited on-path attacker can: 6664 * Inspect packets 6666 * Inject new packets 6668 * Modify unencrypted packet headers 6670 * Reorder packets 6672 A limited on-path attacker cannot: 6674 * Delay packets so that they arrive later than packets sent on the 6675 original path 6677 * Drop packets 6679 * Modify the authenticated and encrypted portion of a packet and 6680 cause the recipient to accept that packet 6682 A limited on-path attacker can only delay packets up to the point 6683 that the original packets arrive before the duplicate packets, 6684 meaning that it cannot offer routing with worse latency than the 6685 original path. If a limited on-path attacker drops packets, the 6686 original copy will still arrive at the destination endpoint. 6688 In the presence of a limited on-path attacker, QUIC aims to provide 6689 the following properties: 6691 1. A limited on-path attacker cannot cause a connection to close 6692 once the handshake has completed. 6694 2. A limited on-path attacker cannot cause an idle connection to 6695 close if the client is first to resume activity. 6697 3. A limited on-path attacker can cause an idle connection to be 6698 deemed lost if the server is the first to resume activity. 6700 Note that these guarantees are the same guarantees provided for any 6701 NAT, for the same reasons. 6703 22. IANA Considerations 6705 This document establishes several registries for the management of 6706 codepoints in QUIC. These registries operate on a common set of 6707 policies as defined in Section 22.1. 6709 22.1. Registration Policies for QUIC Registries 6711 All QUIC registries allow for both provisional and permanent 6712 registration of codepoints. This section documents policies that are 6713 common to these registries. 6715 22.1.1. Provisional Registrations 6717 Provisional registration of codepoints are intended to allow for 6718 private use and experimentation with extensions to QUIC. Provisional 6719 registrations only require the inclusion of the codepoint value and 6720 contact information. However, provisional registrations could be 6721 reclaimed and reassigned for another purpose. 6723 Provisional registrations require Expert Review, as defined in 6724 Section 4.5 of [RFC8126]. Designated expert(s) are advised that only 6725 registrations for an excessive proportion of remaining codepoint 6726 space or the very first unassigned value (see Section 22.1.2) can be 6727 rejected. 6729 Provisional registrations will include a date field that indicates 6730 when the registration was last updated. A request to update the date 6731 on any provisional registration can be made without review from the 6732 designated expert(s). 6734 All QUIC registries include the following fields to support 6735 provisional registration: 6737 Value: The assigned codepoint. 6739 Status: "Permanent" or "Provisional". 6741 Specification: A reference to a publicly available specification for 6742 the value. 6744 Date: The date of last update to the registration. 6746 Contact: Contact details for the registrant. 6748 Notes: Supplementary notes about the registration. 6750 Provisional registrations MAY omit the Specification and Notes 6751 fields, plus any additional fields that might be required for a 6752 permanent registration. The Date field is not required as part of 6753 requesting a registration as it is set to the date the registration 6754 is created or updated. 6756 22.1.2. Selecting Codepoints 6758 New uses of codepoints from QUIC registries SHOULD use a randomly 6759 selected codepoint that excludes both existing allocations and the 6760 first unallocated codepoint in the selected space. Requests for 6761 multiple codepoints MAY use a contiguous range. This minimizes the 6762 risk that differing semantics are attributed to the same codepoint by 6763 different implementations. Use of the first codepoint in a range is 6764 intended for use by specifications that are developed through the 6765 standards process [STD] and its allocation MUST be negotiated with 6766 IANA before use. 6768 For codepoints that are encoded in variable-length integers 6769 (Section 16), such as frame types, codepoints that encode to four or 6770 eight bytes (that is, values 2^14 and above) SHOULD be used unless 6771 the usage is especially sensitive to having a longer encoding. 6773 Applications to register codepoints in QUIC registries MAY include a 6774 codepoint as part of the registration. IANA MUST allocate the 6775 selected codepoint unless that codepoint is already assigned or the 6776 codepoint is the first unallocated codepoint in the registry. 6778 22.1.3. Reclaiming Provisional Codepoints 6780 A request might be made to remove an unused provisional registration 6781 from the registry to reclaim space in a registry, or portion of the 6782 registry (such as the 64-16383 range for codepoints that use 6783 variable-length encodings). This SHOULD be done only for the 6784 codepoints with the earliest recorded date and entries that have been 6785 updated less than a year prior SHOULD NOT be reclaimed. 6787 A request to remove a codepoint MUST be reviewed by the designated 6788 expert(s). The expert(s) MUST attempt to determine whether the 6789 codepoint is still in use. Experts are advised to contact the listed 6790 contacts for the registration, plus as wide a set of protocol 6791 implementers as possible in order to determine whether any use of the 6792 codepoint is known. The expert(s) are advised to allow at least four 6793 weeks for responses. 6795 If any use of the codepoints is identified by this search or a 6796 request to update the registration is made, the codepoint MUST NOT be 6797 reclaimed. Instead, the date on the registration is updated. A note 6798 might be added for the registration recording relevant information 6799 that was learned. 6801 If no use of the codepoint was identified and no request was made to 6802 update the registration, the codepoint MAY be removed from the 6803 registry. 6805 This process also applies to requests to change a provisional 6806 registration into a permanent registration, except that the goal is 6807 not to determine whether there is no use of the codepoint, but to 6808 determine that the registration is an accurate representation of any 6809 deployed usage. 6811 22.1.4. Permanent Registrations 6813 Permanent registrations in QUIC registries use the Specification 6814 Required policy [RFC8126], unless otherwise specified. The 6815 designated expert(s) verify that a specification exists and is 6816 readily accessible. Expert(s) are encouraged to be biased towards 6817 approving registrations unless they are abusive, frivolous, or 6818 actively harmful (not merely aesthetically displeasing, or 6819 architecturally dubious). The creation of a registry MAY specify 6820 additional constraints on permanent registrations. 6822 The creation of a registries MAY identify a range of codepoints where 6823 registrations are governed by a different registration policy. For 6824 instance, the registries for 62-bit codepoints in this document have 6825 stricter policies for codepoints in the range from 0 to 63. 6827 Any stricter requirements for permanent registrations do not prevent 6828 provisional registrations for affected codepoints. For instance, a 6829 provisional registration for a frame type Section 22.3 of 61 could be 6830 requested. 6832 All registrations made by Standards Track publications MUST be 6833 permanent. 6835 All registrations in this document are assigned a permanent status 6836 and list as contact both the IESG (ietf@ietf.org) and the QUIC 6837 working group (quic@ietf.org). 6839 22.2. QUIC Transport Parameter Registry 6841 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 6842 under a "QUIC" heading. 6844 The "QUIC Transport Parameters" registry governs a 16-bit space. 6845 This registry follows the registration policy from Section 22.1. 6846 Permanent registrations in this registry are assigned using the 6847 Specification Required policy [RFC8126]. 6849 In addition to the fields in Section 22.1.1, permanent registrations 6850 in this registry MUST include the following fields: 6852 Parameter Name: A short mnemonic for the parameter. 6854 The initial contents of this registry are shown in Table 6. 6856 +--------+-------------------------------------+---------------+ 6857 | Value | Parameter Name | Specification | 6858 +========+=====================================+===============+ 6859 | 0x0000 | original_connection_id | Section 18.2 | 6860 +--------+-------------------------------------+---------------+ 6861 | 0x0001 | max_idle_timeout | Section 18.2 | 6862 +--------+-------------------------------------+---------------+ 6863 | 0x0002 | stateless_reset_token | Section 18.2 | 6864 +--------+-------------------------------------+---------------+ 6865 | 0x0003 | max_packet_size | Section 18.2 | 6866 +--------+-------------------------------------+---------------+ 6867 | 0x0004 | initial_max_data | Section 18.2 | 6868 +--------+-------------------------------------+---------------+ 6869 | 0x0005 | initial_max_stream_data_bidi_local | Section 18.2 | 6870 +--------+-------------------------------------+---------------+ 6871 | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.2 | 6872 +--------+-------------------------------------+---------------+ 6873 | 0x0007 | initial_max_stream_data_uni | Section 18.2 | 6874 +--------+-------------------------------------+---------------+ 6875 | 0x0008 | initial_max_streams_bidi | Section 18.2 | 6876 +--------+-------------------------------------+---------------+ 6877 | 0x0009 | initial_max_streams_uni | Section 18.2 | 6878 +--------+-------------------------------------+---------------+ 6879 | 0x000a | ack_delay_exponent | Section 18.2 | 6880 +--------+-------------------------------------+---------------+ 6881 | 0x000b | max_ack_delay | Section 18.2 | 6882 +--------+-------------------------------------+---------------+ 6883 | 0x000c | disable_active_migration | Section 18.2 | 6884 +--------+-------------------------------------+---------------+ 6885 | 0x000d | preferred_address | Section 18.2 | 6886 +--------+-------------------------------------+---------------+ 6887 | 0x000e | active_connection_id_limit | Section 18.2 | 6888 +--------+-------------------------------------+---------------+ 6890 Table 6: Initial QUIC Transport Parameters Entries 6892 Additionally, each value of the format "31 * N + 27" for integer 6893 values of N (that is, "27", "58", "89", ...) are reserved and MUST 6894 NOT be assigned by IANA. 6896 22.3. QUIC Frame Type Registry 6898 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 6899 "QUIC" heading. 6901 The "QUIC Frame Types" registry governs a 62-bit space. This 6902 registry follows the registration policy from Section 22.1. 6903 Permanent registrations in this registry are assigned using the 6904 Specification Required policy [RFC8126], except for values between 6905 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 6906 Standards Action or IESG Approval as defined in Section 4.9 and 4.10 6907 of [RFC8126]. 6909 In addition to the fields in Section 22.1.1, permanent registrations 6910 in this registry MUST include the following fields: 6912 Frame Name: A short mnemonic for the frame type. 6914 In addition to the advice in Section 22.1, specifications for new 6915 permanent registrations SHOULD describe the means by which an 6916 endpoint might determine that it can send the identified type of 6917 frame. An accompanying transport parameter registration (see 6918 Section 22.2) is expected for most registrations. Specifications for 6919 permanent registrations also needs to describe the format and 6920 assigned semantics of any fields in the frame. 6922 The initial contents of this registry are tabulated in Table 3. 6924 22.4. QUIC Transport Error Codes Registry 6926 IANA [SHALL add/has added] a registry for "QUIC Transport Error 6927 Codes" under a "QUIC" heading. 6929 The "QUIC Transport Error Codes" registry governs a 62-bit space. 6930 This space is split into three spaces that are governed by different 6931 policies. Permanent registrations in this registry are assigned 6932 using the Specification Required policy [RFC8126], except for values 6933 between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned 6934 using Standards Action or IESG Approval as defined in Section 4.9 and 6935 4.10 of [RFC8126]. 6937 In addition to the fields in Section 22.1.1, permanent registrations 6938 in this registry MUST include the following fields: 6940 Code: A short mnemonic for the parameter. 6942 Description: A brief description of the error code semantics, which 6943 MAY be a summary if a specification reference is provided. 6945 The initial contents of this registry are shown in Table 7. 6947 +------+---------------------------+----------------+---------------+ 6948 |Value | Error | Description | Specification | 6949 +======+===========================+================+===============+ 6950 | 0x0 | NO_ERROR | No error | Section 20 | 6951 +------+---------------------------+----------------+---------------+ 6952 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 6953 | | | error | | 6954 +------+---------------------------+----------------+---------------+ 6955 | 0x2 | SERVER_BUSY |Server currently| Section 20 | 6956 | | | busy | | 6957 +------+---------------------------+----------------+---------------+ 6958 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 6959 | | | error | | 6960 +------+---------------------------+----------------+---------------+ 6961 | 0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 | 6962 | | | opened | | 6963 +------+---------------------------+----------------+---------------+ 6964 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 6965 | | | in invalid | | 6966 | | | stream state | | 6967 +------+---------------------------+----------------+---------------+ 6968 | 0x6 | FINAL_SIZE_ERROR |Change to final | Section 20 | 6969 | | | size | | 6970 +------+---------------------------+----------------+---------------+ 6971 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 6972 | | | error | | 6973 +------+---------------------------+----------------+---------------+ 6974 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 6975 | | | transport | | 6976 | | | parameters | | 6977 +------+---------------------------+----------------+---------------+ 6978 | 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 | 6979 | | | connection IDs | | 6980 | | | received | | 6981 +------+---------------------------+----------------+---------------+ 6982 | 0xA | PROTOCOL_VIOLATION |Generic protocol| Section 20 | 6983 | | | violation | | 6984 +------+---------------------------+----------------+---------------+ 6985 | 0xB | INVALID_TOKEN | Invalid Token | Section 20 | 6986 | | | Received | | 6987 +------+---------------------------+----------------+---------------+ 6988 | 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | 6989 | | | buffer | | 6990 | | | overflowed | | 6991 +------+---------------------------+----------------+---------------+ 6993 Table 7: Initial QUIC Transport Error Codes Entries 6995 23. References 6997 23.1. Normative References 6999 [DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 7000 T. Voelker, "Packetization Layer Path MTU Discovery for 7001 Datagram Transports", Work in Progress, Internet-Draft, 7002 draft-ietf-tsvwg-datagram-plpmtud-08, 5 June 2019, 7003 . 7006 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 7007 DOI 10.17487/RFC0791, September 1981, 7008 . 7010 [QUIC-RECOVERY] 7011 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 7012 and Congestion Control", Work in Progress, Internet-Draft, 7013 draft-ietf-quic-recovery-26, 21 February 2020, 7014 . 7016 [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport 7017 Layer Security (TLS) to Secure QUIC", Work in Progress, 7018 Internet-Draft, draft-ietf-quic-tls-26, 21 February 2020, 7019 . 7021 [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", 7022 RFC 1191, DOI 10.17487/RFC1191, November 1990, 7023 . 7025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7026 Requirement Levels", BCP 14, RFC 2119, 7027 DOI 10.17487/RFC2119, March 1997, 7028 . 7030 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 7031 of Explicit Congestion Notification (ECN) to IP", 7032 RFC 3168, DOI 10.17487/RFC3168, September 2001, 7033 . 7035 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 7036 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 7037 2003, . 7039 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 7040 "Randomness Requirements for Security", BCP 106, RFC 4086, 7041 DOI 10.17487/RFC4086, June 2005, 7042 . 7044 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 7045 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 7046 . 7048 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 7049 "IPv6 Flow Label Specification", RFC 6437, 7050 DOI 10.17487/RFC6437, November 2011, 7051 . 7053 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 7054 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 7055 March 2017, . 7057 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 7058 Writing an IANA Considerations Section in RFCs", BCP 26, 7059 RFC 8126, DOI 10.17487/RFC8126, June 2017, 7060 . 7062 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 7063 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 7064 May 2017, . 7066 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 7067 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 7068 DOI 10.17487/RFC8201, July 2017, 7069 . 7071 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 7072 Notification (ECN) Experimentation", RFC 8311, 7073 DOI 10.17487/RFC8311, January 2018, 7074 . 7076 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 7077 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 7078 . 7080 23.2. Informative References 7082 [EARLY-DESIGN] 7083 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2 7084 December 2013, . 7086 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 7087 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 7088 DOI 10.17487/RFC7540, May 2015, 7089 . 7091 [QUIC-INVARIANTS] 7092 Thomson, M., "Version-Independent Properties of QUIC", 7093 Work in Progress, Internet-Draft, draft-ietf-quic- 7094 invariants-07, 21 February 2020, 7095 . 7098 [QUIC-MANAGEABILITY] 7099 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 7100 Transport Protocol", Work in Progress, Internet-Draft, 7101 draft-ietf-quic-manageability-05, 5 July 2019, 7102 . 7105 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 7106 RFC 1812, DOI 10.17487/RFC1812, June 1995, 7107 . 7109 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 7110 Selective Acknowledgment Options", RFC 2018, 7111 DOI 10.17487/RFC2018, October 1996, 7112 . 7114 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 7115 Hashing for Message Authentication", RFC 2104, 7116 DOI 10.17487/RFC2104, February 1997, 7117 . 7119 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 7120 RFC 2360, DOI 10.17487/RFC2360, June 1998, 7121 . 7123 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 7124 RFC 4303, DOI 10.17487/RFC4303, December 2005, 7125 . 7127 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 7128 Control Message Protocol (ICMPv6) for the Internet 7129 Protocol Version 6 (IPv6) Specification", STD 89, 7130 RFC 4443, DOI 10.17487/RFC4443, March 2006, 7131 . 7133 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 7134 Translation (NAT) Behavioral Requirements for Unicast 7135 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 7136 2007, . 7138 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 7139 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 7140 . 7142 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 7143 Key Derivation Function (HKDF)", RFC 5869, 7144 DOI 10.17487/RFC5869, May 2010, 7145 . 7147 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 7148 "Transport Layer Security (TLS) Application-Layer Protocol 7149 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 7150 July 2014, . 7152 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 7153 (IPv6) Specification", STD 86, RFC 8200, 7154 DOI 10.17487/RFC8200, July 2017, 7155 . 7157 [SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 7158 Text on Security Considerations", BCP 72, RFC 3552, 7159 DOI 10.17487/RFC3552, July 2003, 7160 . 7162 [SLOWLORIS] 7163 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 7164 . 7167 [STD] Bradner, S., "The Internet Standards Process -- Revision 7168 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 7169 . 7171 Appendix A. Sample Packet Number Decoding Algorithm 7173 The pseudo-code in Figure 37 shows how an implementation can decode 7174 packet numbers after header protection has been removed. 7176 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 7177 expected_pn = largest_pn + 1 7178 pn_win = 1 << pn_nbits 7179 pn_hwin = pn_win / 2 7180 pn_mask = pn_win - 1 7181 // The incoming packet number should be greater than 7182 // expected_pn - pn_hwin and less than or equal to 7183 // expected_pn + pn_hwin 7184 // 7185 // This means we can't just strip the trailing bits from 7186 // expected_pn and add the truncated_pn because that might 7187 // yield a value outside the window. 7188 // 7189 // The following code calculates a candidate value and 7190 // makes sure it's within the packet number window. 7191 // Note the extra checks to prevent overflow and underflow. 7192 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 7193 if candidate_pn <= expected_pn - pn_hwin and 7194 candidate_pn < (1 << 62) - pn_win: 7195 return candidate_pn + pn_win 7196 if candidate_pn > expected_pn + pn_hwin and 7197 candidate_pn >= pn_win: 7198 return candidate_pn - pn_win 7199 return candidate_pn 7201 Figure 37: Sample Packet Number Decoding Algorithm 7203 Appendix B. Sample ECN Validation Algorithm 7205 Each time an endpoint commences sending on a new network path, it 7206 determines whether the path supports ECN; see Section 13.4. If the 7207 path supports ECN, the goal is to use ECN. Endpoints might also 7208 periodically reassess a path that was determined to not support ECN. 7210 This section describes one method for testing new paths. This 7211 algorithm is intended to show how a path might be tested for ECN 7212 support. Endpoints can implement different methods. 7214 The path is assigned an ECN state that is one of "testing", 7215 "unknown", "failed", or "capable". On paths with a "testing" or 7216 "capable" state the endpoint sends packets with an ECT marking, by 7217 default ECT(0); otherwise, the endpoint sends unmarked packets. 7219 To start testing a path, the ECN state is set to "testing" and 7220 existing ECN counts are remembered as a baseline. 7222 The testing period runs for a number of packets or round-trip times, 7223 as determined by the endpoint. The goal is not to limit the duration 7224 of the testing period, but to ensure that enough marked packets are 7225 sent for received ECN counts to provide a clear indication of how the 7226 path treats marked packets. Section 13.4.2.2 suggests limiting this 7227 to 10 packets or 3 round-trip times. 7229 After the testing period ends, the ECN state for the path becomes 7230 "unknown". From the "unknown" state, successful validation of the 7231 ECN counts an ACK frame (see Section 13.4.2.2) causes the ECN state 7232 for the path to become "capable", unless no marked packet has been 7233 acknowledged. 7235 If validation of ECN counts fails at any time, the ECN state for the 7236 affected path becomes "failed". An endpoint can also mark the ECN 7237 state for a path as "failed" if marked packets are all declared lost 7238 or if they are all CE marked. 7240 Following this algorithm ensures that ECN is rarely disabled for 7241 paths that properly support ECN. Any path that incorrectly modifies 7242 markings will cause ECN to be disabled. For those rare cases where 7243 marked packets are discarded by the path, the short duration of the 7244 testing period limits the number of losses incurred. 7246 Appendix C. Change Log 7248 *RFC Editor's Note:* Please remove this section prior to 7249 publication of a final version of this document. 7251 Issue and pull request numbers are listed with a leading octothorp. 7253 C.1. Since draft-ietf-quic-transport-24 7255 * Added HANDSHAKE_DONE to signal handshake confirmation (#2863, 7256 #3142, #3145) 7258 * Add integrity check to Retry packets (#3014, #3274, #3120) 7260 * Specify handling of reordered NEW_CONNECTION_ID frames (#3194, 7261 #3202) 7263 * Require checking of sequence numbers in RETIRE_CONNECTION_ID 7264 (#3037, #3036) 7266 * active_connection_id_limit is enforced (#3193, #3197, #3200, 7267 #3201) 7269 * Correct overflow in packet number decode algorithm (#3187, #3188) 7270 * Allow use of CRYPTO_BUFFER_EXCEEDED for CRYPTO frame errors 7271 (#3258, #3186) 7273 * Define applicability and scope of NEW_TOKEN (#3150, #3152, #3155, 7274 #3156) 7276 * Tokens from Retry and NEW_TOKEN must be differentiated (#3127, 7277 #3128) 7279 * Allow CONNECTION_CLOSE in response to invalid token (#3168, #3107) 7281 * Treat an invalid CONNECTION_CLOSE as an invalid frame (#2475, 7282 #3230, #3231) 7284 * Throttle when sending CONNECTION_CLOSE after discarding state 7285 (#3095, #3157) 7287 * Application-variant of CONNECTION_CLOSE can only be sent in 0-RTT 7288 or 1-RTT packets (#3158, #3164) 7290 * Advise sending while blocked to avoid idle timeout (#2744, #3266) 7292 * Define error codes for invalid frames (#3027, #3042) 7294 * Idle timeout is symmetric (#2602, #3099) 7296 * Prohibit IP fragmentation (#3243, #3280) 7298 * Define the use of provisional registration for all registries 7299 (#3109, #3020, #3102, #3170) 7301 * Packets on one path must not adjust values for a different path 7302 (#2909, #3139) 7304 C.2. Since draft-ietf-quic-transport-23 7306 * Allow ClientHello to span multiple packets (#2928, #3045) 7308 * Client Initial size constraints apply to UDP datagram payload 7309 (#3053, #3051) 7311 * Stateless reset changes (#2152, #2993) 7313 - tokens need to be compared in constant time 7315 - detection uses UDP datagrams, not packets 7317 - tokens cannot be reused (#2785, #2968) 7319 * Clearer rules for sharing of UDP ports and use of connection IDs 7320 when doing so (#2844, #2851) 7322 * A new connection ID is necessary when responding to migration 7323 (#2778, #2969) 7325 * Stronger requirements for connection ID retirement (#3046, #3096) 7327 * NEW_TOKEN cannot be empty (#2978, #2977) 7329 * PING can be sent at any encryption level (#3034, #3035) 7331 * CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) 7333 * Frame encoding error conditions updated (#3027, #3042) 7335 * Non-ack-eliciting packets cannot be sent in response to non-ack- 7336 eliciting packets (#3100, #3104) 7338 * Servers have to change connection IDs in Retry (#2837, #3147) 7340 C.3. Since draft-ietf-quic-transport-22 7342 * Rules for preventing correlation by connection ID tightened 7343 (#2084, #2929) 7345 * Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, 7346 #2541, #2688) 7348 * Discourage regressions of largest acknowledged in ACK (#2205, 7349 #2752) 7351 * Improved robustness of validation process for ECN counts (#2534, 7352 #2752) 7354 * Require endpoints to ignore spurious migration attempts (#2342, 7355 #2893) 7357 * Transport parameter for disabling migration clarified to allow NAT 7358 rebinding (#2389, #2893) 7360 * Document principles for defining new error codes (#2388, #2880) 7362 * Reserve transport parameters for greasing (#2550, #2873) 7364 * A maximum ACK delay of 0 is used for handshake packet number 7365 spaces (#2646, #2638) 7367 * Improved rules for use of congestion control state on new paths 7368 (#2685, #2918) 7370 * Removed recommendation to coordinate spin for multiple connections 7371 that share a path (#2763, #2882) 7373 * Allow smaller stateless resets and recommend a smaller minimum on 7374 packets that might trigger a stateless reset (#2770, #2869, #2927, 7375 #3007). 7377 * Provide guidance around the interface to QUIC as used by 7378 application protocols (#2805, #2857) 7380 * Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, 7381 #2826) 7383 * Tighter rules about processing of rejected 0-RTT packets (#2829, 7384 #2840, #2841) 7386 * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) 7388 * Cryptographic handshake needs to provide server transport 7389 parameter encryption (#2920, #2921) 7391 * Moved ACK generation guidance from recovery draft to transport 7392 draft (#1860, #2916). 7394 C.4. Since draft-ietf-quic-transport-21 7396 * Connection ID lengths are now one octet, but limited in version 1 7397 to 20 octets of length (#2736, #2749) 7399 C.5. Since draft-ietf-quic-transport-20 7401 * Error codes are encoded as variable-length integers (#2672, #2680) 7403 * NEW_CONNECTION_ID includes a request to retire old connection IDs 7404 (#2645, #2769) 7406 * Tighter rules for generating and explicitly eliciting ACK frames 7407 (#2546, #2794) 7409 * Recommend having only one packet per encryption level in a 7410 datagram (#2308, #2747) 7412 * More normative language about use of stateless reset (#2471, 7413 #2574) 7415 * Allow reuse of stateless reset tokens (#2732, #2733) 7417 * Allow, but not require, enforcing non-duplicate transport 7418 parameters (#2689, #2691) 7420 * Added an active_connection_id_limit transport parameter (#1994, 7421 #1998) 7423 * max_ack_delay transport parameter defaults to 0 (#2638, #2646) 7425 * When sending 0-RTT, only remembered transport parameters apply 7426 (#2458, #2360, #2466, #2461) 7428 * Define handshake completion and confirmation; define clearer rules 7429 when it encryption keys should be discarded (#2214, #2267, #2673) 7431 * Prohibit path migration prior to handshake confirmation (#2309, 7432 #2370) 7434 * PATH_RESPONSE no longer needs to be received on the validated path 7435 (#2582, #2580, #2579, #2637) 7437 * PATH_RESPONSE frames are not stored and retransmitted (#2724, 7438 #2729) 7440 * Document hack for enabling routing of ICMP when doing PMTU probing 7441 (#1243, #2402) 7443 C.6. Since draft-ietf-quic-transport-19 7445 * Refine discussion of 0-RTT transport parameters (#2467, #2464) 7447 * Fewer transport parameters need to be remembered for 0-RTT (#2624, 7448 #2467) 7450 * Spin bit text incorporated (#2564) 7452 * Close the connection when maximum stream ID in MAX_STREAMS exceeds 7453 2^62 - 1 (#2499, #2487) 7455 * New connection ID required for intentional migration (#2414, 7456 #2413) 7458 * Connection ID issuance can be rate-limited (#2436, #2428) 7460 * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) 7461 * Initial packets from clients need to be padded to 1200 unless a 7462 Handshake packet is sent as well (#2522, #2523) 7464 * CRYPTO frames can be discarded if too much data is buffered 7465 (#1834, #2524) 7467 * Stateless reset uses a short header packet (#2599, #2600) 7469 C.7. Since draft-ietf-quic-transport-18 7471 * Removed version negotiation; version negotiation, including 7472 authentication of the result, will be addressed in the next 7473 version of QUIC (#1773, #2313) 7475 * Added discussion of the use of IPv6 flow labels (#2348, #2399) 7477 * A connection ID can't be retired in a packet that uses that 7478 connection ID (#2101, #2420) 7480 * Idle timeout transport parameter is in milliseconds (from seconds) 7481 (#2453, #2454) 7483 * Endpoints are required to use new connection IDs when they use new 7484 network paths (#2413, #2414) 7486 * Increased the set of permissible frames in 0-RTT (#2344, #2355) 7488 C.8. Since draft-ietf-quic-transport-17 7490 * Stream-related errors now use STREAM_STATE_ERROR (#2305) 7492 * Endpoints discard initial keys as soon as handshake keys are 7493 available (#1951, #2045) 7495 * Expanded conditions for ignoring ICMP packet too big messages 7496 (#2108, #2161) 7498 * Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, 7499 #2241) 7501 * Endpoints are permitted to discard malformed initial packets 7502 (#2141) 7504 * Clarified ECN implementation and usage requirements (#2156, #2201) 7506 * Disable ECN count verification for packets that arrive out of 7507 order (#2198, #2215) 7509 * Use Probe Timeout (PTO) instead of RTO (#2206, #2238) 7511 * Loosen constraints on retransmission of ACK ranges (#2199, #2245) 7513 * Limit Retry and Version Negotiation to once per datagram (#2259, 7514 #2303) 7516 * Set a maximum value for max_ack_delay transport parameter (#2282, 7517 #2301) 7519 * Allow server preferred address for both IPv4 and IPv6 (#2122, 7520 #2296) 7522 * Corrected requirements for migration to a preferred address 7523 (#2146, #2349) 7525 * ACK of non-existent packet is illegal (#2298, #2302) 7527 C.9. Since draft-ietf-quic-transport-16 7529 * Stream limits are defined as counts, not maximums (#1850, #1906) 7531 * Require amplification attack defense after closing (#1905, #1911) 7533 * Remove reservation of application error code 0 for STOPPING 7534 (#1804, #1922) 7536 * Renumbered frames (#1945) 7538 * Renumbered transport parameters (#1946) 7540 * Numeric transport parameters are expressed as varints (#1608, 7541 #1947, #1955) 7543 * Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 7545 * Rework the first byte (#2006) 7547 - Fix the 0x40 bit 7549 - Change type values for long header 7551 - Add spin bit to short header (#631, #1988) 7553 - Encrypt the remainder of the first byte (#1322) 7555 - Move packet number length to first byte 7556 - Move ODCIL to first byte of retry packets 7558 - Simplify packet number protection (#1575) 7560 * Allow STOP_SENDING to open a remote bidirectional stream (#1797, 7561 #2013) 7563 * Added mitigation for off-path migration attacks (#1278, #1749, 7564 #2033) 7566 * Don't let the PMTU to drop below 1280 (#2063, #2069) 7568 * Require peers to replace retired connection IDs (#2085) 7570 * Servers are required to ignore Version Negotiation packets (#2088) 7572 * Tokens are repeated in all Initial packets (#2089) 7574 * Clarified how PING frames are sent after loss (#2094) 7576 * Initial keys are discarded once Handshake are available (#1951, 7577 #2045) 7579 * ICMP PTB validation clarifications (#2161, #2109, #2108) 7581 C.10. Since draft-ietf-quic-transport-15 7583 Substantial editorial reorganization; no technical changes. 7585 C.11. Since draft-ietf-quic-transport-14 7587 * Merge ACK and ACK_ECN (#1778, #1801) 7589 * Explicitly communicate max_ack_delay (#981, #1781) 7591 * Validate original connection ID after Retry packets (#1710, #1486, 7592 #1793) 7594 * Idle timeout is optional and has no specified maximum (#1765) 7596 * Update connection ID handling; add RETIRE_CONNECTION_ID type 7597 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 7598 #1821) 7600 * Include a Token in all Initial packets (#1649, #1794) 7602 * Prevent handshake deadlock (#1764, #1824) 7604 C.12. Since draft-ietf-quic-transport-13 7606 * Streams open when higher-numbered streams of the same type open 7607 (#1342, #1549) 7609 * Split initial stream flow control limit into 3 transport 7610 parameters (#1016, #1542) 7612 * All flow control transport parameters are optional (#1610) 7614 * Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 7616 * Permit stateless reset in response to any packet (#1348, #1553) 7618 * Recommended defense against stateless reset spoofing (#1386, 7619 #1554) 7621 * Prevent infinite stateless reset exchanges (#1443, #1627) 7623 * Forbid processing of the same packet number twice (#1405, #1624) 7625 * Added a packet number decoding example (#1493) 7627 * More precisely define idle timeout (#1429, #1614, #1652) 7629 * Corrected format of Retry packet and prevented looping (#1492, 7630 #1451, #1448, #1498) 7632 * Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 7633 #1514, #1621) 7635 * Permit Retry in response to 0-RTT (#1547, #1552) 7637 * Looser verification of ECN counters to account for ACK loss 7638 (#1555, #1481, #1565) 7640 * Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 7642 C.13. Since draft-ietf-quic-transport-12 7644 * Changes to integration of the TLS handshake (#829, #1018, #1094, 7645 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 7647 - The cryptographic handshake uses CRYPTO frames, not stream 0 7649 - QUIC packet protection is used in place of TLS record 7650 protection 7652 - Separate QUIC packet number spaces are used for the handshake 7654 - Changed Retry to be independent of the cryptographic handshake 7656 - Added NEW_TOKEN frame and Token fields to Initial packet 7658 - Limit the use of HelloRetryRequest to address TLS needs (like 7659 key shares) 7661 * Enable server to transition connections to a preferred address 7662 (#560, #1251, #1373) 7664 * Added ECN feedback mechanisms and handling; new ACK_ECN frame 7665 (#804, #805, #1372) 7667 * Changed rules and recommendations for use of new connection IDs 7668 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 7670 * Added a transport parameter to disable intentional connection 7671 migration (#1271, #1447) 7673 * Packets from different connection ID can't be coalesced (#1287, 7674 #1423) 7676 * Fixed sampling method for packet number encryption; the length 7677 field in long headers includes the packet number field in addition 7678 to the packet payload (#1387, #1389) 7680 * Stateless Reset is now symmetric and subject to size constraints 7681 (#466, #1346) 7683 * Added frame type extension mechanism (#58, #1473) 7685 C.14. Since draft-ietf-quic-transport-11 7687 * Enable server to transition connections to a preferred address 7688 (#560, #1251) 7690 * Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 7691 #990, #734, #1317, #1267, #1079) 7693 * Packet numbers use a variable-length encoding (#989, #1334) 7695 * STREAM frames can now be empty (#1350) 7697 C.15. Since draft-ietf-quic-transport-10 7698 * Swap payload length and packed number fields in long header 7699 (#1294) 7701 * Clarified that CONNECTION_CLOSE is allowed in Handshake packet 7702 (#1274) 7704 * Spin bit reserved (#1283) 7706 * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 7708 * A more complete connection migration (#1249) 7710 * Refine opportunistic ACK defense text (#305, #1030, #1185) 7712 * A Stateless Reset Token isn't mandatory (#818, #1191) 7714 * Removed implicit stream opening (#896, #1193) 7716 * An empty STREAM frame can be used to open a stream without sending 7717 data (#901, #1194) 7719 * Define stream counts in transport parameters rather than a maximum 7720 stream ID (#1023, #1065) 7722 * STOP_SENDING is now prohibited before streams are used (#1050) 7724 * Recommend including ACK in Retry packets and allow PADDING (#1067, 7725 #882) 7727 * Endpoints now become closing after an idle timeout (#1178, #1179) 7729 * Remove implication that Version Negotiation is sent when a packet 7730 of the wrong version is received (#1197) 7732 C.16. Since draft-ietf-quic-transport-09 7734 * Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 7735 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 7736 (#1091, #725, #1086) 7738 * A server can now only send 3 packets without validating the client 7739 address (#38, #1090) 7741 * Delivery order of stream data is no longer strongly specified 7742 (#252, #1070) 7744 * Rework of packet handling and version negotiation (#1038) 7745 * Stream 0 is now exempt from flow control until the handshake 7746 completes (#1074, #725, #825, #1082) 7748 * Improved retransmission rules for all frame types: information is 7749 retransmitted, not packets or frames (#463, #765, #1095, #1053) 7751 * Added an error code for server busy signals (#1137) 7753 * Endpoints now set the connection ID that their peer uses. 7754 Connection IDs are variable length. Removed the 7755 omit_connection_id transport parameter and the corresponding short 7756 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 7758 C.17. Since draft-ietf-quic-transport-08 7760 * Clarified requirements for BLOCKED usage (#65, #924) 7762 * BLOCKED frame now includes reason for blocking (#452, #924, #927, 7763 #928) 7765 * GAP limitation in ACK Frame (#613) 7767 * Improved PMTUD description (#614, #1036) 7769 * Clarified stream state machine (#634, #662, #743, #894) 7771 * Reserved versions don't need to be generated deterministically 7772 (#831, #931) 7774 * You don't always need the draining period (#871) 7776 * Stateless reset clarified as version-specific (#930, #986) 7778 * initial_max_stream_id_x transport parameters are optional (#970, 7779 #971) 7781 * Ack Delay assumes a default value during the handshake (#1007, 7782 #1009) 7784 * Removed transport parameters from NewSessionTicket (#1015) 7786 C.18. Since draft-ietf-quic-transport-07 7788 * The long header now has version before packet number (#926, #939) 7790 * Rename and consolidate packet types (#846, #822, #847) 7791 * Packet types are assigned new codepoints and the Connection ID 7792 Flag is inverted (#426, #956) 7794 * Removed type for Version Negotiation and use Version 0 (#963, 7795 #968) 7797 * Streams are split into unidirectional and bidirectional (#643, 7798 #656, #720, #872, #175, #885) 7800 - Stream limits now have separate uni- and bi-directional 7801 transport parameters (#909, #958) 7803 - Stream limit transport parameters are now optional and default 7804 to 0 (#970, #971) 7806 * The stream state machine has been split into read and write (#634, 7807 #894) 7809 * Employ variable-length integer encodings throughout (#595) 7811 * Improvements to connection close 7813 - Added distinct closing and draining states (#899, #871) 7815 - Draining period can terminate early (#869, #870) 7817 - Clarifications about stateless reset (#889, #890) 7819 * Address validation for connection migration (#161, #732, #878) 7821 * Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 7823 * negotiated_version is sent in server transport parameters (#710, 7824 #959) 7826 * Increased the range over which packet numbers are randomized 7827 (#864, #850, #964) 7829 C.19. Since draft-ietf-quic-transport-06 7831 * Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 7833 * Split error code space between application and transport (#485) 7835 * Stateless reset token moved to end (#820) 7837 * 1-RTT-protected long header types removed (#848) 7838 * No acknowledgments during draining period (#852) 7840 * Remove "application close" as a separate close type (#854) 7842 * Remove timestamps from the ACK frame (#841) 7844 * Require transport parameters to only appear once (#792) 7846 C.20. Since draft-ietf-quic-transport-05 7848 * Stateless token is server-only (#726) 7850 * Refactor section on connection termination (#733, #748, #328, 7851 #177) 7853 * Limit size of Version Negotiation packet (#585) 7855 * Clarify when and what to ack (#736) 7857 * Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 7859 * Clarify Keep-alive requirements (#729) 7861 C.21. Since draft-ietf-quic-transport-04 7863 * Introduce STOP_SENDING frame, RESET_STREAM only resets in one 7864 direction (#165) 7866 * Removed GOAWAY; application protocols are responsible for graceful 7867 shutdown (#696) 7869 * Reduced the number of error codes (#96, #177, #184, #211) 7871 * Version validation fields can't move or change (#121) 7873 * Removed versions from the transport parameters in a 7874 NewSessionTicket message (#547) 7876 * Clarify the meaning of "bytes in flight" (#550) 7878 * Public reset is now stateless reset and not visible to the path 7879 (#215) 7881 * Reordered bits and fields in STREAM frame (#620) 7883 * Clarifications to the stream state machine (#572, #571) 7884 * Increased the maximum length of the Largest Acknowledged field in 7885 ACK frames to 64 bits (#629) 7887 * truncate_connection_id is renamed to omit_connection_id (#659) 7889 * CONNECTION_CLOSE terminates the connection like TCP RST (#330, 7890 #328) 7892 * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 7894 C.22. Since draft-ietf-quic-transport-03 7896 * Change STREAM and RESET_STREAM layout 7898 * Add MAX_STREAM_ID settings 7900 C.23. Since draft-ietf-quic-transport-02 7902 * The size of the initial packet payload has a fixed minimum (#267, 7903 #472) 7905 * Define when Version Negotiation packets are ignored (#284, #294, 7906 #241, #143, #474) 7908 * The 64-bit FNV-1a algorithm is used for integrity protection of 7909 unprotected packets (#167, #480, #481, #517) 7911 * Rework initial packet types to change how the connection ID is 7912 chosen (#482, #442, #493) 7914 * No timestamps are forbidden in unprotected packets (#542, #429) 7916 * Cryptographic handshake is now on stream 0 (#456) 7918 * Remove congestion control exemption for cryptographic handshake 7919 (#248, #476) 7921 * Version 1 of QUIC uses TLS; a new version is needed to use a 7922 different handshake protocol (#516) 7924 * STREAM frames have a reduced number of offset lengths (#543, #430) 7926 * Split some frames into separate connection- and stream- level 7927 frames (#443) 7929 - WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 7931 - BLOCKED split to match WINDOW_UPDATE split (#454) 7932 - Define STREAM_ID_NEEDED frame (#455) 7934 * A NEW_CONNECTION_ID frame supports connection migration without 7935 linkability (#232, #491, #496) 7937 * Transport parameters for 0-RTT are retained from a previous 7938 connection (#405, #513, #512) 7940 - A client in 0-RTT no longer required to reset excess streams 7941 (#425, #479) 7943 * Expanded security considerations (#440, #444, #445, #448) 7945 C.24. Since draft-ietf-quic-transport-01 7947 * Defined short and long packet headers (#40, #148, #361) 7949 * Defined a versioning scheme and stable fields (#51, #361) 7951 * Define reserved version values for "greasing" negotiation (#112, 7952 #278) 7954 * The initial packet number is randomized (#35, #283) 7956 * Narrow the packet number encoding range requirement (#67, #286, 7957 #299, #323, #356) 7959 * Defined client address validation (#52, #118, #120, #275) 7961 * Define transport parameters as a TLS extension (#49, #122) 7963 * SCUP and COPT parameters are no longer valid (#116, #117) 7965 * Transport parameters for 0-RTT are either remembered from before, 7966 or assume default values (#126) 7968 * The server chooses connection IDs in its final flight (#119, #349, 7969 #361) 7971 * The server echoes the Connection ID and packet number fields when 7972 sending a Version Negotiation packet (#133, #295, #244) 7974 * Defined a minimum packet size for the initial handshake packet 7975 from the client (#69, #136, #139, #164) 7977 * Path MTU Discovery (#64, #106) 7978 * The initial handshake packet from the client needs to fit in a 7979 single packet (#338) 7981 * Forbid acknowledgment of packets containing only ACK and PADDING 7982 (#291) 7984 * Require that frames are processed when packets are acknowledged 7985 (#381, #341) 7987 * Removed the STOP_WAITING frame (#66) 7989 * Don't require retransmission of old timestamps for lost ACK frames 7990 (#308) 7992 * Clarified that frames are not retransmitted, but the information 7993 in them can be (#157, #298) 7995 * Error handling definitions (#335) 7997 * Split error codes into four sections (#74) 7999 * Forbid the use of Public Reset where CONNECTION_CLOSE is possible 8000 (#289) 8002 * Define packet protection rules (#336) 8004 * Require that stream be entirely delivered or reset, including 8005 acknowledgment of all STREAM frames or the RESET_STREAM, before it 8006 closes (#381) 8008 * Remove stream reservation from state machine (#174, #280) 8010 * Only stream 1 does not contribute to connection-level flow control 8011 (#204) 8013 * Stream 1 counts towards the maximum concurrent stream limit (#201, 8014 #282) 8016 * Remove connection-level flow control exclusion for some streams 8017 (except 1) (#246) 8019 * RESET_STREAM affects connection-level flow control (#162, #163) 8021 * Flow control accounting uses the maximum data offset on each 8022 stream, rather than bytes received (#378) 8024 * Moved length-determining fields to the start of STREAM and ACK 8025 (#168, #277) 8027 * Added the ability to pad between frames (#158, #276) 8029 * Remove error code and reason phrase from GOAWAY (#352, #355) 8031 * GOAWAY includes a final stream number for both directions (#347) 8033 * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 8034 consistent offset (#249) 8036 * Defined priority as the responsibility of the application protocol 8037 (#104, #303) 8039 C.25. Since draft-ietf-quic-transport-00 8041 * Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 8043 * Defined versioning 8045 * Reworked description of packet and frame layout 8047 * Error code space is divided into regions for each component 8049 * Use big endian for all numeric values 8051 C.26. Since draft-hamilton-quic-transport-protocol-01 8053 * Adopted as base for draft-ietf-quic-tls 8055 * Updated authors/editors list 8057 * Added IANA Considerations section 8059 * Moved Contributors and Acknowledgments to appendices 8061 Contributors 8063 The original design and rationale behind this protocol draw 8064 significantly from work by Jim Roskind [EARLY-DESIGN]. 8066 The IETF QUIC Working Group received an enormous amount of support 8067 from many people. The following people provided substantive 8068 contributions to this document: Alessandro Ghedini, Alyssa Wilk, 8069 Antoine Delignat-Lavaud, Brian Trammell, Christian Huitema, Colin 8070 Perkins, David Schinazi, Dmitri Tikhonov, Eric Kinnear, Eric 8071 Rescorla, Gorry Fairhurst, Ian Swett, Igor Lubashev, 奥 一穂 (Kazuho 8072 Oku), Lucas Pardue, Magnus Westerlund, Marten Seemann, Martin Duke, 8073 Mike Bishop, Mikkel Fahnøe Jørgensen, Mirja Kühlewind, Nick Banks, 8074 Nick Harper, Patrick McManus, Roberto Peon, Ryan Hamilton, Subodh 8075 Iyengar, Tatsuhiro Tsujikawa, Ted Hardie, Tom Jones, and Victor 8076 Vasiliev. 8078 Authors' Addresses 8080 Jana Iyengar (editor) 8081 Fastly 8083 Email: jri.ietf@gmail.com 8085 Martin Thomson (editor) 8086 Mozilla 8088 Email: mt@lowentropy.net