idnits 2.17.1 draft-ietf-quic-transport-31.txt: -(7832): 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 6 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 date (25 September 2020) is 1308 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 2317 == Missing Reference: 'CH' is mentioned on line 2313, but not defined == Missing Reference: 'SH' is mentioned on line 2315, but not defined == Missing Reference: 'EE' is mentioned on line 2316, but not defined == Missing Reference: 'CERT' is mentioned on line 2316, but not defined == Missing Reference: 'CV' is mentioned on line 2316, but not defined == Missing Reference: 'FIN' is mentioned on line 2316, but not defined -- Looks like a reference, but probably isn't: '1' on line 2315 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-31 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-31 -- 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-11 == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-07 Summary: 0 errors (**), 0 flaws (~~), 12 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: 29 March 2021 Mozilla 6 25 September 2020 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-31 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 (mailto:quic@ietf.org)), which is 21 archived at https://mailarchive.ietf.org/arch/search/?email_list=quic 23 Working Group information can be found at https://github.com/quicwg; 24 source code and issues list for this draft can be found at 25 https://github.com/quicwg/base-drafts/labels/-transport. 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 29 March 2021. 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 8 62 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 9 63 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 64 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 12 66 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 13 67 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13 68 2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 14 69 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15 71 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 18 72 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20 73 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 21 74 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22 75 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 24 76 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 24 77 4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 25 78 4.3. Flow Control Performance . . . . . . . . . . . . . . . . 26 79 4.4. Handling Stream Cancellation . . . . . . . . . . . . . . 27 80 4.5. Stream Final Size . . . . . . . . . . . . . . . . . . . . 27 81 4.6. Controlling Concurrency . . . . . . . . . . . . . . . . . 28 82 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 29 83 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 29 84 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 31 85 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 32 86 5.2. Matching Packets to Connections . . . . . . . . . . . . . 33 87 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 34 88 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 34 89 5.2.3. Considerations for Simple Load Balancers . . . . . . 35 90 5.3. Operations on Connections . . . . . . . . . . . . . . . . 36 91 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 37 92 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 37 93 6.2. Handling Version Negotiation Packets . . . . . . . . . . 38 94 6.2.1. Version Negotiation Between Draft Versions . . . . . 38 95 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 39 96 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 39 97 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 40 98 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 42 99 7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 43 100 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 45 101 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 46 102 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 48 103 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 48 104 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 49 105 8.1. Address Validation During Connection Establishment . . . 49 106 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 50 107 8.1.2. Address Validation using Retry Packets . . . . . . . 51 108 8.1.3. Address Validation for Future Connections . . . . . . 52 109 8.1.4. Address Validation Token Integrity . . . . . . . . . 54 110 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 55 111 8.2.1. Initiating Path Validation . . . . . . . . . . . . . 56 112 8.2.2. Path Validation Responses . . . . . . . . . . . . . . 57 113 8.2.3. Successful Path Validation . . . . . . . . . . . . . 57 114 8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 57 115 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 58 116 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 59 117 9.2. Initiating Connection Migration . . . . . . . . . . . . . 59 118 9.3. Responding to Connection Migration . . . . . . . . . . . 60 119 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 60 120 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 61 121 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 61 122 9.4. Loss Detection and Congestion Control . . . . . . . . . . 62 123 9.5. Privacy Implications of Connection Migration . . . . . . 63 124 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 65 125 9.6.1. Communicating a Preferred Address . . . . . . . . . . 65 126 9.6.2. Migration to a Preferred Address . . . . . . . . . . 66 127 9.6.3. Interaction of Client Migration and Preferred 128 Address . . . . . . . . . . . . . . . . . . . . . . . 66 129 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 67 130 10. Connection Termination . . . . . . . . . . . . . . . . . . . 67 131 10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 68 132 10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 68 133 10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 68 134 10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 69 135 10.2.1. Closing Connection State . . . . . . . . . . . . . . 70 136 10.2.2. Draining Connection State . . . . . . . . . . . . . 71 137 10.2.3. Immediate Close During the Handshake . . . . . . . . 72 138 10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 73 139 10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 76 140 10.3.2. Calculating a Stateless Reset Token . . . . . . . . 77 141 10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 78 142 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 78 143 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79 144 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 79 146 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 80 147 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 80 148 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 81 149 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 82 150 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 83 151 12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 87 152 13. Packetization and Reliability . . . . . . . . . . . . . . . . 87 153 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 88 154 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 88 155 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 89 156 13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 90 157 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 91 158 13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 92 159 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 92 160 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 93 161 13.2.7. PADDING Frames Consume Congestion Window . . . . . . 93 162 13.3. Retransmission of Information . . . . . . . . . . . . . 93 163 13.4. Explicit Congestion Notification . . . . . . . . . . . . 96 164 13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 96 165 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 97 166 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 99 167 14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 100 168 14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 100 169 14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 101 170 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 102 171 14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 102 172 14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 102 173 14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 102 174 14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 103 175 14.4.1. PMTU Probes Containing Source Connection ID . . . . 103 176 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 103 177 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 104 178 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 105 179 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 105 180 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 106 181 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 109 182 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 110 183 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 113 184 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114 185 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 115 186 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117 187 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 119 188 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 120 189 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 121 190 18.2. Transport Parameter Definitions . . . . . . . . . . . . 121 191 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125 192 19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125 193 19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 126 194 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126 195 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 128 196 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 129 197 19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 130 198 19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 131 199 19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131 200 19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132 201 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 133 202 19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 135 203 19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 135 204 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 136 205 19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 137 206 19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 138 207 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 138 208 19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 139 209 19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140 210 19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141 211 19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 142 212 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142 213 19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143 214 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 144 215 20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144 216 20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 145 217 20.2. Application Protocol Error Codes . . . . . . . . . . . . 146 218 21. Security Considerations . . . . . . . . . . . . . . . . . . . 147 219 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 147 220 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 148 221 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 148 222 21.4. Request Forgery Attacks . . . . . . . . . . . . . . . . 148 223 21.4.1. Control Options for Endpoints . . . . . . . . . . . 149 224 21.4.2. Request Forgery with Client Initial Packets . . . . 151 225 21.4.3. Request Forgery with Preferred Addresses . . . . . . 151 226 21.4.4. Request Forgery with Spoofed Migration . . . . . . . 152 227 21.4.5. Generic Request Forgery Countermeasures . . . . . . 152 228 21.5. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 153 229 21.6. Stream Fragmentation and Reassembly Attacks . . . . . . 154 230 21.7. Stream Commitment Attack . . . . . . . . . . . . . . . . 154 231 21.8. Peer Denial of Service . . . . . . . . . . . . . . . . . 155 232 21.9. Explicit Congestion Notification Attacks . . . . . . . . 155 233 21.10. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 156 234 21.11. Version Downgrade . . . . . . . . . . . . . . . . . . . 156 235 21.12. Targeted Attacks by Routing . . . . . . . . . . . . . . 157 236 21.13. Overview of Security Properties . . . . . . . . . . . . 157 237 21.13.1. Handshake . . . . . . . . . . . . . . . . . . . . . 157 238 21.13.2. Protected Packets . . . . . . . . . . . . . . . . . 159 239 21.13.3. Connection Migration . . . . . . . . . . . . . . . 160 240 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 241 22.1. Registration Policies for QUIC Registries . . . . . . . 164 242 22.1.1. Provisional Registrations . . . . . . . . . . . . . 164 243 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 165 244 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 166 245 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 166 246 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 167 247 22.3. QUIC Frame Types Registry . . . . . . . . . . . . . . . 168 248 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 169 249 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 250 23.1. Normative References . . . . . . . . . . . . . . . . . . 171 251 23.2. Informative References . . . . . . . . . . . . . . . . . 172 252 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 175 253 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 176 254 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 177 255 C.1. Since draft-ietf-quic-transport-30 . . . . . . . . . . . 177 256 C.2. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 177 257 C.3. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 178 258 C.4. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 178 259 C.5. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 180 260 C.6. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 180 261 C.7. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 180 262 C.8. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 181 263 C.9. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 182 264 C.10. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 183 265 C.11. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 183 266 C.12. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 184 267 C.13. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 184 268 C.14. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 185 269 C.15. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 186 270 C.16. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 187 271 C.17. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 187 272 C.18. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 187 273 C.19. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 188 274 C.20. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 189 275 C.21. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 189 276 C.22. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 190 277 C.23. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 191 278 C.24. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 191 279 C.25. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 192 280 C.26. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 192 281 C.27. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 193 282 C.28. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 193 283 C.29. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 194 284 C.30. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 194 285 C.31. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 196 286 C.32. Since draft-hamilton-quic-transport-protocol-01 . . . . . 197 287 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 197 288 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 198 290 1. Overview 292 QUIC is a multiplexed and secure general-purpose transport protocol 293 that provides: 295 * Stream multiplexing 297 * Stream- and connection-level flow control 299 * Low-latency connection establishment 301 * Connection migration and resilience to NAT rebinding 303 * Authenticated and encrypted header and payload 305 QUIC establishes a connection, which is a stateful interaction 306 between a client and server. The primary purpose of a connection is 307 to support the structured exchange of data by an application 308 protocol. 310 Application protocols exchange information over a QUIC connection via 311 streams, which are ordered sequences of bytes. Two types of stream 312 can be created: bidirectional streams, which allow both endpoints to 313 send data; and unidirectional streams, which allow a single endpoint 314 to send data. A credit-based scheme is used to limit stream creation 315 and to bound the amount of data that can be sent. 317 The QUIC handshake combines negotiation of cryptographic and 318 transport parameters. The handshake is structured to permit the 319 exchange of application data as soon as possible. This includes an 320 option for clients to send data immediately (0-RTT), which might 321 require prior communication to enable. 323 QUIC connections are not strictly bound to a single network path. 324 Connection migration uses connection identifiers to allow connections 325 to transfer to a new network path. 327 Frames are used in QUIC to communicate between endpoints. One or 328 more frames are assembled into a QUIC packet. QUIC authenticates all 329 packets and encrypts as much as is practical. QUIC packets are 330 carried in UDP datagrams ([UDP]) to better facilitate deployment in 331 existing systems and networks. 333 Once established, multiple options are provided for connection 334 termination. Applications can manage a graceful shutdown, endpoints 335 can negotiate a timeout period, errors can cause immediate connection 336 teardown, and a stateless mechanism provides for termination of 337 connections after one endpoint has lost state. 339 1.1. Document Structure 341 This document describes the core QUIC protocol and is structured as 342 follows: 344 * Streams are the basic service abstraction that QUIC provides. 346 - Section 2 describes core concepts related to streams, 348 - Section 3 provides a reference model for stream states, and 350 - Section 4 outlines the operation of flow control. 352 * Connections are the context in which QUIC endpoints communicate. 354 - Section 5 describes core concepts related to connections, 356 - Section 6 describes version negotiation, 358 - Section 7 details the process for establishing connections, 360 - Section 8 describes address validation and critical denial of 361 service mitigations, 363 - Section 9 describes how endpoints migrate a connection to a new 364 network path, 366 - Section 10 lists the options for terminating an open 367 connection, and 369 - Section 11 provides guidance for stream and connection error 370 handling. 372 * Packets and frames are the basic unit used by QUIC to communicate. 374 - Section 12 describes concepts related to packets and frames, 376 - Section 13 defines models for the transmission, retransmission, 377 and acknowledgement of data, and 379 - Section 14 specifies rules for managing the size of packets. 381 * Finally, encoding details of QUIC protocol elements are described 382 in: 384 - Section 15 (Versions), 386 - Section 16 (Integer Encoding), 387 - Section 17 (Packet Headers), 389 - Section 18 (Transport Parameters), 391 - Section 19 (Frames), and 393 - Section 20 (Errors). 395 Accompanying documents describe QUIC's loss detection and congestion 396 control [QUIC-RECOVERY], and the use of TLS for key negotiation 397 [QUIC-TLS]. 399 This document defines QUIC version 1, which conforms to the protocol 400 invariants in [QUIC-INVARIANTS]. 402 To refer to QUIC version 1, cite this document. References to the 403 limited set of version-independent properties of QUIC can cite 404 [QUIC-INVARIANTS]. 406 1.2. Terms and Definitions 408 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 409 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 410 "OPTIONAL" in this document are to be interpreted as described in 411 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 412 capitals, as shown here. 414 Commonly used terms in the document are described below. 416 QUIC: The transport protocol described by this document. QUIC is a 417 name, not an acronym. 419 QUIC packet: A complete processable unit of QUIC that can be 420 encapsulated in a UDP datagram. Multiple QUIC packets can be 421 encapsulated in a single UDP datagram. 423 Ack-eliciting Packet: A QUIC packet that contains frames other than 424 ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to 425 send an acknowledgment; see Section 13.2.1. 427 Endpoint: An entity that can participate in a QUIC connection by 428 generating, receiving, and processing QUIC packets. There are 429 only two types of endpoint in QUIC: client and server. 431 Client: The endpoint that initiates a QUIC connection. 433 Server: The endpoint that accepts a QUIC connection. 435 Address: When used without qualification, the tuple of IP version, 436 IP address, and UDP port number that represents one end of a 437 network path. 439 Connection ID: An identifier that is used to identify a QUIC 440 connection at an endpoint. Each endpoint selects one or more 441 Connection IDs for its peer to include in packets sent towards the 442 endpoint. This value is opaque to the peer. 444 Stream: A unidirectional or bidirectional channel of ordered bytes 445 within a QUIC connection. A QUIC connection can carry multiple 446 simultaneous streams. 448 Application: An entity that uses QUIC to send and receive data. 450 1.3. Notational Conventions 452 Packet and frame diagrams in this document use a custom format. The 453 purpose of this format is to summarize, not define, protocol 454 elements. Prose defines the complete semantics and details of 455 structures. 457 Complex fields are named and then followed by a list of fields 458 surrounded by a pair of matching braces. Each field in this list is 459 separated by commas. 461 Individual fields include length information, plus indications about 462 fixed value, optionality, or repetitions. Individual fields use the 463 following notational conventions, with all lengths in bits: 465 x (A): Indicates that x is A bits long 467 x (i): Indicates that x uses the variable-length encoding in 468 Section 16 470 x (A..B): Indicates that x can be any length from A to B; A can be 471 omitted to indicate a minimum of zero bits and B can be omitted to 472 indicate no set upper limit; values in this format always end on 473 an octet boundary 475 x (?) = C: Indicates that x has a fixed value of C with the length 476 described by ?, as above 478 x (?) = C..D: Indicates that x has a value in the range from C to D, 479 inclusive, with the length described by ?, as above 481 [x (E)]: Indicates that x is optional (and has length of E) 482 x (E) ...: Indicates that x is repeated zero or more times (and that 483 each instance is length E) 485 This document uses network byte order (that is, big endian) values. 486 Fields are placed starting from the high-order bits of each byte. 488 By convention, individual fields reference a complex field by using 489 the name of the complex field. 491 For example: 493 Example Structure { 494 One-bit Field (1), 495 7-bit Field with Fixed Value (7) = 61, 496 Field with Variable-Length Integer (i), 497 Arbitrary-Length Field (..), 498 Variable-Length Field (8..24), 499 Field With Minimum Length (16..), 500 Field With Maximum Length (..128), 501 [Optional Field (64)], 502 Repeated Field (8) ..., 503 } 505 Figure 1: Example Format 507 2. Streams 509 Streams in QUIC provide a lightweight, ordered byte-stream 510 abstraction to an application. Streams can be unidirectional or 511 bidirectional. 513 Streams can be created by sending data. Other processes associated 514 with stream management - ending, cancelling, and managing flow 515 control - are all designed to impose minimal overheads. For 516 instance, a single STREAM frame (Section 19.8) can open, carry data 517 for, and close a stream. Streams can also be long-lived and can last 518 the entire duration of a connection. 520 Streams can be created by either endpoint, can concurrently send data 521 interleaved with other streams, and can be cancelled. QUIC does not 522 provide any means of ensuring ordering between bytes on different 523 streams. 525 QUIC allows for an arbitrary number of streams to operate 526 concurrently and for an arbitrary amount of data to be sent on any 527 stream, subject to flow control constraints and stream limits; see 528 Section 4. 530 2.1. Stream Types and Identifiers 532 Streams can be unidirectional or bidirectional. Unidirectional 533 streams carry data in one direction: from the initiator of the stream 534 to its peer. Bidirectional streams allow for data to be sent in both 535 directions. 537 Streams are identified within a connection by a numeric value, 538 referred to as the stream ID. A stream ID is a 62-bit integer (0 to 539 2^62-1) that is unique for all streams on a connection. Stream IDs 540 are encoded as variable-length integers; see Section 16. A QUIC 541 endpoint MUST NOT reuse a stream ID within a connection. 543 The least significant bit (0x1) of the stream ID identifies the 544 initiator of the stream. Client-initiated streams have even-numbered 545 stream IDs (with the bit set to 0), and server-initiated streams have 546 odd-numbered stream IDs (with the bit set to 1). 548 The second least significant bit (0x2) of the stream ID distinguishes 549 between bidirectional streams (with the bit set to 0) and 550 unidirectional streams (with the bit set to 1). 552 The two least significant bits from a stream ID therefore identify a 553 stream as one of four types, as summarized in Table 1. 555 +======+==================================+ 556 | Bits | Stream Type | 557 +======+==================================+ 558 | 0x0 | Client-Initiated, Bidirectional | 559 +------+----------------------------------+ 560 | 0x1 | Server-Initiated, Bidirectional | 561 +------+----------------------------------+ 562 | 0x2 | Client-Initiated, Unidirectional | 563 +------+----------------------------------+ 564 | 0x3 | Server-Initiated, Unidirectional | 565 +------+----------------------------------+ 567 Table 1: Stream ID Types 569 The stream space for each type begins at the minimum value (0x0 570 through 0x3 respectively); successive streams of each type are 571 created with numerically increasing stream IDs. A stream ID that is 572 used out of order results in all streams of that type with lower- 573 numbered stream IDs also being opened. 575 2.2. Sending and Receiving Data 577 STREAM frames (Section 19.8) encapsulate data sent by an application. 578 An endpoint uses the Stream ID and Offset fields in STREAM frames to 579 place data in order. 581 Endpoints MUST be able to deliver stream data to an application as an 582 ordered byte-stream. Delivering an ordered byte-stream requires that 583 an endpoint buffer any data that is received out of order, up to the 584 advertised flow control limit. 586 QUIC makes no specific allowances for delivery of stream data out of 587 order. However, implementations MAY choose to offer the ability to 588 deliver data out of order to a receiving application. 590 An endpoint could receive data for a stream at the same stream offset 591 multiple times. Data that has already been received can be 592 discarded. The data at a given offset MUST NOT change if it is sent 593 multiple times; an endpoint MAY treat receipt of different data at 594 the same offset within a stream as a connection error of type 595 PROTOCOL_VIOLATION. 597 Streams are an ordered byte-stream abstraction with no other 598 structure visible to QUIC. STREAM frame boundaries are not expected 599 to be preserved when data is transmitted, retransmitted after packet 600 loss, or delivered to the application at a receiver. 602 An endpoint MUST NOT send data on any stream without ensuring that it 603 is within the flow control limits set by its peer. Flow control is 604 described in detail in Section 4. 606 2.3. Stream Prioritization 608 Stream multiplexing can have a significant effect on application 609 performance if resources allocated to streams are correctly 610 prioritized. 612 QUIC does not provide a mechanism for exchanging prioritization 613 information. Instead, it relies on receiving priority information 614 from the application. 616 A QUIC implementation SHOULD provide ways in which an application can 617 indicate the relative priority of streams. An implementation uses 618 information provided by the application to determine how to allocate 619 resources to active streams. 621 2.4. Operations on Streams 623 This document does not define an API for QUIC, but instead defines a 624 set of functions on streams that application protocols can rely upon. 625 An application protocol can assume that a QUIC implementation 626 provides an interface that includes the operations described in this 627 section. An implementation designed for use with a specific 628 application protocol might provide only those operations that are 629 used by that protocol. 631 On the sending part of a stream, an application protocol can: 633 * write data, understanding when stream flow control credit 634 (Section 4.1) has successfully been reserved to send the written 635 data; 637 * end the stream (clean termination), resulting in a STREAM frame 638 (Section 19.8) with the FIN bit set; and 640 * reset the stream (abrupt termination), resulting in a RESET_STREAM 641 frame (Section 19.4) if the stream was not already in a terminal 642 state. 644 On the receiving part of a stream, an application protocol can: 646 * read data; and 648 * abort reading of the stream and request closure, possibly 649 resulting in a STOP_SENDING frame (Section 19.5). 651 An application protocol can also request to be informed of state 652 changes on streams, including when the peer has opened or reset a 653 stream, when a peer aborts reading on a stream, when new data is 654 available, and when data can or cannot be written to the stream due 655 to flow control. 657 3. Stream States 659 This section describes streams in terms of their send or receive 660 components. Two state machines are described: one for the streams on 661 which an endpoint transmits data (Section 3.1), and another for 662 streams on which an endpoint receives data (Section 3.2). 664 Unidirectional streams use the applicable state machine directly. 665 Bidirectional streams use both state machines. For the most part, 666 the use of these state machines is the same whether the stream is 667 unidirectional or bidirectional. The conditions for opening a stream 668 are slightly more complex for a bidirectional stream because the 669 opening of either the send or receive side causes the stream to open 670 in both directions. 672 The state machines shown in this section are largely informative. 673 This document uses stream states to describe rules for when and how 674 different types of frames can be sent and the reactions that are 675 expected when different types of frames are received. Though these 676 state machines are intended to be useful in implementing QUIC, these 677 states are not intended to constrain implementations. An 678 implementation can define a different state machine as long as its 679 behavior is consistent with an implementation that implements these 680 states. 682 Note: In some cases, a single event or action can cause a transition 683 through multiple states. For instance, sending STREAM with a FIN 684 bit set can cause two state transitions for a sending stream: from 685 the Ready state to the Send state, and from the Send state to the 686 Data Sent state. 688 3.1. Sending Stream States 690 Figure 2 shows the states for the part of a stream that sends data to 691 a peer. 693 o 694 | Create Stream (Sending) 695 | Peer Creates Bidirectional Stream 696 v 697 +-------+ 698 | Ready | Send RESET_STREAM 699 | |-----------------------. 700 +-------+ | 701 | | 702 | Send STREAM / | 703 | STREAM_DATA_BLOCKED | 704 | | 705 | Peer Creates | 706 | Bidirectional Stream | 707 v | 708 +-------+ | 709 | Send | Send RESET_STREAM | 710 | |---------------------->| 711 +-------+ | 712 | | 713 | Send STREAM + FIN | 714 v v 715 +-------+ +-------+ 716 | Data | Send RESET_STREAM | Reset | 717 | Sent |------------------>| Sent | 718 +-------+ +-------+ 719 | | 720 | Recv All ACKs | Recv ACK 721 v v 722 +-------+ +-------+ 723 | Data | | Reset | 724 | Recvd | | Recvd | 725 +-------+ +-------+ 727 Figure 2: States for Sending Parts of Streams 729 The sending part of a stream that the endpoint initiates (types 0 and 730 2 for clients, 1 and 3 for servers) is opened by the application. 731 The "Ready" state represents a newly created stream that is able to 732 accept data from the application. Stream data might be buffered in 733 this state in preparation for sending. 735 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a 736 sending part of a stream to enter the "Send" state. An 737 implementation might choose to defer allocating a stream ID to a 738 stream until it sends the first STREAM frame and enters this state, 739 which can allow for better stream prioritization. 741 The sending part of a bidirectional stream initiated by a peer (type 742 0 for a server, type 1 for a client) starts in the "Ready" state when 743 the receiving part is created. 745 In the "Send" state, an endpoint transmits - and retransmits as 746 necessary - stream data in STREAM frames. The endpoint respects the 747 flow control limits set by its peer, and continues to accept and 748 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 749 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 750 stream or connection flow control limits Section 4.1. 752 After the application indicates that all stream data has been sent 753 and a STREAM frame containing the FIN bit is sent, the sending part 754 of the stream enters the "Data Sent" state. From this state, the 755 endpoint only retransmits stream data as necessary. The endpoint 756 does not need to check flow control limits or send 757 STREAM_DATA_BLOCKED frames for a stream in this state. 758 MAX_STREAM_DATA frames might be received until the peer receives the 759 final stream offset. The endpoint can safely ignore any 760 MAX_STREAM_DATA frames it receives from its peer for a stream in this 761 state. 763 Once all stream data has been successfully acknowledged, the sending 764 part of the stream enters the "Data Recvd" state, which is a terminal 765 state. 767 From any of the "Ready", "Send", or "Data Sent" states, an 768 application can signal that it wishes to abandon transmission of 769 stream data. Alternatively, an endpoint might receive a STOP_SENDING 770 frame from its peer. In either case, the endpoint sends a 771 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 772 state. 774 An endpoint MAY send a RESET_STREAM as the first frame that mentions 775 a stream; this causes the sending part of that stream to open and 776 then immediately transition to the "Reset Sent" state. 778 Once a packet containing a RESET_STREAM has been acknowledged, the 779 sending part of the stream enters the "Reset Recvd" state, which is a 780 terminal state. 782 3.2. Receiving Stream States 784 Figure 3 shows the states for the part of a stream that receives data 785 from a peer. The states for a receiving part of a stream mirror only 786 some of the states of the sending part of the stream at the peer. 787 The receiving part of a stream does not track states on the sending 788 part that cannot be observed, such as the "Ready" state. Instead, 789 the receiving part of a stream tracks the delivery of data to the 790 application, some of which cannot be observed by the sender. 792 o 793 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 794 | Create Bidirectional Stream (Sending) 795 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 796 | Create Higher-Numbered Stream 797 v 798 +-------+ 799 | Recv | Recv RESET_STREAM 800 | |-----------------------. 801 +-------+ | 802 | | 803 | Recv STREAM + FIN | 804 v | 805 +-------+ | 806 | Size | Recv RESET_STREAM | 807 | Known |---------------------->| 808 +-------+ | 809 | | 810 | Recv All Data | 811 v v 812 +-------+ Recv RESET_STREAM +-------+ 813 | Data |--- (optional) --->| Reset | 814 | Recvd | Recv All Data | Recvd | 815 +-------+<-- (optional) ----+-------+ 816 | | 817 | App Read All Data | App Read RST 818 v v 819 +-------+ +-------+ 820 | Data | | Reset | 821 | Read | | Read | 822 +-------+ +-------+ 824 Figure 3: States for Receiving Parts of Streams 826 The receiving part of a stream initiated by a peer (types 1 and 3 for 827 a client, or 0 and 2 for a server) is created when the first STREAM, 828 STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that 829 stream. For bidirectional streams initiated by a peer, receipt of a 830 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 831 stream also creates the receiving part. The initial state for the 832 receiving part of a stream is "Recv". 834 The receiving part of a stream enters the "Recv" state when the 835 sending part of a bidirectional stream initiated by the endpoint 836 (type 0 for a client, type 1 for a server) enters the "Ready" state. 838 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 839 STOP_SENDING frame is received from the peer for that stream. 840 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 841 that the remote peer has opened the stream and is providing flow 842 control credit. Receiving a STOP_SENDING frame for an unopened 843 stream indicates that the remote peer no longer wishes to receive 844 data on this stream. Either frame might arrive before a STREAM or 845 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 847 Before a stream is created, all streams of the same type with lower- 848 numbered stream IDs MUST be created. This ensures that the creation 849 order for streams is consistent on both endpoints. 851 In the "Recv" state, the endpoint receives STREAM and 852 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 853 reassembled into the correct order for delivery to the application. 854 As data is consumed by the application and buffer space becomes 855 available, the endpoint sends MAX_STREAM_DATA frames to allow the 856 peer to send more data. 858 When a STREAM frame with a FIN bit is received, the final size of the 859 stream is known; see Section 4.5. The receiving part of the stream 860 then enters the "Size Known" state. In this state, the endpoint no 861 longer needs to send MAX_STREAM_DATA frames, it only receives any 862 retransmissions of stream data. 864 Once all data for the stream has been received, the receiving part 865 enters the "Data Recvd" state. This might happen as a result of 866 receiving the same STREAM frame that causes the transition to "Size 867 Known". After all data has been received, any STREAM or 868 STREAM_DATA_BLOCKED frames for the stream can be discarded. 870 The "Data Recvd" state persists until stream data has been delivered 871 to the application. Once stream data has been delivered, the stream 872 enters the "Data Read" state, which is a terminal state. 874 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 875 causes the stream to enter the "Reset Recvd" state. This might cause 876 the delivery of stream data to the application to be interrupted. 878 It is possible that all stream data has already been received when a 879 RESET_STREAM is received (that is, in the "Data Recvd" state). 880 Similarly, it is possible for remaining stream data to arrive after 881 receiving a RESET_STREAM frame (the "Reset Recvd" state). An 882 implementation is free to manage this situation as it chooses. 884 Sending RESET_STREAM means that an endpoint cannot guarantee delivery 885 of stream data; however there is no requirement that stream data not 886 be delivered if a RESET_STREAM is received. An implementation MAY 887 interrupt delivery of stream data, discard any data that was not 888 consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM 889 signal might be suppressed or withheld if stream data is completely 890 received and is buffered to be read by the application. If the 891 RESET_STREAM is suppressed, the receiving part of the stream remains 892 in "Data Recvd". 894 Once the application receives the signal indicating that the stream 895 was reset, the receiving part of the stream transitions to the "Reset 896 Read" state, which is a terminal state. 898 3.3. Permitted Frame Types 900 The sender of a stream sends just three frame types that affect the 901 state of a stream at either sender or receiver: STREAM 902 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 903 (Section 19.4). 905 A sender MUST NOT send any of these frames from a terminal state 906 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send a STREAM or 907 STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or 908 any terminal state, that is, after sending a RESET_STREAM frame. A 909 receiver could receive any of these three frames in any state, due to 910 the possibility of delayed delivery of packets carrying them. 912 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 913 STOP_SENDING frames (Section 19.5). 915 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 916 receiver MAY send STOP_SENDING in any state where it has not received 917 a RESET_STREAM frame; that is states other than "Reset Recvd" or 918 "Reset Read". However there is little value in sending a 919 STOP_SENDING frame in the "Data Recvd" state, since all stream data 920 has been received. A sender could receive either of these two frames 921 in any state as a result of delayed delivery of packets. 923 3.4. Bidirectional Stream States 925 A bidirectional stream is composed of sending and receiving parts. 926 Implementations may represent states of the bidirectional stream as 927 composites of sending and receiving stream states. The simplest 928 model presents the stream as "open" when either sending or receiving 929 parts are in a non-terminal state and "closed" when both sending and 930 receiving streams are in terminal states. 932 Table 2 shows a more complex mapping of bidirectional stream states 933 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 934 shows that multiple states on sending or receiving parts of streams 935 are mapped to the same composite state. Note that this is just one 936 possibility for such a mapping; this mapping requires that data is 937 acknowledged before the transition to a "closed" or "half-closed" 938 state. 940 +======================+======================+=================+ 941 | Sending Part | Receiving Part | Composite State | 942 +======================+======================+=================+ 943 | No Stream/Ready | No Stream/Recv *1 | idle | 944 +----------------------+----------------------+-----------------+ 945 | Ready/Send/Data Sent | Recv/Size Known | open | 946 +----------------------+----------------------+-----------------+ 947 | Ready/Send/Data Sent | Data Recvd/Data Read | half-closed | 948 | | | (remote) | 949 +----------------------+----------------------+-----------------+ 950 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 951 | | Read | (remote) | 952 +----------------------+----------------------+-----------------+ 953 | Data Recvd | Recv/Size Known | half-closed | 954 | | | (local) | 955 +----------------------+----------------------+-----------------+ 956 | Reset Sent/Reset | Recv/Size Known | half-closed | 957 | Recvd | | (local) | 958 +----------------------+----------------------+-----------------+ 959 | Reset Sent/Reset | Data Recvd/Data Read | closed | 960 | Recvd | | | 961 +----------------------+----------------------+-----------------+ 962 | Reset Sent/Reset | Reset Recvd/Reset | closed | 963 | Recvd | Read | | 964 +----------------------+----------------------+-----------------+ 965 | Data Recvd | Data Recvd/Data Read | closed | 966 +----------------------+----------------------+-----------------+ 967 | Data Recvd | Reset Recvd/Reset | closed | 968 | | Read | | 969 +----------------------+----------------------+-----------------+ 971 Table 2: Possible Mapping of Stream States to HTTP/2 973 Note (*1): A stream is considered "idle" if it has not yet been 974 created, or if the receiving part of the stream is in the "Recv" 975 state without yet having received any frames. 977 3.5. Solicited State Transitions 979 If an application is no longer interested in the data it is receiving 980 on a stream, it can abort reading the stream and specify an 981 application error code. 983 If the stream is in the "Recv" or "Size Known" states, the transport 984 SHOULD signal this by sending a STOP_SENDING frame to prompt closure 985 of the stream in the opposite direction. This typically indicates 986 that the receiving application is no longer reading data it receives 987 from the stream, but it is not a guarantee that incoming data will be 988 ignored. 990 STREAM frames received after sending a STOP_SENDING frame are still 991 counted toward connection and stream flow control, even though these 992 frames can be discarded upon receipt. 994 A STOP_SENDING frame requests that the receiving endpoint send a 995 RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame 996 MUST send a RESET_STREAM frame if the stream is in the Ready or Send 997 state. If the stream is in the "Data Sent" state, the endpoint MAY 998 defer sending the RESET_STREAM frame until the packets containing 999 outstanding data are acknowledged or declared lost. If any 1000 outstanding data is declared lost, the endpoint SHOULD send a 1001 RESET_STREAM frame instead of retransmitting the data. 1003 An endpoint SHOULD copy the error code from the STOP_SENDING frame to 1004 the RESET_STREAM frame it sends, but MAY use any application error 1005 code. An endpoint that sends a STOP_SENDING frame MAY ignore the 1006 error code in any RESET_STREAM frames subsequently received for that 1007 stream. 1009 STOP_SENDING SHOULD only be sent for a stream that has not been reset 1010 by the peer. STOP_SENDING is most useful for streams in the "Recv" 1011 or "Size Known" states. 1013 An endpoint is expected to send another STOP_SENDING frame if a 1014 packet containing a previous STOP_SENDING is lost. However, once 1015 either all stream data or a RESET_STREAM frame has been received for 1016 the stream - that is, the stream is in any state other than "Recv" or 1017 "Size Known" - sending a STOP_SENDING frame is unnecessary. 1019 An endpoint that wishes to terminate both directions of a 1020 bidirectional stream can terminate one direction by sending a 1021 RESET_STREAM frame, and it can encourage prompt termination in the 1022 opposite direction by sending a STOP_SENDING frame. 1024 4. Flow Control 1026 It is necessary to limit the amount of data that a receiver could 1027 buffer, to prevent a fast sender from overwhelming a slow receiver, 1028 or to prevent a malicious sender from consuming a large amount of 1029 memory at a receiver. To enable a receiver to limit memory 1030 commitment to a connection and to apply back pressure on the sender, 1031 streams are flow controlled both individually and as an aggregate. A 1032 QUIC receiver controls the maximum amount of data the sender can send 1033 on a stream at any time, as described in Section 4.1 and Section 4.2. 1035 Similarly, to limit concurrency within a connection, a QUIC endpoint 1036 controls the maximum cumulative number of streams that its peer can 1037 initiate, as described in Section 4.6. 1039 Data sent in CRYPTO frames is not flow controlled in the same way as 1040 stream data. QUIC relies on the cryptographic protocol 1041 implementation to avoid excessive buffering of data; see [QUIC-TLS]. 1042 To avoid excessive buffering at multiple layers, QUIC implementations 1043 SHOULD provide an interface for the cryptographic protocol 1044 implementation to communicate its buffering limits. 1046 4.1. Data Flow Control 1048 QUIC employs a limit-based flow-control scheme where a receiver 1049 advertises the limit of total bytes it is prepared to receive on a 1050 given stream or for the entire connection. This leads to two levels 1051 of data flow control in QUIC: 1053 * Stream flow control, which prevents a single stream from consuming 1054 the entire receive buffer for a connection by limiting the amount 1055 of data that can be sent on any stream. 1057 * Connection flow control, which prevents senders from exceeding a 1058 receiver's buffer capacity for the connection, by limiting the 1059 total bytes of stream data sent in STREAM frames on all streams. 1061 Senders MUST NOT send data in excess of either limit. 1063 A receiver sets initial limits for all streams through transport 1064 parameters during the handshake (Section 7.4). Subsequently, a 1065 receiver sends MAX_STREAM_DATA (Section 19.10) or MAX_DATA 1066 (Section 19.9) frames to the sender to advertise larger limits. 1068 A receiver can advertise a larger limit for a stream by sending a 1069 MAX_STREAM_DATA frame with the corresponding stream ID. A 1070 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 1071 stream. A receiver could determine the flow control offset to be 1072 advertised based on the current offset of data consumed on that 1073 stream. 1075 A receiver can advertise a larger limit for a connection by sending a 1076 MAX_DATA frame, which indicates the maximum of the sum of the 1077 absolute byte offsets of all streams. A receiver maintains a 1078 cumulative sum of bytes received on all streams, which is used to 1079 check for violations of the advertised connection or stream data 1080 limits. A receiver could determine the maximum data limit to be 1081 advertised based on the sum of bytes consumed on all streams. 1083 Once a receiver advertises a limit for the connection or a stream, it 1084 MAY advertise a smaller limit, but this has no effect. 1086 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 1087 (Section 11) if the sender violates the advertised connection or 1088 stream data limits. 1090 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 1091 not increase flow control limits. 1093 If a sender has sent data up to the limit, it will be unable to send 1094 new data and is considered blocked. A sender SHOULD send a 1095 STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver 1096 that it has data to write but is blocked by flow control limits. If 1097 a sender is blocked for a period longer than the idle timeout 1098 (Section 10.1), the receiver might close the connection even when the 1099 sender has data that is available for transmission. To keep the 1100 connection from closing, a sender that is flow control limited SHOULD 1101 periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it 1102 has no ack-eliciting packets in flight. 1104 4.2. Increasing Flow Control Limits 1106 Implementations decide when and how much credit to advertise in 1107 MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few 1108 considerations. 1110 To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or 1111 MAX_DATA frame multiple times within a round trip or send it early 1112 enough to allow time for loss of the frame and subsequent recovery. 1114 Control frames contribute to connection overhead. Therefore, 1115 frequently sending MAX_STREAM_DATA and MAX_DATA frames with small 1116 changes is undesirable. On the other hand, if updates are less 1117 frequent, larger increments to limits are necessary to avoid blocking 1118 a sender, requiring larger resource commitments at the receiver. 1119 There is a trade-off between resource commitment and overhead when 1120 determining how large a limit is advertised. 1122 A receiver can use an autotuning mechanism to tune the frequency and 1123 amount of advertised additional credit based on a round-trip time 1124 estimate and the rate at which the receiving application consumes 1125 data, similar to common TCP implementations. As an optimization, an 1126 endpoint could send frames related to flow control only when there 1127 are other frames to send, ensuring that flow control does not cause 1128 extra packets to be sent. 1130 A blocked sender is not required to send STREAM_DATA_BLOCKED or 1131 DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a 1132 STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a 1133 MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the 1134 sender being blocked for the rest of the connection. Even if the 1135 sender sends these frames, waiting for them will result in the sender 1136 being blocked for at least an entire round trip. 1138 When a sender receives credit after being blocked, it might be able 1139 to send a large amount of data in response, resulting in short-term 1140 congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of 1141 how a sender can avoid this congestion. 1143 4.3. Flow Control Performance 1145 If an endpoint cannot ensure that its peer always has available flow 1146 control credit that is greater than the peer's bandwidth-delay 1147 product on this connection, its receive throughput will be limited by 1148 flow control. 1150 Packet loss can cause gaps in the receive buffer, preventing the 1151 application from consuming data and freeing up receive buffer space. 1153 Sending timely updates of flow control limits can improve 1154 performance. Sending packets only to provide flow control updates 1155 can increase network load and adversely affect performance. Sending 1156 flow control updates along with other frames, such as ACK frames, 1157 reduces the cost of those updates. 1159 4.4. Handling Stream Cancellation 1161 Endpoints need to eventually agree on the amount of flow control 1162 credit that has been consumed on every stream, to be able to account 1163 for all bytes for connection-level flow control. 1165 On receipt of a RESET_STREAM frame, an endpoint will tear down state 1166 for the matching stream and ignore further data arriving on that 1167 stream. 1169 RESET_STREAM terminates one direction of a stream abruptly. For a 1170 bidirectional stream, RESET_STREAM has no effect on data flow in the 1171 opposite direction. Both endpoints MUST maintain flow control state 1172 for the stream in the unterminated direction until that direction 1173 enters a terminal state. 1175 4.5. Stream Final Size 1177 The final size is the amount of flow control credit that is consumed 1178 by a stream. Assuming that every contiguous byte on the stream was 1179 sent once, the final size is the number of bytes sent. More 1180 generally, this is one higher than the offset of the byte with the 1181 largest offset sent on the stream, or zero if no bytes were sent. 1183 A sender always communicates the final size of a stream to the 1184 receiver reliably, no matter how the stream is terminated. The final 1185 size is the sum of the Offset and Length fields of a STREAM frame 1186 with a FIN flag, noting that these fields might be implicit. 1187 Alternatively, the Final Size field of a RESET_STREAM frame carries 1188 this value. This guarantees that both endpoints agree on how much 1189 flow control credit was consumed by the sender on that stream. 1191 An endpoint will know the final size for a stream when the receiving 1192 part of the stream enters the "Size Known" or "Reset Recvd" state 1193 (Section 3). The receiver MUST use the final size of the stream to 1194 account for all bytes sent on the stream in its connection level flow 1195 controller. 1197 An endpoint MUST NOT send data on a stream at or beyond the final 1198 size. 1200 Once a final size for a stream is known, it cannot change. If a 1201 RESET_STREAM or STREAM frame is received indicating a change in the 1202 final size for the stream, an endpoint SHOULD respond with a 1203 FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat 1204 receipt of data at or beyond the final size as a FINAL_SIZE_ERROR 1205 error, even after a stream is closed. Generating these errors is not 1206 mandatory, because requiring that an endpoint generate these errors 1207 also means that the endpoint needs to maintain the final size state 1208 for closed streams, which could mean a significant state commitment. 1210 4.6. Controlling Concurrency 1212 An endpoint limits the cumulative number of incoming streams a peer 1213 can open. Only streams with a stream ID less than (max_stream * 4 + 1214 initial_stream_id_for_type) can be opened; see Table 1. Initial 1215 limits are set in the transport parameters; see Section 18.2. 1216 Subsequent limits are advertised using MAX_STREAMS frames; see 1217 Section 19.11. Separate limits apply to unidirectional and 1218 bidirectional streams. 1220 If a max_streams transport parameter or a MAX_STREAMS frame is 1221 received with a value greater than 2^60, this would allow a maximum 1222 stream ID that cannot be expressed as a variable-length integer; see 1223 Section 16. If either is received, the connection MUST be closed 1224 immediately with a connection error of type TRANSPORT_PARAMETER_ERROR 1225 if the offending value was received in a transport parameter or of 1226 type FRAME_ENCODING_ERROR if it was received in a frame; see 1227 Section 10.2. 1229 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1230 that receives a frame with a stream ID exceeding the limit it has 1231 sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR 1232 (Section 11). 1234 Once a receiver advertises a stream limit using the MAX_STREAMS 1235 frame, advertising a smaller limit has no effect. A receiver MUST 1236 ignore any MAX_STREAMS frame that does not increase the stream limit. 1238 As with stream and connection flow control, this document leaves 1239 implementations to decide when and how many streams should be 1240 advertised to a peer via MAX_STREAMS. Implementations might choose 1241 to increase limits as streams are closed, to keep the number of 1242 streams available to peers roughly consistent. 1244 An endpoint that is unable to open a new stream due to the peer's 1245 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1246 signal is considered useful for debugging. An endpoint MUST NOT wait 1247 to receive this signal before advertising additional credit, since 1248 doing so will mean that the peer will be blocked for at least an 1249 entire round trip, and potentially indefinitely if the peer chooses 1250 not to send STREAMS_BLOCKED frames. 1252 5. Connections 1254 A QUIC connection is shared state between a client and a server. 1256 Each connection starts with a handshake phase, during which the two 1257 endpoints establish a shared secret using the cryptographic handshake 1258 protocol [QUIC-TLS] and negotiate the application protocol. The 1259 handshake (Section 7) confirms that both endpoints are willing to 1260 communicate (Section 8.1) and establishes parameters for the 1261 connection (Section 7.4). 1263 An application protocol can use the connection during the handshake 1264 phase with some limitations. 0-RTT allows application data to be 1265 sent by a client before receiving a response from the server. 1266 However, 0-RTT provides no protection against replay attacks; see 1267 Section 9.2 of [QUIC-TLS]. A server can also send application data 1268 to a client before it receives the final cryptographic handshake 1269 messages that allow it to confirm the identity and liveness of the 1270 client. These capabilities allow an application protocol to offer 1271 the option of trading some security guarantees for reduced latency. 1273 The use of connection IDs (Section 5.1) allows connections to migrate 1274 to a new network path, both as a direct choice of an endpoint and 1275 when forced by a change in a middlebox. Section 9 describes 1276 mitigations for the security and privacy issues associated with 1277 migration. 1279 For connections that are no longer needed or desired, there are 1280 several ways for a client and server to terminate a connection, as 1281 described in Section 10. 1283 5.1. Connection ID 1285 Each connection possesses a set of connection identifiers, or 1286 connection IDs, each of which can identify the connection. 1287 Connection IDs are independently selected by endpoints; each endpoint 1288 selects the connection IDs that its peer uses. 1290 The primary function of a connection ID is to ensure that changes in 1291 addressing at lower protocol layers (UDP, IP) do not cause packets 1292 for a QUIC connection to be delivered to the wrong endpoint. Each 1293 endpoint selects connection IDs using an implementation-specific (and 1294 perhaps deployment-specific) method that will allow packets with that 1295 connection ID to be routed back to the endpoint and to be identified 1296 by the endpoint upon receipt. 1298 Connection IDs MUST NOT contain any information that can be used by 1299 an external observer (that is, one that does not cooperate with the 1300 issuer) to correlate them with other connection IDs for the same 1301 connection. As a trivial example, this means the same connection ID 1302 MUST NOT be issued more than once on the same connection. 1304 Packets with long headers include Source Connection ID and 1305 Destination Connection ID fields. These fields are used to set the 1306 connection IDs for new connections; see Section 7.2 for details. 1308 Packets with short headers (Section 17.3) only include the 1309 Destination Connection ID and omit the explicit length. The length 1310 of the Destination Connection ID field is expected to be known to 1311 endpoints. Endpoints using a load balancer that routes based on 1312 connection ID could agree with the load balancer on a fixed length 1313 for connection IDs, or agree on an encoding scheme. A fixed portion 1314 could encode an explicit length, which allows the entire connection 1315 ID to vary in length and still be used by the load balancer. 1317 A Version Negotiation (Section 17.2.1) packet echoes the connection 1318 IDs selected by the client, both to ensure correct routing toward the 1319 client and to demonstrate that the packet is in response to a packet 1320 sent by the client. 1322 A zero-length connection ID can be used when a connection ID is not 1323 needed to route to the correct endpoint. However, multiplexing 1324 connections on the same local IP address and port while using zero- 1325 length connection IDs will cause failures in the presence of peer 1326 connection migration, NAT rebinding, and client port reuse. An 1327 endpoint MUST NOT use the same IP address and port for multiple 1328 connections with zero-length connection IDs, unless it is certain 1329 that those protocol features are not in use. 1331 When an endpoint uses a non-zero-length connection ID, it needs to 1332 ensure that the peer has a supply of connection IDs from which to 1333 choose for packets sent to the endpoint. These connection IDs are 1334 supplied by the endpoint using the NEW_CONNECTION_ID frame 1335 (Section 19.15). 1337 5.1.1. Issuing Connection IDs 1339 Each Connection ID has an associated sequence number to assist in 1340 detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer 1341 to the same value. The initial connection ID issued by an endpoint 1342 is sent in the Source Connection ID field of the long packet header 1343 (Section 17.2) during the handshake. The sequence number of the 1344 initial connection ID is 0. If the preferred_address transport 1345 parameter is sent, the sequence number of the supplied connection ID 1346 is 1. 1348 Additional connection IDs are communicated to the peer using 1349 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1350 each newly issued connection ID MUST increase by 1. The connection 1351 ID randomly selected by the client in the Initial packet and any 1352 connection ID provided by a Retry packet are not assigned sequence 1353 numbers unless a server opts to retain them as its initial connection 1354 ID. 1356 When an endpoint issues a connection ID, it MUST accept packets that 1357 carry this connection ID for the duration of the connection or until 1358 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1359 frame (Section 19.16). Connection IDs that are issued and not 1360 retired are considered active; any active connection ID is valid for 1361 use with the current connection at any time, in any packet type. 1362 This includes the connection ID issued by the server via the 1363 preferred_address transport parameter. 1365 An endpoint SHOULD ensure that its peer has a sufficient number of 1366 available and unused connection IDs. Endpoints advertise the number 1367 of active connection IDs they are willing to maintain using the 1368 active_connection_id_limit transport parameter. An endpoint MUST NOT 1369 provide more connection IDs than the peer's limit. An endpoint MAY 1370 send connection IDs that temporarily exceed a peer's limit if the 1371 NEW_CONNECTION_ID frame also requires the retirement of any excess, 1372 by including a sufficiently large value in the Retire Prior To field. 1374 A NEW_CONNECTION_ID frame might cause an endpoint to add some active 1375 connection IDs and retire others based on the value of the Retire 1376 Prior To field. After processing a NEW_CONNECTION_ID frame and 1377 adding and retiring active connection IDs, if the number of active 1378 connection IDs exceeds the value advertised in its 1379 active_connection_id_limit transport parameter, an endpoint MUST 1380 close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. 1382 An endpoint SHOULD supply a new connection ID when the peer retires a 1383 connection ID. If an endpoint provided fewer connection IDs than the 1384 peer's active_connection_id_limit, it MAY supply a new connection ID 1385 when it receives a packet with a previously unused connection ID. An 1386 endpoint MAY limit the total number of connection IDs issued for each 1387 connection to avoid the risk of running out of connection IDs; see 1388 Section 10.3.2. An endpoint MAY also limit the issuance of 1389 connection IDs to reduce the amount of per-path state it maintains, 1390 such as path validation status, as its peer might interact with it 1391 over as many paths as there are issued connection IDs. 1393 An endpoint that initiates migration and requires non-zero-length 1394 connection IDs SHOULD ensure that the pool of connection IDs 1395 available to its peer allows the peer to use a new connection ID on 1396 migration, as the peer will be unable to respond if the pool is 1397 exhausted. 1399 5.1.2. Consuming and Retiring Connection IDs 1401 An endpoint can change the connection ID it uses for a peer to 1402 another available one at any time during the connection. An endpoint 1403 consumes connection IDs in response to a migrating peer; see 1404 Section 9.5 for more. 1406 An endpoint maintains a set of connection IDs received from its peer, 1407 any of which it can use when sending packets. When the endpoint 1408 wishes to remove a connection ID from use, it sends a 1409 RETIRE_CONNECTION_ID frame to its peer. Sending a 1410 RETIRE_CONNECTION_ID frame indicates that the connection ID will not 1411 be used again and requests that the peer replace it with a new 1412 connection ID using a NEW_CONNECTION_ID frame. 1414 As discussed in Section 9.5, endpoints limit the use of a connection 1415 ID to packets sent from a single local address to a single 1416 destination address. Endpoints SHOULD retire connection IDs when 1417 they are no longer actively using either the local or destination 1418 address for which the connection ID was used. 1420 An endpoint might need to stop accepting previously issued connection 1421 IDs in certain circumstances. Such an endpoint can cause its peer to 1422 retire connection IDs by sending a NEW_CONNECTION_ID frame with an 1423 increased Retire Prior To field. The endpoint SHOULD continue to 1424 accept the previously issued connection IDs until they are retired by 1425 the peer. If the endpoint can no longer process the indicated 1426 connection IDs, it MAY close the connection. 1428 Upon receipt of an increased Retire Prior To field, the peer MUST 1429 stop using the corresponding connection IDs and retire them with 1430 RETIRE_CONNECTION_ID frames before adding the newly provided 1431 connection ID to the set of active connection IDs. This ordering 1432 allows an endpoint to replace all active connection IDs without the 1433 possibility of a peer having no available connection IDs and without 1434 exceeding the limit the peer sets in the active_connection_id_limit 1435 transport parameter; see Section 18.2. Failure to cease using the 1436 connection IDs when requested can result in connection failures, as 1437 the issuing endpoint might be unable to continue using the connection 1438 IDs with the active connection. 1440 An endpoint SHOULD limit the number of connection IDs it has retired 1441 locally and have not yet been acknowledged. An endpoint SHOULD allow 1442 for sending and tracking a number of RETIRE_CONNECTION_ID frames of 1443 at least twice the active_connection_id limit. An endpoint MUST NOT 1444 forget a connection ID without retiring it, though it MAY choose to 1445 treat having connection IDs in need of retirement that exceed this 1446 limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. 1448 Endpoints SHOULD NOT issue updates of the Retire Prior To field 1449 before receiving RETIRE_CONNECTION_ID frames that retire all 1450 connection IDs indicated by the previous Retire Prior To value. 1452 5.2. Matching Packets to Connections 1454 Incoming packets are classified on receipt. Packets can either be 1455 associated with an existing connection, or - for servers - 1456 potentially create a new connection. 1458 Endpoints try to associate a packet with an existing connection. If 1459 the packet has a non-zero-length Destination Connection ID 1460 corresponding to an existing connection, QUIC processes that packet 1461 accordingly. Note that more than one connection ID can be associated 1462 with a connection; see Section 5.1. 1464 If the Destination Connection ID is zero length and the addressing 1465 information in the packet matches the addressing information the 1466 endpoint uses to identify a connection with a zero-length connection 1467 ID, QUIC processes the packet as part of that connection. An 1468 endpoint can use just destination IP and port or both source and 1469 destination addresses for identification, though this makes 1470 connections fragile as described in Section 5.1. 1472 Endpoints can send a Stateless Reset (Section 10.3) for any packets 1473 that cannot be attributed to an existing connection. A stateless 1474 reset allows a peer to more quickly identify when a connection 1475 becomes unusable. 1477 Packets that are matched to an existing connection are discarded if 1478 the packets are inconsistent with the state of that connection. For 1479 example, packets are discarded if they indicate a different protocol 1480 version than that of the connection, or if the removal of packet 1481 protection is unsuccessful once the expected keys are available. 1483 Invalid packets that lack strong integrity protection, such as 1484 Initial, Retry, or Version Negotiation, MAY be discarded. An 1485 endpoint MUST generate a connection error if processing the contents 1486 of these packets prior to discovering an error, unless it fully 1487 reverts these changes. 1489 5.2.1. Client Packet Handling 1491 Valid packets sent to clients always include a Destination Connection 1492 ID that matches a value the client selects. Clients that choose to 1493 receive zero-length connection IDs can use the local address and port 1494 to identify a connection. Packets that do not match an existing 1495 connection, based on Destination Connection ID or, if this value is 1496 zero-length, local IP address and port, are discarded. 1498 Due to packet reordering or loss, a client might receive packets for 1499 a connection that are encrypted with a key it has not yet computed. 1500 The client MAY drop these packets, or MAY buffer them in anticipation 1501 of later packets that allow it to compute the key. 1503 If a client receives a packet that uses a different version than it 1504 initially selected, it MUST discard that packet. 1506 5.2.2. Server Packet Handling 1508 If a server receives a packet that indicates an unsupported version 1509 but is large enough to initiate a new connection for any supported 1510 version, the server SHOULD send a Version Negotiation packet as 1511 described in Section 6.1. A server MAY limit the number of packets 1512 to which it responds with a Version Negotiation packet. Servers MUST 1513 drop smaller packets that specify unsupported versions. 1515 The first packet for an unsupported version can use different 1516 semantics and encodings for any version-specific field. In 1517 particular, different packet protection keys might be used for 1518 different versions. Servers that do not support a particular version 1519 are unlikely to be able to decrypt the payload of the packet or 1520 properly interpret the result. Servers SHOULD respond with a Version 1521 Negotiation packet, provided that the datagram is sufficiently long. 1523 Packets with a supported version, or no version field, are matched to 1524 a connection using the connection ID or - for packets with zero- 1525 length connection IDs - the local address and port. These packets 1526 are processed using the selected connection; otherwise, the server 1527 continues below. 1529 If the packet is an Initial packet fully conforming with the 1530 specification, the server proceeds with the handshake (Section 7). 1531 This commits the server to the version that the client selected. 1533 If a server refuses to accept a new connection, it SHOULD send an 1534 Initial packet containing a CONNECTION_CLOSE frame with error code 1535 CONNECTION_REFUSED. 1537 If the packet is a 0-RTT packet, the server MAY buffer a limited 1538 number of these packets in anticipation of a late-arriving Initial 1539 packet. Clients are not able to send Handshake packets prior to 1540 receiving a server response, so servers SHOULD ignore any such 1541 packets. 1543 Servers MUST drop incoming packets under all other circumstances. 1545 5.2.3. Considerations for Simple Load Balancers 1547 A server deployment could load balance among servers using only 1548 source and destination IP addresses and ports. Changes to the 1549 client's IP address or port could result in packets being forwarded 1550 to the wrong server. Such a server deployment could use one of the 1551 following methods for connection continuity when a client's address 1552 changes. 1554 * Servers could use an out-of-band mechanism to forward packets to 1555 the correct server based on Connection ID. 1557 * If servers can use a dedicated server IP address or port, other 1558 than the one that the client initially connects to, they could use 1559 the preferred_address transport parameter to request that clients 1560 move connections to that dedicated address. Note that clients 1561 could choose not to use the preferred address. 1563 A server in a deployment that does not implement a solution to 1564 maintain connection continuity when the client address changes SHOULD 1565 indicate migration is not supported using the 1566 disable_active_migration transport parameter. The 1567 disable_active_migration transport parameter does not prohibit 1568 connection migration after a client has acted on a preferred_address 1569 transport parameter. 1571 Server deployments that use this simple form of load balancing MUST 1572 avoid the creation of a stateless reset oracle; see Section 21.10. 1574 5.3. Operations on Connections 1576 This document does not define an API for QUIC, but instead defines a 1577 set of functions for QUIC connections that application protocols can 1578 rely upon. An application protocol can assume that an implementation 1579 of QUIC provides an interface that includes the operations described 1580 in this section. An implementation designed for use with a specific 1581 application protocol might provide only those operations that are 1582 used by that protocol. 1584 When implementing the client role, an application protocol can: 1586 * open a connection, which begins the exchange described in 1587 Section 7; 1589 * enable Early Data when available; and 1591 * be informed when Early Data has been accepted or rejected by a 1592 server. 1594 When implementing the server role, an application protocol can: 1596 * listen for incoming connections, which prepares for the exchange 1597 described in Section 7; 1599 * if Early Data is supported, embed application-controlled data in 1600 the TLS resumption ticket sent to the client; and 1602 * if Early Data is supported, retrieve application-controlled data 1603 from the client's resumption ticket and accept or reject Early 1604 Data based on that information. 1606 In either role, an application protocol can: 1608 * configure minimum values for the initial number of permitted 1609 streams of each type, as communicated in the transport parameters 1610 (Section 7.4); 1612 * control resource allocation for receive buffers by setting flow 1613 control limits both for streams and for the connection 1615 * identify whether the handshake has completed successfully or is 1616 still ongoing; 1618 * keep a connection from silently closing, either by generating PING 1619 frames (Section 19.2) or by requesting that the transport send 1620 additional frames before the idle timeout expires (Section 10.1); 1621 and 1623 * immediately close (Section 10.2) the connection. 1625 6. Version Negotiation 1627 Version negotiation allows a server to indicate that it does not 1628 support the version the client used. A server sends a Version 1629 Negotiation packet in response to each packet that might initiate a 1630 new connection; see Section 5.2 for details. 1632 The size of the first packet sent by a client will determine whether 1633 a server sends a Version Negotiation packet. Clients that support 1634 multiple QUIC versions SHOULD ensure that the first UDP datagram they 1635 send is sized to the largest of the minimum datagram sizes from all 1636 versions they support, using PADDING frames (Section 19.1) as 1637 necessary. This ensures that the server responds if there is a 1638 mutually supported version. A server might not send a Version 1639 Negotiation packet if the datagram it receives is smaller than the 1640 minimum size specified in a different version; see Section 14.1. 1642 6.1. Sending Version Negotiation Packets 1644 If the version selected by the client is not acceptable to the 1645 server, the server responds with a Version Negotiation packet; see 1646 Section 17.2.1. This includes a list of versions that the server 1647 will accept. An endpoint MUST NOT send a Version Negotiation packet 1648 in response to receiving a Version Negotiation packet. 1650 This system allows a server to process packets with unsupported 1651 versions without retaining state. Though either the Initial packet 1652 or the Version Negotiation packet that is sent in response could be 1653 lost, the client will send new packets until it successfully receives 1654 a response or it abandons the connection attempt. As a result, the 1655 client discards all state for the connection and does not send any 1656 more packets on the connection. 1658 A server MAY limit the number of Version Negotiation packets it 1659 sends. For instance, a server that is able to recognize packets as 1660 0-RTT might choose not to send Version Negotiation packets in 1661 response to 0-RTT packets with the expectation that it will 1662 eventually receive an Initial packet. 1664 6.2. Handling Version Negotiation Packets 1666 Version Negotiation packets are designed to allow future versions of 1667 QUIC to negotiate the version in use between endpoints. Future 1668 versions of QUIC might change how implementations that support 1669 multiple versions of QUIC react to Version Negotiation packets when 1670 attempting to establish a connection using this version. 1672 A client that supports only this version of QUIC MUST abandon the 1673 current connection attempt if it receives a Version Negotiation 1674 packet, with the following two exceptions. A client MUST discard any 1675 Version Negotiation packet if it has received and successfully 1676 processed any other packet, including an earlier Version Negotiation 1677 packet. A client MUST discard a Version Negotiation packet that 1678 lists the QUIC version selected by the client. 1680 How to perform version negotiation is left as future work defined by 1681 future versions of QUIC. In particular, that future work will ensure 1682 robustness against version downgrade attacks; see Section 21.11. 1684 6.2.1. Version Negotiation Between Draft Versions 1686 [[RFC editor: please remove this section before publication.]] 1688 When a draft implementation receives a Version Negotiation packet, it 1689 MAY use it to attempt a new connection with one of the versions 1690 listed in the packet, instead of abandoning the current connection 1691 attempt; see Section 6.2. 1693 The client MUST check that the Destination and Source Connection ID 1694 fields match the Source and Destination Connection ID fields in a 1695 packet that the client sent. If this check fails, the packet MUST be 1696 discarded. 1698 Once the Version Negotiation packet is determined to be valid, the 1699 client then selects an acceptable protocol version from the list 1700 provided by the server. The client then attempts to create a new 1701 connection using that version. The new connection MUST use a new 1702 random Destination Connection ID different from the one it had 1703 previously sent. 1705 Note that this mechanism does not protect against downgrade attacks 1706 and MUST NOT be used outside of draft implementations. 1708 6.3. Using Reserved Versions 1710 For a server to use a new version in the future, clients need to 1711 correctly handle unsupported versions. Some version numbers 1712 (0x?a?a?a?a as defined in Section 15) are reserved for inclusion in 1713 fields that contain version numbers. 1715 Endpoints MAY add reserved versions to any field where unknown or 1716 unsupported versions are ignored to test that a peer correctly 1717 ignores the value. For instance, an endpoint could include a 1718 reserved version in a Version Negotiation packet; see Section 17.2.1. 1719 Endpoints MAY send packets with a reserved version to test that a 1720 peer correctly discards the packet. 1722 7. Cryptographic and Transport Handshake 1724 QUIC relies on a combined cryptographic and transport handshake to 1725 minimize connection establishment latency. QUIC uses the CRYPTO 1726 frame (Section 19.6) to transmit the cryptographic handshake. 1727 Version 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a 1728 different QUIC version number could indicate that a different 1729 cryptographic handshake protocol is in use. 1731 QUIC provides reliable, ordered delivery of the cryptographic 1732 handshake data. QUIC packet protection is used to encrypt as much of 1733 the handshake protocol as possible. The cryptographic handshake MUST 1734 provide the following properties: 1736 * authenticated key exchange, where 1738 - a server is always authenticated, 1740 - a client is optionally authenticated, 1742 - every connection produces distinct and unrelated keys, and 1744 - keying material is usable for packet protection for both 0-RTT 1745 and 1-RTT packets 1747 * authenticated values for transport parameters of both endpoints, 1748 and confidentiality protection for server transport parameters 1749 (see Section 7.4) 1751 * authenticated negotiation of an application protocol (TLS uses 1752 ALPN [ALPN] for this purpose) 1754 Endpoints can use packets sent during the handshake to test for 1755 Explicit Congestion Notification (ECN) support; see Section 13.4. An 1756 endpoint verifies support for ECN by observing whether the ACK frames 1757 acknowledging the first packets it sends carry ECN counts, as 1758 described in Section 13.4.2. 1760 The CRYPTO frame can be sent in different packet number spaces 1761 (Section 12.3). The offsets used by CRYPTO frames to ensure ordered 1762 delivery of cryptographic handshake data start from zero in each 1763 packet number space. 1765 Figure 4 shows a simplified handshake and the exchange of packets and 1766 frames that are used to advance the handshake. Exchange of 1767 application data during the handshake is enabled where possible, 1768 shown with a '*'. Once completed, endpoints are able to exchange 1769 application data. 1771 Client Server 1773 Initial (CRYPTO) 1774 0-RTT (*) ----------> 1775 Initial (CRYPTO) 1776 Handshake (CRYPTO) 1777 <---------- 1-RTT (*) 1778 Handshake (CRYPTO) 1779 1-RTT (*) ----------> 1780 <---------- 1-RTT (HANDSHAKE_DONE,*) 1782 1-RTT (*) <=========> 1-RTT (*) 1784 Figure 4: Simplified QUIC Handshake 1786 An endpoint validates support for Explicit Congestion Notification 1787 (ECN) by observing whether the ACK frames acknowledging the first 1788 packets it sends carry ECN counts, as described in Section 13.4.2. 1790 Endpoints MUST explicitly negotiate an application protocol. This 1791 avoids situations where there is a disagreement about the protocol 1792 that is in use. 1794 7.1. Example Handshake Flows 1796 Details of how TLS is integrated with QUIC are provided in 1797 [QUIC-TLS], but some examples are provided here. An extension of 1798 this exchange to support client address validation is shown in 1799 Section 8.1.2. 1801 Once any address validation exchanges are complete, the cryptographic 1802 handshake is used to agree on cryptographic keys. The cryptographic 1803 handshake is carried in Initial (Section 17.2.2) and Handshake 1804 (Section 17.2.4) packets. 1806 Figure 5 provides an overview of the 1-RTT handshake. Each line 1807 shows a QUIC packet with the packet type and packet number shown 1808 first, followed by the frames that are typically contained in those 1809 packets. So, for instance the first packet is of type Initial, with 1810 packet number 0, and contains a CRYPTO frame carrying the 1811 ClientHello. 1813 Multiple QUIC packets - even of different packet types - can be 1814 coalesced into a single UDP datagram; see Section 12.2. As a result, 1815 this handshake may consist of as few as 4 UDP datagrams, or any 1816 number more (subject to limits inherent to the protocol, such as 1817 congestion control or anti-amplification). For instance, the 1818 server's first flight contains Initial packets, Handshake packets, 1819 and "0.5-RTT data" in 1-RTT packets with a short header. 1821 Client Server 1823 Initial[0]: CRYPTO[CH] -> 1825 Initial[0]: CRYPTO[SH] ACK[0] 1826 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1827 <- 1-RTT[0]: STREAM[1, "..."] 1829 Initial[1]: ACK[0] 1830 Handshake[0]: CRYPTO[FIN], ACK[0] 1831 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1833 Handshake[1]: ACK[0] 1834 <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0] 1836 Figure 5: Example 1-RTT Handshake 1838 Figure 6 shows an example of a connection with a 0-RTT handshake and 1839 a single packet of 0-RTT data. Note that as described in 1840 Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets, 1841 and the client sends 1-RTT packets in the same packet number space. 1843 Client Server 1845 Initial[0]: CRYPTO[CH] 1846 0-RTT[0]: STREAM[0, "..."] -> 1848 Initial[0]: CRYPTO[SH] ACK[0] 1849 Handshake[0] CRYPTO[EE, FIN] 1850 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1852 Initial[1]: ACK[0] 1853 Handshake[0]: CRYPTO[FIN], ACK[0] 1854 1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1856 Handshake[1]: ACK[0] 1857 <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1] 1859 Figure 6: Example 0-RTT Handshake 1861 7.2. Negotiating Connection IDs 1863 A connection ID is used to ensure consistent routing of packets, as 1864 described in Section 5.1. The long header contains two connection 1865 IDs: the Destination Connection ID is chosen by the recipient of the 1866 packet and is used to provide consistent routing; the Source 1867 Connection ID is used to set the Destination Connection ID used by 1868 the peer. 1870 During the handshake, packets with the long header (Section 17.2) are 1871 used to establish the connection IDs used by both endpoints. Each 1872 endpoint uses the Source Connection ID field to specify the 1873 connection ID that is used in the Destination Connection ID field of 1874 packets being sent to them. After processing the first Initial 1875 packet, each endpoint sets the Destination Connection ID field in 1876 subsequent packets it sends to the value of the Source Connection ID 1877 field that it received. 1879 When an Initial packet is sent by a client that has not previously 1880 received an Initial or Retry packet from the server, the client 1881 populates the Destination Connection ID field with an unpredictable 1882 value. This Destination Connection ID MUST be at least 8 bytes in 1883 length. Until a packet is received from the server, the client MUST 1884 use the same Destination Connection ID value on all packets in this 1885 connection. 1887 The Destination Connection ID field from the first Initial packet 1888 sent by a client is used to determine packet protection keys for 1889 Initial packets. These keys change after receiving a Retry packet; 1890 see Section 5.2 of [QUIC-TLS]. 1892 The client populates the Source Connection ID field with a value of 1893 its choosing and sets the Source Connection ID Length field to 1894 indicate the length. 1896 The first flight of 0-RTT packets use the same Destination Connection 1897 ID and Source Connection ID values as the client's first Initial 1898 packet. 1900 Upon first receiving an Initial or Retry packet from the server, the 1901 client uses the Source Connection ID supplied by the server as the 1902 Destination Connection ID for subsequent packets, including any 0-RTT 1903 packets. This means that a client might have to change the 1904 connection ID it sets in the Destination Connection ID field twice 1905 during connection establishment: once in response to a Retry, and 1906 once in response to an Initial packet from the server. Once a client 1907 has received a valid Initial packet from the server, it MUST discard 1908 any subsequent packet it receives with a different Source Connection 1909 ID. 1911 A client MUST change the Destination Connection ID it uses for 1912 sending packets in response to only the first received Initial or 1913 Retry packet. A server MUST set the Destination Connection ID it 1914 uses for sending packets based on the first received Initial packet. 1915 Any further changes to the Destination Connection ID are only 1916 permitted if the values are taken from NEW_CONNECTION_ID frames; if 1917 subsequent Initial packets include a different Source Connection ID, 1918 they MUST be discarded. This avoids unpredictable outcomes that 1919 might otherwise result from stateless processing of multiple Initial 1920 packets with different Source Connection IDs. 1922 The Destination Connection ID that an endpoint sends can change over 1923 the lifetime of a connection, especially in response to connection 1924 migration (Section 9); see Section 5.1.1 for details. 1926 7.3. Authenticating Connection IDs 1928 The choice each endpoint makes about connection IDs during the 1929 handshake is authenticated by including all values in transport 1930 parameters; see Section 7.4. This ensures that all connection IDs 1931 used for the handshake are also authenticated by the cryptographic 1932 handshake. 1934 Each endpoint includes the value of the Source Connection ID field 1935 from the first Initial packet it sent in the 1936 initial_source_connection_id transport parameter; see Section 18.2. 1937 A server includes the Destination Connection ID field from the first 1938 Initial packet it received from the client in the 1939 original_destination_connection_id transport parameter; if the server 1940 sent a Retry packet, this refers to the first Initial packet received 1941 before sending the Retry packet. If it sends a Retry packet, a 1942 server also includes the Source Connection ID field from the Retry 1943 packet in the retry_source_connection_id transport parameter. 1945 The values provided by a peer for these transport parameters MUST 1946 match the values that an endpoint used in the Destination and Source 1947 Connection ID fields of Initial packets that it sent. Including 1948 connection ID values in transport parameters and verifying them 1949 ensures that that an attacker cannot influence the choice of 1950 connection ID for a successful connection by injecting packets 1951 carrying attacker-chosen connection IDs during the handshake. 1953 An endpoint MUST treat absence of the initial_source_connection_id 1954 transport parameter from either endpoint or absence of the 1955 original_destination_connection_id transport parameter from the 1956 server as a connection error of type TRANSPORT_PARAMETER_ERROR. 1958 An endpoint MUST treat the following as a connection error of type 1959 TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: 1961 * absence of the retry_source_connection_id transport parameter from 1962 the server after receiving a Retry packet, 1964 * presence of the retry_source_connection_id transport parameter 1965 when no Retry packet was received, or 1967 * a mismatch between values received from a peer in these transport 1968 parameters and the value sent in the corresponding Destination or 1969 Source Connection ID fields of Initial packets. 1971 If a zero-length connection ID is selected, the corresponding 1972 transport parameter is included with a zero-length value. 1974 Figure 7 shows the connection IDs (with DCID=Destination Connection 1975 ID, SCID=Source Connection ID) that are used in a complete handshake. 1976 The exchange of Initial packets is shown, plus the later exchange of 1977 1-RTT packets that includes the connection ID established during the 1978 handshake. 1980 Client Server 1982 Initial: DCID=S1, SCID=C1 -> 1983 <- Initial: DCID=C1, SCID=S3 1984 ... 1985 1-RTT: DCID=S3 -> 1986 <- 1-RTT: DCID=C1 1988 Figure 7: Use of Connection IDs in a Handshake 1990 Figure 8 shows a similar handshake that includes a Retry packet. 1992 Client Server 1994 Initial: DCID=S1, SCID=C1 -> 1995 <- Retry: DCID=C1, SCID=S2 1996 Initial: DCID=S2, SCID=C1 -> 1997 <- Initial: DCID=C1, SCID=S3 1998 ... 1999 1-RTT: DCID=S3 -> 2000 <- 1-RTT: DCID=C1 2002 Figure 8: Use of Connection IDs in a Handshake with Retry 2004 In both cases (Figure 7 and Figure 8), the client sets the value of 2005 the initial_source_connection_id transport parameter to "C1". 2007 When the handshake does not include a Retry (Figure 7), the server 2008 sets original_destination_connection_id to "S1" and 2009 initial_source_connection_id to "S3". In this case, the server does 2010 not include a retry_source_connection_id transport parameter. 2012 When the handshake includes a Retry (Figure 8), the server sets 2013 original_destination_connection_id to "S1", 2014 retry_source_connection_id to "S2", and initial_source_connection_id 2015 to "S3". 2017 7.4. Transport Parameters 2019 During connection establishment, both endpoints make authenticated 2020 declarations of their transport parameters. Endpoints are required 2021 to comply with the restrictions that each parameter defines; the 2022 description of each parameter includes rules for its handling. 2024 Transport parameters are declarations that are made unilaterally by 2025 each endpoint. Each endpoint can choose values for transport 2026 parameters independent of the values chosen by its peer. 2028 The encoding of the transport parameters is detailed in Section 18. 2030 QUIC includes the encoded transport parameters in the cryptographic 2031 handshake. Once the handshake completes, the transport parameters 2032 declared by the peer are available. Each endpoint validates the 2033 values provided by its peer. 2035 Definitions for each of the defined transport parameters are included 2036 in Section 18.2. 2038 An endpoint MUST treat receipt of a transport parameter with an 2039 invalid value as a connection error of type 2040 TRANSPORT_PARAMETER_ERROR. 2042 An endpoint MUST NOT send a parameter more than once in a given 2043 transport parameters extension. An endpoint SHOULD treat receipt of 2044 duplicate transport parameters as a connection error of type 2045 TRANSPORT_PARAMETER_ERROR. 2047 Endpoints use transport parameters to authenticate the negotiation of 2048 connection IDs during the handshake; see Section 7.3. 2050 Application Layer Protocol Negotiation (ALPN; see [ALPN]) allows 2051 clients to offer multiple application protocols during connection 2052 establishment. The transport parameters that a client includes 2053 during the handshake apply to all application protocols that the 2054 client offers. Application protocols can recommend values for 2055 transport parameters, such as the initial flow control limits. 2056 However, application protocols that set constraints on values for 2057 transport parameters could make it impossible for a client to offer 2058 multiple application protocols if these constraints conflict. 2060 7.4.1. Values of Transport Parameters for 0-RTT 2062 Using 0-RTT depends on both client and server using protocol 2063 parameters that were negotiated from a previous connection. To 2064 enable 0-RTT, endpoints store the value of the server transport 2065 parameters from a connection and apply them to any 0-RTT packets that 2066 are sent in subsequent connections to that peer. This information is 2067 stored with any information required by the application protocol or 2068 cryptographic handshake; see Section 4.6 of [QUIC-TLS]. 2070 Remembered transport parameters apply to the new connection until the 2071 handshake completes and the client starts sending 1-RTT packets. 2072 Once the handshake completes, the client uses the transport 2073 parameters established in the handshake. Not all transport 2074 parameters are remembered, as some do not apply to future connections 2075 or they have no effect on use of 0-RTT. 2077 The definition of a new transport parameter (Section 7.4.2) MUST 2078 specify whether storing the transport parameter for 0-RTT is 2079 mandatory, optional, or prohibited. A client need not store a 2080 transport parameter it cannot process. 2082 A client MUST NOT use remembered values for the following parameters: 2083 ack_delay_exponent, max_ack_delay, initial_source_connection_id, 2084 original_destination_connection_id, preferred_address, 2085 retry_source_connection_id, and stateless_reset_token. The client 2086 MUST use the server's new values in the handshake instead; if the 2087 server does not provide new values, the default value is used. 2089 A client that attempts to send 0-RTT data MUST remember all other 2090 transport parameters used by the server that it is able to process. 2091 The server can remember these transport parameters, or store an 2092 integrity-protected copy of the values in the ticket and recover the 2093 information when accepting 0-RTT data. A server uses the transport 2094 parameters in determining whether to accept 0-RTT data. 2096 If 0-RTT data is accepted by the server, the server MUST NOT reduce 2097 any limits or alter any values that might be violated by the client 2098 with its 0-RTT data. In particular, a server that accepts 0-RTT data 2099 MUST NOT set values for the following parameters (Section 18.2) that 2100 are smaller than the remembered value of the parameters. 2102 * active_connection_id_limit 2104 * initial_max_data 2106 * initial_max_stream_data_bidi_local 2108 * initial_max_stream_data_bidi_remote 2110 * initial_max_stream_data_uni 2112 * initial_max_streams_bidi 2114 * initial_max_streams_uni 2116 Omitting or setting a zero value for certain transport parameters can 2117 result in 0-RTT data being enabled, but not usable. The applicable 2118 subset of transport parameters that permit sending of application 2119 data SHOULD be set to non-zero values for 0-RTT. This includes 2120 initial_max_data and either initial_max_streams_bidi and 2121 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 2122 initial_max_stream_data_uni. 2124 A server MAY store and recover the previously sent values of the 2125 max_idle_timeout, max_udp_payload_size, and disable_active_migration 2126 parameters and reject 0-RTT if it selects smaller values. Lowering 2127 the values of these parameters while also accepting 0-RTT data could 2128 degrade the performance of the connection. Specifically, lowering 2129 the max_udp_payload_size could result in dropped packets leading to 2130 worse performance compared to rejecting 0-RTT data outright. 2132 A server MUST reject 0-RTT data if the restored values for transport 2133 parameters cannot be supported. 2135 When sending frames in 0-RTT packets, a client MUST only use 2136 remembered transport parameters; importantly, it MUST NOT use updated 2137 values that it learns from the server's updated transport parameters 2138 or from frames received in 1-RTT packets. Updated values of 2139 transport parameters from the handshake apply only to 1-RTT packets. 2140 For instance, flow control limits from remembered transport 2141 parameters apply to all 0-RTT packets even if those values are 2142 increased by the handshake or by frames sent in 1-RTT packets. A 2143 server MAY treat use of updated transport parameters in 0-RTT as a 2144 connection error of type PROTOCOL_VIOLATION. 2146 7.4.2. New Transport Parameters 2148 New transport parameters can be used to negotiate new protocol 2149 behavior. An endpoint MUST ignore transport parameters that it does 2150 not support. Absence of a transport parameter therefore disables any 2151 optional protocol feature that is negotiated using the parameter. As 2152 described in Section 18.1, some identifiers are reserved in order to 2153 exercise this requirement. 2155 A client that does not understand a transport parameter can discard 2156 it and attempt 0-RTT on subsequent connections. However, if the 2157 client adds support for a discarded transport parameter, it risks 2158 violating the constraints that the transport parameter establishes if 2159 it attempts 0-RTT. New transport parameters can avoid this problem 2160 by setting a default of the most conservative value. 2162 New transport parameters can be registered according to the rules in 2163 Section 22.2. 2165 7.5. Cryptographic Message Buffering 2167 Implementations need to maintain a buffer of CRYPTO data received out 2168 of order. Because there is no flow control of CRYPTO frames, an 2169 endpoint could potentially force its peer to buffer an unbounded 2170 amount of data. 2172 Implementations MUST support buffering at least 4096 bytes of data 2173 received in out-of-order CRYPTO frames. Endpoints MAY choose to 2174 allow more data to be buffered during the handshake. A larger limit 2175 during the handshake could allow for larger keys or credentials to be 2176 exchanged. An endpoint's buffer size does not need to remain 2177 constant during the life of the connection. 2179 Being unable to buffer CRYPTO frames during the handshake can lead to 2180 a connection failure. If an endpoint's buffer is exceeded during the 2181 handshake, it can expand its buffer temporarily to complete the 2182 handshake. If an endpoint does not expand its buffer, it MUST close 2183 the connection with a CRYPTO_BUFFER_EXCEEDED error code. 2185 Once the handshake completes, if an endpoint is unable to buffer all 2186 data in a CRYPTO frame, it MAY discard that CRYPTO frame and all 2187 CRYPTO frames received in the future, or it MAY close the connection 2188 with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing 2189 discarded CRYPTO frames MUST be acknowledged because the packet has 2190 been received and processed by the transport even though the CRYPTO 2191 frame was discarded. 2193 8. Address Validation 2195 Address validation ensures that an endpoint cannot be used for a 2196 traffic amplification attack. In such an attack, a packet is sent to 2197 a server with spoofed source address information that identifies a 2198 victim. If a server generates more or larger packets in response to 2199 that packet, the attacker can use the server to send more data toward 2200 the victim than it would be able to send on its own. 2202 The primary defense against amplification attack is verifying that an 2203 endpoint is able to receive packets at the transport address that it 2204 claims. Address validation is performed both during connection 2205 establishment (see Section 8.1) and during connection migration (see 2206 Section 8.2). 2208 8.1. Address Validation During Connection Establishment 2210 Connection establishment implicitly provides address validation for 2211 both endpoints. In particular, receipt of a packet protected with 2212 Handshake keys confirms that the client received the Initial packet 2213 from the server. Once the server has successfully processed a 2214 Handshake packet from the client, it can consider the client address 2215 to have been validated. 2217 Additionally, a server MAY consider the client address validated if 2218 the client uses a connection ID chosen by the server and the 2219 connection ID contains at least 64 bits of entropy. 2221 Prior to validating the client address, servers MUST NOT send more 2222 than three times as many bytes as the number of bytes they have 2223 received. This limits the magnitude of any amplification attack that 2224 can be mounted using spoofed source addresses. For the purposes of 2225 avoiding amplification prior to address validation, servers MUST 2226 count all of the payload bytes received in datagrams that are 2227 uniquely attributed to a single connection. This includes datagrams 2228 that contain packets that are successfully processed and datagrams 2229 that contain packets that are all discarded. 2231 Clients MUST ensure that UDP datagrams containing Initial packets 2232 have UDP payloads of at least 1200 bytes, adding PADDING frames as 2233 necessary. A client that sends padded datagrams allows the server to 2234 send more data prior to completing address validation. 2236 Loss of an Initial or Handshake packet from the server can cause a 2237 deadlock if the client does not send additional Initial or Handshake 2238 packets. A deadlock could occur when the server reaches its anti- 2239 amplification limit and the client has received acknowledgements for 2240 all the data it has sent. In this case, when the client has no 2241 reason to send additional packets, the server will be unable to send 2242 more data because it has not validated the client's address. To 2243 prevent this deadlock, clients MUST send a packet on a probe timeout 2244 (PTO, see Section 6.2 of [QUIC-RECOVERY]). Specifically, the client 2245 MUST send an Initial packet in a UDP datagram that contains at least 2246 1200 bytes if it does not have Handshake keys, and otherwise send a 2247 Handshake packet. 2249 A server might wish to validate the client address before starting 2250 the cryptographic handshake. QUIC uses a token in the Initial packet 2251 to provide address validation prior to completing the handshake. 2252 This token is delivered to the client during connection establishment 2253 with a Retry packet (see Section 8.1.2) or in a previous connection 2254 using the NEW_TOKEN frame (see Section 8.1.3). 2256 In addition to sending limits imposed prior to address validation, 2257 servers are also constrained in what they can send by the limits set 2258 by the congestion controller. Clients are only constrained by the 2259 congestion controller. 2261 8.1.1. Token Construction 2263 A token sent in a NEW_TOKEN frames or a Retry packet MUST be 2264 constructed in a way that allows the server to identify how it was 2265 provided to a client. These tokens are carried in the same field, 2266 but require different handling from servers. 2268 8.1.2. Address Validation using Retry Packets 2270 Upon receiving the client's Initial packet, the server can request 2271 address validation by sending a Retry packet (Section 17.2.5) 2272 containing a token. This token MUST be repeated by the client in all 2273 Initial packets it sends for that connection after it receives the 2274 Retry packet. 2276 In response to processing an Initial containing a token that was 2277 provided in a Retry packet, a server cannot send another Retry 2278 packet; it can only refuse the connection or permit it to proceed. 2280 As long as it is not possible for an attacker to generate a valid 2281 token for its own address (see Section 8.1.4) and the client is able 2282 to return that token, it proves to the server that it received the 2283 token. 2285 A server can also use a Retry packet to defer the state and 2286 processing costs of connection establishment. Requiring the server 2287 to provide a different connection ID, along with the 2288 original_destination_connection_id transport parameter defined in 2289 Section 18.2, forces the server to demonstrate that it, or an entity 2290 it cooperates with, received the original Initial packet from the 2291 client. Providing a different connection ID also grants a server 2292 some control over how subsequent packets are routed. This can be 2293 used to direct connections to a different server instance. 2295 If a server receives a client Initial that can be unprotected but 2296 contains an invalid Retry token, it knows the client will not accept 2297 another Retry token. The server can discard such a packet and allow 2298 the client to time out to detect handshake failure, but that could 2299 impose a significant latency penalty on the client. Instead, the 2300 server SHOULD immediately close (Section 10.2) the connection with an 2301 INVALID_TOKEN error. Note that a server has not established any 2302 state for the connection at this point and so does not enter the 2303 closing period. 2305 A flow showing the use of a Retry packet is shown in Figure 9. 2307 Client Server 2309 Initial[0]: CRYPTO[CH] -> 2311 <- Retry+Token 2313 Initial+Token[1]: CRYPTO[CH] -> 2315 Initial[0]: CRYPTO[SH] ACK[1] 2316 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 2317 <- 1-RTT[0]: STREAM[1, "..."] 2319 Figure 9: Example Handshake with Retry 2321 8.1.3. Address Validation for Future Connections 2323 A server MAY provide clients with an address validation token during 2324 one connection that can be used on a subsequent connection. Address 2325 validation is especially important with 0-RTT because a server 2326 potentially sends a significant amount of data to a client in 2327 response to 0-RTT data. 2329 The server uses the NEW_TOKEN frame (Section 19.7) to provide the 2330 client with an address validation token that can be used to validate 2331 future connections. In a future connection, the client includes this 2332 token in Initial packets to provide address validation. The client 2333 MUST include the token in all Initial packets it sends, unless a 2334 Retry replaces the token with a newer one. The client MUST NOT use 2335 the token provided in a Retry for future connections. Servers MAY 2336 discard any Initial packet that does not carry the expected token. 2338 Unlike the token that is created for a Retry packet, which is used 2339 immediately, the token sent in the NEW_TOKEN frame can be used after 2340 some period of time has passed. Thus, a token SHOULD have an 2341 expiration time, which could be either an explicit expiration time or 2342 an issued timestamp that can be used to dynamically calculate the 2343 expiration time. A server can store the expiration time or include 2344 it in an encrypted form in the token. 2346 A token issued with NEW_TOKEN MUST NOT include information that would 2347 allow values to be linked by an observer to the connection on which 2348 it was issued. For example, it cannot include the previous 2349 connection ID or addressing information, unless the values are 2350 encrypted. A server MUST ensure that every NEW_TOKEN frame it sends 2351 is unique across all clients, with the exception of those sent to 2352 repair losses of previously sent NEW_TOKEN frames. Information that 2353 allows the server to distinguish between tokens from Retry and 2354 NEW_TOKEN MAY be accessible to entities other than the server. 2356 It is unlikely that the client port number is the same on two 2357 different connections; validating the port is therefore unlikely to 2358 be successful. 2360 A token received in a NEW_TOKEN frame is applicable to any server 2361 that the connection is considered authoritative for (e.g., server 2362 names included in the certificate). When connecting to a server for 2363 which the client retains an applicable and unused token, it SHOULD 2364 include that token in the Token field of its Initial packet. 2365 Including a token might allow the server to validate the client 2366 address without an additional round trip. A client MUST NOT include 2367 a token that is not applicable to the server that it is connecting 2368 to, unless the client has the knowledge that the server that issued 2369 the token and the server the client is connecting to are jointly 2370 managing the tokens. A client MAY use a token from any previous 2371 connection to that server. 2373 A token allows a server to correlate activity between the connection 2374 where the token was issued and any connection where it is used. 2375 Clients that want to break continuity of identity with a server MAY 2376 discard tokens provided using the NEW_TOKEN frame. In comparison, a 2377 token obtained in a Retry packet MUST be used immediately during the 2378 connection attempt and cannot be used in subsequent connection 2379 attempts. 2381 A client SHOULD NOT reuse a NEW_TOKEN token for different connection 2382 attempts. Reusing a token allows connections to be linked by 2383 entities on the network path; see Section 9.5. 2385 Clients might receive multiple tokens on a single connection. Aside 2386 from preventing linkability, any token can be used in any connection 2387 attempt. Servers can send additional tokens to either enable address 2388 validation for multiple connection attempts or to replace older 2389 tokens that might become invalid. For a client, this ambiguity means 2390 that sending the most recent unused token is most likely to be 2391 effective. Though saving and using older tokens has no negative 2392 consequences, clients can regard older tokens as being less likely be 2393 useful to the server for address validation. 2395 When a server receives an Initial packet with an address validation 2396 token, it MUST attempt to validate the token, unless it has already 2397 completed address validation. If the token is invalid then the 2398 server SHOULD proceed as if the client did not have a validated 2399 address, including potentially sending a Retry. A server SHOULD 2400 encode tokens provided with NEW_TOKEN frames and Retry packets 2401 differently, and validate the latter more strictly. If the 2402 validation succeeds, the server SHOULD then allow the handshake to 2403 proceed. 2405 Note: The rationale for treating the client as unvalidated rather 2406 than discarding the packet is that the client might have received 2407 the token in a previous connection using the NEW_TOKEN frame, and 2408 if the server has lost state, it might be unable to validate the 2409 token at all, leading to connection failure if the packet is 2410 discarded. 2412 In a stateless design, a server can use encrypted and authenticated 2413 tokens to pass information to clients that the server can later 2414 recover and use to validate a client address. Tokens are not 2415 integrated into the cryptographic handshake and so they are not 2416 authenticated. For instance, a client might be able to reuse a 2417 token. To avoid attacks that exploit this property, a server can 2418 limit its use of tokens to only the information needed to validate 2419 client addresses. 2421 Clients MAY use tokens obtained on one connection for any connection 2422 attempt using the same version. When selecting a token to use, 2423 clients do not need to consider other properties of the connection 2424 that is being attempted, including the choice of possible application 2425 protocols, session tickets, or other connection properties. 2427 8.1.4. Address Validation Token Integrity 2429 An address validation token MUST be difficult to guess. Including a 2430 large enough random value in the token would be sufficient, but this 2431 depends on the server remembering the value it sends to clients. 2433 A token-based scheme allows the server to offload any state 2434 associated with validation to the client. For this design to work, 2435 the token MUST be covered by integrity protection against 2436 modification or falsification by clients. Without integrity 2437 protection, malicious clients could generate or guess values for 2438 tokens that would be accepted by the server. Only the server 2439 requires access to the integrity protection key for tokens. 2441 There is no need for a single well-defined format for the token 2442 because the server that generates the token also consumes it. Tokens 2443 sent in Retry packets SHOULD include information that allows the 2444 server to verify that the source IP address and port in client 2445 packets remain constant. 2447 Tokens sent in NEW_TOKEN frames MUST include information that allows 2448 the server to verify that the client IP address has not changed from 2449 when the token was issued. Servers can use tokens from NEW_TOKEN in 2450 deciding not to send a Retry packet, even if the client address has 2451 changed. If the client IP address has changed, the server MUST 2452 adhere to the anti-amplification limits found in Section 8.1. Note 2453 that in the presence of NAT, this requirement might be insufficient 2454 to protect other hosts that share the NAT from amplification attack. 2456 Attackers could replay tokens to use servers as amplifiers in DDoS 2457 attacks. To protect against such attacks, servers MUST ensure that 2458 replay of tokens is prevented or limited. Servers SHOULD ensure that 2459 tokens sent in Retry packets are only accepted for a short time. 2460 Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to 2461 be valid for longer, but SHOULD NOT be accepted multiple times in a 2462 short period. Servers are encouraged to allow tokens to be used only 2463 once, if possible; tokens MAY include additional information about 2464 clients to further narrow applicability or reuse. 2466 8.2. Path Validation 2468 Path validation is used by both peers during connection migration 2469 (see Section 9) to verify reachability after a change of address. In 2470 path validation, endpoints test reachability between a specific local 2471 address and a specific peer address, where an address is the two- 2472 tuple of IP address and port. 2474 Path validation tests that packets sent on a path to a peer are 2475 received by that peer. Path validation is used to ensure that 2476 packets received from a migrating peer do not carry a spoofed source 2477 address. 2479 Path validation does not validate that a peer can send in the return 2480 direction. Acknowledgments cannot be used for return path validation 2481 because they contain insufficient entropy and might be spoofed. 2482 Endpoints independently determine reachability on each direction of a 2483 path, and therefore return reachability can only be established by 2484 the peer. 2486 Path validation can be used at any time by either endpoint. For 2487 instance, an endpoint might check that a peer is still in possession 2488 of its address after a period of quiescence. 2490 Path validation is not designed as a NAT traversal mechanism. Though 2491 the mechanism described here might be effective for the creation of 2492 NAT bindings that support NAT traversal, the expectation is that one 2493 or other peer is able to receive packets without first having sent a 2494 packet on that path. Effective NAT traversal needs additional 2495 synchronization mechanisms that are not provided here. 2497 An endpoint MAY include other frames with the PATH_CHALLENGE and 2498 PATH_RESPONSE frames used for path validation. In particular, an 2499 endpoint can include PADDING frames with a PATH_CHALLENGE frame for 2500 Path Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1); 2501 it can also include its own PATH_CHALLENGE frame with a PATH_RESPONSE 2502 frame. 2504 An endpoint uses a new connection ID for probes sent from a new local 2505 address; see Section 9.5. When probing a new path, an endpoint can 2506 ensure that its peer has an unused connection ID available for 2507 responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in 2508 the same packet, if the peer's active_connection_id_limit permits, 2509 ensures that an unused connection ID will be available to the peer 2510 when sending a response. 2512 An endpoint can choose to simultaneously probe multiple paths. The 2513 number of simultaneous paths used for probes is limited by the number 2514 of extra connection IDs its peer has previously supplied, since each 2515 new local address used for a probe requires a previously unused 2516 connection ID. 2518 8.2.1. Initiating Path Validation 2520 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 2521 containing an unpredictable payload on the path to be validated. 2523 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 2524 packet loss. However, an endpoint SHOULD NOT send multiple 2525 PATH_CHALLENGE frames in a single packet. 2527 An endpoint SHOULD NOT probe a new path with packets containing a 2528 PATH_CHALLENGE frame more frequently than it would send an Initial 2529 packet. This ensures that connection migration is no more load on a 2530 new path than establishing a new connection. 2532 The endpoint MUST use unpredictable data in every PATH_CHALLENGE 2533 frame so that it can associate the peer's response with the 2534 corresponding PATH_CHALLENGE. 2536 8.2.2. Path Validation Responses 2538 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by 2539 echoing the data contained in the PATH_CHALLENGE frame in a 2540 PATH_RESPONSE frame. A PATH_RESPONSE frame does not need to be sent 2541 on the network path where the PATH_CHALLENGE was received; a 2542 PATH_RESPONSE can be sent on any network path. An endpoint MUST NOT 2543 delay transmission of a packet containing a PATH_RESPONSE frame 2544 unless constrained by congestion control. 2546 An endpoint MUST NOT send more than one PATH_RESPONSE frame in 2547 response to one PATH_CHALLENGE frame; see Section 13.3. The peer is 2548 expected to send more PATH_CHALLENGE frames as necessary to evoke 2549 additional PATH_RESPONSE frames. 2551 8.2.3. Successful Path Validation 2553 Path validation succeeds when a PATH_RESPONSE frame is received that 2554 contains the data that was sent in a previous PATH_CHALLENGE frame. 2555 This validates the path on which the PATH_CHALLENGE was sent. 2557 Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE 2558 frame is not adequate validation, since the acknowledgment can be 2559 spoofed by a malicious peer. 2561 8.2.4. Failed Path Validation 2563 Path validation only fails when the endpoint attempting to validate 2564 the path abandons its attempt to validate the path. 2566 Endpoints SHOULD abandon path validation based on a timer. When 2567 setting this timer, implementations are cautioned that the new path 2568 could have a longer round-trip time than the original. A value of 2569 three times the larger of the current Probe Timeout (PTO) or the 2570 initial timeout (that is, 2*kInitialRtt) as defined in 2571 [QUIC-RECOVERY] is RECOMMENDED. That is: 2573 validation_timeout = max(3*PTO, 6*kInitialRtt) 2575 This timeout allows for multiple PTOs to expire prior to failing path 2576 validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE 2577 frame does not cause path validation failure. 2579 Note that the endpoint might receive packets containing other frames 2580 on the new path, but a PATH_RESPONSE frame with appropriate data is 2581 required for path validation to succeed. 2583 When an endpoint abandons path validation, it determines that the 2584 path is unusable. This does not necessarily imply a failure of the 2585 connection - endpoints can continue sending packets over other paths 2586 as appropriate. If no paths are available, an endpoint can wait for 2587 a new path to become available or close the connection. 2589 A path validation might be abandoned for other reasons besides 2590 failure. Primarily, this happens if a connection migration to a new 2591 path is initiated while a path validation on the old path is in 2592 progress. 2594 9. Connection Migration 2596 The use of a connection ID allows connections to survive changes to 2597 endpoint addresses (IP address and port), such as those caused by an 2598 endpoint migrating to a new network. This section describes the 2599 process by which an endpoint migrates to a new address. 2601 The design of QUIC relies on endpoints retaining a stable address for 2602 the duration of the handshake. An endpoint MUST NOT initiate 2603 connection migration before the handshake is confirmed, as defined in 2604 section 4.1.2 of [QUIC-TLS]. 2606 If the peer sent the disable_active_migration transport parameter, an 2607 endpoint also MUST NOT send packets (including probing packets; see 2608 Section 9.1) from a different local address to the address the peer 2609 used during the handshake, unless the endpoint has acted on a 2610 preferred_address transport parameter from the peer. If the peer 2611 violates this requirement, the endpoint MUST either drop the incoming 2612 packets on that path without generating a stateless reset or proceed 2613 with path validation and allow the peer to migrate. Generating a 2614 stateless reset or closing the connection would allow third parties 2615 in the network to cause connections to close by spoofing or otherwise 2616 manipulating observed traffic. 2618 Not all changes of peer address are intentional, or active, 2619 migrations. The peer could experience NAT rebinding: a change of 2620 address due to a middlebox, usually a NAT, allocating a new outgoing 2621 port or even a new outgoing IP address for a flow. An endpoint MUST 2622 perform path validation (Section 8.2) if it detects any change to a 2623 peer's address, unless it has previously validated that address. 2625 When an endpoint has no validated path on which to send packets, it 2626 MAY discard connection state. An endpoint capable of connection 2627 migration MAY wait for a new path to become available before 2628 discarding connection state. 2630 This document limits migration of connections to new client 2631 addresses, except as described in Section 9.6. Clients are 2632 responsible for initiating all migrations. Servers do not send non- 2633 probing packets (see Section 9.1) toward a client address until they 2634 see a non-probing packet from that address. If a client receives 2635 packets from an unknown server address, the client MUST discard these 2636 packets. 2638 9.1. Probing a New Path 2640 An endpoint MAY probe for peer reachability from a new local address 2641 using path validation (Section 8.2) prior to migrating the connection 2642 to the new local address. Failure of path validation simply means 2643 that the new path is not usable for this connection. Failure to 2644 validate a path does not cause the connection to end unless there are 2645 no valid alternative paths available. 2647 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2648 are "probing frames", and all other frames are "non-probing frames". 2649 A packet containing only probing frames is a "probing packet", and a 2650 packet containing any other frame is a "non-probing packet". 2652 9.2. Initiating Connection Migration 2654 An endpoint can migrate a connection to a new local address by 2655 sending packets containing non-probing frames from that address. 2657 Each endpoint validates its peer's address during connection 2658 establishment. Therefore, a migrating endpoint can send to its peer 2659 knowing that the peer is willing to receive at the peer's current 2660 address. Thus an endpoint can migrate to a new local address without 2661 first validating the peer's address. 2663 To establish reachability on the new path, an endpoint initiates path 2664 validation (Section 8.2) on the new path. An endpoint MAY defer path 2665 validation until after a peer sends the next non-probing frame to its 2666 new address. 2668 When migrating, the new path might not support the endpoint's current 2669 sending rate. Therefore, the endpoint resets its congestion 2670 controller and RTT estimate, as described in Section 9.4. 2672 The new path might not have the same ECN capability. Therefore, the 2673 endpoint validates ECN capability as described in Section 13.4. 2675 9.3. Responding to Connection Migration 2677 Receiving a packet from a new peer address containing a non-probing 2678 frame indicates that the peer has migrated to that address. 2680 If the recipient permits the migration, it MUST send subsequent 2681 packets to the new peer address and MUST initiate path validation 2682 (Section 8.2) to verify the peer's ownership of the address if 2683 validation is not already underway. 2685 An endpoint only changes the address to which it sends packets in 2686 response to the highest-numbered non-probing packet. This ensures 2687 that an endpoint does not send packets to an old peer address in the 2688 case that it receives reordered packets. 2690 An endpoint MAY send data to an unvalidated peer address, but it MUST 2691 protect against potential attacks as described in Section 9.3.1 and 2692 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2693 that address has been seen recently. In particular, if an endpoint 2694 returns to a previously-validated path after detecting some form of 2695 spurious migration, skipping address validation and restoring loss 2696 detection and congestion state can reduce the performance impact of 2697 the attack. 2699 After changing the address to which it sends non-probing packets, an 2700 endpoint can abandon any path validation for other addresses. 2702 Receiving a packet from a new peer address could be the result of a 2703 NAT rebinding at the peer. 2705 After verifying a new client address, the server SHOULD send new 2706 address validation tokens (Section 8) to the client. 2708 9.3.1. Peer Address Spoofing 2710 It is possible that a peer is spoofing its source address to cause an 2711 endpoint to send excessive amounts of data to an unwilling host. If 2712 the endpoint sends significantly more data than the spoofing peer, 2713 connection migration might be used to amplify the volume of data that 2714 an attacker can generate toward a victim. 2716 As described in Section 9.3, an endpoint is required to validate a 2717 peer's new address to confirm the peer's possession of the new 2718 address. Until a peer's address is deemed valid, an endpoint MUST 2719 limit the rate at which it sends data to this address. The endpoint 2720 MUST NOT send more than a minimum congestion window's worth of data 2721 per estimated round-trip time (kMinimumWindow, as defined in 2722 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2723 being used for a denial of service attack against an unsuspecting 2724 victim. Note that since the endpoint will not have any round-trip 2725 time measurements to this address, the estimate SHOULD be the default 2726 initial value; see [QUIC-RECOVERY]. 2728 If an endpoint skips validation of a peer address as described above, 2729 it does not need to limit its sending rate. 2731 9.3.2. On-Path Address Spoofing 2733 An on-path attacker could cause a spurious connection migration by 2734 copying and forwarding a packet with a spoofed address such that it 2735 arrives before the original packet. The packet with the spoofed 2736 address will be seen to come from a migrating connection, and the 2737 original packet will be seen as a duplicate and dropped. After a 2738 spurious migration, validation of the source address will fail 2739 because the entity at the source address does not have the necessary 2740 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2741 that is sent to it even if it wanted to. 2743 To protect the connection from failing due to such a spurious 2744 migration, an endpoint MUST revert to using the last validated peer 2745 address when validation of a new peer address fails. Additionally, 2746 receipt of packets with higher packet numbers from the legitimate 2747 peer address will trigger another connection migration. This will 2748 cause the validation of the address of the spurious migration to be 2749 abandoned, thus containing migrations initiated by the attacker 2750 injecting a single packet. 2752 If an endpoint has no state about the last validated peer address, it 2753 MUST close the connection silently by discarding all connection 2754 state. This results in new packets on the connection being handled 2755 generically. For instance, an endpoint MAY send a stateless reset in 2756 response to any further incoming packets. 2758 9.3.3. Off-Path Packet Forwarding 2760 An off-path attacker that can observe packets might forward copies of 2761 genuine packets to endpoints. If the copied packet arrives before 2762 the genuine packet, this will appear as a NAT rebinding. Any genuine 2763 packet will be discarded as a duplicate. If the attacker is able to 2764 continue forwarding packets, it might be able to cause migration to a 2765 path via the attacker. This places the attacker on path, giving it 2766 the ability to observe or drop all subsequent packets. 2768 This style of attack relies on the attacker using a path that has 2769 approximately the same characteristics as the direct path between 2770 endpoints. The attack is more reliable if relatively few packets are 2771 sent or if packet loss coincides with the attempted attack. 2773 A non-probing packet received on the original path that increases the 2774 maximum received packet number will cause the endpoint to move back 2775 to that path. Eliciting packets on this path increases the 2776 likelihood that the attack is unsuccessful. Therefore, mitigation of 2777 this attack relies on triggering the exchange of packets. 2779 In response to an apparent migration, endpoints MUST validate the 2780 previously active path using a PATH_CHALLENGE frame. This induces 2781 the sending of new packets on that path. If the path is no longer 2782 viable, the validation attempt will time out and fail; if the path is 2783 viable, but no longer desired, the validation will succeed, but only 2784 results in probing packets being sent on the path. 2786 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2787 send a non-probing packet in response. If the non-probing packet 2788 arrives before any copy made by an attacker, this results in the 2789 connection being migrated back to the original path. Any subsequent 2790 migration to another path restarts this entire process. 2792 This defense is imperfect, but this is not considered a serious 2793 problem. If the path via the attack is reliably faster than the 2794 original path despite multiple attempts to use that original path, it 2795 is not possible to distinguish between attack and an improvement in 2796 routing. 2798 An endpoint could also use heuristics to improve detection of this 2799 style of attack. For instance, NAT rebinding is improbable if 2800 packets were recently received on the old path, similarly rebinding 2801 is rare on IPv6 paths. Endpoints can also look for duplicated 2802 packets. Conversely, a change in connection ID is more likely to 2803 indicate an intentional migration rather than an attack. 2805 9.4. Loss Detection and Congestion Control 2807 The capacity available on the new path might not be the same as the 2808 old path. Packets sent on the old path MUST NOT contribute to 2809 congestion control or RTT estimation for the new path. 2811 On confirming a peer's ownership of its new address, an endpoint MUST 2812 immediately reset the congestion controller and round-trip time 2813 estimator for the new path to initial values (see Appendices A.3 and 2814 B.3 in [QUIC-RECOVERY]) unless the only change in the peer's address 2815 is its port number. Because port-only changes are commonly the 2816 result of NAT rebinding or other middlebox activity, the endpoint MAY 2817 instead retain its congestion control state and round-trip estimate 2818 in those cases instead of reverting to initial values. In cases 2819 where congestion control state retained from an old path is used on a 2820 new path with substantially different characteristics, a sender may 2821 transmit too aggressively until the congestion controller and the RTT 2822 estimator have adapted. Generally, implementations are advised to be 2823 cautious when using previous values on a new path. 2825 There may be apparent reordering at the receiver when an endpoint 2826 sends data and probes from/to multiple addresses during the migration 2827 period, since the two resulting paths may have different round-trip 2828 times. A receiver of packets on multiple paths will still send ACK 2829 frames covering all received packets. 2831 While multiple paths might be used during connection migration, a 2832 single congestion control context and a single loss recovery context 2833 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2834 endpoint might delay switching to a new congestion control context 2835 until it is confirmed that an old path is no longer needed (such as 2836 the case in Section 9.3.3). 2838 A sender can make exceptions for probe packets so that their loss 2839 detection is independent and does not unduly cause the congestion 2840 controller to reduce its sending rate. An endpoint might set a 2841 separate timer when a PATH_CHALLENGE is sent, which is cancelled if 2842 the corresponding PATH_RESPONSE is received. If the timer fires 2843 before the PATH_RESPONSE is received, the endpoint might send a new 2844 PATH_CHALLENGE, and restart the timer for a longer period of time. 2845 This timer SHOULD be set as described in Section 6.2.1 of 2846 [QUIC-RECOVERY] and MUST NOT be more aggressive. 2848 9.5. Privacy Implications of Connection Migration 2850 Using a stable connection ID on multiple network paths would allow a 2851 passive observer to correlate activity between those paths. An 2852 endpoint that moves between networks might not wish to have their 2853 activity correlated by any entity other than their peer, so different 2854 connection IDs are used when sending from different local addresses, 2855 as discussed in Section 5.1. For this to be effective, endpoints 2856 need to ensure that connection IDs they provide cannot be linked by 2857 any other entity. 2859 At any time, endpoints MAY change the Destination Connection ID they 2860 transmit with to a value that has not been used on another path. 2862 An endpoint MUST NOT reuse a connection ID when sending from more 2863 than one local address, for example when initiating connection 2864 migration as described in Section 9.2 or when probing a new network 2865 path as described in Section 9.1. 2867 Similarly, an endpoint MUST NOT reuse a connection ID when sending to 2868 more than one destination address. Due to network changes outside 2869 the control of its peer, an endpoint might receive packets from a new 2870 source address with the same destination connection ID, in which case 2871 it MAY continue to use the current connection ID with the new remote 2872 address while still sending from the same local address. 2874 These requirements regarding connection ID reuse apply only to the 2875 sending of packets, as unintentional changes in path without a change 2876 in connection ID are possible. For example, after a period of 2877 network inactivity, NAT rebinding might cause packets to be sent on a 2878 new path when the client resumes sending. An endpoint responds to 2879 such an event as described in Section 9.3. 2881 Using different connection IDs for packets sent in both directions on 2882 each new network path eliminates the use of the connection ID for 2883 linking packets from the same connection across different network 2884 paths. Header protection ensures that packet numbers cannot be used 2885 to correlate activity. This does not prevent other properties of 2886 packets, such as timing and size, from being used to correlate 2887 activity. 2889 An endpoint SHOULD NOT initiate migration with a peer that has 2890 requested a zero-length connection ID, because traffic over the new 2891 path might be trivially linkable to traffic over the old one. If the 2892 server is able to associate packets with a zero-length connection ID 2893 to the right connection, it means that the server is using other 2894 information to demultiplex packets. For example, a server might 2895 provide a unique address to every client, for instance using HTTP 2896 alternative services [ALTSVC]. Information that might allow correct 2897 routing of packets across multiple network paths will also allow 2898 activity on those paths to be linked by entities other than the peer. 2900 A client might wish to reduce linkability by employing a new 2901 connection ID and source UDP port when sending traffic after a period 2902 of inactivity. Changing the UDP port from which it sends packets at 2903 the same time might cause the packet to appear as a connection 2904 migration. This ensures that the mechanisms that support migration 2905 are exercised even for clients that do not experience NAT rebindings 2906 or genuine migrations. Changing port number can cause a peer to 2907 reset its congestion state (see Section 9.4), so the port SHOULD only 2908 be changed infrequently. 2910 An endpoint that exhausts available connection IDs cannot probe new 2911 paths or initiate migration, nor can it respond to probes or attempts 2912 by its peer to migrate. To ensure that migration is possible and 2913 packets sent on different paths cannot be correlated, endpoints 2914 SHOULD provide new connection IDs before peers migrate; see 2915 Section 5.1.1. If a peer might have exhausted available connection 2916 IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in 2917 all packets sent on a new network path. 2919 9.6. Server's Preferred Address 2921 QUIC allows servers to accept connections on one IP address and 2922 attempt to transfer these connections to a more preferred address 2923 shortly after the handshake. This is particularly useful when 2924 clients initially connect to an address shared by multiple servers 2925 but would prefer to use a unicast address to ensure connection 2926 stability. This section describes the protocol for migrating a 2927 connection to a preferred server address. 2929 Migrating a connection to a new server address mid-connection is not 2930 supported by the version of QUIC specified in this document. If a 2931 client receives packets from a new server address when the client has 2932 not initiated a migration to that address, the client SHOULD discard 2933 these packets. 2935 9.6.1. Communicating a Preferred Address 2937 A server conveys a preferred address by including the 2938 preferred_address transport parameter in the TLS handshake. 2940 Servers MAY communicate a preferred address of each address family 2941 (IPv4 and IPv6) to allow clients to pick the one most suited to their 2942 network attachment. 2944 Once the handshake is confirmed, the client SHOULD select one of the 2945 two addresses provided by the server and initiate path validation 2946 (see Section 8.2). A client constructs packets using any previously 2947 unused active connection ID, taken from either the preferred_address 2948 transport parameter or a NEW_CONNECTION_ID frame. 2950 As soon as path validation succeeds, the client SHOULD begin sending 2951 all future packets to the new server address using the new connection 2952 ID and discontinue use of the old server address. If path validation 2953 fails, the client MUST continue sending all future packets to the 2954 server's original IP address. 2956 9.6.2. Migration to a Preferred Address 2958 A client that migrates to a preferred address MUST validate the 2959 address it chooses before migrating; see Section 21.4.3. 2961 A server might receive a packet addressed to its preferred IP address 2962 at any time after it accepts a connection. If this packet contains a 2963 PATH_CHALLENGE frame, the server sends a packet containing a 2964 PATH_RESPONSE frame as per Section 8.2. The server MUST send non- 2965 probing packets from its original address until it receives a non- 2966 probing packet from the client at its preferred address and until the 2967 server has validated the new path. 2969 The server MUST probe on the path toward the client from its 2970 preferred address. This helps to guard against spurious migration 2971 initiated by an attacker. 2973 Once the server has completed its path validation and has received a 2974 non-probing packet with a new largest packet number on its preferred 2975 address, the server begins sending non-probing packets to the client 2976 exclusively from its preferred IP address. It SHOULD drop packets 2977 for this connection received on the old IP address, but MAY continue 2978 to process delayed packets. 2980 The addresses that a server provides in the preferred_address 2981 transport parameter are only valid for the connection in which they 2982 are provided. A client MUST NOT use these for other connections, 2983 including connections that are resumed from the current connection. 2985 9.6.3. Interaction of Client Migration and Preferred Address 2987 A client might need to perform a connection migration before it has 2988 migrated to the server's preferred address. In this case, the client 2989 SHOULD perform path validation to both the original and preferred 2990 server address from the client's new address concurrently. 2992 If path validation of the server's preferred address succeeds, the 2993 client MUST abandon validation of the original address and migrate to 2994 using the server's preferred address. If path validation of the 2995 server's preferred address fails but validation of the server's 2996 original address succeeds, the client MAY migrate to its new address 2997 and continue sending to the server's original address. 2999 If packets received at the server's preferred address have a 3000 different source address than observed from the client during the 3001 handshake, the server MUST protect against potential attacks as 3002 described in Section 9.3.1 and Section 9.3.2. In addition to 3003 intentional simultaneous migration, this might also occur because the 3004 client's access network used a different NAT binding for the server's 3005 preferred address. 3007 Servers SHOULD initiate path validation to the client's new address 3008 upon receiving a probe packet from a different address. Servers MUST 3009 NOT send more than a minimum congestion window's worth of non-probing 3010 packets to the new address before path validation is complete. 3012 A client that migrates to a new address SHOULD use a preferred 3013 address from the same address family for the server. 3015 The connection ID provided in the preferred_address transport 3016 parameter is not specific to the addresses that are provided. This 3017 connection ID is provided to ensure that the client has a connection 3018 ID available for migration, but the client MAY use this connection ID 3019 on any path. 3021 9.7. Use of IPv6 Flow-Label and Migration 3023 Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label 3024 in compliance with [RFC6437], unless the local API does not allow 3025 setting IPv6 flow labels. 3027 The IPv6 flow label SHOULD be a pseudo-random function of the source 3028 and destination addresses, source and destination UDP ports, and the 3029 Destination Connection ID field. The flow label generation MUST be 3030 designed to minimize the chances of linkability with a previously 3031 used flow label, as this would enable correlating activity on 3032 multiple paths; see Section 9.5. 3034 A possible implementation is to compute the flow label as a 3035 cryptographic hash function of the source and destination addresses, 3036 source and destination UDP ports, Destination Connection ID field, 3037 and a local secret. 3039 10. Connection Termination 3041 An established QUIC connection can be terminated in one of three 3042 ways: 3044 * idle timeout (Section 10.1) 3046 * immediate close (Section 10.2) 3047 * stateless reset (Section 10.3) 3049 An endpoint MAY discard connection state if it does not have a 3050 validated path on which it can send packets; see Section 8.2. 3052 10.1. Idle Timeout 3054 If a max_idle_timeout is specified by either peer in its transport 3055 parameters (Section 18.2), the connection is silently closed and its 3056 state is discarded when it remains idle for longer than the minimum 3057 of both peers max_idle_timeout values. 3059 Each endpoint advertises a max_idle_timeout, but the effective value 3060 at an endpoint is computed as the minimum of the two advertised 3061 values. By announcing a max_idle_timeout, an endpoint commits to 3062 initiating an immediate close (Section 10.2) if it abandons the 3063 connection prior to the effective value. 3065 An endpoint restarts its idle timer when a packet from its peer is 3066 received and processed successfully. An endpoint also restarts its 3067 idle timer when sending an ack-eliciting packet if no other ack- 3068 eliciting packets have been sent since last receiving and processing 3069 a packet. Restarting this timer when sending a packet ensures that 3070 connections are not closed after new activity is initiated. 3072 To avoid excessively small idle timeout periods, endpoints MUST 3073 increase the idle timeout period to be at least three times the 3074 current Probe Timeout (PTO). This allows for multiple PTOs to 3075 expire, and therefore multiple probes to be sent and lost, prior to 3076 idle timeout. 3078 10.1.1. Liveness Testing 3080 An endpoint that sends packets close to the effective timeout risks 3081 having them be discarded at the peer, since the idle timeout period 3082 might have expired at the peer before these packets arrive. 3084 An endpoint can send a PING or another ack-eliciting frame to test 3085 the connection for liveness if the peer could time out soon, such as 3086 within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially 3087 useful if any available application data cannot be safely retried. 3088 Note that the application determines what data is safe to retry. 3090 10.1.2. Deferring Idle Timeout 3092 An endpoint might need to send ack-eliciting packets to avoid an idle 3093 timeout if it is expecting response data, but does not have or is 3094 unable to send application data. 3096 An implementation of QUIC might provide applications with an option 3097 to defer an idle timeout. This facility could be used when the 3098 application wishes to avoid losing state that has been associated 3099 with an open connection, but does not expect to exchange application 3100 data for some time. With this option, an endpoint could send a PING 3101 frame (Section 19.2) periodically, which will cause the peer to 3102 restart its idle timeout period. Sending a packet containing a PING 3103 frame restarts the idle timeout for this endpoint also if this is the 3104 first ack-eliciting packet sent since receiving a packet. Sending a 3105 PING frame causes the peer to respond with an acknowledgment, which 3106 also restarts the idle timeout for the endpoint. 3108 Application protocols that use QUIC SHOULD provide guidance on when 3109 deferring an idle timeout is appropriate. Unnecessary sending of 3110 PING frames could have a detrimental effect on performance. 3112 A connection will time out if no packets are sent or received for a 3113 period longer than the time negotiated using the max_idle_timeout 3114 transport parameter; see Section 10. However, state in middleboxes 3115 might time out earlier than that. Though REQ-5 in [RFC4787] 3116 recommends a 2 minute timeout interval, experience shows that sending 3117 packets every 30 seconds is necessary to prevent the majority of 3118 middleboxes from losing state for UDP flows [GATEWAY]. 3120 10.2. Immediate Close 3122 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 3123 terminate the connection immediately. A CONNECTION_CLOSE frame 3124 causes all streams to immediately become closed; open streams can be 3125 assumed to be implicitly reset. 3127 After sending a CONNECTION_CLOSE frame, an endpoint immediately 3128 enters the closing state; see Section 10.2.1. After receiving a 3129 CONNECTION_CLOSE frame, endpoints enter the draining state; see 3130 Section 10.2.2. 3132 Violations of the protocol lead to an immediate close. 3134 An immediate close can be used after an application protocol has 3135 arranged to close a connection. This might be after the application 3136 protocol negotiates a graceful shutdown. The application protocol 3137 can exchange messages that are needed for both application endpoints 3138 to agree that the connection can be closed, after which the 3139 application requests that QUIC close the connection. When QUIC 3140 consequently closes the connection, a CONNECTION_CLOSE frame with an 3141 application-supplied error code will be used to signal closure to the 3142 peer. 3144 The closing and draining connection states exist to ensure that 3145 connections close cleanly and that delayed or reordered packets are 3146 properly discarded. These states SHOULD persist for at least three 3147 times the current Probe Timeout (PTO) interval as defined in 3148 [QUIC-RECOVERY]. 3150 Disposing of connection state prior to exiting the closing or 3151 draining state could result in an endpoint generating a stateless 3152 reset unnecessarily when it receives a late-arriving packet. 3153 Endpoints that have some alternative means to ensure that late- 3154 arriving packets do not induce a response, such as those that are 3155 able to close the UDP socket, MAY end these states earlier to allow 3156 for faster resource recovery. Servers that retain an open socket for 3157 accepting new connections SHOULD NOT end the closing or draining 3158 states early. 3160 Once its closing or draining state ends, an endpoint SHOULD discard 3161 all connection state. The endpoint MAY send a stateless reset in 3162 response to any further incoming packets belonging to this 3163 connection. 3165 10.2.1. Closing Connection State 3167 An endpoint enters the closing state after initiating an immediate 3168 close. 3170 In the closing state, an endpoint retains only enough information to 3171 generate a packet containing a CONNECTION_CLOSE frame and to identify 3172 packets as belonging to the connection. An endpoint in the closing 3173 state sends a packet containing a CONNECTION_CLOSE frame in response 3174 to any incoming packet that it attributes to the connection. 3176 An endpoint SHOULD limit the rate at which it generates packets in 3177 the closing state. For instance, an endpoint could wait for a 3178 progressively increasing number of received packets or amount of time 3179 before responding to received packets. 3181 An endpoint's selected connection ID and the QUIC version are 3182 sufficient information to identify packets for a closing connection; 3183 the endpoint MAY discard all other connection state. An endpoint 3184 that is closing is not required to process any received frame. An 3185 endpoint MAY retain packet protection keys for incoming packets to 3186 allow it to read and process a CONNECTION_CLOSE frame. 3188 An endpoint MAY drop packet protection keys when entering the closing 3189 state and send a packet containing a CONNECTION_CLOSE frame in 3190 response to any UDP datagram that is received. However, an endpoint 3191 that discards packet protection keys cannot identify and discard 3192 invalid packets. To avoid being used for an amplication attack, such 3193 endpoints MUST limit the cumulative size of packets it sends to three 3194 times the cumulative size of the packets that are received and 3195 attributed to the connection. To minimize the state that an endpoint 3196 maintains for a closing connection, endpoints MAY send the exact same 3197 packet in response to any received packet. 3199 Note: Allowing retransmission of a closing packet is an exception to 3200 the requirement that a new packet number be used for each packet 3201 in Section 12.3. Sending new packet numbers is primarily of 3202 advantage to loss recovery and congestion control, which are not 3203 expected to be relevant for a closed connection. Retransmitting 3204 the final packet requires less state. 3206 While in the closing state, an endpoint could receive packets from a 3207 new source address, possibly indicating a connection migration; see 3208 Section 9. An endpoint in the closing state MUST either discard 3209 packets received from an unvalidated address or limit the cumulative 3210 size of packets it sends to an unvalidated address to three times the 3211 size of packets it receives from that address. 3213 An endpoint is not expected to handle key updates when it is closing 3214 (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint 3215 from moving from the closing state to the draining state, as the 3216 endpoint will not be able to process subsequently received packets, 3217 but it otherwise has no impact. 3219 10.2.2. Draining Connection State 3221 The draining state is entered once an endpoint receives a 3222 CONNECTION_CLOSE frame, which indicates that its peer is closing or 3223 draining. While otherwise identical to the closing state, an 3224 endpoint in the draining state MUST NOT send any packets. Retaining 3225 packet protection keys is unnecessary once a connection is in the 3226 draining state. 3228 An endpoint that receives a CONNECTION_CLOSE frame MAY send a single 3229 packet containing a CONNECTION_CLOSE frame before entering the 3230 draining state, using a NO_ERROR code if appropriate. An endpoint 3231 MUST NOT send further packets. Doing so could result in a constant 3232 exchange of CONNECTION_CLOSE frames until one of the endpoints exits 3233 the closing state. 3235 An endpoint MAY enter the draining state from the closing state if it 3236 receives a CONNECTION_CLOSE frame, which indicates that the peer is 3237 also closing or draining. In this case, the draining state SHOULD 3238 end when the closing state would have ended. In other words, the 3239 endpoint uses the same end time, but ceases transmission of any 3240 packets on this connection. 3242 10.2.3. Immediate Close During the Handshake 3244 When sending CONNECTION_CLOSE, the goal is to ensure that the peer 3245 will process the frame. Generally, this means sending the frame in a 3246 packet with the highest level of packet protection to avoid the 3247 packet being discarded. After the handshake is confirmed (see 3248 Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any 3249 CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to 3250 confirming the handshake, it is possible that more advanced packet 3251 protection keys are not available to the peer, so another 3252 CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower 3253 packet protection level. More specifically: 3255 * A client will always know whether the server has Handshake keys 3256 (see Section 17.2.2.1), but it is possible that a server does not 3257 know whether the client has Handshake keys. Under these 3258 circumstances, a server SHOULD send a CONNECTION_CLOSE frame in 3259 both Handshake and Initial packets to ensure that at least one of 3260 them is processable by the client. 3262 * A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be 3263 assured that the server has accepted 0-RTT. Sending a 3264 CONNECTION_CLOSE frame in an Initial packet makes it more likely 3265 that the server can receive the close signal, even if the 3266 application error code might not be received. 3268 * Prior to confirming the handshake, a peer might be unable to 3269 process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE 3270 in both Handshake and 1-RTT packets. A server SHOULD also send 3271 CONNECTION_CLOSE in an Initial packet. 3273 Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake 3274 packet could expose application state or be used to alter application 3275 state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a 3276 CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or 3277 Handshake packets. Otherwise, information about the application 3278 state might be revealed. Endpoints MUST clear the value of the 3279 Reason Phrase field and SHOULD use the APPLICATION_ERROR code when 3280 converting to a CONNECTION_CLOSE of type 0x1c. 3282 CONNECTION_CLOSE frames sent in multiple packet types can be 3283 coalesced into a single UDP datagram; see Section 12.2. 3285 An endpoint can send a CONNECTION_CLOSE frame in an Initial packet. 3286 This might be in response to unauthenticated information received in 3287 Initial or Handshake packets. Such an immediate close might expose 3288 legitimate connections to a denial of service. QUIC does not include 3289 defensive measures for on-path attacks during the handshake; see 3290 Section 21.1. However, at the cost of reducing feedback about errors 3291 for legitimate peers, some forms of denial of service can be made 3292 more difficult for an attacker if endpoints discard illegal packets 3293 rather than terminating a connection with CONNECTION_CLOSE. For this 3294 reason, endpoints MAY discard packets rather than immediately close 3295 if errors are detected in packets that lack authentication. 3297 An endpoint that has not established state, such as a server that 3298 detects an error in an Initial packet, does not enter the closing 3299 state. An endpoint that has no state for the connection does not 3300 enter a closing or draining period on sending a CONNECTION_CLOSE 3301 frame. 3303 10.3. Stateless Reset 3305 A stateless reset is provided as an option of last resort for an 3306 endpoint that does not have access to the state of a connection. A 3307 crash or outage might result in peers continuing to send data to an 3308 endpoint that is unable to properly continue the connection. An 3309 endpoint MAY send a stateless reset in response to receiving a packet 3310 that it cannot associate with an active connection. 3312 A stateless reset is not appropriate for indicating errors in active 3313 connections. An endpoint that wishes to communicate a fatal 3314 connection error MUST use a CONNECTION_CLOSE frame if it is able. 3316 To support this process, a token is sent by endpoints. The token is 3317 carried in the Stateless Reset Token field of a NEW_CONNECTION_ID 3318 frame. Servers can also specify a stateless_reset_token transport 3319 parameter during the handshake that applies to the connection ID that 3320 it selected during the handshake; clients cannot use this transport 3321 parameter because their transport parameters do not have 3322 confidentiality protection. These tokens are protected by 3323 encryption, so only client and server know their value. Tokens are 3324 invalidated when their associated connection ID is retired via a 3325 RETIRE_CONNECTION_ID frame (Section 19.16). 3327 An endpoint that receives packets that it cannot process sends a 3328 packet in the following layout: 3330 Stateless Reset { 3331 Fixed Bits (2) = 1, 3332 Unpredictable Bits (38..), 3333 Stateless Reset Token (128), 3334 } 3336 Figure 10: Stateless Reset Packet 3338 This design ensures that a stateless reset packet is - to the extent 3339 possible - indistinguishable from a regular packet with a short 3340 header. 3342 A stateless reset uses an entire UDP datagram, starting with the 3343 first two bits of the packet header. The remainder of the first byte 3344 and an arbitrary number of bytes following it are set to values that 3345 SHOULD be indistinguishable from random. The last 16 bytes of the 3346 datagram contain a Stateless Reset Token. 3348 To entities other than its intended recipient, a stateless reset will 3349 appear to be a packet with a short header. For the stateless reset 3350 to appear as a valid QUIC packet, the Unpredictable Bits field needs 3351 to include at least 38 bits of data (or 5 bytes, less the two fixed 3352 bits). 3354 The resulting minimum size of 21 bytes does not guarantee that a 3355 stateless reset is difficult to distinguish from other packets if the 3356 recipient requires the use of a connection ID. To achieve that end, 3357 the endpoint SHOULD ensure that all packets it sends are at least 22 3358 bytes longer than the minimum connection ID length that it requests 3359 the peer to include in its packets, adding PADDING frames as 3360 necessary. This ensures that any stateless reset sent by the peer is 3361 indistinguishable from a valid packet sent to the endpoint. An 3362 endpoint that sends a stateless reset in response to a packet that is 3363 43 bytes or shorter SHOULD send a stateless reset that is one byte 3364 shorter than the packet it responds to. 3366 These values assume that the Stateless Reset Token is the same length 3367 as the minimum expansion of the packet protection AEAD. Additional 3368 unpredictable bytes are necessary if the endpoint could have 3369 negotiated a packet protection scheme with a larger minimum 3370 expansion. 3372 An endpoint MUST NOT send a stateless reset that is three times or 3373 more larger than the packet it receives to avoid being used for 3374 amplification. Section 10.3.3 describes additional limits on 3375 stateless reset size. 3377 Endpoints MUST discard packets that are too small to be valid QUIC 3378 packets. With the set of AEAD functions defined in [QUIC-TLS], 3379 packets that are smaller than 21 bytes are never valid. 3381 Endpoints MUST send stateless reset packets formatted as a packet 3382 with a short header. However, endpoints MUST treat any packet ending 3383 in a valid stateless reset token as a stateless reset, as other QUIC 3384 versions might allow the use of a long header. 3386 An endpoint MAY send a stateless reset in response to a packet with a 3387 long header. Sending a stateless reset is not effective prior to the 3388 stateless reset token being available to a peer. In this QUIC 3389 version, packets with a long header are only used during connection 3390 establishment. Because the stateless reset token is not available 3391 until connection establishment is complete or near completion, 3392 ignoring an unknown packet with a long header might be as effective 3393 as sending a stateless reset. 3395 An endpoint cannot determine the Source Connection ID from a packet 3396 with a short header, therefore it cannot set the Destination 3397 Connection ID in the stateless reset packet. The Destination 3398 Connection ID will therefore differ from the value used in previous 3399 packets. A random Destination Connection ID makes the connection ID 3400 appear to be the result of moving to a new connection ID that was 3401 provided using a NEW_CONNECTION_ID frame (Section 19.15). 3403 Using a randomized connection ID results in two problems: 3405 * The packet might not reach the peer. If the Destination 3406 Connection ID is critical for routing toward the peer, then this 3407 packet could be incorrectly routed. This might also trigger 3408 another Stateless Reset in response; see Section 10.3.3. A 3409 Stateless Reset that is not correctly routed is an ineffective 3410 error detection and recovery mechanism. In this case, endpoints 3411 will need to rely on other methods - such as timers - to detect 3412 that the connection has failed. 3414 * The randomly generated connection ID can be used by entities other 3415 than the peer to identify this as a potential stateless reset. An 3416 endpoint that occasionally uses different connection IDs might 3417 introduce some uncertainty about this. 3419 This stateless reset design is specific to QUIC version 1. An 3420 endpoint that supports multiple versions of QUIC needs to generate a 3421 stateless reset that will be accepted by peers that support any 3422 version that the endpoint might support (or might have supported 3423 prior to losing state). Designers of new versions of QUIC need to be 3424 aware of this and either reuse this design, or use a portion of the 3425 packet other than the last 16 bytes for carrying data. 3427 10.3.1. Detecting a Stateless Reset 3429 An endpoint detects a potential stateless reset using the trailing 16 3430 bytes of the UDP datagram. An endpoint remembers all Stateless Reset 3431 Tokens associated with the connection IDs and remote addresses for 3432 datagrams it has recently sent. This includes Stateless Reset Tokens 3433 from NEW_CONNECTION_ID frames and the server's transport parameters 3434 but excludes Stateless Reset Tokens associated with connection IDs 3435 that are either unused or retired. The endpoint identifies a 3436 received datagram as a stateless reset by comparing the last 16 bytes 3437 of the datagram with all Stateless Reset Tokens associated with the 3438 remote address on which the datagram was received. 3440 This comparison can be performed for every inbound datagram. 3441 Endpoints MAY skip this check if any packet from a datagram is 3442 successfully processed. However, the comparison MUST be performed 3443 when the first packet in an incoming datagram either cannot be 3444 associated with a connection, or cannot be decrypted. 3446 An endpoint MUST NOT check for any Stateless Reset Tokens associated 3447 with connection IDs it has not used or for connection IDs that have 3448 been retired. 3450 When comparing a datagram to Stateless Reset Token values, endpoints 3451 MUST perform the comparison without leaking information about the 3452 value of the token. For example, performing this comparison in 3453 constant time protects the value of individual Stateless Reset Tokens 3454 from information leakage through timing side channels. Another 3455 approach would be to store and compare the transformed values of 3456 Stateless Reset Tokens instead of the raw token values, where the 3457 transformation is defined as a cryptographically-secure pseudo-random 3458 function using a secret key (e.g., block cipher, HMAC [RFC2104]). An 3459 endpoint is not expected to protect information about whether a 3460 packet was successfully decrypted, or the number of valid Stateless 3461 Reset Tokens. 3463 If the last 16 bytes of the datagram are identical in value to a 3464 Stateless Reset Token, the endpoint MUST enter the draining period 3465 and not send any further packets on this connection. 3467 10.3.2. Calculating a Stateless Reset Token 3469 The stateless reset token MUST be difficult to guess. In order to 3470 create a Stateless Reset Token, an endpoint could randomly generate 3471 ([RFC4086]) a secret for every connection that it creates. However, 3472 this presents a coordination problem when there are multiple 3473 instances in a cluster or a storage problem for an endpoint that 3474 might lose state. Stateless reset specifically exists to handle the 3475 case where state is lost, so this approach is suboptimal. 3477 A single static key can be used across all connections to the same 3478 endpoint by generating the proof using a second iteration of a 3479 preimage-resistant function that takes a static key and the 3480 connection ID chosen by the endpoint (see Section 5.1) as input. An 3481 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 3482 connection_id)) or HKDF [RFC5869] (for example, using the static key 3483 as input keying material, with the connection ID as salt). The 3484 output of this function is truncated to 16 bytes to produce the 3485 Stateless Reset Token for that connection. 3487 An endpoint that loses state can use the same method to generate a 3488 valid Stateless Reset Token. The connection ID comes from the packet 3489 that the endpoint receives. 3491 This design relies on the peer always sending a connection ID in its 3492 packets so that the endpoint can use the connection ID from a packet 3493 to reset the connection. An endpoint that uses this design MUST 3494 either use the same connection ID length for all connections or 3495 encode the length of the connection ID such that it can be recovered 3496 without state. In addition, it cannot provide a zero-length 3497 connection ID. 3499 Revealing the Stateless Reset Token allows any entity to terminate 3500 the connection, so a value can only be used once. This method for 3501 choosing the Stateless Reset Token means that the combination of 3502 connection ID and static key MUST NOT be used for another connection. 3503 A denial of service attack is possible if the same connection ID is 3504 used by instances that share a static key, or if an attacker can 3505 cause a packet to be routed to an instance that has no state but the 3506 same static key; see Section 21.10. A connection ID from a 3507 connection that is reset by revealing the Stateless Reset Token MUST 3508 NOT be reused for new connections at nodes that share a static key. 3510 The same Stateless Reset Token MUST NOT be used for multiple 3511 connection IDs. Endpoints are not required to compare new values 3512 against all previous values, but a duplicate value MAY be treated as 3513 a connection error of type PROTOCOL_VIOLATION. 3515 Note that Stateless Reset packets do not have any cryptographic 3516 protection. 3518 10.3.3. Looping 3520 The design of a Stateless Reset is such that without knowing the 3521 stateless reset token it is indistinguishable from a valid packet. 3522 For instance, if a server sends a Stateless Reset to another server 3523 it might receive another Stateless Reset in response, which could 3524 lead to an infinite exchange. 3526 An endpoint MUST ensure that every Stateless Reset that it sends is 3527 smaller than the packet that triggered it, unless it maintains state 3528 sufficient to prevent looping. In the event of a loop, this results 3529 in packets eventually being too small to trigger a response. 3531 An endpoint can remember the number of Stateless Reset packets that 3532 it has sent and stop generating new Stateless Reset packets once a 3533 limit is reached. Using separate limits for different remote 3534 addresses will ensure that Stateless Reset packets can be used to 3535 close connections when other peers or connections have exhausted 3536 limits. 3538 Reducing the size of a Stateless Reset below 41 bytes means that the 3539 packet could reveal to an observer that it is a Stateless Reset, 3540 depending upon the length of the peer's connection IDs. Conversely, 3541 refusing to send a Stateless Reset in response to a small packet 3542 might result in Stateless Reset not being useful in detecting cases 3543 of broken connections where only very small packets are sent; such 3544 failures might only be detected by other means, such as timers. 3546 11. Error Handling 3548 An endpoint that detects an error SHOULD signal the existence of that 3549 error to its peer. Both transport-level and application-level errors 3550 can affect an entire connection; see Section 11.1. Only application- 3551 level errors can be isolated to a single stream; see Section 11.2. 3553 The most appropriate error code (Section 20) SHOULD be included in 3554 the frame that signals the error. Where this specification 3555 identifies error conditions, it also identifies the error code that 3556 is used; though these are worded as requirements, different 3557 implementation strategies might lead to different errors being 3558 reported. In particular, an endpoint MAY use any applicable error 3559 code when it detects an error condition; a generic error code (such 3560 as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place 3561 of specific error codes. 3563 A stateless reset (Section 10.3) is not suitable for any error that 3564 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 3565 stateless reset MUST NOT be used by an endpoint that has the state 3566 necessary to send a frame on the connection. 3568 11.1. Connection Errors 3570 Errors that result in the connection being unusable, such as an 3571 obvious violation of protocol semantics or corruption of state that 3572 affects an entire connection, MUST be signaled using a 3573 CONNECTION_CLOSE frame (Section 19.19). 3575 Application-specific protocol errors are signaled using the 3576 CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are 3577 specific to the transport, including all those described in this 3578 document, are carried in the CONNECTION_CLOSE frame with a frame type 3579 of 0x1c. 3581 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 3582 endpoint SHOULD be prepared to retransmit a packet containing a 3583 CONNECTION_CLOSE frame if it receives more packets on a terminated 3584 connection. Limiting the number of retransmissions and the time over 3585 which this final packet is sent limits the effort expended on 3586 terminated connections. 3588 An endpoint that chooses not to retransmit packets containing a 3589 CONNECTION_CLOSE frame risks a peer missing the first such packet. 3590 The only mechanism available to an endpoint that continues to receive 3591 data for a terminated connection is to use the stateless reset 3592 process (Section 10.3). 3594 11.2. Stream Errors 3596 If an application-level error affects a single stream, but otherwise 3597 leaves the connection in a recoverable state, the endpoint can send a 3598 RESET_STREAM frame (Section 19.4) with an appropriate error code to 3599 terminate just the affected stream. 3601 Resetting a stream without the involvement of the application 3602 protocol could cause the application protocol to enter an 3603 unrecoverable state. RESET_STREAM MUST only be instigated by the 3604 application protocol that uses QUIC. 3606 The semantics of the application error code carried in RESET_STREAM 3607 are defined by the application protocol. Only the application 3608 protocol is able to cause a stream to be terminated. A local 3609 instance of the application protocol uses a direct API call and a 3610 remote instance uses the STOP_SENDING frame, which triggers an 3611 automatic RESET_STREAM. 3613 Application protocols SHOULD define rules for handling streams that 3614 are prematurely cancelled by either endpoint. 3616 12. Packets and Frames 3618 QUIC endpoints communicate by exchanging packets. Packets have 3619 confidentiality and integrity protection; see Section 12.1. Packets 3620 are carried in UDP datagrams; see Section 12.2. 3622 This version of QUIC uses the long packet header during connection 3623 establishment; see Section 17.2. Packets with the long header are 3624 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake 3625 (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation 3626 uses a version-independent packet with a long header; see 3627 Section 17.2.1. 3629 Packets with the short header are designed for minimal overhead and 3630 are used after a connection is established and 1-RTT keys are 3631 available; see Section 17.3. 3633 12.1. Protected Packets 3635 QUIC packets have different levels of cryptographic protection based 3636 on the type of packet. Details of packet protection are found in 3637 [QUIC-TLS]; this section includes an overview of the protections that 3638 are provided. 3640 Version Negotiation packets have no cryptographic protection; see 3641 [QUIC-INVARIANTS]. 3643 Retry packets use an authenticated encryption with associated data 3644 function (AEAD; [AEAD]) to protect against accidental modification. 3646 Initial packets use an AEAD, the keys for which are derived using a 3647 value that is visible on the wire. Initial packets therefore do not 3648 have effective confidentiality protection. Initial protection exists 3649 to ensure that the sender of the packet is on the network path. Any 3650 entity that receives an Initial packet from a client can recover the 3651 keys that will allow them to both read the contents of the packet and 3652 generate Initial packets that will be successfully authenticated at 3653 either endpoint. 3655 All other packets are protected with keys derived from the 3656 cryptographic handshake. The cryptographic handshake ensures that 3657 only the communicating endpoints receive the corresponding keys for 3658 Handshake, 0-RTT, and 1-RTT packets. Packets protected with 0-RTT 3659 and 1-RTT keys have strong confidentiality and integrity protection. 3661 The Packet Number field that appears in some packet types has 3662 alternative confidentiality protection that is applied as part of 3663 header protection; see Section 5.4 of [QUIC-TLS] for details. The 3664 underlying packet number increases with each packet sent in a given 3665 packet number space; see Section 12.3 for details. 3667 12.2. Coalescing Packets 3669 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake 3670 (Section 17.2.4) packets contain a Length field that determines the 3671 end of the packet. The length includes both the Packet Number and 3672 Payload fields, both of which are confidentiality protected and 3673 initially of unknown length. The length of the Payload field is 3674 learned once header protection is removed. 3676 Using the Length field, a sender can coalesce multiple QUIC packets 3677 into one UDP datagram. This can reduce the number of UDP datagrams 3678 needed to complete the cryptographic handshake and start sending 3679 data. This can also be used to construct PMTU probes; see 3680 Section 14.4.1. Receivers MUST be able to process coalesced packets. 3682 Coalescing packets in order of increasing encryption levels (Initial, 3683 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it 3684 more likely the receiver will be able to process all the packets in a 3685 single pass. A packet with a short header does not include a length, 3686 so it can only be the last packet included in a UDP datagram. An 3687 endpoint SHOULD include multiple frames in a single packet if they 3688 are to be sent at the same encryption level, instead of coalescing 3689 multiple packets at the same encryption level. 3691 Receivers MAY route based on the information in the first packet 3692 contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets 3693 with different connection IDs into a single UDP datagram. Receivers 3694 SHOULD ignore any subsequent packets with a different Destination 3695 Connection ID than the first packet in the datagram. 3697 Every QUIC packet that is coalesced into a single UDP datagram is 3698 separate and complete. The receiver of coalesced QUIC packets MUST 3699 individually process each QUIC packet and separately acknowledge 3700 them, as if they were received as the payload of different UDP 3701 datagrams. For example, if decryption fails (because the keys are 3702 not available or any other reason), the receiver MAY either discard 3703 or buffer the packet for later processing and MUST attempt to process 3704 the remaining packets. 3706 Retry packets (Section 17.2.5), Version Negotiation packets 3707 (Section 17.2.1), and packets with a short header (Section 17.3) do 3708 not contain a Length field and so cannot be followed by other packets 3709 in the same UDP datagram. Note also that there is no situation where 3710 a Retry or Version Negotiation packet is coalesced with another 3711 packet. 3713 12.3. Packet Numbers 3715 The packet number is an integer in the range 0 to 2^62-1. This 3716 number is used in determining the cryptographic nonce for packet 3717 protection. Each endpoint maintains a separate packet number for 3718 sending and receiving. 3720 Packet numbers are limited to this range because they need to be 3721 representable in whole in the Largest Acknowledged field of an ACK 3722 frame (Section 19.3). When present in a long or short header 3723 however, packet numbers are reduced and encoded in 1 to 4 bytes; see 3724 Section 17.1. 3726 Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) 3727 packets do not include a packet number. 3729 Packet numbers are divided into 3 spaces in QUIC: 3731 * Initial space: All Initial packets (Section 17.2.2) are in this 3732 space. 3734 * Handshake space: All Handshake packets (Section 17.2.4) are in 3735 this space. 3737 * Application data space: All 0-RTT (Section 17.2.3) and 1-RTT 3738 (Section 17.3) encrypted packets are in this space. 3740 As described in [QUIC-TLS], each packet type uses different 3741 protection keys. 3743 Conceptually, a packet number space is the context in which a packet 3744 can be processed and acknowledged. Initial packets can only be sent 3745 with Initial packet protection keys and acknowledged in packets that 3746 are also Initial packets. Similarly, Handshake packets are sent at 3747 the Handshake encryption level and can only be acknowledged in 3748 Handshake packets. 3750 This enforces cryptographic separation between the data sent in the 3751 different packet number spaces. Packet numbers in each space start 3752 at packet number 0. Subsequent packets sent in the same packet 3753 number space MUST increase the packet number by at least one. 3755 0-RTT and 1-RTT data exist in the same packet number space to make 3756 loss recovery algorithms easier to implement between the two packet 3757 types. 3759 A QUIC endpoint MUST NOT reuse a packet number within the same packet 3760 number space in one connection. If the packet number for sending 3761 reaches 2^62 - 1, the sender MUST close the connection without 3762 sending a CONNECTION_CLOSE frame or any further packets; an endpoint 3763 MAY send a Stateless Reset (Section 10.3) in response to further 3764 packets that it receives. 3766 A receiver MUST discard a newly unprotected packet unless it is 3767 certain that it has not processed another packet with the same packet 3768 number from the same packet number space. Duplicate suppression MUST 3769 happen after removing packet protection for the reasons described in 3770 Section 9.3 of [QUIC-TLS]. 3772 Endpoints that track all individual packets for the purposes of 3773 detecting duplicates are at risk of accumulating excessive state. 3774 The data required for detecting duplicates can be limited by 3775 maintaining a minimum packet number below which all packets are 3776 immediately dropped. Any minimum needs to account for large 3777 variations in round trip time, which includes the possibility that a 3778 peer might probe network paths with much larger round trip times; see 3779 Section 9. 3781 Packet number encoding at a sender and decoding at a receiver are 3782 described in Section 17.1. 3784 12.4. Frames and Frame Types 3786 The payload of QUIC packets, after removing packet protection, 3787 consists of a sequence of complete frames, as shown in Figure 11. 3788 Version Negotiation, Stateless Reset, and Retry packets do not 3789 contain frames. 3791 Packet Payload { 3792 Frame (8..) ..., 3793 } 3795 Figure 11: QUIC Payload 3797 The payload of a packet that contains frames MUST contain at least 3798 one frame, and MAY contain multiple frames and multiple frame types. 3799 Frames always fit within a single QUIC packet and cannot span 3800 multiple packets. 3802 Each frame begins with a Frame Type, indicating its type, followed by 3803 additional type-dependent fields: 3805 Frame { 3806 Frame Type (i), 3807 Type-Dependent Fields (..), 3808 } 3810 Figure 12: Generic Frame Layout 3812 The frame types defined in this specification are listed in Table 3. 3813 The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and 3814 CONNECTION_CLOSE frames is used to carry other frame-specific flags. 3815 For all other frames, the Frame Type field simply identifies the 3816 frame. These frames are explained in more detail in Section 19. 3818 +=============+======================+===============+======+======+ 3819 | Type Value | Frame Type Name | Definition | Pkts | Spec | 3820 +=============+======================+===============+======+======+ 3821 | 0x00 | PADDING | Section 19.1 | IH01 | NP | 3822 +-------------+----------------------+---------------+------+------+ 3823 | 0x01 | PING | Section 19.2 | IH01 | | 3824 +-------------+----------------------+---------------+------+------+ 3825 | 0x02 - 0x03 | ACK | Section 19.3 | IH_1 | NC | 3826 +-------------+----------------------+---------------+------+------+ 3827 | 0x04 | RESET_STREAM | Section 19.4 | __01 | | 3828 +-------------+----------------------+---------------+------+------+ 3829 | 0x05 | STOP_SENDING | Section 19.5 | __01 | | 3830 +-------------+----------------------+---------------+------+------+ 3831 | 0x06 | CRYPTO | Section 19.6 | IH_1 | | 3832 +-------------+----------------------+---------------+------+------+ 3833 | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | 3834 +-------------+----------------------+---------------+------+------+ 3835 | 0x08 - 0x0f | STREAM | Section 19.8 | __01 | F | 3836 +-------------+----------------------+---------------+------+------+ 3837 | 0x10 | MAX_DATA | Section 19.9 | __01 | | 3838 +-------------+----------------------+---------------+------+------+ 3839 | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | 3840 +-------------+----------------------+---------------+------+------+ 3841 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | __01 | | 3842 +-------------+----------------------+---------------+------+------+ 3843 | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | 3844 +-------------+----------------------+---------------+------+------+ 3845 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | 3846 +-------------+----------------------+---------------+------+------+ 3847 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | 3848 +-------------+----------------------+---------------+------+------+ 3849 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | 3850 +-------------+----------------------+---------------+------+------+ 3851 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | 3852 +-------------+----------------------+---------------+------+------+ 3853 | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | 3854 +-------------+----------------------+---------------+------+------+ 3855 | 0x1b | PATH_RESPONSE | Section 19.18 | __01 | P | 3856 +-------------+----------------------+---------------+------+------+ 3857 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | | 3858 +-------------+----------------------+---------------+------+------+ 3859 | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | 3860 +-------------+----------------------+---------------+------+------+ 3862 Table 3: Frame Types 3864 The "Pkts" column in Table 3 lists the types of packets that each 3865 frame type could appear in, indicated by the following characters: 3867 I: Initial (Section 17.2.2) 3869 H: Handshake (Section 17.2.4) 3871 0: 0-RTT (Section 17.2.3) 3873 1: 1-RTT (Section 17.3) 3875 ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial 3876 or Handshake packets. 3878 For more detail about these restrictions, see Section 12.5. Note 3879 that all frames can appear in 1-RTT packets. An endpoint MUST treat 3880 receipt of a frame in a packet type that is not permitted as a 3881 connection error of type PROTOCOL_VIOLATION. 3883 The "Spec" column in Table 3 summarizes any special rules governing 3884 the processing or generation of the frame type, as indicated by the 3885 following characters: 3887 N: Packets containing only frames with this marking are not ack- 3888 eliciting; see Section 13.2. 3890 C: Packets containing only frames with this marking do not count 3891 toward bytes in flight for congestion control purposes; see 3892 [QUIC-RECOVERY]. 3894 P: Packets containing only frames with this marking can be used to 3895 probe new network paths during connection migration; see 3896 Section 9.1. 3898 F: The content of frames with this marking are flow controlled; see 3899 Section 4. 3901 The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA 3902 registry; see Section 22.3. 3904 An endpoint MUST treat the receipt of a frame of unknown type as a 3905 connection error of type FRAME_ENCODING_ERROR. 3907 All QUIC frames are idempotent in this version of QUIC. That is, a 3908 valid frame does not cause undesirable side effects or errors when 3909 received more than once. 3911 The Frame Type field uses a variable-length integer encoding (see 3912 Section 16) with one exception. To ensure simple and efficient 3913 implementations of frame parsing, a frame type MUST use the shortest 3914 possible encoding. For frame types defined in this document, this 3915 means a single-byte encoding, even though it is possible to encode 3916 these values as a two-, four- or eight-byte variable-length integer. 3917 For instance, though 0x4001 is a legitimate two-byte encoding for a 3918 variable-length integer with a value of 1, PING frames are always 3919 encoded as a single byte with the value 0x01. This rule applies to 3920 all current and future QUIC frame types. An endpoint MAY treat the 3921 receipt of a frame type that uses a longer encoding than necessary as 3922 a connection error of type PROTOCOL_VIOLATION. 3924 12.5. Frames and Number Spaces 3926 Some frames are prohibited in different packet number spaces. The 3927 rules here generalize those of TLS, in that frames associated with 3928 establishing the connection can usually appear in packets in any 3929 packet number space, whereas those associated with transferring data 3930 can only appear in the application data packet number space: 3932 * PADDING, PING, and CRYPTO frames MAY appear in any packet number 3933 space. 3935 * CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 3936 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE 3937 frames signaling application errors (type 0x1d) MUST only appear 3938 in the application data packet number space. 3940 * ACK frames MAY appear in any packet number space, but can only 3941 acknowledge packets that appeared in that packet number space. 3942 However, as noted below, 0-RTT packets cannot contain ACK frames. 3944 * All other frame types MUST only be sent in the application data 3945 packet number space. 3947 Note that it is not possible to send the following frames in 0-RTT 3948 packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, 3949 PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt 3950 of these frames in 0-RTT packets as a connection error of type 3951 PROTOCOL_VIOLATION. 3953 13. Packetization and Reliability 3955 A sender sends one or more frames in a QUIC packet; see Section 12.4. 3957 A sender can minimize per-packet bandwidth and computational costs by 3958 including as many frames as possible in each QUIC packet. A sender 3959 MAY wait for a short period of time to collect multiple frames before 3960 sending a packet that is not maximally packed, to avoid sending out 3961 large numbers of small packets. An implementation MAY use knowledge 3962 about application sending behavior or heuristics to determine whether 3963 and for how long to wait. This waiting period is an implementation 3964 decision, and an implementation should be careful to delay 3965 conservatively, since any delay is likely to increase application- 3966 visible latency. 3968 Stream multiplexing is achieved by interleaving STREAM frames from 3969 multiple streams into one or more QUIC packets. A single QUIC packet 3970 can include multiple STREAM frames from one or more streams. 3972 One of the benefits of QUIC is avoidance of head-of-line blocking 3973 across multiple streams. When a packet loss occurs, only streams 3974 with data in that packet are blocked waiting for a retransmission to 3975 be received, while other streams can continue making progress. Note 3976 that when data from multiple streams is included in a single QUIC 3977 packet, loss of that packet blocks all those streams from making 3978 progress. Implementations are advised to include as few streams as 3979 necessary in outgoing packets without losing transmission efficiency 3980 to underfilled packets. 3982 13.1. Packet Processing 3984 A packet MUST NOT be acknowledged until packet protection has been 3985 successfully removed and all frames contained in the packet have been 3986 processed. For STREAM frames, this means the data has been enqueued 3987 in preparation to be received by the application protocol, but it 3988 does not require that data is delivered and consumed. 3990 Once the packet has been fully processed, a receiver acknowledges 3991 receipt by sending one or more ACK frames containing the packet 3992 number of the received packet. 3994 An endpoint SHOULD treat receipt of an acknowledgment for a packet it 3995 did not send as a connection error of type PROTOCOL_VIOLATION, if it 3996 is able to detect the condition. 3998 13.2. Generating Acknowledgements 4000 Endpoints acknowledge all packets they receive and process. However, 4001 only ack-eliciting packets cause an ACK frame to be sent within the 4002 maximum ack delay. Packets that are not ack-eliciting are only 4003 acknowledged when an ACK frame is sent for other reasons. 4005 When sending a packet for any reason, an endpoint SHOULD attempt to 4006 include an ACK frame if one has not been sent recently. Doing so 4007 helps with timely loss detection at the peer. 4009 In general, frequent feedback from a receiver improves loss and 4010 congestion response, but this has to be balanced against excessive 4011 load generated by a receiver that sends an ACK frame in response to 4012 every ack-eliciting packet. The guidance offered below seeks to 4013 strike this balance. 4015 13.2.1. Sending ACK Frames 4017 Every packet SHOULD be acknowledged at least once, and ack-eliciting 4018 packets MUST be acknowledged at least once within the maximum delay 4019 an endpoint communicated using the max_ack_delay transport parameter; 4020 see Section 18.2. max_ack_delay declares an explicit contract: an 4021 endpoint promises to never intentionally delay acknowledgments of an 4022 ack-eliciting packet by more than the indicated value. If it does, 4023 any excess accrues to the RTT estimate and could result in spurious 4024 or delayed retransmissions from the peer. A sender uses the 4025 receiver's max_ack_delay value in determining timeouts for timer- 4026 based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY]. 4028 An endpoint MUST acknowledge all ack-eliciting Initial and Handshake 4029 packets immediately and all ack-eliciting 0-RTT and 1-RTT packets 4030 within its advertised max_ack_delay, with the following exception. 4031 Prior to handshake confirmation, an endpoint might not have packet 4032 protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets 4033 when they are received. It might therefore buffer them and 4034 acknowledge them when the requisite keys become available. 4036 Since packets containing only ACK frames are not congestion 4037 controlled, an endpoint MUST NOT send more than one such packet in 4038 response to receiving an ack-eliciting packet. 4040 An endpoint MUST NOT send a non-ack-eliciting packet in response to a 4041 non-ack-eliciting packet, even if there are packet gaps that precede 4042 the received packet. This avoids an infinite feedback loop of 4043 acknowledgements, which could prevent the connection from ever 4044 becoming idle. Non-ack-eliciting packets are eventually acknowledged 4045 when the endpoint sends an ACK frame in response to other events. 4047 In order to assist loss detection at the sender, an endpoint SHOULD 4048 generate and send an ACK frame without delay when it receives an ack- 4049 eliciting packet either: 4051 * when the received packet has a packet number less than another 4052 ack-eliciting packet that has been received, or 4054 * when the packet has a packet number larger than the highest- 4055 numbered ack-eliciting packet that has been received and there are 4056 missing packets between that packet and this packet. 4058 Similarly, packets marked with the ECN Congestion Experienced (CE) 4059 codepoint in the IP header SHOULD be acknowledged immediately, to 4060 reduce the peer's response time to congestion events. 4062 The algorithms in [QUIC-RECOVERY] are expected to be resilient to 4063 receivers that do not follow the guidance offered above. However, an 4064 implementation should only deviate from these requirements after 4065 careful consideration of the performance implications of a change, 4066 for connections made by the endpoint and for other users of the 4067 network. 4069 An endpoint that is only sending ACK frames will not receive 4070 acknowledgments from its peer unless those acknowledgements are 4071 included in packets with ack-eliciting frames. An endpoint SHOULD 4072 send an ACK frame with other frames when there are new ack-eliciting 4073 packets to acknowledge. When only non-ack-eliciting packets need to 4074 be acknowledged, an endpoint MAY wait until an ack-eliciting packet 4075 has been received to include an ACK frame with outgoing frames. 4077 A receiver MUST NOT send an ack-eliciting frame in all packets that 4078 would otherwise be non-ack-eliciting, to avoid an infinite feedback 4079 loop of acknowledgements. 4081 13.2.2. Acknowledgement Frequency 4083 A receiver determines how frequently to send acknowledgements in 4084 response to ack-eliciting packets. This determination involves a 4085 trade-off. 4087 Endpoints rely on timely acknowledgment to detect loss; see Section 6 4088 of [QUIC-RECOVERY]. Window-based congestion controllers, such as the 4089 one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to 4090 manage their congestion window. In both cases, delaying 4091 acknowledgments can adversely affect performance. 4093 On the other hand, reducing the frequency of packets that carry only 4094 acknowledgements reduces packet transmission and processing cost at 4095 both endpoints. It can improve connection throughput on severely 4096 asymmetric links and reduce the volume of acknowledgment traffic 4097 using return path capacity; see Section 3 of [RFC3449]. 4099 A receiver SHOULD send an ACK frame after receiving at least two ack- 4100 eliciting packets. This recommendation is general in nature and 4101 consistent with recommendations for TCP endpoint behavior [RFC5681]. 4102 Knowledge of network conditions, knowledge of the peer's congestion 4103 controller, or further research and experimentation might suggest 4104 alternative acknowledgment strategies with better performance 4105 characteristics. 4107 A receiver MAY process multiple available packets before determining 4108 whether to send an ACK frame in response. 4110 13.2.3. Managing ACK Ranges 4112 When an ACK frame is sent, one or more ranges of acknowledged packets 4113 are included. Including acknowledgements for older packets reduces 4114 the chance of spurious retransmissions caused by losing previously 4115 sent ACK frames, at the cost of larger ACK frames. 4117 ACK frames SHOULD always acknowledge the most recently received 4118 packets, and the more out-of-order the packets are, the more 4119 important it is to send an updated ACK frame quickly, to prevent the 4120 peer from declaring a packet as lost and spuriously retransmitting 4121 the frames it contains. An ACK frame is expected to fit within a 4122 single QUIC packet. If it does not, then older ranges (those with 4123 the smallest packet numbers) are omitted. 4125 A receiver limits the number of ACK Ranges (Section 19.3.1) it 4126 remembers and sends in ACK frames, both to limit the size of ACK 4127 frames and to avoid resource exhaustion. After receiving 4128 acknowledgments for an ACK frame, the receiver SHOULD stop tracking 4129 those acknowledged ACK Ranges. Senders can expect acknowledgements 4130 for most packets, but QUIC does not guarantee receipt of an 4131 acknowledgment for every packet that the receiver processes. 4133 It is possible that retaining many ACK Ranges could cause an ACK 4134 frame to become too large. A receiver can discard unacknowledged ACK 4135 Ranges to limit ACK frame size, at the cost of increased 4136 retransmissions from the sender. This is necessary if an ACK frame 4137 would be too large to fit in a packet. Receivers MAY also limit ACK 4138 frame size further to preserve space for other frames or to limit the 4139 capacity that acknowledgments consume. 4141 A receiver MUST retain an ACK Range unless it can ensure that it will 4142 not subsequently accept packets with numbers in that range. 4143 Maintaining a minimum packet number that increases as ranges are 4144 discarded is one way to achieve this with minimal state. 4146 Receivers can discard all ACK Ranges, but they MUST retain the 4147 largest packet number that has been successfully processed as that is 4148 used to recover packet numbers from subsequent packets; see 4149 Section 17.1. 4151 A receiver SHOULD include an ACK Range containing the largest 4152 received packet number in every ACK frame. The Largest Acknowledged 4153 field is used in ECN validation at a sender and including a lower 4154 value than what was included in a previous ACK frame could cause ECN 4155 to be unnecessarily disabled; see Section 13.4.2. 4157 Section 13.2.4 describes an exemplary approach for determining what 4158 packets to acknowledge in each ACK frame. Though the goal of this 4159 algorithm is to generate an acknowledgment for every packet that is 4160 processed, it is still possible for acknowledgments to be lost. 4162 13.2.4. Limiting Ranges by Tracking ACK Frames 4164 When a packet containing an ACK frame is sent, the largest 4165 acknowledged in that frame may be saved. When a packet containing an 4166 ACK frame is acknowledged, the receiver can stop acknowledging 4167 packets less than or equal to the largest acknowledged in the sent 4168 ACK frame. 4170 A receiver that sends only non-ack-eliciting packets, such as ACK 4171 frames, might not receive an acknowledgement for a long period of 4172 time. This could cause the receiver to maintain state for a large 4173 number of ACK frames for a long period of time, and ACK frames it 4174 sends could be unnecessarily large. In such a case, a receiver could 4175 send a PING or other small ack-eliciting frame occasionally, such as 4176 once per round trip, to elicit an ACK from the peer. 4178 In cases without ACK frame loss, this algorithm allows for a minimum 4179 of 1 RTT of reordering. In cases with ACK frame loss and reordering, 4180 this approach does not guarantee that every acknowledgement is seen 4181 by the sender before it is no longer included in the ACK frame. 4182 Packets could be received out of order and all subsequent ACK frames 4183 containing them could be lost. In this case, the loss recovery 4184 algorithm could cause spurious retransmissions, but the sender will 4185 continue making forward progress. 4187 13.2.5. Measuring and Reporting Host Delay 4189 An endpoint measures the delays intentionally introduced between the 4190 time the packet with the largest packet number is received and the 4191 time an acknowledgment is sent. The endpoint encodes this 4192 acknowledgement delay in the ACK Delay field of an ACK frame; see 4193 Section 19.3. This allows the receiver of the ACK frame to adjust 4194 for any intentional delays, which is important for getting a better 4195 estimate of the path RTT when acknowledgments are delayed. 4197 A packet might be held in the OS kernel or elsewhere on the host 4198 before being processed. An endpoint MUST NOT include delays that it 4199 does not control when populating the ACK Delay field in an ACK frame. 4200 However, endpoints SHOULD include buffering delays caused by 4201 unavailability of decryption keys, since these delays can be large 4202 and are likely to be non-repeating. 4204 When the measured acknowledgement delay is larger than its 4205 max_ack_delay, an endpoint SHOULD report the measured delay. This 4206 information is especially useful during the handshake when delays 4207 might be large; see Section 13.2.1. 4209 13.2.6. ACK Frames and Packet Protection 4211 ACK frames MUST only be carried in a packet that has the same packet 4212 number space as the packet being acknowledged; see Section 12.1. For 4213 instance, packets that are protected with 1-RTT keys MUST be 4214 acknowledged in packets that are also protected with 1-RTT keys. 4216 Packets that a client sends with 0-RTT packet protection MUST be 4217 acknowledged by the server in packets protected by 1-RTT keys. This 4218 can mean that the client is unable to use these acknowledgments if 4219 the server cryptographic handshake messages are delayed or lost. 4220 Note that the same limitation applies to other data sent by the 4221 server protected by the 1-RTT keys. 4223 13.2.7. PADDING Frames Consume Congestion Window 4225 Packets containing PADDING frames are considered to be in flight for 4226 congestion control purposes [QUIC-RECOVERY]. Packets containing only 4227 PADDING frames therefore consume congestion window but do not 4228 generate acknowledgments that will open the congestion window. To 4229 avoid a deadlock, a sender SHOULD ensure that other frames are sent 4230 periodically in addition to PADDING frames to elicit acknowledgments 4231 from the receiver. 4233 13.3. Retransmission of Information 4235 QUIC packets that are determined to be lost are not retransmitted 4236 whole. The same applies to the frames that are contained within lost 4237 packets. Instead, the information that might be carried in frames is 4238 sent again in new frames as needed. 4240 New frames and packets are used to carry information that is 4241 determined to have been lost. In general, information is sent again 4242 when a packet containing that information is determined to be lost 4243 and sending ceases when a packet containing that information is 4244 acknowledged. 4246 * Data sent in CRYPTO frames is retransmitted according to the rules 4247 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 4248 CRYPTO frames for Initial and Handshake packets is discarded when 4249 keys for the corresponding packet number space are discarded. 4251 * Application data sent in STREAM frames is retransmitted in new 4252 STREAM frames unless the endpoint has sent a RESET_STREAM for that 4253 stream. Once an endpoint sends a RESET_STREAM frame, no further 4254 STREAM frames are needed. 4256 * ACK frames carry the most recent set of acknowledgements and the 4257 acknowledgement delay from the largest acknowledged packet, as 4258 described in Section 13.2.1. Delaying the transmission of packets 4259 containing ACK frames or resending old ACK frames can cause the 4260 peer to generate an inflated RTT sample or unnecessarily disable 4261 ECN. 4263 * Cancellation of stream transmission, as carried in a RESET_STREAM 4264 frame, is sent until acknowledged or until all stream data is 4265 acknowledged by the peer (that is, either the "Reset Recvd" or 4266 "Data Recvd" state is reached on the sending part of the stream). 4267 The content of a RESET_STREAM frame MUST NOT change when it is 4268 sent again. 4270 * Similarly, a request to cancel stream transmission, as encoded in 4271 a STOP_SENDING frame, is sent until the receiving part of the 4272 stream enters either a "Data Recvd" or "Reset Recvd" state; see 4273 Section 3.5. 4275 * Connection close signals, including packets that contain 4276 CONNECTION_CLOSE frames, are not sent again when packet loss is 4277 detected, but as described in Section 10. 4279 * The current connection maximum data is sent in MAX_DATA frames. 4280 An updated value is sent in a MAX_DATA frame if the packet 4281 containing the most recently sent MAX_DATA frame is declared lost, 4282 or when the endpoint decides to update the limit. Care is 4283 necessary to avoid sending this frame too often as the limit can 4284 increase frequently and cause an unnecessarily large number of 4285 MAX_DATA frames to be sent; see Section 4.2. 4287 * The current maximum stream data offset is sent in MAX_STREAM_DATA 4288 frames. Like MAX_DATA, an updated value is sent when the packet 4289 containing the most recent MAX_STREAM_DATA frame for a stream is 4290 lost or when the limit is updated, with care taken to prevent the 4291 frame from being sent too often. An endpoint SHOULD stop sending 4292 MAX_STREAM_DATA frames when the receiving part of the stream 4293 enters a "Size Known" state. 4295 * The limit on streams of a given type is sent in MAX_STREAMS 4296 frames. Like MAX_DATA, an updated value is sent when a packet 4297 containing the most recent MAX_STREAMS for a stream type frame is 4298 declared lost or when the limit is updated, with care taken to 4299 prevent the frame from being sent too often. 4301 * Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 4302 and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection 4303 scope, STREAM_DATA_BLOCKED frames have stream scope, and 4304 STREAMS_BLOCKED frames are scoped to a specific stream type. New 4305 frames are sent if packets containing the most recent frame for a 4306 scope is lost, but only while the endpoint is blocked on the 4307 corresponding limit. These frames always include the limit that 4308 is causing blocking at the time that they are transmitted. 4310 * A liveness or path validation check using PATH_CHALLENGE frames is 4311 sent periodically until a matching PATH_RESPONSE frame is received 4312 or until there is no remaining need for liveness or path 4313 validation checking. PATH_CHALLENGE frames include a different 4314 payload each time they are sent. 4316 * Responses to path validation using PATH_RESPONSE frames are sent 4317 just once. The peer is expected to send more PATH_CHALLENGE 4318 frames as necessary to evoke additional PATH_RESPONSE frames. 4320 * New connection IDs are sent in NEW_CONNECTION_ID frames and 4321 retransmitted if the packet containing them is lost. 4322 Retransmissions of this frame carry the same sequence number 4323 value. Likewise, retired connection IDs are sent in 4324 RETIRE_CONNECTION_ID frames and retransmitted if the packet 4325 containing them is lost. 4327 * NEW_TOKEN frames are retransmitted if the packet containing them 4328 is lost. No special support is made for detecting reordered and 4329 duplicated NEW_TOKEN frames other than a direct comparison of the 4330 frame contents. 4332 * PING and PADDING frames contain no information, so lost PING or 4333 PADDING frames do not require repair. 4335 * The HANDSHAKE_DONE frame MUST be retransmitted until it is 4336 acknowledged. 4338 Endpoints SHOULD prioritize retransmission of data over sending new 4339 data, unless priorities specified by the application indicate 4340 otherwise; see Section 2.3. 4342 Even though a sender is encouraged to assemble frames containing up- 4343 to-date information every time it sends a packet, it is not forbidden 4344 to retransmit copies of frames from lost packets. A sender that 4345 retransmits copies of frames needs to handle decreases in available 4346 payload size due to change in packet number length, connection ID 4347 length, and path MTU. A receiver MUST accept packets containing an 4348 outdated frame, such as a MAX_DATA frame carrying a smaller maximum 4349 data than one found in an older packet. 4351 A sender SHOULD avoid retransmitting information from packets once 4352 they are acknowledged. This includes packets that are acknowledged 4353 after being declared lost, which can happen in the presence of 4354 network reordering. Doing so requires senders to retain information 4355 about packets after they are declared lost. A sender can discard 4356 this information after a period of time elapses that adequately 4357 allows for reordering, such as a PTO (Section 6.2 of 4358 [QUIC-RECOVERY]), or on other events, such as reaching a memory 4359 limit. 4361 Upon detecting losses, a sender MUST take appropriate congestion 4362 control action. The details of loss detection and congestion control 4363 are described in [QUIC-RECOVERY]. 4365 13.4. Explicit Congestion Notification 4367 QUIC endpoints can use Explicit Congestion Notification (ECN) 4368 [RFC3168] to detect and respond to network congestion. ECN allows an 4369 endpoint to set an ECT codepoint in the ECN field of an IP packet. A 4370 network node can then indicate congestion by setting the CE codepoint 4371 in the ECN field instead of dropping the packet [RFC8087]. Endpoints 4372 react to reported congestion by reducing their sending rate in 4373 response, as described in [QUIC-RECOVERY]. 4375 To enable ECN, a sending QUIC endpoint first determines whether a 4376 path supports ECN marking and whether the peer reports the ECN values 4377 in received IP headers; see Section 13.4.2. 4379 13.4.1. Reporting ECN Counts 4381 Use of ECN requires the receiving endpoint to read the ECN field from 4382 an IP packet, which is not possible on all platforms. If an endpoint 4383 does not implement ECN support or does not have access to received 4384 ECN fields, it does not report ECN counts for packets it receives. 4386 Even if an endpoint does not set an ECT field on packets it sends, 4387 the endpoint MUST provide feedback about ECN markings it receives, if 4388 these are accessible. Failing to report the ECN counts will cause 4389 the sender to disable use of ECN for this connection. 4391 On receiving an IP packet with an ECT(0), ECT(1) or CE codepoint, an 4392 ECN-enabled endpoint accesses the ECN field and increases the 4393 corresponding ECT(0), ECT(1), or CE count. These ECN counts are 4394 included in subsequent ACK frames; see Section 13.2 and Section 19.3. 4396 Each packet number space maintains separate acknowledgement state and 4397 separate ECN counts. Coalesced QUIC packets (see Section 12.2) share 4398 the same IP header so the ECN counts are incremented once for each 4399 coalesced QUIC packet. 4401 For example, if one each of an Initial, Handshake, and 1-RTT QUIC 4402 packet are coalesced into a single UDP datagram, the ECN counts for 4403 all three packet number spaces will be incremented by one each, based 4404 on the ECN field of the single IP header. 4406 ECN counts are only incremented when QUIC packets from the received 4407 IP packet are processed. As such, duplicate QUIC packets are not 4408 processed and do not increase ECN counts; see Section 21.9 for 4409 relevant security concerns. 4411 13.4.2. ECN Validation 4413 It is possible for faulty network devices to corrupt or erroneously 4414 drop packets that carry a non-zero ECN codepoint. To ensure 4415 connectivity in the presence of such devices, an endpoint validates 4416 the ECN counts for each network path and disables use of ECN on that 4417 path if errors are detected. 4419 To perform ECN validation for a new path: 4421 * The endpoint sets an ECT(0) codepoint in the IP header of early 4422 outgoing packets sent on a new path to the peer ([RFC8311]). 4424 * The endpoint monitors whether all packets sent with an ECT 4425 codepoint are eventually deemed lost (Section 6 of 4426 [QUIC-RECOVERY]), indicating that ECN validation has failed. 4428 If an endpoint has cause to expect that IP packets with an ECT 4429 codepoint might be dropped by a faulty network element, the endpoint 4430 could set an ECT codepoint for only the first ten outgoing packets on 4431 a path, or for a period of three PTOs (see Section 6.2 of 4432 [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints 4433 are subsequently lost, it can disable marking on the assumption that 4434 the marking causes in loss. 4436 An endpoint thus attempts to use ECN and validates this for each new 4437 connection, when switching to a server's preferred address, and on 4438 active connection migration to a new path. Appendix B describes one 4439 possible algorithm. 4441 Other methods of probing paths for ECN support are possible, as are 4442 different marking strategies. Implementations MAY use other methods 4443 defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) 4444 codepoint need to perform ECN validation using the reported ECT(1) 4445 counts. 4447 13.4.2.1. Receiving ACK Frames with ECN Counts 4449 Erroneous application of CE markings by the network can result in 4450 degraded connection performance. An endpoint that receives an ACK 4451 frame with ECN counts therefore validates the counts before using 4452 them. It performs this validation by comparing newly received counts 4453 against those from the last successfully processed ACK frame. Any 4454 increase in the ECN counts is validated based on the ECN markings 4455 that were applied to packets that are newly acknowledged in the ACK 4456 frame. 4458 If an ACK frame newly acknowledges a packet that the endpoint sent 4459 with either the ECT(0) or ECT(1) codepoint set, ECN validation fails 4460 if the corresponding ECN counts are not present in the ACK frame. 4461 This check detects a network element that zeroes the ECN field or a 4462 peer that does not report ECN markings. 4464 ECN validation also fails if the sum of the increase in ECT(0) and 4465 ECN-CE counts is less than the number of newly acknowledged packets 4466 that were originally sent with an ECT(0) marking. Similarly, ECN 4467 validation fails if the sum of the increases to ECT(1) and ECN-CE 4468 counts is less than the number of newly acknowledged packets sent 4469 with an ECT(1) marking. These checks can detect remarking of ECN-CE 4470 markings by the network. 4472 An endpoint could miss acknowledgements for a packet when ACK frames 4473 are lost. It is therefore possible for the total increase in ECT(0), 4474 ECT(1), and ECN-CE counts to be greater than the number of packets 4475 that are newly acknowledged by an ACK frame. This is why ECN counts 4476 are permitted to be larger than the total number of packets that are 4477 acknowledged. 4479 Validating ECN counts from reordered ACK frames can result in 4480 failure. An endpoint MUST NOT fail ECN validation as a result of 4481 processing an ACK frame that does not increase the largest 4482 acknowledged packet number. 4484 ECN validation can fail if the received total count for either ECT(0) 4485 or ECT(1) exceeds the total number of packets sent with each 4486 corresponding ECT codepoint. In particular, validation will fail 4487 when an endpoint receives a non-zero ECN count corresponding to an 4488 ECT codepoint that it never applied. This check detects when packets 4489 are remarked to ECT(0) or ECT(1) in the network. 4491 13.4.2.2. ECN Validation Outcomes 4493 If validation fails, then the endpoint MUST disable ECN. It stops 4494 setting the ECT codepoint in IP packets that it sends, assuming that 4495 either the network path or the peer does not support ECN. 4497 Even if validation fails, an endpoint MAY revalidate ECN for the same 4498 path at any later time in the connection. An endpoint could continue 4499 to periodically attempt validation. 4501 Upon successful validation, an endpoint MAY continue to set an ECT 4502 codepoint in subsequent packets it sends, with the expectation that 4503 the path is ECN-capable. Network routing and path elements can 4504 however change mid-connection; an endpoint MUST disable ECN if 4505 validation later fails. 4507 14. Packet Size 4509 The QUIC packet size includes the QUIC header and protected payload, 4510 but not the UDP or IP headers. 4512 QUIC depends upon a minimum IP packet size of at least 1280 bytes. 4513 This is the IPv6 minimum size ([IPv6]) and is also supported by most 4514 modern IPv4 networks. Assuming the minimum IP header size, this 4515 results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 4516 bytes for IPv4. 4518 The QUIC maximum packet size is the largest size of QUIC packet that 4519 can be sent across a network path using a single packet. Any maximum 4520 packet size larger than 1200 bytes can be discovered using Path 4521 Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or 4522 Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see 4523 Section 14.3). 4525 Enforcement of the max_udp_payload_size transport parameter 4526 (Section 18.2) might act as an additional limit on the maximum packet 4527 size. A sender can avoid exceeding this limit, once the value is 4528 known. However, prior to learning the value of the transport 4529 parameter, endpoints risk datagrams being lost if they send packets 4530 larger than the smallest allowed maximum packet size of 1200 bytes. 4532 UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 4533 ([IPv4]), the DF bit MUST be set if possible, to prevent 4534 fragmentation on the path. 4536 14.1. Initial Packet Size 4538 A client MUST expand the payload of all UDP datagrams carrying 4539 Initial packets to at least the smallest allowed maximum packet size 4540 (1200 bytes) by adding PADDING frames to the Initial packet or by 4541 coalescing the Initial packet; see Section 12.2. Sending a UDP 4542 datagram of this size ensures that the network path from the client 4543 to the server supports a reasonable Path Maximum Transmission Unit 4544 (PMTU). This also helps reduce the amplitude of amplification 4545 attacks caused by server responses toward an unverified client 4546 address; see Section 8. 4548 Datagrams containing Initial packets MAY exceed 1200 bytes if the 4549 client believes that the network path and peer both support the size 4550 that it chooses. 4552 A server MUST discard an Initial packet that is carried in a UDP 4553 datagram with a payload that is less than the smallest allowed 4554 maximum packet size of 1200 bytes. A server MAY also immediately 4555 close the connection by sending a CONNECTION_CLOSE frame with an 4556 error code of PROTOCOL_VIOLATION; see Section 10.2.3. 4558 The server MUST also limit the number of bytes it sends before 4559 validating the address of the client; see Section 8. 4561 14.2. Path Maximum Transmission Unit 4563 The Path Maximum Transmission Unit (PMTU) is the maximum size of the 4564 entire IP packet including the IP header, UDP header, and UDP 4565 payload. The UDP payload includes the QUIC packet header, protected 4566 payload, and any authentication fields. The PMTU can depend on path 4567 characteristics, and can therefore change over time. The largest UDP 4568 payload an endpoint sends at any given time is referred to as the 4569 endpoint's maximum packet size. 4571 An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD 4572 (Section 14.2.1) to determine whether the path to a destination will 4573 support a desired maximum packet size without fragmentation. In the 4574 absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 4575 packets larger than the smallest allowed maximum packet size. 4577 Both DPLPMTUD and PMTUD send IP packets that are larger than the 4578 current maximum packet size, referred to as PMTU probes. All QUIC 4579 packets that are not sent in a PMTU probe SHOULD be sized to fit 4580 within the maximum packet size to avoid the packet being fragmented 4581 or dropped ([RFC8085]). 4583 If a QUIC endpoint determines that the PMTU between any pair of local 4584 and remote IP addresses has fallen below the smallest allowed maximum 4585 packet size of 1200 bytes, it MUST immediately cease sending QUIC 4586 packets, except for those in PMTU probes or those containing 4587 CONNECTION_CLOSE frames, on the affected path. An endpoint MAY 4588 terminate the connection if an alternative path cannot be found. 4590 Each pair of local and remote addresses could have a different PMTU. 4591 QUIC implementations that implement any kind of PMTU discovery 4592 therefore SHOULD maintain a maximum packet size for each combination 4593 of local and remote IP addresses. 4595 A QUIC implementation MAY be more conservative in computing the 4596 maximum packet size to allow for unknown tunnel overheads or IP 4597 header options/extensions. 4599 14.2.1. Handling of ICMP Messages by PMTUD 4601 Path Maximum Transmission Unit Discovery (PMTUD; [RFC1191], 4602 [RFC8201]) relies on reception of ICMP messages (e.g., IPv6 Packet 4603 Too Big messages) that indicate when a packet is dropped because it 4604 is larger than the local router MTU. DPLPMTUD can also optionally 4605 use these messages. This use of ICMP messages is potentially 4606 vulnerable to off-path attacks that successfully guess the addresses 4607 used on the path and reduce the PMTU to a bandwidth-inefficient 4608 value. 4610 An endpoint MUST ignore an ICMP message that claims the PMTU has 4611 decreased below the minimum QUIC packet size. 4613 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 4614 that the quoted packet should contain as much of the original packet 4615 as possible without exceeding the minimum MTU for the IP version. 4616 The size of the quoted packet can actually be smaller, or the 4617 information unintelligible, as described in Section 1.1 of 4618 [DPLPMTUD]. 4620 QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect 4621 from off-path injection as specified in [RFC8201] and Section 5.2 of 4622 [RFC8085]. This validation SHOULD use the quoted packet supplied in 4623 the payload of an ICMP message to associate the message with a 4624 corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). 4626 ICMP message validation MUST include matching IP addresses and UDP 4627 ports ([RFC8085]) and, when possible, connection IDs to an active 4628 QUIC session. The endpoint SHOULD ignore all ICMP messages that fail 4629 validation. 4631 An endpoint MUST NOT increase PMTU based on ICMP messages; see 4632 Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum 4633 packet size in response to ICMP messages MAY be provisional until 4634 QUIC's loss detection algorithm determines that the quoted packet has 4635 actually been lost. 4637 14.3. Datagram Packetization Layer PMTU Discovery 4639 Datagram Packetization Layer PMTU Discovery (DPLPMTUD; [DPLPMTUD]) 4640 relies on tracking loss or acknowledgment of QUIC packets that are 4641 carried in PMTU probes. PMTU probes for DPLPMTUD that use the 4642 PADDING frame implement "Probing using padding data", as defined in 4643 Section 4.1 of [DPLPMTUD]. 4645 Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 4646 of [DPLPMTUD]) to be consistent with the minimum QUIC packet size. 4647 The MIN_PLPMTU is the same as the BASE_PMTU. 4649 QUIC endpoints implementing DPLPMTUD maintain a maximum packet size 4650 (DPLPMTUD MPS) for each combination of local and remote IP addresses. 4652 14.3.1. DPLPMTUD and Initial Connectivity 4654 From the perspective of DPLPMTUD, QUIC is an acknowledged 4655 packetization layer (PL). A sender can therefore enter the DPLPMTUD 4656 BASE state when the QUIC connection handshake has been completed. 4658 14.3.2. Validating the QUIC Path with DPLPMTUD 4660 QUIC provides an acknowledged PL, therefore a sender does not 4661 implement the DPLPMTUD CONFIRMATION_TIMER while in the 4662 SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD]. 4664 14.3.3. Handling of ICMP Messages by DPLPMTUD 4666 An endpoint using DPLPMTUD requires the validation of any received 4667 ICMP Packet Too Big (PTB) message before using the PTB information, 4668 as defined in Section 4.6 of [DPLPMTUD]. In addition to UDP port 4669 validation, QUIC validates an ICMP message by using other PL 4670 information (e.g., validation of connection IDs in the quoted packet 4671 of any received ICMP message). 4673 The considerations for processing ICMP messages described in 4674 Section 14.2.1 also apply if these messages are used by DPLPMTUD. 4676 14.4. Sending QUIC PMTU Probes 4678 PMTU probes are ack-eliciting packets. 4680 Endpoints could limit the content of PMTU probes to PING and PADDING 4681 frames as packets that are larger than the current maximum packet 4682 size are more likely to be dropped by the network. Loss of a QUIC 4683 packet that is carried in a PMTU probe is therefore not a reliable 4684 indication of congestion and SHOULD NOT trigger a congestion control 4685 reaction; see Section 3, Bullet 7 of [DPLPMTUD]. However, PMTU 4686 probes consume congestion window, which could delay subsequent 4687 transmission by an application. 4689 14.4.1. PMTU Probes Containing Source Connection ID 4691 Endpoints that rely on the destination connection ID for routing 4692 incoming QUIC packets are likely to require that the connection ID be 4693 included in PMTU probes to route any resulting ICMP messages 4694 (Section 14.2.1) back to the correct endpoint. However, only long 4695 header packets (Section 17.2) contain the Source Connection ID field, 4696 and long header packets are not decrypted or acknowledged by the peer 4697 once the handshake is complete. 4699 One way to construct a PMTU probe is to coalesce (see Section 12.2) a 4700 packet with a long header, such as a Handshake or 0-RTT packet 4701 (Section 17.2), with a short header packet in a single UDP datagram. 4702 If the resulting PMTU probe reaches the endpoint, the packet with the 4703 long header will be ignored, but the short header packet will be 4704 acknowledged. If the PMTU probe causes an ICMP message to be sent, 4705 the first part of the probe will be quoted in that message. If the 4706 Source Connection ID field is within the quoted portion of the probe, 4707 that could be used for routing or validation of the ICMP message. 4709 Note: The purpose of using a packet with a long header is only to 4710 ensure that the quoted packet contained in the ICMP message 4711 contains a Source Connection ID field. This packet does not need 4712 to be a valid packet and it can be sent even if there is no 4713 current use for packets of that type. 4715 15. Versions 4717 QUIC versions are identified using a 32-bit unsigned number. 4719 The version 0x00000000 is reserved to represent version negotiation. 4720 This version of the specification is identified by the number 4721 0x00000001. 4723 Other versions of QUIC might have different properties from this 4724 version. The properties of QUIC that are guaranteed to be consistent 4725 across all versions of the protocol are described in 4726 [QUIC-INVARIANTS]. 4728 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 4729 protocol, as described in [QUIC-TLS]. 4731 Versions with the most significant 16 bits of the version number 4732 cleared are reserved for use in future IETF consensus documents. 4734 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 4735 forcing version negotiation to be exercised. That is, any version 4736 number where the low four bits of all bytes is 1010 (in binary). A 4737 client or server MAY advertise support for any of these reserved 4738 versions. 4740 Reserved version numbers will never represent a real protocol; a 4741 client MAY use one of these version numbers with the expectation that 4742 the server will initiate version negotiation; a server MAY advertise 4743 support for one of these versions and can expect that clients ignore 4744 the value. 4746 [[RFC editor: please remove the remainder of this section before 4747 publication.]] 4749 The version number for the final version of this specification 4750 (0x00000001), is reserved for the version of the protocol that is 4751 published as an RFC. 4753 Version numbers used to identify IETF drafts are created by adding 4754 the draft number to 0xff000000. For example, draft-ietf-quic- 4755 transport-13 would be identified as 0xff00000d. 4757 Implementors are encouraged to register version numbers of QUIC that 4758 they are using for private experimentation on the GitHub wiki at 4759 https://github.com/quicwg/base-drafts/wiki/QUIC-Versions. 4761 16. Variable-Length Integer Encoding 4763 QUIC packets and frames commonly use a variable-length encoding for 4764 non-negative integer values. This encoding ensures that smaller 4765 integer values need fewer bytes to encode. 4767 The QUIC variable-length integer encoding reserves the two most 4768 significant bits of the first byte to encode the base 2 logarithm of 4769 the integer encoding length in bytes. The integer value is encoded 4770 on the remaining bits, in network byte order. 4772 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 4773 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 4774 the encoding properties. 4776 +======+========+=============+=======================+ 4777 | 2Bit | Length | Usable Bits | Range | 4778 +======+========+=============+=======================+ 4779 | 00 | 1 | 6 | 0-63 | 4780 +------+--------+-------------+-----------------------+ 4781 | 01 | 2 | 14 | 0-16383 | 4782 +------+--------+-------------+-----------------------+ 4783 | 10 | 4 | 30 | 0-1073741823 | 4784 +------+--------+-------------+-----------------------+ 4785 | 11 | 8 | 62 | 0-4611686018427387903 | 4786 +------+--------+-------------+-----------------------+ 4788 Table 4: Summary of Integer Encodings 4790 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 4791 hexadecimal) decodes to the decimal value 151288809941952652; the 4792 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 4793 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 4794 (as does the two byte sequence 40 25). 4796 Versions (Section 15) and packet numbers sent in the header 4797 (Section 17.1) are described using integers, but do not use this 4798 encoding. 4800 17. Packet Formats 4802 All numeric values are encoded in network byte order (that is, big- 4803 endian) and all field sizes are in bits. Hexadecimal notation is 4804 used for describing the value of fields. 4806 17.1. Packet Number Encoding and Decoding 4808 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). 4809 When present in long or short packet headers, they are encoded in 1 4810 to 4 bytes. The number of bits required to represent the packet 4811 number is reduced by including only the least significant bits of the 4812 packet number. 4814 The encoded packet number is protected as described in Section 5.4 of 4815 [QUIC-TLS]. 4817 Prior to receiving an acknowledgement for a packet number space, the 4818 full packet number MUST be included; it is not to be truncated as 4819 described below. 4821 After an acknowledgement is received for a packet number space, the 4822 sender MUST use a packet number size able to represent more than 4823 twice as large a range than the difference between the largest 4824 acknowledged packet and packet number being sent. A peer receiving 4825 the packet will then correctly decode the packet number, unless the 4826 packet is delayed in transit such that it arrives after many higher- 4827 numbered packets have been received. An endpoint SHOULD use a large 4828 enough packet number encoding to allow the packet number to be 4829 recovered even if the packet arrives after packets that are sent 4830 afterwards. 4832 As a result, the size of the packet number encoding is at least one 4833 bit more than the base-2 logarithm of the number of contiguous 4834 unacknowledged packet numbers, including the new packet. 4836 For example, if an endpoint has received an acknowledgment for packet 4837 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 4838 packet number encoding with 16 bits or more; whereas the 24-bit 4839 packet number encoding is needed to send a packet with a number of 4840 0xace8fe. 4842 At a receiver, protection of the packet number is removed prior to 4843 recovering the full packet number. The full packet number is then 4844 reconstructed based on the number of significant bits present, the 4845 value of those bits, and the largest packet number received on a 4846 successfully authenticated packet. Recovering the full packet number 4847 is necessary to successfully remove packet protection. 4849 Once header protection is removed, the packet number is decoded by 4850 finding the packet number value that is closest to the next expected 4851 packet. The next expected packet is the highest received packet 4852 number plus one. For example, if the highest successfully 4853 authenticated packet had a packet number of 0xa82f30ea, then a packet 4854 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 4855 Example pseudo-code for packet number decoding can be found in 4856 Appendix A. 4858 17.2. Long Header Packets 4859 Long Header Packet { 4860 Header Form (1) = 1, 4861 Fixed Bit (1) = 1, 4862 Long Packet Type (2), 4863 Type-Specific Bits (4), 4864 Version (32), 4865 Destination Connection ID Length (8), 4866 Destination Connection ID (0..160), 4867 Source Connection ID Length (8), 4868 Source Connection ID (0..160), 4869 } 4871 Figure 13: Long Header Packet Format 4873 Long headers are used for packets that are sent prior to the 4874 establishment of 1-RTT keys. Once 1-RTT keys are available, a sender 4875 switches to sending packets using the short header (Section 17.3). 4876 The long form allows for special packets - such as the Version 4877 Negotiation packet - to be represented in this uniform fixed-length 4878 packet format. Packets that use the long header contain the 4879 following fields: 4881 Header Form: The most significant bit (0x80) of byte 0 (the first 4882 byte) is set to 1 for long headers. 4884 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4885 containing a zero value for this bit are not valid packets in this 4886 version and MUST be discarded. 4888 Long Packet Type: The next two bits (those with a mask of 0x30) of 4889 byte 0 contain a packet type. Packet types are listed in Table 5. 4891 Type-Specific Bits: The lower four bits (those with a mask of 0x0f) 4892 of byte 0 are type-specific. 4894 Version: The QUIC Version is a 32-bit field that follows the first 4895 byte. This field indicates the version of QUIC that is in use and 4896 determines how the rest of the protocol fields are interpreted. 4898 Destination Connection ID Length: The byte following the version 4899 contains the length in bytes of the Destination Connection ID 4900 field that follows it. This length is encoded as an 8-bit 4901 unsigned integer. In QUIC version 1, this value MUST NOT exceed 4902 20. Endpoints that receive a version 1 long header with a value 4903 larger than 20 MUST drop the packet. In order to properly form a 4904 Version Negotiation packet, servers SHOULD be able to read longer 4905 connection IDs from other QUIC versions. 4907 Destination Connection ID: The Destination Connection ID field 4908 follows the Destination Connection ID Length field, which 4909 indicates the length of this field. Section 7.2 describes the use 4910 of this field in more detail. 4912 Source Connection ID Length: The byte following the Destination 4913 Connection ID contains the length in bytes of the Source 4914 Connection ID field that follows it. This length is encoded as a 4915 8-bit unsigned integer. In QUIC version 1, this value MUST NOT 4916 exceed 20 bytes. Endpoints that receive a version 1 long header 4917 with a value larger than 20 MUST drop the packet. In order to 4918 properly form a Version Negotiation packet, servers SHOULD be able 4919 to read longer connection IDs from other QUIC versions. 4921 Source Connection ID: The Source Connection ID field follows the 4922 Source Connection ID Length field, which indicates the length of 4923 this field. Section 7.2 describes the use of this field in more 4924 detail. 4926 In this version of QUIC, the following packet types with the long 4927 header are defined: 4929 +======+===========+================+ 4930 | Type | Name | Section | 4931 +======+===========+================+ 4932 | 0x0 | Initial | Section 17.2.2 | 4933 +------+-----------+----------------+ 4934 | 0x1 | 0-RTT | Section 17.2.3 | 4935 +------+-----------+----------------+ 4936 | 0x2 | Handshake | Section 17.2.4 | 4937 +------+-----------+----------------+ 4938 | 0x3 | Retry | Section 17.2.5 | 4939 +------+-----------+----------------+ 4941 Table 5: Long Header Packet Types 4943 The header form bit, Destination and Source Connection ID lengths, 4944 Destination and Source Connection ID fields, and Version fields of a 4945 long header packet are version-independent. The other fields in the 4946 first byte are version-specific. See [QUIC-INVARIANTS] for details 4947 on how packets from different versions of QUIC are interpreted. 4949 The interpretation of the fields and the payload are specific to a 4950 version and packet type. While type-specific semantics for this 4951 version are described in the following sections, several long-header 4952 packets in this version of QUIC contain these additional fields: 4954 Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are 4955 reserved across multiple packet types. These bits are protected 4956 using header protection; see Section 5.4 of [QUIC-TLS]. The value 4957 included prior to protection MUST be set to 0. An endpoint MUST 4958 treat receipt of a packet that has a non-zero value for these bits 4959 after removing both packet and header protection as a connection 4960 error of type PROTOCOL_VIOLATION. Discarding such a packet after 4961 only removing header protection can expose the endpoint to 4962 attacks; see Section 9.3 of [QUIC-TLS]. 4964 Packet Number Length: In packet types that contain a Packet Number 4965 field, the least significant two bits (those with a mask of 0x03) 4966 of byte 0 contain the length of the packet number, encoded as an 4967 unsigned, two-bit integer that is one less than the length of the 4968 packet number field in bytes. That is, the length of the packet 4969 number field is the value of this field, plus one. These bits are 4970 protected using header protection; see Section 5.4 of [QUIC-TLS]. 4972 Length: The length of the remainder of the packet (that is, the 4973 Packet Number and Payload fields) in bytes, encoded as a variable- 4974 length integer (Section 16). 4976 Packet Number: The packet number field is 1 to 4 bytes long. The 4977 packet number is protected using header protection; see 4978 Section 5.4 of [QUIC-TLS]. The length of the packet number field 4979 is encoded in the Packet Number Length bits of byte 0; see above. 4981 17.2.1. Version Negotiation Packet 4983 A Version Negotiation packet is inherently not version-specific. 4984 Upon receipt by a client, it will be identified as a Version 4985 Negotiation packet based on the Version field having a value of 0. 4987 The Version Negotiation packet is a response to a client packet that 4988 contains a version that is not supported by the server, and is only 4989 sent by servers. 4991 The layout of a Version Negotiation packet is: 4993 Version Negotiation Packet { 4994 Header Form (1) = 1, 4995 Unused (7), 4996 Version (32) = 0, 4997 Destination Connection ID Length (8), 4998 Destination Connection ID (0..2040), 4999 Source Connection ID Length (8), 5000 Source Connection ID (0..2040), 5001 Supported Version (32) ..., 5002 } 5003 Figure 14: Version Negotiation Packet 5005 The value in the Unused field is selected randomly by the server. 5006 Clients MUST ignore the value of this field. Servers SHOULD set the 5007 most significant bit of this field (0x40) to 1 so that Version 5008 Negotiation packets appear to have the Fixed Bit field. 5010 The Version field of a Version Negotiation packet MUST be set to 5011 0x00000000. 5013 The server MUST include the value from the Source Connection ID field 5014 of the packet it receives in the Destination Connection ID field. 5015 The value for Source Connection ID MUST be copied from the 5016 Destination Connection ID of the received packet, which is initially 5017 randomly selected by a client. Echoing both connection IDs gives 5018 clients some assurance that the server received the packet and that 5019 the Version Negotiation packet was not generated by an off-path 5020 attacker. 5022 As future versions of QUIC may support Connection IDs larger than the 5023 version 1 limit, Version Negotiation packets could carry Connection 5024 IDs that are longer than 20 bytes. 5026 The remainder of the Version Negotiation packet is a list of 32-bit 5027 versions that the server supports. 5029 A Version Negotiation packet is not acknowledged. It is only sent in 5030 response to a packet that indicates an unsupported version; see 5031 Section 5.2.2. 5033 The Version Negotiation packet does not include the Packet Number and 5034 Length fields present in other packets that use the long header form. 5035 Consequently, a Version Negotiation packet consumes an entire UDP 5036 datagram. 5038 A server MUST NOT send more than one Version Negotiation packet in 5039 response to a single UDP datagram. 5041 See Section 6 for a description of the version negotiation process. 5043 17.2.2. Initial Packet 5045 An Initial packet uses long headers with a type value of 0x0. It 5046 carries the first CRYPTO frames sent by the client and server to 5047 perform key exchange, and carries ACKs in either direction. 5049 Initial Packet { 5050 Header Form (1) = 1, 5051 Fixed Bit (1) = 1, 5052 Long Packet Type (2) = 0, 5053 Reserved Bits (2), 5054 Packet Number Length (2), 5055 Version (32), 5056 Destination Connection ID Length (8), 5057 Destination Connection ID (0..160), 5058 Source Connection ID Length (8), 5059 Source Connection ID (0..160), 5060 Token Length (i), 5061 Token (..), 5062 Length (i), 5063 Packet Number (8..32), 5064 Packet Payload (..), 5065 } 5067 Figure 15: Initial Packet 5069 The Initial packet contains a long header as well as the Length and 5070 Packet Number fields; see Section 17.2. The first byte contains the 5071 Reserved and Packet Number Length bits; see also Section 17.2. 5072 Between the Source Connection ID and Length fields, there are two 5073 additional fields specific to the Initial packet. 5075 Token Length: A variable-length integer specifying the length of the 5076 Token field, in bytes. This value is zero if no token is present. 5077 Initial packets sent by the server MUST set the Token Length field 5078 to zero; clients that receive an Initial packet with a non-zero 5079 Token Length field MUST either discard the packet or generate a 5080 connection error of type PROTOCOL_VIOLATION. 5082 Token: The value of the token that was previously provided in a 5083 Retry packet or NEW_TOKEN frame; see Section 8.1. 5085 Packet Payload: The payload of the packet. 5087 In order to prevent tampering by version-unaware middleboxes, Initial 5088 packets are protected with connection- and version-specific keys 5089 (Initial keys) as described in [QUIC-TLS]. This protection does not 5090 provide confidentiality or integrity against on-path attackers, but 5091 provides some level of protection against off-path attackers. 5093 The client and server use the Initial packet type for any packet that 5094 contains an initial cryptographic handshake message. This includes 5095 all cases where a new packet containing the initial cryptographic 5096 message needs to be created, such as the packets sent after receiving 5097 a Retry packet (Section 17.2.5). 5099 A server sends its first Initial packet in response to a client 5100 Initial. A server may send multiple Initial packets. The 5101 cryptographic key exchange could require multiple round trips or 5102 retransmissions of this data. 5104 The payload of an Initial packet includes a CRYPTO frame (or frames) 5105 containing a cryptographic handshake message, ACK frames, or both. 5106 PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also 5107 permitted. An endpoint that receives an Initial packet containing 5108 other frames can either discard the packet as spurious or treat it as 5109 a connection error. 5111 The first packet sent by a client always includes a CRYPTO frame that 5112 contains the start or all of the first cryptographic handshake 5113 message. The first CRYPTO frame sent always begins at an offset of 5114 0; see Section 7. 5116 Note that if the server sends a HelloRetryRequest, the client will 5117 send another series of Initial packets. These Initial packets will 5118 continue the cryptographic handshake and will contain CRYPTO frames 5119 starting at an offset matching the size of the CRYPTO frames sent in 5120 the first flight of Initial packets. 5122 17.2.2.1. Abandoning Initial Packets 5124 A client stops both sending and processing Initial packets when it 5125 sends its first Handshake packet. A server stops sending and 5126 processing Initial packets when it receives its first Handshake 5127 packet. Though packets might still be in flight or awaiting 5128 acknowledgment, no further Initial packets need to be exchanged 5129 beyond this point. Initial packet protection keys are discarded (see 5130 Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and 5131 congestion control state; see Section 6.4 of [QUIC-RECOVERY]. 5133 Any data in CRYPTO frames is discarded - and no longer retransmitted 5134 - when Initial keys are discarded. 5136 17.2.3. 0-RTT 5138 A 0-RTT packet uses long headers with a type value of 0x1, followed 5139 by the Length and Packet Number fields; see Section 17.2. The first 5140 byte contains the Reserved and Packet Number Length bits; see 5141 Section 17.2. A 0-RTT packet is used to carry "early" data from the 5142 client to the server as part of the first flight, prior to handshake 5143 completion. As part of the TLS handshake, the server can accept or 5144 reject this early data. 5146 See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its 5147 limitations. 5149 0-RTT Packet { 5150 Header Form (1) = 1, 5151 Fixed Bit (1) = 1, 5152 Long Packet Type (2) = 1, 5153 Reserved Bits (2), 5154 Packet Number Length (2), 5155 Version (32), 5156 Destination Connection ID Length (8), 5157 Destination Connection ID (0..160), 5158 Source Connection ID Length (8), 5159 Source Connection ID (0..160), 5160 Length (i), 5161 Packet Number (8..32), 5162 Packet Payload (..), 5163 } 5165 Figure 16: 0-RTT Packet 5167 Packet numbers for 0-RTT protected packets use the same space as 5168 1-RTT protected packets. 5170 After a client receives a Retry packet, 0-RTT packets are likely to 5171 have been lost or discarded by the server. A client SHOULD attempt 5172 to resend data in 0-RTT packets after it sends a new Initial packet. 5173 New packet numbers MUST be used for any new packets that are sent; as 5174 described in Section 17.2.5.3, reusing packet numbers could 5175 compromise packet protection. 5177 A client only receives acknowledgments for its 0-RTT packets once the 5178 handshake is complete, as defined Section 4.1.1 of [QUIC-TLS]. 5180 A client MUST NOT send 0-RTT packets once it starts processing 1-RTT 5181 packets from the server. This means that 0-RTT packets cannot 5182 contain any response to frames from 1-RTT packets. For instance, a 5183 client cannot send an ACK frame in a 0-RTT packet, because that can 5184 only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT 5185 packet MUST be carried in a 1-RTT packet. 5187 A server SHOULD treat a violation of remembered limits 5188 (Section 7.4.1) as a connection error of an appropriate type (for 5189 instance, a FLOW_CONTROL_ERROR for exceeding stream data limits). 5191 17.2.4. Handshake Packet 5193 A Handshake packet uses long headers with a type value of 0x2, 5194 followed by the Length and Packet Number fields; see Section 17.2. 5195 The first byte contains the Reserved and Packet Number Length bits; 5196 see Section 17.2. It is used to carry cryptographic handshake 5197 messages and acknowledgments from the server and client. 5199 Handshake Packet { 5200 Header Form (1) = 1, 5201 Fixed Bit (1) = 1, 5202 Long Packet Type (2) = 2, 5203 Reserved Bits (2), 5204 Packet Number Length (2), 5205 Version (32), 5206 Destination Connection ID Length (8), 5207 Destination Connection ID (0..160), 5208 Source Connection ID Length (8), 5209 Source Connection ID (0..160), 5210 Length (i), 5211 Packet Number (8..32), 5212 Packet Payload (..), 5213 } 5215 Figure 17: Handshake Protected Packet 5217 Once a client has received a Handshake packet from a server, it uses 5218 Handshake packets to send subsequent cryptographic handshake messages 5219 and acknowledgments to the server. 5221 The Destination Connection ID field in a Handshake packet contains a 5222 connection ID that is chosen by the recipient of the packet; the 5223 Source Connection ID includes the connection ID that the sender of 5224 the packet wishes to use; see Section 7.2. 5226 Handshake packets are their own packet number space, and thus the 5227 first Handshake packet sent by a server contains a packet number of 5228 0. 5230 The payload of this packet contains CRYPTO frames and could contain 5231 PING, PADDING, or ACK frames. Handshake packets MAY contain 5232 CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt 5233 of Handshake packets with other frames as a connection error. 5235 Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames 5236 for Handshake packets is discarded - and no longer retransmitted - 5237 when Handshake protection keys are discarded. 5239 17.2.5. Retry Packet 5241 A Retry packet uses a long packet header with a type value of 0x3. 5242 It carries an address validation token created by the server. It is 5243 used by a server that wishes to perform a retry; see Section 8.1. 5245 Retry Packet { 5246 Header Form (1) = 1, 5247 Fixed Bit (1) = 1, 5248 Long Packet Type (2) = 3, 5249 Unused (4), 5250 Version (32), 5251 Destination Connection ID Length (8), 5252 Destination Connection ID (0..160), 5253 Source Connection ID Length (8), 5254 Source Connection ID (0..160), 5255 Retry Token (..), 5256 Retry Integrity Tag (128), 5257 } 5259 Figure 18: Retry Packet 5261 A Retry packet (shown in Figure 18) does not contain any protected 5262 fields. The value in the Unused field is set to an arbitrary value 5263 by the server; a client MUST ignore these bits. In addition to the 5264 fields from the long header, it contains these additional fields: 5266 Retry Token: An opaque token that the server can use to validate the 5267 client's address. 5269 Retry Integrity Tag: See the Retry Packet Integrity section of 5270 [QUIC-TLS]. 5272 17.2.5.1. Sending a Retry Packet 5274 The server populates the Destination Connection ID with the 5275 connection ID that the client included in the Source Connection ID of 5276 the Initial packet. 5278 The server includes a connection ID of its choice in the Source 5279 Connection ID field. This value MUST NOT be equal to the Destination 5280 Connection ID field of the packet sent by the client. A client MUST 5281 discard a Retry packet that contains a Source Connection ID field 5282 that is identical to the Destination Connection ID field of its 5283 Initial packet. The client MUST use the value from the Source 5284 Connection ID field of the Retry packet in the Destination Connection 5285 ID field of subsequent packets that it sends. 5287 A server MAY send Retry packets in response to Initial and 0-RTT 5288 packets. A server can either discard or buffer 0-RTT packets that it 5289 receives. A server can send multiple Retry packets as it receives 5290 Initial or 0-RTT packets. A server MUST NOT send more than one Retry 5291 packet in response to a single UDP datagram. 5293 17.2.5.2. Handling a Retry Packet 5295 A client MUST accept and process at most one Retry packet for each 5296 connection attempt. After the client has received and processed an 5297 Initial or Retry packet from the server, it MUST discard any 5298 subsequent Retry packets that it receives. 5300 Clients MUST discard Retry packets that have a Retry Integrity Tag 5301 that cannot be validated; see the Retry Packet Integrity section of 5302 [QUIC-TLS]. This diminishes an off-path attacker's ability to inject 5303 a Retry packet and protects against accidental corruption of Retry 5304 packets. A client MUST discard a Retry packet with a zero-length 5305 Retry Token field. 5307 The client responds to a Retry packet with an Initial packet that 5308 includes the provided Retry Token to continue connection 5309 establishment. 5311 A client sets the Destination Connection ID field of this Initial 5312 packet to the value from the Source Connection ID in the Retry 5313 packet. Changing Destination Connection ID also results in a change 5314 to the keys used to protect the Initial packet. It also sets the 5315 Token field to the token provided in the Retry. The client MUST NOT 5316 change the Source Connection ID because the server could include the 5317 connection ID as part of its token validation logic; see 5318 Section 8.1.4. 5320 A Retry packet does not include a packet number and cannot be 5321 explicitly acknowledged by a client. 5323 17.2.5.3. Continuing a Handshake After Retry 5325 Subsequent Initial packets from the client include the connection ID 5326 and token values from the Retry packet. The client copies the Source 5327 Connection ID field from the Retry packet to the Destination 5328 Connection ID field and uses this value until an Initial packet with 5329 an updated value is received; see Section 7.2. The value of the 5330 Token field is copied to all subsequent Initial packets; see 5331 Section 8.1.2. 5333 Other than updating the Destination Connection ID and Token fields, 5334 the Initial packet sent by the client is subject to the same 5335 restrictions as the first Initial packet. A client MUST use the same 5336 cryptographic handshake message it included in this packet. A server 5337 MAY treat a packet that contains a different cryptographic handshake 5338 message as a connection error or discard it. 5340 A client MAY attempt 0-RTT after receiving a Retry packet by sending 5341 0-RTT packets to the connection ID provided by the server. A client 5342 MUST NOT change the cryptographic handshake message it sends in 5343 response to receiving a Retry. 5345 A client MUST NOT reset the packet number for any packet number space 5346 after processing a Retry packet. In particular, 0-RTT packets 5347 contain confidential information that will most likely be 5348 retransmitted on receiving a Retry packet. The keys used to protect 5349 these new 0-RTT packets will not change as a result of responding to 5350 a Retry packet. However, the data sent in these packets could be 5351 different than what was sent earlier. Sending these new packets with 5352 the same packet number is likely to compromise the packet protection 5353 for those packets because the same key and nonce could be used to 5354 protect different content. A server MAY abort the connection if it 5355 detects that the client reset the packet number. 5357 The connection IDs used on Initial and Retry packets exchanged 5358 between client and server are copied to the transport parameters and 5359 validated as described in Section 7.3. 5361 17.3. Short Header Packets 5363 This version of QUIC defines a single packet type that uses the short 5364 packet header. 5366 Short Header Packet { 5367 Header Form (1) = 0, 5368 Fixed Bit (1) = 1, 5369 Spin Bit (1), 5370 Reserved Bits (2), 5371 Key Phase (1), 5372 Packet Number Length (2), 5373 Destination Connection ID (0..160), 5374 Packet Number (8..32), 5375 Packet Payload (..), 5376 } 5378 Figure 19: Short Header Packet Format 5380 The short header can be used after the version and 1-RTT keys are 5381 negotiated. Packets that use the short header contain the following 5382 fields: 5384 Header Form: The most significant bit (0x80) of byte 0 is set to 0 5385 for the short header. 5387 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 5388 containing a zero value for this bit are not valid packets in this 5389 version and MUST be discarded. 5391 Spin Bit: The third most significant bit (0x20) of byte 0 is the 5392 latency spin bit, set as described in Section 17.3.1. 5394 Reserved Bits: The next two bits (those with a mask of 0x18) of byte 5395 0 are reserved. These bits are protected using header protection; 5396 see Section 5.4 of [QUIC-TLS]. The value included prior to 5397 protection MUST be set to 0. An endpoint MUST treat receipt of a 5398 packet that has a non-zero value for these bits, after removing 5399 both packet and header protection, as a connection error of type 5400 PROTOCOL_VIOLATION. Discarding such a packet after only removing 5401 header protection can expose the endpoint to attacks; see 5402 Section 9.3 of [QUIC-TLS]. 5404 Key Phase: The next bit (0x04) of byte 0 indicates the key phase, 5405 which allows a recipient of a packet to identify the packet 5406 protection keys that are used to protect the packet. See 5407 [QUIC-TLS] for details. This bit is protected using header 5408 protection; see Section 5.4 of [QUIC-TLS]. 5410 Packet Number Length: The least significant two bits (those with a 5411 mask of 0x03) of byte 0 contain the length of the packet number, 5412 encoded as an unsigned, two-bit integer that is one less than the 5413 length of the packet number field in bytes. That is, the length 5414 of the packet number field is the value of this field, plus one. 5415 These bits are protected using header protection; see Section 5.4 5416 of [QUIC-TLS]. 5418 Destination Connection ID: The Destination Connection ID is a 5419 connection ID that is chosen by the intended recipient of the 5420 packet. See Section 5.1 for more details. 5422 Packet Number: The packet number field is 1 to 4 bytes long. The 5423 packet number has confidentiality protection separate from packet 5424 protection, as described in Section 5.4 of [QUIC-TLS]. The length 5425 of the packet number field is encoded in Packet Number Length 5426 field. See Section 17.1 for details. 5428 Packet Payload: Packets with a short header always include a 1-RTT 5429 protected payload. 5431 The header form bit and the connection ID field of a short header 5432 packet are version-independent. The remaining fields are specific to 5433 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 5434 packets from different versions of QUIC are interpreted. 5436 17.3.1. Latency Spin Bit 5438 The latency spin bit enables passive latency monitoring from 5439 observation points on the network path throughout the duration of a 5440 connection. The spin bit is only present in the short packet header, 5441 since it is possible to measure the initial RTT of a connection by 5442 observing the handshake. Therefore, the spin bit is available after 5443 version negotiation and connection establishment are completed. On- 5444 path measurement and use of the latency spin bit is further discussed 5445 in [QUIC-MANAGEABILITY]. 5447 The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that 5448 chooses to support the spin bit MUST implement it as specified in 5449 this section. 5451 Each endpoint unilaterally decides if the spin bit is enabled or 5452 disabled for a connection. Implementations MUST allow administrators 5453 of clients and servers to disable the spin bit either globally or on 5454 a per-connection basis. Even when the spin bit is not disabled by 5455 the administrator, endpoints MUST disable their use of the spin bit 5456 for a random selection of at least one in every 16 network paths, or 5457 for one in every 16 connection IDs. As each endpoint disables the 5458 spin bit independently, this ensures that the spin bit signal is 5459 disabled on approximately one in eight network paths. 5461 When the spin bit is disabled, endpoints MAY set the spin bit to any 5462 value, and MUST ignore any incoming value. It is RECOMMENDED that 5463 endpoints set the spin bit to a random value either chosen 5464 independently for each packet or chosen independently for each 5465 connection ID. 5467 If the spin bit is enabled for the connection, the endpoint maintains 5468 a spin value for each network path and sets the spin bit in the short 5469 header to the currently stored value when a packet with a short 5470 header is sent on that path. The spin value is initialized to 0 in 5471 the endpoint for each network path. Each endpoint also remembers the 5472 highest packet number seen from its peer on each path. 5474 When a server receives a short header packet that increases the 5475 highest packet number seen by the server from the client on a given 5476 network path, it sets the spin value for that path to be equal to the 5477 spin bit in the received packet. 5479 When a client receives a short header packet that increases the 5480 highest packet number seen by the client from the server on a given 5481 network path, it sets the spin value for that path to the inverse of 5482 the spin bit in the received packet. 5484 An endpoint resets the spin value for a network path to zero when 5485 changing the connection ID being used on that network path. 5487 With this mechanism, the server reflects the spin value received, 5488 while the client 'spins' it after one RTT. On-path observers can 5489 measure the time between two spin bit toggle events to estimate the 5490 end-to-end RTT of a connection. 5492 18. Transport Parameter Encoding 5494 The extension_data field of the quic_transport_parameters extension 5495 defined in [QUIC-TLS] contains the QUIC transport parameters. They 5496 are encoded as a sequence of transport parameters, as shown in 5497 Figure 20: 5499 Transport Parameters { 5500 Transport Parameter (..) ..., 5501 } 5503 Figure 20: Sequence of Transport Parameters 5505 Each transport parameter is encoded as an (identifier, length, value) 5506 tuple, as shown in Figure 21: 5508 Transport Parameter { 5509 Transport Parameter ID (i), 5510 Transport Parameter Length (i), 5511 Transport Parameter Value (..), 5512 } 5514 Figure 21: Transport Parameter Encoding 5516 The Transport Parameter Length field contains the length of the 5517 Transport Parameter Value field. 5519 QUIC encodes transport parameters into a sequence of bytes, which is 5520 then included in the cryptographic handshake. 5522 18.1. Reserved Transport Parameters 5524 Transport parameters with an identifier of the form "31 * N + 27" for 5525 integer values of N are reserved to exercise the requirement that 5526 unknown transport parameters be ignored. These transport parameters 5527 have no semantics, and may carry arbitrary values. 5529 18.2. Transport Parameter Definitions 5531 This section details the transport parameters defined in this 5532 document. 5534 Many transport parameters listed here have integer values. Those 5535 transport parameters that are identified as integers use a variable- 5536 length integer encoding; see Section 16. Transport parameters have a 5537 default value of 0 if the transport parameter is absent unless 5538 otherwise stated. 5540 The following transport parameters are defined: 5542 original_destination_connection_id (0x00): The value of the 5543 Destination Connection ID field from the first Initial packet sent 5544 by the client; see Section 7.3. This transport parameter is only 5545 sent by a server. 5547 max_idle_timeout (0x01): The max idle timeout is a value in 5548 milliseconds that is encoded as an integer; see (Section 10.1). 5549 Idle timeout is disabled when both endpoints omit this transport 5550 parameter or specify a value of 0. 5552 stateless_reset_token (0x02): A stateless reset token is used in 5553 verifying a stateless reset; see Section 10.3. This parameter is 5554 a sequence of 16 bytes. This transport parameter MUST NOT be sent 5555 by a client, but MAY be sent by a server. A server that does not 5556 send this transport parameter cannot use stateless reset 5557 (Section 10.3) for the connection ID negotiated during the 5558 handshake. 5560 max_udp_payload_size (0x03): The maximum UDP payload size parameter 5561 is an integer value that limits the size of UDP payloads that the 5562 endpoint is willing to receive. UDP datagrams with payloads 5563 larger than this limit are not likely to be processed by the 5564 receiver. 5566 The default for this parameter is the maximum permitted UDP 5567 payload of 65527. Values below 1200 are invalid. 5569 This limit does act as an additional constraint on datagram size 5570 in the same way as the path MTU, but it is a property of the 5571 endpoint and not the path; see Section 14. It is expected that 5572 this is the space an endpoint dedicates to holding incoming 5573 packets. 5575 initial_max_data (0x04): The initial maximum data parameter is an 5576 integer value that contains the initial value for the maximum 5577 amount of data that can be sent on the connection. This is 5578 equivalent to sending a MAX_DATA (Section 19.9) for the connection 5579 immediately after completing the handshake. 5581 initial_max_stream_data_bidi_local (0x05): This parameter is an 5582 integer value specifying the initial flow control limit for 5583 locally-initiated bidirectional streams. This limit applies to 5584 newly created bidirectional streams opened by the endpoint that 5585 sends the transport parameter. In client transport parameters, 5586 this applies to streams with an identifier with the least 5587 significant two bits set to 0x0; in server transport parameters, 5588 this applies to streams with the least significant two bits set to 5589 0x1. 5591 initial_max_stream_data_bidi_remote (0x06): This parameter is an 5592 integer value specifying the initial flow control limit for peer- 5593 initiated bidirectional streams. This limit applies to newly 5594 created bidirectional streams opened by the endpoint that receives 5595 the transport parameter. In client transport parameters, this 5596 applies to streams with an identifier with the least significant 5597 two bits set to 0x1; in server transport parameters, this applies 5598 to streams with the least significant two bits set to 0x0. 5600 initial_max_stream_data_uni (0x07): This parameter is an integer 5601 value specifying the initial flow control limit for unidirectional 5602 streams. This limit applies to newly created unidirectional 5603 streams opened by the endpoint that receives the transport 5604 parameter. In client transport parameters, this applies to 5605 streams with an identifier with the least significant two bits set 5606 to 0x3; in server transport parameters, this applies to streams 5607 with the least significant two bits set to 0x2. 5609 initial_max_streams_bidi (0x08): The initial maximum bidirectional 5610 streams parameter is an integer value that contains the initial 5611 maximum number of bidirectional streams the peer may initiate. If 5612 this parameter is absent or zero, the peer cannot open 5613 bidirectional streams until a MAX_STREAMS frame is sent. Setting 5614 this parameter is equivalent to sending a MAX_STREAMS 5615 (Section 19.11) of the corresponding type with the same value. 5617 initial_max_streams_uni (0x09): The initial maximum unidirectional 5618 streams parameter is an integer value that contains the initial 5619 maximum number of unidirectional streams the peer may initiate. 5620 If this parameter is absent or zero, the peer cannot open 5621 unidirectional streams until a MAX_STREAMS frame is sent. Setting 5622 this parameter is equivalent to sending a MAX_STREAMS 5623 (Section 19.11) of the corresponding type with the same value. 5625 ack_delay_exponent (0x0a): The acknowledgement delay exponent is an 5626 integer value indicating an exponent used to decode the ACK Delay 5627 field in the ACK frame (Section 19.3). If this value is absent, a 5628 default value of 3 is assumed (indicating a multiplier of 8). 5629 Values above 20 are invalid. 5631 max_ack_delay (0x0b): The maximum acknowledgement delay is an 5632 integer value indicating the maximum amount of time in 5633 milliseconds by which the endpoint will delay sending 5634 acknowledgments. This value SHOULD include the receiver's 5635 expected delays in alarms firing. For example, if a receiver sets 5636 a timer for 5ms and alarms commonly fire up to 1ms late, then it 5637 should send a max_ack_delay of 6ms. If this value is absent, a 5638 default of 25 milliseconds is assumed. Values of 2^14 or greater 5639 are invalid. 5641 disable_active_migration (0x0c): The disable active migration 5642 transport parameter is included if the endpoint does not support 5643 active connection migration (Section 9) on the address being used 5644 during the handshake. When a peer sets this transport parameter, 5645 an endpoint MUST NOT use a new local address when sending to the 5646 address that the peer used during the handshake. This transport 5647 parameter does not prohibit connection migration after a client 5648 has acted on a preferred_address transport parameter. This 5649 parameter is a zero-length value. 5651 preferred_address (0x0d): The server's preferred address is used to 5652 effect a change in server address at the end of the handshake, as 5653 described in Section 9.6. This transport parameter is only sent 5654 by a server. Servers MAY choose to only send a preferred address 5655 of one address family by sending an all-zero address and port 5656 (0.0.0.0:0 or ::.0) for the other family. IP addresses are 5657 encoded in network byte order. 5659 The preferred_address transport parameter contains an address and 5660 port for both IP version 4 and 6. The four-byte IPv4 Address 5661 field is followed by the associated two-byte IPv4 Port field. 5662 This is followed by a 16-byte IPv6 Address field and two-byte IPv6 5663 Port field. After address and port pairs, a Connection ID Length 5664 field describes the length of the following Connection ID field. 5665 Finally, a 16-byte Stateless Reset Token field includes the 5666 stateless reset token associated with the connection ID. The 5667 format of this transport parameter is shown in Figure 22. 5669 The Connection ID field and the Stateless Reset Token field 5670 contain an alternative connection ID that has a sequence number of 5671 1; see Section 5.1.1. Having these values sent alongside the 5672 preferred address ensures that there will be at least one unused 5673 active connection ID when the client initiates migration to the 5674 preferred address. 5676 The Connection ID and Stateless Reset Token fields of a preferred 5677 address are identical in syntax and semantics to the corresponding 5678 fields of a NEW_CONNECTION_ID frame (Section 19.15). A server 5679 that chooses a zero-length connection ID MUST NOT provide a 5680 preferred address. Similarly, a server MUST NOT include a zero- 5681 length connection ID in this transport parameter. A client MUST 5682 treat violation of these requirements as a connection error of 5683 type TRANSPORT_PARAMETER_ERROR. 5685 Preferred Address { 5686 IPv4 Address (32), 5687 IPv4 Port (16), 5688 IPv6 Address (128), 5689 IPv6 Port (16), 5690 Connection ID Length (8), 5691 Connection ID (..), 5692 Stateless Reset Token (128), 5693 } 5695 Figure 22: Preferred Address format 5697 active_connection_id_limit (0x0e): The active connection ID limit is 5698 an integer value specifying the maximum number of connection IDs 5699 from the peer that an endpoint is willing to store. This value 5700 includes the connection ID received during the handshake, that 5701 received in the preferred_address transport parameter, and those 5702 received in NEW_CONNECTION_ID frames. The value of the 5703 active_connection_id_limit parameter MUST be at least 2. An 5704 endpoint that receives a value less than 2 MUST close the 5705 connection with an error of type TRANSPORT_PARAMETER_ERROR. If 5706 this transport parameter is absent, a default of 2 is assumed. If 5707 an endpoint issues a zero-length connection ID, it will never send 5708 a NEW_CONNECTION_ID frame and therefore ignores the 5709 active_connection_id_limit value received from its peer. 5711 initial_source_connection_id (0x0f): The value that the endpoint 5712 included in the Source Connection ID field of the first Initial 5713 packet it sends for the connection; see Section 7.3. 5715 retry_source_connection_id (0x10): The value that the server 5716 included in the Source Connection ID field of a Retry packet; see 5717 Section 7.3. This transport parameter is only sent by a server. 5719 If present, transport parameters that set initial flow control limits 5720 (initial_max_stream_data_bidi_local, 5721 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 5722 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 5723 every stream of the corresponding type immediately after opening. If 5724 the transport parameter is absent, streams of that type start with a 5725 flow control limit of 0. 5727 A client MUST NOT include any server-only transport parameter: 5728 original_destination_connection_id, preferred_address, 5729 retry_source_connection_id, or stateless_reset_token. A server MUST 5730 treat receipt of any of these transport parameters as a connection 5731 error of type TRANSPORT_PARAMETER_ERROR. 5733 19. Frame Types and Formats 5735 As described in Section 12.4, packets contain one or more frames. 5736 This section describes the format and semantics of the core QUIC 5737 frame types. 5739 19.1. PADDING Frames 5741 A PADDING frame (type=0x00) has no semantic value. PADDING frames 5742 can be used to increase the size of a packet. Padding can be used to 5743 increase an initial client packet to the minimum required size, or to 5744 provide protection against traffic analysis for protected packets. 5746 PADDING frames are formatted as shown in Figure 23, which shows that 5747 PADDING frames have no content. That is, a PADDING frame consists of 5748 the single byte that identifies the frame as a PADDING frame. 5750 PADDING Frame { 5751 Type (i) = 0x00, 5752 } 5754 Figure 23: PADDING Frame Format 5756 19.2. PING Frames 5758 Endpoints can use PING frames (type=0x01) to verify that their peers 5759 are still alive or to check reachability to the peer. 5761 PING frames are formatted as shown in Figure 24, which shows that 5762 PING frames have no content. 5764 PING Frame { 5765 Type (i) = 0x01, 5766 } 5768 Figure 24: PING Frame Format 5770 The receiver of a PING frame simply needs to acknowledge the packet 5771 containing this frame. 5773 The PING frame can be used to keep a connection alive when an 5774 application or application protocol wishes to prevent the connection 5775 from timing out; see Section 10.1.2. 5777 19.3. ACK Frames 5779 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 5780 packets they have received and processed. The ACK frame contains one 5781 or more ACK Ranges. ACK Ranges identify acknowledged packets. If 5782 the frame type is 0x03, ACK frames also contain the sum of QUIC 5783 packets with associated ECN marks received on the connection up until 5784 this point. QUIC implementations MUST properly handle both types 5785 and, if they have enabled ECN for packets they send, they SHOULD use 5786 the information in the ECN section to manage their congestion state. 5788 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 5789 remains acknowledged, even if it does not appear in a future ACK 5790 frame. This is unlike reneging for TCP SACKs ([RFC2018]). 5792 Packets from different packet number spaces can be identified using 5793 the same numeric value. An acknowledgment for a packet needs to 5794 indicate both a packet number and a packet number space. This is 5795 accomplished by having each ACK frame only acknowledge packet numbers 5796 in the same space as the packet in which the ACK frame is contained. 5798 Version Negotiation and Retry packets cannot be acknowledged because 5799 they do not contain a packet number. Rather than relying on ACK 5800 frames, these packets are implicitly acknowledged by the next Initial 5801 packet sent by the client. 5803 ACK frames are formatted as shown in Figure 25. 5805 ACK Frame { 5806 Type (i) = 0x02..0x03, 5807 Largest Acknowledged (i), 5808 ACK Delay (i), 5809 ACK Range Count (i), 5810 First ACK Range (i), 5811 ACK Range (..) ..., 5812 [ECN Counts (..)], 5813 } 5815 Figure 25: ACK Frame Format 5817 ACK frames contain the following fields: 5819 Largest Acknowledged: A variable-length integer representing the 5820 largest packet number the peer is acknowledging; this is usually 5821 the largest packet number that the peer has received prior to 5822 generating the ACK frame. Unlike the packet number in the QUIC 5823 long or short header, the value in an ACK frame is not truncated. 5825 ACK Delay: A variable-length integer encoding the acknowledgement 5826 delay in microseconds; see Section 13.2.5. It is decoded by 5827 multiplying the value in the field by 2 to the power of the 5828 ack_delay_exponent transport parameter sent by the sender of the 5829 ACK frame; see Section 18.2. Compared to simply expressing the 5830 delay as an integer, this encoding allows for a larger range of 5831 values within the same number of bytes, at the cost of lower 5832 resolution. 5834 ACK Range Count: A variable-length integer specifying the number of 5835 Gap and ACK Range fields in the frame. 5837 First ACK Range: A variable-length integer indicating the number of 5838 contiguous packets preceding the Largest Acknowledged that are 5839 being acknowledged. The First ACK Range is encoded as an ACK 5840 Range; see Section 19.3.1 starting from the Largest Acknowledged. 5841 That is, the smallest packet acknowledged in the range is 5842 determined by subtracting the First ACK Range value from the 5843 Largest Acknowledged. 5845 ACK Ranges: Contains additional ranges of packets that are 5846 alternately not acknowledged (Gap) and acknowledged (ACK Range); 5847 see Section 19.3.1. 5849 ECN Counts: The three ECN Counts; see Section 19.3.2. 5851 19.3.1. ACK Ranges 5853 Each ACK Range consists of alternating Gap and ACK Range values in 5854 descending packet number order. ACK Ranges can be repeated. The 5855 number of Gap and ACK Range values is determined by the ACK Range 5856 Count field; one of each value is present for each value in the ACK 5857 Range Count field. 5859 ACK Ranges are structured as shown in Figure 26. 5861 ACK Range { 5862 Gap (i), 5863 ACK Range Length (i), 5864 } 5866 Figure 26: ACK Ranges 5868 The fields that form each ACK Range are: 5870 Gap: A variable-length integer indicating the number of contiguous 5871 unacknowledged packets preceding the packet number one lower than 5872 the smallest in the preceding ACK Range. 5874 ACK Range Length: A variable-length integer indicating the number of 5875 contiguous acknowledged packets preceding the largest packet 5876 number, as determined by the preceding Gap. 5878 Gap and ACK Range value use a relative integer encoding for 5879 efficiency. Though each encoded value is positive, the values are 5880 subtracted, so that each ACK Range describes progressively lower- 5881 numbered packets. 5883 Each ACK Range acknowledges a contiguous range of packets by 5884 indicating the number of acknowledged packets that precede the 5885 largest packet number in that range. A value of zero indicates that 5886 only the largest packet number is acknowledged. Larger ACK Range 5887 values indicate a larger range, with corresponding lower values for 5888 the smallest packet number in the range. Thus, given a largest 5889 packet number for the range, the smallest value is determined by the 5890 formula: 5892 smallest = largest - ack_range 5894 An ACK Range acknowledges all packets between the smallest packet 5895 number and the largest, inclusive. 5897 The largest value for an ACK Range is determined by cumulatively 5898 subtracting the size of all preceding ACK Ranges and Gaps. 5900 Each Gap indicates a range of packets that are not being 5901 acknowledged. The number of packets in the gap is one higher than 5902 the encoded value of the Gap field. 5904 The value of the Gap field establishes the largest packet number 5905 value for the subsequent ACK Range using the following formula: 5907 largest = previous_smallest - gap - 2 5909 If any computed packet number is negative, an endpoint MUST generate 5910 a connection error of type FRAME_ENCODING_ERROR. 5912 19.3.2. ECN Counts 5914 The ACK frame uses the least significant bit (that is, type 0x03) to 5915 indicate ECN feedback and report receipt of QUIC packets with 5916 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 5917 header. ECN Counts are only present when the ACK frame type is 0x03. 5919 When present, there are 3 ECN counts, as shown in Figure 27. 5921 ECN Counts { 5922 ECT0 Count (i), 5923 ECT1 Count (i), 5924 ECN-CE Count (i), 5925 } 5927 Figure 27: ECN Count Format 5929 The three ECN Counts are: 5931 ECT0 Count: A variable-length integer representing the total number 5932 of packets received with the ECT(0) codepoint in the packet number 5933 space of the ACK frame. 5935 ECT1 Count: A variable-length integer representing the total number 5936 of packets received with the ECT(1) codepoint in the packet number 5937 space of the ACK frame. 5939 CE Count: A variable-length integer representing the total number of 5940 packets received with the CE codepoint in the packet number space 5941 of the ACK frame. 5943 ECN counts are maintained separately for each packet number space. 5945 19.4. RESET_STREAM Frames 5947 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 5948 terminate the sending part of a stream. 5950 After sending a RESET_STREAM, an endpoint ceases transmission and 5951 retransmission of STREAM frames on the identified stream. A receiver 5952 of RESET_STREAM can discard any data that it already received on that 5953 stream. 5955 An endpoint that receives a RESET_STREAM frame for a send-only stream 5956 MUST terminate the connection with error STREAM_STATE_ERROR. 5958 RESET_STREAM frames are formatted as shown in Figure 28. 5960 RESET_STREAM Frame { 5961 Type (i) = 0x04, 5962 Stream ID (i), 5963 Application Protocol Error Code (i), 5964 Final Size (i), 5965 } 5967 Figure 28: RESET_STREAM Frame Format 5969 RESET_STREAM frames contain the following fields: 5971 Stream ID: A variable-length integer encoding of the Stream ID of 5972 the stream being terminated. 5974 Application Protocol Error Code: A variable-length integer 5975 containing the application protocol error code (see Section 20.2) 5976 that indicates why the stream is being closed. 5978 Final Size: A variable-length integer indicating the final size of 5979 the stream by the RESET_STREAM sender, in unit of bytes; see 5980 Section 4.5. 5982 19.5. STOP_SENDING Frames 5984 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 5985 incoming data is being discarded on receipt at application request. 5986 STOP_SENDING requests that a peer cease transmission on a stream. 5988 A STOP_SENDING frame can be sent for streams in the Recv or Size 5989 Known states; see Section 3.1. Receiving a STOP_SENDING frame for a 5990 locally-initiated stream that has not yet been created MUST be 5991 treated as a connection error of type STREAM_STATE_ERROR. An 5992 endpoint that receives a STOP_SENDING frame for a receive-only stream 5993 MUST terminate the connection with error STREAM_STATE_ERROR. 5995 STOP_SENDING frames are formatted as shown in Figure 29. 5997 STOP_SENDING Frame { 5998 Type (i) = 0x05, 5999 Stream ID (i), 6000 Application Protocol Error Code (i), 6001 } 6003 Figure 29: STOP_SENDING Frame Format 6005 STOP_SENDING frames contain the following fields: 6007 Stream ID: A variable-length integer carrying the Stream ID of the 6008 stream being ignored. 6010 Application Protocol Error Code: A variable-length integer 6011 containing the application-specified reason the sender is ignoring 6012 the stream; see Section 20.2. 6014 19.6. CRYPTO Frames 6016 A CRYPTO frame (type=0x06) is used to transmit cryptographic 6017 handshake messages. It can be sent in all packet types except 0-RTT. 6018 The CRYPTO frame offers the cryptographic protocol an in-order stream 6019 of bytes. CRYPTO frames are functionally identical to STREAM frames, 6020 except that they do not bear a stream identifier; they are not flow 6021 controlled; and they do not carry markers for optional offset, 6022 optional length, and the end of the stream. 6024 CRYPTO frames are formatted as shown in Figure 30. 6026 CRYPTO Frame { 6027 Type (i) = 0x06, 6028 Offset (i), 6029 Length (i), 6030 Crypto Data (..), 6031 } 6033 Figure 30: CRYPTO Frame Format 6035 CRYPTO frames contain the following fields: 6037 Offset: A variable-length integer specifying the byte offset in the 6038 stream for the data in this CRYPTO frame. 6040 Length: A variable-length integer specifying the length of the 6041 Crypto Data field in this CRYPTO frame. 6043 Crypto Data: The cryptographic message data. 6045 There is a separate flow of cryptographic handshake data in each 6046 encryption level, each of which starts at an offset of 0. This 6047 implies that each encryption level is treated as a separate CRYPTO 6048 stream of data. 6050 The largest offset delivered on a stream - the sum of the offset and 6051 data length - cannot exceed 2^62-1. Receipt of a frame that exceeds 6052 this limit MUST be treated as a connection error of type 6053 FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. 6055 Unlike STREAM frames, which include a Stream ID indicating to which 6056 stream the data belongs, the CRYPTO frame carries data for a single 6057 stream per encryption level. The stream does not have an explicit 6058 end, so CRYPTO frames do not have a FIN bit. 6060 19.7. NEW_TOKEN Frames 6062 A server sends a NEW_TOKEN frame (type=0x07) to provide the client 6063 with a token to send in the header of an Initial packet for a future 6064 connection. 6066 NEW_TOKEN frames are formatted as shown in Figure 31. 6068 NEW_TOKEN Frame { 6069 Type (i) = 0x07, 6070 Token Length (i), 6071 Token (..), 6072 } 6073 Figure 31: NEW_TOKEN Frame Format 6075 NEW_TOKEN frames contain the following fields: 6077 Token Length: A variable-length integer specifying the length of the 6078 token in bytes. 6080 Token: An opaque blob that the client may use with a future Initial 6081 packet. The token MUST NOT be empty. An endpoint MUST treat 6082 receipt of a NEW_TOKEN frame with an empty Token field as a 6083 connection error of type FRAME_ENCODING_ERROR. 6085 An endpoint might receive multiple NEW_TOKEN frames that contain the 6086 same token value if packets containing the frame are incorrectly 6087 determined to be lost. Endpoints are responsible for discarding 6088 duplicate values, which might be used to link connection attempts; 6089 see Section 8.1.3. 6091 Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt 6092 of a NEW_TOKEN frame as a connection error of type 6093 PROTOCOL_VIOLATION. 6095 19.8. STREAM Frames 6097 STREAM frames implicitly create a stream and carry stream data. The 6098 STREAM frame Type field takes the form 0b00001XXX (or the set of 6099 values from 0x08 to 0x0f). The three low-order bits of the frame 6100 type determine the fields that are present in the frame: 6102 * The OFF bit (0x04) in the frame type is set to indicate that there 6103 is an Offset field present. When set to 1, the Offset field is 6104 present. When set to 0, the Offset field is absent and the Stream 6105 Data starts at an offset of 0 (that is, the frame contains the 6106 first bytes of the stream, or the end of a stream that includes no 6107 data). 6109 * The LEN bit (0x02) in the frame type is set to indicate that there 6110 is a Length field present. If this bit is set to 0, the Length 6111 field is absent and the Stream Data field extends to the end of 6112 the packet. If this bit is set to 1, the Length field is present. 6114 * The FIN bit (0x01) indicates that the frame marks the end of the 6115 stream. The final size of the stream is the sum of the offset and 6116 the length of this frame. 6118 An endpoint MUST terminate the connection with error 6119 STREAM_STATE_ERROR if it receives a STREAM frame for a locally- 6120 initiated stream that has not yet been created, or for a send-only 6121 stream. 6123 STREAM frames are formatted as shown in Figure 32. 6125 STREAM Frame { 6126 Type (i) = 0x08..0x0f, 6127 Stream ID (i), 6128 [Offset (i)], 6129 [Length (i)], 6130 Stream Data (..), 6131 } 6133 Figure 32: STREAM Frame Format 6135 STREAM frames contain the following fields: 6137 Stream ID: A variable-length integer indicating the stream ID of the 6138 stream; see Section 2.1. 6140 Offset: A variable-length integer specifying the byte offset in the 6141 stream for the data in this STREAM frame. This field is present 6142 when the OFF bit is set to 1. When the Offset field is absent, 6143 the offset is 0. 6145 Length: A variable-length integer specifying the length of the 6146 Stream Data field in this STREAM frame. This field is present 6147 when the LEN bit is set to 1. When the LEN bit is set to 0, the 6148 Stream Data field consumes all the remaining bytes in the packet. 6150 Stream Data: The bytes from the designated stream to be delivered. 6152 When a Stream Data field has a length of 0, the offset in the STREAM 6153 frame is the offset of the next byte that would be sent. 6155 The first byte in the stream has an offset of 0. The largest offset 6156 delivered on a stream - the sum of the offset and data length - 6157 cannot exceed 2^62-1, as it is not possible to provide flow control 6158 credit for that data. Receipt of a frame that exceeds this limit 6159 MUST be treated as a connection error of type FRAME_ENCODING_ERROR or 6160 FLOW_CONTROL_ERROR. 6162 19.9. MAX_DATA Frames 6164 A MAX_DATA frame (type=0x10) is used in flow control to inform the 6165 peer of the maximum amount of data that can be sent on the connection 6166 as a whole. 6168 MAX_DATA frames are formatted as shown in Figure 33. 6170 MAX_DATA Frame { 6171 Type (i) = 0x10, 6172 Maximum Data (i), 6173 } 6175 Figure 33: MAX_DATA Frame Format 6177 MAX_DATA frames contain the following field: 6179 Maximum Data: A variable-length integer indicating the maximum 6180 amount of data that can be sent on the entire connection, in units 6181 of bytes. 6183 All data sent in STREAM frames counts toward this limit. The sum of 6184 the final sizes on all streams - including streams in terminal states 6185 - MUST NOT exceed the value advertised by a receiver. An endpoint 6186 MUST terminate a connection with a FLOW_CONTROL_ERROR error if it 6187 receives more data than the maximum data value that it has sent. 6188 This includes violations of remembered limits in Early Data; see 6189 Section 7.4.1. 6191 19.10. MAX_STREAM_DATA Frames 6193 A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform 6194 a peer of the maximum amount of data that can be sent on a stream. 6196 A MAX_STREAM_DATA frame can be sent for streams in the Recv state; 6197 see Section 3.1. Receiving a MAX_STREAM_DATA frame for a locally- 6198 initiated stream that has not yet been created MUST be treated as a 6199 connection error of type STREAM_STATE_ERROR. An endpoint that 6200 receives a MAX_STREAM_DATA frame for a receive-only stream MUST 6201 terminate the connection with error STREAM_STATE_ERROR. 6203 MAX_STREAM_DATA frames are formatted as shown in Figure 34. 6205 MAX_STREAM_DATA Frame { 6206 Type (i) = 0x11, 6207 Stream ID (i), 6208 Maximum Stream Data (i), 6209 } 6210 Figure 34: MAX_STREAM_DATA Frame Format 6212 MAX_STREAM_DATA frames contain the following fields: 6214 Stream ID: The stream ID of the stream that is affected encoded as a 6215 variable-length integer. 6217 Maximum Stream Data: A variable-length integer indicating the 6218 maximum amount of data that can be sent on the identified stream, 6219 in units of bytes. 6221 When counting data toward this limit, an endpoint accounts for the 6222 largest received offset of data that is sent or received on the 6223 stream. Loss or reordering can mean that the largest received offset 6224 on a stream can be greater than the total size of data received on 6225 that stream. Receiving STREAM frames might not increase the largest 6226 received offset. 6228 The data sent on a stream MUST NOT exceed the largest maximum stream 6229 data value advertised by the receiver. An endpoint MUST terminate a 6230 connection with a FLOW_CONTROL_ERROR error if it receives more data 6231 than the largest maximum stream data that it has sent for the 6232 affected stream. This includes violations of remembered limits in 6233 Early Data; see Section 7.4.1. 6235 19.11. MAX_STREAMS Frames 6237 A MAX_STREAMS frame (type=0x12 or 0x13) inform the peer of the 6238 cumulative number of streams of a given type it is permitted to open. 6239 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 6240 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 6241 unidirectional streams. 6243 MAX_STREAMS frames are formatted as shown in Figure 35; 6245 MAX_STREAMS Frame { 6246 Type (i) = 0x12..0x13, 6247 Maximum Streams (i), 6248 } 6250 Figure 35: MAX_STREAMS Frame Format 6252 MAX_STREAMS frames contain the following field: 6254 Maximum Streams: A count of the cumulative number of streams of the 6255 corresponding type that can be opened over the lifetime of the 6256 connection. This value cannot exceed 2^60, as it is not possible 6257 to encode stream IDs larger than 2^62-1. Receipt of a frame that 6258 permits opening of a stream larger than this limit MUST be treated 6259 as a FRAME_ENCODING_ERROR. 6261 Loss or reordering can cause a MAX_STREAMS frame to be received that 6262 state a lower stream limit than an endpoint has previously received. 6263 MAX_STREAMS frames that do not increase the stream limit MUST be 6264 ignored. 6266 An endpoint MUST NOT open more streams than permitted by the current 6267 stream limit set by its peer. For instance, a server that receives a 6268 unidirectional stream limit of 3 is permitted to open stream 3, 7, 6269 and 11, but not stream 15. An endpoint MUST terminate a connection 6270 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 6271 permitted. This includes violations of remembered limits in Early 6272 Data; see Section 7.4.1. 6274 Note that these frames (and the corresponding transport parameters) 6275 do not describe the number of streams that can be opened 6276 concurrently. The limit includes streams that have been closed as 6277 well as those that are open. 6279 19.12. DATA_BLOCKED Frames 6281 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 6282 to send data, but is unable to do so due to connection-level flow 6283 control; see Section 4. DATA_BLOCKED frames can be used as input to 6284 tuning of flow control algorithms; see Section 4.2. 6286 DATA_BLOCKED frames are formatted as shown in Figure 36. 6288 DATA_BLOCKED Frame { 6289 Type (i) = 0x14, 6290 Maximum Data (i), 6291 } 6293 Figure 36: DATA_BLOCKED Frame Format 6295 DATA_BLOCKED frames contain the following field: 6297 Maximum Data: A variable-length integer indicating the connection- 6298 level limit at which blocking occurred. 6300 19.13. STREAM_DATA_BLOCKED Frames 6302 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 6303 wishes to send data, but is unable to do so due to stream-level flow 6304 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 6306 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 6307 stream MUST terminate the connection with error STREAM_STATE_ERROR. 6309 STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37. 6311 STREAM_DATA_BLOCKED Frame { 6312 Type (i) = 0x15, 6313 Stream ID (i), 6314 Maximum Stream Data (i), 6315 } 6317 Figure 37: STREAM_DATA_BLOCKED Frame Format 6319 STREAM_DATA_BLOCKED frames contain the following fields: 6321 Stream ID: A variable-length integer indicating the stream that is 6322 blocked due to flow control. 6324 Maximum Stream Data: A variable-length integer indicating the offset 6325 of the stream at which the blocking occurred. 6327 19.14. STREAMS_BLOCKED Frames 6329 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 6330 it wishes to open a stream, but is unable to due to the maximum 6331 stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED 6332 frame of type 0x16 is used to indicate reaching the bidirectional 6333 stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to 6334 indicate reaching the unidirectional stream limit. 6336 A STREAMS_BLOCKED frame does not open the stream, but informs the 6337 peer that a new stream was needed and the stream limit prevented the 6338 creation of the stream. 6340 STREAMS_BLOCKED frames are formatted as shown in Figure 38. 6342 STREAMS_BLOCKED Frame { 6343 Type (i) = 0x16..0x17, 6344 Maximum Streams (i), 6345 } 6347 Figure 38: STREAMS_BLOCKED Frame Format 6349 STREAMS_BLOCKED frames contain the following field: 6351 Maximum Streams: A variable-length integer indicating the maximum 6352 number of streams allowed at the time the frame was sent. This 6353 value cannot exceed 2^60, as it is not possible to encode stream 6354 IDs larger than 2^62-1. Receipt of a frame that encodes a larger 6355 stream ID MUST be treated as a STREAM_LIMIT_ERROR or a 6356 FRAME_ENCODING_ERROR. 6358 19.15. NEW_CONNECTION_ID Frames 6360 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 6361 its peer with alternative connection IDs that can be used to break 6362 linkability when migrating connections; see Section 9.5. 6364 NEW_CONNECTION_ID frames are formatted as shown in Figure 39. 6366 NEW_CONNECTION_ID Frame { 6367 Type (i) = 0x18, 6368 Sequence Number (i), 6369 Retire Prior To (i), 6370 Length (8), 6371 Connection ID (8..160), 6372 Stateless Reset Token (128), 6373 } 6375 Figure 39: NEW_CONNECTION_ID Frame Format 6377 NEW_CONNECTION_ID frames contain the following fields: 6379 Sequence Number: The sequence number assigned to the connection ID 6380 by the sender, encoded as a variable-length integer; see 6381 Section 5.1.1. 6383 Retire Prior To: A variable-length integer indicating which 6384 connection IDs should be retired; see Section 5.1.2. 6386 Length: An 8-bit unsigned integer containing the length of the 6387 connection ID. Values less than 1 and greater than 20 are invalid 6388 and MUST be treated as a connection error of type 6389 FRAME_ENCODING_ERROR. 6391 Connection ID: A connection ID of the specified length. 6393 Stateless Reset Token: A 128-bit value that will be used for a 6394 stateless reset when the associated connection ID is used; see 6395 Section 10.3. 6397 An endpoint MUST NOT send this frame if it currently requires that 6398 its peer send packets with a zero-length Destination Connection ID. 6399 Changing the length of a connection ID to or from zero-length makes 6400 it difficult to identify when the value of the connection ID changed. 6401 An endpoint that is sending packets with a zero-length Destination 6402 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 6403 connection error of type PROTOCOL_VIOLATION. 6405 Transmission errors, timeouts and retransmissions might cause the 6406 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 6407 of the same frame multiple times MUST NOT be treated as a connection 6408 error. A receiver can use the sequence number supplied in the 6409 NEW_CONNECTION_ID frame to handle receiving the same 6410 NEW_CONNECTION_ID frame multiple times. 6412 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 6413 previously issued connection ID with a different Stateless Reset 6414 Token or a different sequence number, or if a sequence number is used 6415 for different connection IDs, the endpoint MAY treat that receipt as 6416 a connection error of type PROTOCOL_VIOLATION. 6418 The Retire Prior To field applies to connection IDs established 6419 during connection setup and the preferred_address transport 6420 parameter; see Section 5.1.2. The Retire Prior To field MUST be less 6421 than or equal to the Sequence Number field. Receiving a value 6422 greater than the Sequence Number MUST be treated as a connection 6423 error of type FRAME_ENCODING_ERROR. 6425 Once a sender indicates a Retire Prior To value, smaller values sent 6426 in subsequent NEW_CONNECTION_ID frames have no effect. A receiver 6427 MUST ignore any Retire Prior To fields that do not increase the 6428 largest received Retire Prior To value. 6430 An endpoint that receives a NEW_CONNECTION_ID frame with a sequence 6431 number smaller than the Retire Prior To field of a previously 6432 received NEW_CONNECTION_ID frame MUST send a corresponding 6433 RETIRE_CONNECTION_ID frame that retires the newly received connection 6434 ID, unless it has already done so for that sequence number. 6436 19.16. RETIRE_CONNECTION_ID Frames 6438 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 6439 indicate that it will no longer use a connection ID that was issued 6440 by its peer. This may include the connection ID provided during the 6441 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 6442 request to the peer to send additional connection IDs for future use; 6443 see Section 5.1. New connection IDs can be delivered to a peer using 6444 the NEW_CONNECTION_ID frame (Section 19.15). 6446 Retiring a connection ID invalidates the stateless reset token 6447 associated with that connection ID. 6449 RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40. 6451 RETIRE_CONNECTION_ID Frame { 6452 Type (i) = 0x19, 6453 Sequence Number (i), 6454 } 6456 Figure 40: RETIRE_CONNECTION_ID Frame Format 6458 RETIRE_CONNECTION_ID frames contain the following field: 6460 Sequence Number: The sequence number of the connection ID being 6461 retired; see Section 5.1.2. 6463 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 6464 greater than any previously sent to the peer MUST be treated as a 6465 connection error of type PROTOCOL_VIOLATION. 6467 The sequence number specified in a RETIRE_CONNECTION_ID frame MUST 6468 NOT refer to the Destination Connection ID field of the packet in 6469 which the frame is contained. The peer MAY treat this as a 6470 connection error of type PROTOCOL_VIOLATION. 6472 An endpoint cannot send this frame if it was provided with a zero- 6473 length connection ID by its peer. An endpoint that provides a zero- 6474 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 6475 frame as a connection error of type PROTOCOL_VIOLATION. 6477 19.17. PATH_CHALLENGE Frames 6479 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 6480 reachability to the peer and for path validation during connection 6481 migration. 6483 PATH_CHALLENGE frames are formatted as shown in Figure 41. 6485 PATH_CHALLENGE Frame { 6486 Type (i) = 0x1a, 6487 Data (64), 6488 } 6490 Figure 41: PATH_CHALLENGE Frame Format 6492 PATH_CHALLENGE frames contain the following field: 6494 Data: This 8-byte field contains arbitrary data. 6496 Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that 6497 it is easier to receive the packet than it is to guess the value 6498 correctly. 6500 The recipient of this frame MUST generate a PATH_RESPONSE frame 6501 (Section 19.18) containing the same Data. 6503 19.18. PATH_RESPONSE Frames 6505 A PATH_RESPONSE frame (type=0x1b) is sent in response to a 6506 PATH_CHALLENGE frame. 6508 PATH_RESPONSE frames are formatted as shown in Figure 42, which is 6509 identical to the PATH_CHALLENGE frame (Section 19.17). 6511 PATH_RESPONSE Frame { 6512 Type (i) = 0x1b, 6513 Data (64), 6514 } 6516 Figure 42: PATH_RESPONSE Frame Format 6518 If the content of a PATH_RESPONSE frame does not match the content of 6519 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 6520 MAY generate a connection error of type PROTOCOL_VIOLATION. 6522 19.19. CONNECTION_CLOSE Frames 6524 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 6525 notify its peer that the connection is being closed. The 6526 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 6527 at only the QUIC layer, or the absence of errors (with the NO_ERROR 6528 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 6529 signal an error with the application that uses QUIC. 6531 If there are open streams that have not been explicitly closed, they 6532 are implicitly closed when the connection is closed. 6534 CONNECTION_CLOSE frames are formatted as shown in Figure 43. 6536 CONNECTION_CLOSE Frame { 6537 Type (i) = 0x1c..0x1d, 6538 Error Code (i), 6539 [Frame Type (i)], 6540 Reason Phrase Length (i), 6541 Reason Phrase (..), 6542 } 6544 Figure 43: CONNECTION_CLOSE Frame Format 6546 CONNECTION_CLOSE frames contain the following fields: 6548 Error Code: A variable-length integer error code that indicates the 6549 reason for closing this connection. A CONNECTION_CLOSE frame of 6550 type 0x1c uses codes from the space defined in Section 20.1. A 6551 CONNECTION_CLOSE frame of type 0x1d uses codes from the 6552 application protocol error code space; see Section 20.2. 6554 Frame Type: A variable-length integer encoding the type of frame 6555 that triggered the error. A value of 0 (equivalent to the mention 6556 of the PADDING frame) is used when the frame type is unknown. The 6557 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 6558 not include this field. 6560 Reason Phrase Length: A variable-length integer specifying the 6561 length of the reason phrase in bytes. Because a CONNECTION_CLOSE 6562 frame cannot be split between packets, any limits on packet size 6563 will also limit the space available for a reason phrase. 6565 Reason Phrase: A human-readable explanation for why the connection 6566 was closed. This can be zero length if the sender chooses not to 6567 give details beyond the Error Code. This SHOULD be a UTF-8 6568 encoded string [RFC3629]. 6570 The application-specific variant of CONNECTION_CLOSE (type 0x1d) can 6571 only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an 6572 application wishes to abandon a connection during the handshake, an 6573 endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error 6574 code of APPLICATION_ERROR in an Initial or a Handshake packet. 6576 19.20. HANDSHAKE_DONE Frames 6578 The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal 6579 confirmation of the handshake to the client. 6581 HANDSHAKE_DONE frames are formatted as shown in Figure 44, which 6582 shows that HANDSHAKE_DONE frames have no content. 6584 HANDSHAKE_DONE Frame { 6585 Type (i) = 0x1e, 6586 } 6588 Figure 44: HANDSHAKE_DONE Frame Format 6590 A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST 6591 NOT send a HANDSHAKE_DONE frame before completing the handshake. A 6592 server MUST treat receipt of a HANDSHAKE_DONE frame as a connection 6593 error of type PROTOCOL_VIOLATION. 6595 19.21. Extension Frames 6597 QUIC frames do not use a self-describing encoding. An endpoint 6598 therefore needs to understand the syntax of all frames before it can 6599 successfully process a packet. This allows for efficient encoding of 6600 frames, but it means that an endpoint cannot send a frame of a type 6601 that is unknown to its peer. 6603 An extension to QUIC that wishes to use a new type of frame MUST 6604 first ensure that a peer is able to understand the frame. An 6605 endpoint can use a transport parameter to signal its willingness to 6606 receive extension frame types. One transport parameter can indicate 6607 support for one or more extension frame types. 6609 Extensions that modify or replace core protocol functionality 6610 (including frame types) will be difficult to combine with other 6611 extensions that modify or replace the same functionality unless the 6612 behavior of the combination is explicitly defined. Such extensions 6613 SHOULD define their interaction with previously-defined extensions 6614 modifying the same protocol components. 6616 Extension frames MUST be congestion controlled and MUST cause an ACK 6617 frame to be sent. The exception is extension frames that replace or 6618 supplement the ACK frame. Extension frames are not included in flow 6619 control unless specified in the extension. 6621 An IANA registry is used to manage the assignment of frame types; see 6622 Section 22.3. 6624 20. Error Codes 6626 QUIC transport error codes and application error codes are 62-bit 6627 unsigned integers. 6629 20.1. Transport Error Codes 6631 This section lists the defined QUIC transport error codes that may be 6632 used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors 6633 apply to the entire connection. 6635 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 6636 signal that the connection is being closed abruptly in the absence 6637 of any error. 6639 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 6640 cannot continue with the connection. 6642 CONNECTION_REFUSED (0x2): The server refused to accept a new 6643 connection. 6645 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 6646 permitted in its advertised data limits; see Section 4. 6648 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 6649 identifier that exceeded its advertised stream limit for the 6650 corresponding stream type. 6652 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 6653 that was not in a state that permitted that frame; see Section 3. 6655 FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame 6656 containing data that exceeded the previously established final 6657 size. Or an endpoint received a STREAM frame or a RESET_STREAM 6658 frame containing a final size that was lower than the size of 6659 stream data that was already received. Or an endpoint received a 6660 STREAM frame or a RESET_STREAM frame containing a different final 6661 size to the one already established. 6663 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 6664 badly formatted. For instance, a frame of an unknown type, or an 6665 ACK frame that has more acknowledgment ranges than the remainder 6666 of the packet could carry. 6668 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 6669 parameters that were badly formatted, included an invalid value, 6670 was absent even though it is mandatory, was present though it is 6671 forbidden, or is otherwise in error. 6673 CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs 6674 provided by the peer exceeds the advertised 6675 active_connection_id_limit. 6677 PROTOCOL_VIOLATION (0xa): An endpoint detected an error with 6678 protocol compliance that was not covered by more specific error 6679 codes. 6681 INVALID_TOKEN (0xb): A server received a client Initial that 6682 contained an invalid Token field. 6684 APPLICATION_ERROR (0xc): The application or application protocol 6685 caused the connection to be closed. 6687 CRYPTO_BUFFER_EXCEEDED (0xd): An endpoint has received more data in 6688 CRYPTO frames than it can buffer. 6690 KEY_UPDATE_ERROR (0xe): An endpoint detected errors in performing 6691 key updates; see Section 6 of [QUIC-TLS]. 6693 AEAD_LIMIT_REACHED (0xf): An endpoint has reached the 6694 confidentiality or integrity limit for the AEAD algorithm used by 6695 the given connection. 6697 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 6698 of 256 values is reserved for carrying error codes specific to the 6699 cryptographic handshake that is used. Codes for errors occurring 6700 when TLS is used for the crypto handshake are described in 6701 Section 4.8 of [QUIC-TLS]. 6703 See Section 22.4 for details of registering new error codes. 6705 In defining these error codes, several principles are applied. Error 6706 conditions that might require specific action on the part of a 6707 recipient are given unique codes. Errors that represent common 6708 conditions are given specific codes. Absent either of these 6709 conditions, error codes are used to identify a general function of 6710 the stack, like flow control or transport parameter handling. 6711 Finally, generic errors are provided for conditions where 6712 implementations are unable or unwilling to use more specific codes. 6714 20.2. Application Protocol Error Codes 6716 The management of application error codes is left to application 6717 protocols. Application protocol error codes are used for the 6718 RESET_STREAM frame (Section 19.4), the STOP_SENDING frame 6719 (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d 6720 (Section 19.19). 6722 21. Security Considerations 6724 21.1. Handshake Denial of Service 6726 As an encrypted and authenticated transport QUIC provides a range of 6727 protections against denial of service. Once the cryptographic 6728 handshake is complete, QUIC endpoints discard most packets that are 6729 not authenticated, greatly limiting the ability of an attacker to 6730 interfere with existing connections. 6732 Once a connection is established QUIC endpoints might accept some 6733 unauthenticated ICMP packets (see Section 14.2.1), but the use of 6734 these packets is extremely limited. The only other type of packet 6735 that an endpoint might accept is a stateless reset (Section 10.3), 6736 which relies on the token being kept secret until it is used. 6738 During the creation of a connection, QUIC only provides protection 6739 against attack from off the network path. All QUIC packets contain 6740 proof that the recipient saw a preceding packet from its peer. 6742 Addresses cannot change during the handshake, so endpoints can 6743 discard packets that are received on a different network path. 6745 The Source and Destination Connection ID fields are the primary means 6746 of protection against off-path attack during the handshake. These 6747 are required to match those set by a peer. Except for an Initial and 6748 stateless reset packets, an endpoint only accepts packets that 6749 include a Destination Connection ID field that matches a value the 6750 endpoint previously chose. This is the only protection offered for 6751 Version Negotiation packets. 6753 The Destination Connection ID field in an Initial packet is selected 6754 by a client to be unpredictable, which serves an additional purpose. 6755 The packets that carry the cryptographic handshake are protected with 6756 a key that is derived from this connection ID and salt specific to 6757 the QUIC version. This allows endpoints to use the same process for 6758 authenticating packets that they receive as they use after the 6759 cryptographic handshake completes. Packets that cannot be 6760 authenticated are discarded. Protecting packets in this fashion 6761 provides a strong assurance that the sender of the packet saw the 6762 Initial packet and understood it. 6764 These protections are not intended to be effective against an 6765 attacker that is able to receive QUIC packets prior to the connection 6766 being established. Such an attacker can potentially send packets 6767 that will be accepted by QUIC endpoints. This version of QUIC 6768 attempts to detect this sort of attack, but it expects that endpoints 6769 will fail to establish a connection rather than recovering. For the 6770 most part, the cryptographic handshake protocol [QUIC-TLS] is 6771 responsible for detecting tampering during the handshake. 6773 Endpoints are permitted to use other methods to detect and attempt to 6774 recover from interference with the handshake. Invalid packets may be 6775 identified and discarded using other methods, but no specific method 6776 is mandated in this document. 6778 21.2. Amplification Attack 6780 An attacker might be able to receive an address validation token 6781 (Section 8) from a server and then release the IP address it used to 6782 acquire that token. At a later time, the attacker may initiate a 6783 0-RTT connection with a server by spoofing this same address, which 6784 might now address a different (victim) endpoint. The attacker can 6785 thus potentially cause the server to send an initial congestion 6786 window's worth of data towards the victim. 6788 Servers SHOULD provide mitigations for this attack by limiting the 6789 usage and lifetime of address validation tokens; see Section 8.1.3. 6791 21.3. Optimistic ACK Attack 6793 An endpoint that acknowledges packets it has not received might cause 6794 a congestion controller to permit sending at rates beyond what the 6795 network supports. An endpoint MAY skip packet numbers when sending 6796 packets to detect this behavior. An endpoint can then immediately 6797 close the connection with a connection error of type 6798 PROTOCOL_VIOLATION; see Section 10.2. 6800 21.4. Request Forgery Attacks 6802 A request forgery attack occurs where an endpoint causes its peer to 6803 issue a request towards a victim, with the request controlled by the 6804 endpoint. Request forgery attacks aim to provide an attacker with 6805 access to capabilities of its peer that might otherwise be 6806 unavailable to the attacker. For a networking protocol, a request 6807 forgery attack is often used to exploit any implicit authorization 6808 conferred on the peer by the victim due to the peer's location in the 6809 network. 6811 For request forgery to be effective, an attacker needs to be able to 6812 influence what packets the peer sends and where these packets are 6813 sent. If an attacker can target a vulnerable service with a 6814 controlled payload, that service might perform actions that are 6815 attributed to the attacker's peer, but decided by the attacker. 6817 For example, cross-site request forgery [CSRF] exploits on the Web 6818 cause a client to issue requests that include authorization cookies 6819 [COOKIE], allowing one site access to information and actions that 6820 are intended to be restricted to a different site. 6822 As QUIC runs over UDP, the primary attack modality of concern is one 6823 where an attacker can select the address to which its peer sends UDP 6824 datagrams and can control some of the unprotected content of those 6825 packets. As much of the data sent by QUIC endpoints is protected, 6826 this includes control over ciphertext. An attack is successful if an 6827 attacker can cause a peer to send a UDP datagram to a host that will 6828 perform some action based on content in the datagram. 6830 This section discusses ways in which QUIC might be used for request 6831 forgery attacks. 6833 This section also describes limited countermeasures that can be 6834 implemented by QUIC endpoints. These mitigations can be employed 6835 unilaterally by a QUIC implementation or deployment, without 6836 potential targets for request forgery attacks taking action. However 6837 these countermeasures could be insufficient if UDP-based services do 6838 not properly authorize requests. 6840 Because the migration attack described in Section 21.4.4 is quite 6841 powerful and does not have adequate countermeasures, QUIC server 6842 implementations should assume that attackers can cause them to 6843 generate arbitrary UDP payloads to arbitrary destinations. QUIC 6844 servers SHOULD NOT be deployed in networks that also have 6845 inadequately secured UDP endpoints. 6847 Although it is not generally possible to ensure that clients are not 6848 co-located with vulnerable endpoints, this version of QUIC does not 6849 allow servers to migrate, thus preventing spoofed migration attacks 6850 on clients. Any future extension which allows server migration MUST 6851 also define countermeasures for forgery attacks. 6853 21.4.1. Control Options for Endpoints 6855 QUIC offers some opportunities for an attacker to influence or 6856 control where its peer sends UDP datagrams: 6858 * initial connection establishment (Section 7), where a server is 6859 able to choose where a client sends datagrams, for example by 6860 populating DNS records; 6862 * preferred addresses (Section 9.6), where a server is able to 6863 choose where a client sends datagrams; and 6865 * spoofed connection migrations (Section 9.3.1), where a client is 6866 able to use source address spoofing to select where a server sends 6867 subsequent datagrams. 6869 In all three cases, the attacker can cause its peer to send datagrams 6870 to a victim that might not understand QUIC. That is, these packets 6871 are sent by the peer prior to address validation; see Section 8. 6873 Outside of the encrypted portion of packets, QUIC offers an endpoint 6874 several options for controlling the content of UDP datagrams that its 6875 peer sends. The Destination Connection ID field offers direct 6876 control over bytes that appear early in packets sent by the peer; see 6877 Section 5.1. The Token field in Initial packets offers a server 6878 control over other bytes of Initial packets; see Section 17.2.2. 6880 There are no measures in this version of QUIC to prevent indirect 6881 control over the encrypted portions of packets. It is necessary to 6882 assume that endpoints are able to control the contents of frames that 6883 a peer sends, especially those frames that convey application data, 6884 such as STREAM frames. Though this depends to some degree on details 6885 of the application protocol, some control is possible in many 6886 protocol usage contexts. As the attacker has access to packet 6887 protection keys, they are likely to be capable of predicting how a 6888 peer will encrypt future packets. Successful control over datagram 6889 content then only requires that the attacker be able to predict the 6890 packet number and placement of frames in packets with some amount of 6891 reliability. 6893 This section assumes that limiting control over datagram content is 6894 not feasible. The focus of the mitigations in subsequent sections is 6895 on limiting the ways in which datagrams that are sent prior to 6896 address validation can be used for request forgery. 6898 21.4.2. Request Forgery with Client Initial Packets 6900 An attacker acting as a server can choose the IP address and port on 6901 which it advertises its availability, so Initial packets from clients 6902 are assumed to be available for use in this sort of attack. The 6903 address validation implicit in the handshake ensures that - for a new 6904 connection - a client will not send other types of packet to a 6905 destination that does not understand QUIC or is not willing to accept 6906 a QUIC connection. 6908 Initial packet protection (Section 5.2 of [QUIC-TLS]) makes it 6909 difficult for servers to control the content of Initial packets sent 6910 by clients. A client choosing an unpredictable Destination 6911 Connection ID ensures that servers are unable to control any of the 6912 encrypted portion of Initial packets from clients. 6914 However, the Token field is open to server control and does allow a 6915 server to use clients to mount request forgery attacks. Use of 6916 tokens provided with the NEW_TOKEN frame (Section 8.1.3) offers the 6917 only option for request forgery during connection establishment. 6919 Clients however are not obligated to use the NEW_TOKEN frame. 6920 Request forgery attacks that rely on the Token field can be avoided 6921 if clients send an empty Token field when the server address has 6922 changed from when the NEW_TOKEN frame was received. 6924 Clients could avoid using NEW_TOKEN if the server address changes. 6925 However, not including a Token field could adversely affect 6926 performance. Servers could rely on NEW_TOKEN to enable sending of 6927 data in excess of the three times limit on sending data; see 6928 Section 8.1. In particular, this affects cases where clients use 6929 0-RTT to request data from servers. 6931 Sending a Retry packet (Section 17.2.5) offers a server the option to 6932 change the Token field. After sending a Retry, the server can also 6933 control the Destination Connection ID field of subsequent Initial 6934 packets from the client. This also might allow indirect control over 6935 the encrypted content of Initial packets. However, the exchange of a 6936 Retry packet validates the server's address, thereby preventing the 6937 use of subsequent Initial packets for request forgery. 6939 21.4.3. Request Forgery with Preferred Addresses 6941 Servers can specify a preferred address, which clients then migrate 6942 to after confirming the handshake; see Section 9.6. The Destination 6943 Connection ID field of packets that the client sends to a preferred 6944 address can be used for request forgery. 6946 A client MUST NOT send non-probing frames to a preferred address 6947 prior to validating that address; see Section 8. This greatly 6948 reduces the options that a server has to control the encrypted 6949 portion of datagrams. 6951 This document does not offer any additional countermeasures that are 6952 specific to use of preferred addresses and can be implemented by 6953 endpoints. The generic measures described in Section 21.4.5 could be 6954 used as further mitigation. 6956 21.4.4. Request Forgery with Spoofed Migration 6958 Clients are able to present a spoofed source address as part of an 6959 apparent connection migration to cause a server to send datagrams to 6960 that address. 6962 The Destination Connection ID field in any packets that a server 6963 subsequently sends to this spoofed address can be used for request 6964 forgery. A client might also be able to influence the ciphertext. 6966 A server that only sends probing packets (Section 9.1) to an address 6967 prior to address validation provides an attacker with only limited 6968 control over the encrypted portion of datagrams. However, 6969 particularly for NAT rebinding, this can adversely affect 6970 performance. If the server sends frames carrying application data, 6971 an attacker might be able to control most of the content of 6972 datagrams. 6974 This document does not offer specific countermeasures that can be 6975 implemented by endpoints aside from the generic measures described in 6976 Section 21.4.5. However, countermeasures for address spoofing at the 6977 network level, in particular ingress filtering [BCP38], are 6978 especially effective against attacks that use spoofing and originate 6979 from an external network. 6981 21.4.5. Generic Request Forgery Countermeasures 6983 The most effective defense against request forgery attacks is to 6984 modify vulnerable services to use strong authentication. However, 6985 this is not always something that is within the control of a QUIC 6986 deployment. This section outlines some others steps that QUIC 6987 endpoints could take unilaterally. These additional steps are all 6988 discretionary as, depending on circumstances, they could interfere 6989 with or prevent legitimate uses. 6991 Services offered over loopback interfaces often lack proper 6992 authentication. Endpoints MAY prevent connection attempts or 6993 migration to a loopback address. Endpoints SHOULD NOT allow 6994 connections or migration to a loopback address if the same service 6995 was previously available at a different interface or if the address 6996 was provided by a service at a non-loopback address. Endpoints that 6997 depend on these capabilities could offer an option to disable these 6998 protections. 7000 Similarly, endpoints could regard a change in address to link-local 7001 address [RFC4291] or an address in a private use range [RFC1918] from 7002 a global, unique-local [RFC4193], or non-private address as a 7003 potential attempt at request forgery. Endpoints could refuse to use 7004 these addresses entirely, but that carries a significant risk of 7005 interfering with legitimate uses. Endpoints SHOULD NOT refuse to use 7006 an address unless they have specific knowledge about the network 7007 indicating that sending datagrams to unvalidated addresses in a given 7008 range is not safe. 7010 Endpoints MAY choose to reduce the risk of request forgery by not 7011 including values from NEW_TOKEN frames in Initial packets or by only 7012 sending probing frames in packets prior to completing address 7013 validation. Note that this does not prevent an attacker from using 7014 the Destination Connection ID field for an attack. 7016 Endpoints are not expected to have specific information about the 7017 location of servers that could be vulnerable targets of a request 7018 forgery attack. However, it might be possible over time to identify 7019 specific UDP ports that are common targets of attacks or particular 7020 patterns in datagrams that are used for attacks. Endpoints MAY 7021 choose to avoid sending datagrams to these ports or not send 7022 datagrams that match these patterns prior to validating the 7023 destination address. Endpoints MAY retire connection IDs containing 7024 patterns known to be problematic without using them. 7026 Note: Modifying endpoints to apply these protections is more 7027 efficient than deploying network-based protections, as endpoints 7028 do not need to perform any additional processing when sending to 7029 an address that has been validated. 7031 21.5. Slowloris Attacks 7033 The attacks commonly known as Slowloris ([SLOWLORIS]) try to keep 7034 many connections to the target endpoint open and hold them open as 7035 long as possible. These attacks can be executed against a QUIC 7036 endpoint by generating the minimum amount of activity necessary to 7037 avoid being closed for inactivity. This might involve sending small 7038 amounts of data, gradually opening flow control windows in order to 7039 control the sender rate, or manufacturing ACK frames that simulate a 7040 high loss rate. 7042 QUIC deployments SHOULD provide mitigations for the Slowloris 7043 attacks, such as increasing the maximum number of clients the server 7044 will allow, limiting the number of connections a single IP address is 7045 allowed to make, imposing restrictions on the minimum transfer speed 7046 a connection is allowed to have, and restricting the length of time 7047 an endpoint is allowed to stay connected. 7049 21.6. Stream Fragmentation and Reassembly Attacks 7051 An adversarial sender might intentionally not send portions of the 7052 stream data, causing the receiver to commit resources for the unsent 7053 data. This could cause a disproportionate receive buffer memory 7054 commitment and/or the creation of a large and inefficient data 7055 structure at the receiver. 7057 An adversarial receiver might intentionally not acknowledge packets 7058 containing stream data in an attempt to force the sender to store the 7059 unacknowledged stream data for retransmission. 7061 The attack on receivers is mitigated if flow control windows 7062 correspond to available memory. However, some receivers will over- 7063 commit memory and advertise flow control offsets in the aggregate 7064 that exceed actual available memory. The over-commitment strategy 7065 can lead to better performance when endpoints are well behaved, but 7066 renders endpoints vulnerable to the stream fragmentation attack. 7068 QUIC deployments SHOULD provide mitigations against stream 7069 fragmentation attacks. Mitigations could consist of avoiding over- 7070 committing memory, limiting the size of tracking data structures, 7071 delaying reassembly of STREAM frames, implementing heuristics based 7072 on the age and duration of reassembly holes, or some combination. 7074 21.7. Stream Commitment Attack 7076 An adversarial endpoint can open a large number of streams, 7077 exhausting state on an endpoint. The adversarial endpoint could 7078 repeat the process on a large number of connections, in a manner 7079 similar to SYN flooding attacks in TCP. 7081 Normally, clients will open streams sequentially, as explained in 7082 Section 2.1. However, when several streams are initiated at short 7083 intervals, loss or reordering may cause STREAM frames that open 7084 streams to be received out of sequence. On receiving a higher- 7085 numbered stream ID, a receiver is required to open all intervening 7086 streams of the same type; see Section 3.2. Thus, on a new 7087 connection, opening stream 4000000 opens 1 million and 1 client- 7088 initiated bidirectional streams. 7090 The number of active streams is limited by the 7091 initial_max_streams_bidi and initial_max_streams_uni transport 7092 parameters, as explained in Section 4.6. If chosen judiciously, 7093 these limits mitigate the effect of the stream commitment attack. 7094 However, setting the limit too low could affect performance when 7095 applications expect to open large number of streams. 7097 21.8. Peer Denial of Service 7099 QUIC and TLS both contain frames or messages that have legitimate 7100 uses in some contexts, but that can be abused to cause a peer to 7101 expend processing resources without having any observable impact on 7102 the state of the connection. 7104 Messages can also be used to change and revert state in small or 7105 inconsequential ways, such as by sending small increments to flow 7106 control limits. 7108 If processing costs are disproportionately large in comparison to 7109 bandwidth consumption or effect on state, then this could allow a 7110 malicious peer to exhaust processing capacity. 7112 While there are legitimate uses for all messages, implementations 7113 SHOULD track cost of processing relative to progress and treat 7114 excessive quantities of any non-productive packets as indicative of 7115 an attack. Endpoints MAY respond to this condition with a connection 7116 error, or by dropping packets. 7118 21.9. Explicit Congestion Notification Attacks 7120 An on-path attacker could manipulate the value of ECN fields in the 7121 IP header to influence the sender's rate. [RFC3168] discusses 7122 manipulations and their effects in more detail. 7124 An on-the-side attacker can duplicate and send packets with modified 7125 ECN fields to affect the sender's rate. If duplicate packets are 7126 discarded by a receiver, an off-path attacker will need to race the 7127 duplicate packet against the original to be successful in this 7128 attack. Therefore, QUIC endpoints ignore the ECN field on an IP 7129 packet unless at least one QUIC packet in that IP packet is 7130 successfully processed; see Section 13.4. 7132 21.10. Stateless Reset Oracle 7134 Stateless resets create a possible denial of service attack analogous 7135 to a TCP reset injection. This attack is possible if an attacker is 7136 able to cause a stateless reset token to be generated for a 7137 connection with a selected connection ID. An attacker that can cause 7138 this token to be generated can reset an active connection with the 7139 same connection ID. 7141 If a packet can be routed to different instances that share a static 7142 key, for example by changing an IP address or port, then an attacker 7143 can cause the server to send a stateless reset. To defend against 7144 this style of denial of service, endpoints that share a static key 7145 for stateless reset (see Section 10.3.2) MUST be arranged so that 7146 packets with a given connection ID always arrive at an instance that 7147 has connection state, unless that connection is no longer active. 7149 More generally, servers MUST NOT generate a stateless reset if a 7150 connection with the corresponding connection ID could be active on 7151 any endpoint using the same static key. 7153 In the case of a cluster that uses dynamic load balancing, it is 7154 possible that a change in load balancer configuration could occur 7155 while an active instance retains connection state. Even if an 7156 instance retains connection state, the change in routing and 7157 resulting stateless reset will result in the connection being 7158 terminated. If there is no chance of the packet being routed to the 7159 correct instance, it is better to send a stateless reset than wait 7160 for the connection to time out. However, this is acceptable only if 7161 the routing cannot be influenced by an attacker. 7163 21.11. Version Downgrade 7165 This document defines QUIC Version Negotiation packets in Section 6 7166 that can be used to negotiate the QUIC version used between two 7167 endpoints. However, this document does not specify how this 7168 negotiation will be performed between this version and subsequent 7169 future versions. In particular, Version Negotiation packets do not 7170 contain any mechanism to prevent version downgrade attacks. Future 7171 versions of QUIC that use Version Negotiation packets MUST define a 7172 mechanism that is robust against version downgrade attacks. 7174 21.12. Targeted Attacks by Routing 7176 Deployments should limit the ability of an attacker to target a new 7177 connection to a particular server instance. This means that client- 7178 controlled fields, such as the initial Destination Connection ID used 7179 on Initial and 0-RTT packets SHOULD NOT be used by themselves to make 7180 routing decisions. Ideally, routing decisions are made independently 7181 of client-selected values; a Source Connection ID can be selected to 7182 route later packets to the same server. 7184 21.13. Overview of Security Properties 7186 A complete security analysis of QUIC is outside the scope of this 7187 document. This section provides an informal description of the 7188 desired security properties as an aid to implementors and to help 7189 guide protocol analysis. 7191 QUIC assumes the threat model described in [SEC-CONS] and provides 7192 protections against many of the attacks that arise from that model. 7194 For this purpose, attacks are divided into passive and active 7195 attacks. Passive attackers have the capability to read packets from 7196 the network, while active attackers also have the capability to write 7197 packets into the network. However, a passive attack may involve an 7198 attacker with the ability to cause a routing change or other 7199 modification in the path taken by packets that comprise a connection. 7201 Attackers are additionally categorized as either on-path attackers or 7202 off-path attackers; see Section 3.5 of [SEC-CONS]. An on-path 7203 attacker can read, modify, or remove any packet it observes such that 7204 it no longer reaches its destination, while an off-path attacker 7205 observes the packets, but cannot prevent the original packet from 7206 reaching its intended destination. Both types of attackers can also 7207 transmit arbitrary packets. 7209 Properties of the handshake, protected packets, and connection 7210 migration are considered separately. 7212 21.13.1. Handshake 7214 The QUIC handshake incorporates the TLS 1.3 handshake and inherits 7215 the cryptographic properties described in Appendix E.1 of [TLS13]. 7216 Many of the security properties of QUIC depend on the TLS handshake 7217 providing these properties. Any attack on the TLS handshake could 7218 affect QUIC. 7220 Any attack on the TLS handshake that compromises the secrecy or 7221 uniqueness of session keys affects other security guarantees provided 7222 by QUIC that depends on these keys. For instance, migration 7223 (Section 9) depends on the efficacy of confidentiality protections, 7224 both for the negotiation of keys using the TLS handshake and for QUIC 7225 packet protection, to avoid linkability across network paths. 7227 An attack on the integrity of the TLS handshake might allow an 7228 attacker to affect the selection of application protocol or QUIC 7229 version. 7231 In addition to the properties provided by TLS, the QUIC handshake 7232 provides some defense against DoS attacks on the handshake. 7234 21.13.1.1. Anti-Amplification 7236 Address validation (Section 8) is used to verify that an entity that 7237 claims a given address is able to receive packets at that address. 7238 Address validation limits amplification attack targets to addresses 7239 for which an attacker can observe packets. 7241 Prior to validation, endpoints are limited in what they are able to 7242 send. During the handshake, a server cannot send more than three 7243 times the data it receives; clients that initiate new connections or 7244 migrate to a new network path are limited. 7246 21.13.1.2. Server-Side DoS 7248 Computing the server's first flight for a full handshake is 7249 potentially expensive, requiring both a signature and a key exchange 7250 computation. In order to prevent computational DoS attacks, the 7251 Retry packet provides a cheap token exchange mechanism that allows 7252 servers to validate a client's IP address prior to doing any 7253 expensive computations at the cost of a single round trip. After a 7254 successful handshake, servers can issue new tokens to a client, which 7255 will allow new connection establishment without incurring this cost. 7257 21.13.1.3. On-Path Handshake Termination 7259 An on-path or off-path attacker can force a handshake to fail by 7260 replacing or racing Initial packets. Once valid Initial packets have 7261 been exchanged, subsequent Handshake packets are protected with the 7262 handshake keys and an on-path attacker cannot force handshake failure 7263 other than by dropping packets to cause endpoints to abandon the 7264 attempt. 7266 An on-path attacker can also replace the addresses of packets on 7267 either side and therefore cause the client or server to have an 7268 incorrect view of the remote addresses. Such an attack is 7269 indistinguishable from the functions performed by a NAT. 7271 21.13.1.4. Parameter Negotiation 7273 The entire handshake is cryptographically protected, with the Initial 7274 packets being encrypted with per-version keys and the Handshake and 7275 later packets being encrypted with keys derived from the TLS key 7276 exchange. Further, parameter negotiation is folded into the TLS 7277 transcript and thus provides the same integrity guarantees as 7278 ordinary TLS negotiation. An attacker can observe the client's 7279 transport parameters (as long as it knows the version-specific salt) 7280 but cannot observe the server's transport parameters and cannot 7281 influence parameter negotiation. 7283 Connection IDs are unencrypted but integrity protected in all 7284 packets. 7286 This version of QUIC does not incorporate a version negotiation 7287 mechanism; implementations of incompatible versions will simply fail 7288 to establish a connection. 7290 21.13.2. Protected Packets 7292 Packet protection (Section 12.1) provides authentication and 7293 encryption of all packets except Version Negotiation packets, though 7294 Initial and Retry packets have limited encryption and authentication 7295 based on version-specific inputs; see [QUIC-TLS] for more details. 7296 This section considers passive and active attacks against protected 7297 packets. 7299 Both on-path and off-path attackers can mount a passive attack in 7300 which they save observed packets for an offline attack against packet 7301 protection at a future time; this is true for any observer of any 7302 packet on any network. 7304 A blind attacker, one who injects packets without being able to 7305 observe valid packets for a connection, is unlikely to be successful, 7306 since packet protection ensures that valid packets are only generated 7307 by endpoints that possess the key material established during the 7308 handshake; see Section 7 and Section 21.13.1. Similarly, any active 7309 attacker that observes packets and attempts to insert new data or 7310 modify existing data in those packets should not be able to generate 7311 packets deemed valid by the receiving endpoint. 7313 A spoofing attack, in which an active attacker rewrites unprotected 7314 parts of a packet that it forwards or injects, such as the source or 7315 destination address, is only effective if the attacker can forward 7316 packets to the original endpoint. Packet protection ensures that the 7317 packet payloads can only be processed by the endpoints that completed 7318 the handshake, and invalid packets are ignored by those endpoints. 7320 An attacker can also modify the boundaries between packets and UDP 7321 datagrams, causing multiple packets to be coalesced into a single 7322 datagram, or splitting coalesced packets into multiple datagrams. 7323 Aside from datagrams containing Initial packets, which require 7324 padding, modification of how packets are arranged in datagrams has no 7325 functional effect on a connection, although it might change some 7326 performance characteristics. 7328 21.13.3. Connection Migration 7330 Connection Migration (Section 9) provides endpoints with the ability 7331 to transition between IP addresses and ports on multiple paths, using 7332 one path at a time for transmission and receipt of non-probing 7333 frames. Path validation (Section 8.2) establishes that a peer is 7334 both willing and able to receive packets sent on a particular path. 7335 This helps reduce the effects of address spoofing by limiting the 7336 number of packets sent to a spoofed address. 7338 This section describes the intended security properties of connection 7339 migration when under various types of DoS attacks. 7341 21.13.3.1. On-Path Active Attacks 7343 An attacker that can cause a packet it observes to no longer reach 7344 its intended destination is considered an on-path attacker. When an 7345 attacker is present between a client and server, endpoints are 7346 required to send packets through the attacker to establish 7347 connectivity on a given path. 7349 An on-path attacker can: 7351 * Inspect packets 7353 * Modify IP and UDP packet headers 7355 * Inject new packets 7357 * Delay packets 7359 * Reorder packets 7360 * Drop packets 7362 * Split and merge datagrams along packet boundaries 7364 An on-path attacker cannot: 7366 * Modify an authenticated portion of a packet and cause the 7367 recipient to accept that packet 7369 An on-path attacker has the opportunity to modify the packets that it 7370 observes, however any modifications to an authenticated portion of a 7371 packet will cause it to be dropped by the receiving endpoint as 7372 invalid, as packet payloads are both authenticated and encrypted. 7374 In the presence of an on-path attacker, QUIC aims to provide the 7375 following properties: 7377 1. An on-path attacker can prevent use of a path for a connection, 7378 causing it to fail if it cannot use a different path that does 7379 not contain the attacker. This can be achieved by dropping all 7380 packets, modifying them so that they fail to decrypt, or other 7381 methods. 7383 2. An on-path attacker can prevent migration to a new path for which 7384 the attacker is also on-path by causing path validation to fail 7385 on the new path. 7387 3. An on-path attacker cannot prevent a client from migrating to a 7388 path for which the attacker is not on-path. 7390 4. An on-path attacker can reduce the throughput of a connection by 7391 delaying packets or dropping them. 7393 5. An on-path attacker cannot cause an endpoint to accept a packet 7394 for which it has modified an authenticated portion of that 7395 packet. 7397 21.13.3.2. Off-Path Active Attacks 7399 An off-path attacker is not directly on the path between a client and 7400 server, but could be able to obtain copies of some or all packets 7401 sent between the client and the server. It is also able to send 7402 copies of those packets to either endpoint. 7404 An off-path attacker can: 7406 * Inspect packets 7407 * Inject new packets 7409 * Reorder injected packets 7411 An off-path attacker cannot: 7413 * Modify any part of a packet 7415 * Delay packets 7417 * Drop packets 7419 * Reorder original packets 7421 An off-path attacker can modify packets that it has observed and 7422 inject them back into the network, potentially with spoofed source 7423 and destination addresses. 7425 For the purposes of this discussion, it is assumed that an off-path 7426 attacker has the ability to observe, modify, and re-inject a packet 7427 into the network that will reach the destination endpoint prior to 7428 the arrival of the original packet observed by the attacker. In 7429 other words, an attacker has the ability to consistently "win" a race 7430 with the legitimate packets between the endpoints, potentially 7431 causing the original packet to be ignored by the recipient. 7433 It is also assumed that an attacker has the resources necessary to 7434 affect NAT state, potentially both causing an endpoint to lose its 7435 NAT binding, and an attacker to obtain the same port for use with its 7436 traffic. 7438 In the presence of an off-path attacker, QUIC aims to provide the 7439 following properties: 7441 1. An off-path attacker can race packets and attempt to become a 7442 "limited" on-path attacker. 7444 2. An off-path attacker can cause path validation to succeed for 7445 forwarded packets with the source address listed as the off-path 7446 attacker as long as it can provide improved connectivity between 7447 the client and the server. 7449 3. An off-path attacker cannot cause a connection to close once the 7450 handshake has completed. 7452 4. An off-path attacker cannot cause migration to a new path to fail 7453 if it cannot observe the new path. 7455 5. An off-path attacker can become a limited on-path attacker during 7456 migration to a new path for which it is also an off-path 7457 attacker. 7459 6. An off-path attacker can become a limited on-path attacker by 7460 affecting shared NAT state such that it sends packets to the 7461 server from the same IP address and port that the client 7462 originally used. 7464 21.13.3.3. Limited On-Path Active Attacks 7466 A limited on-path attacker is an off-path attacker that has offered 7467 improved routing of packets by duplicating and forwarding original 7468 packets between the server and the client, causing those packets to 7469 arrive before the original copies such that the original packets are 7470 dropped by the destination endpoint. 7472 A limited on-path attacker differs from an on-path attacker in that 7473 it is not on the original path between endpoints, and therefore the 7474 original packets sent by an endpoint are still reaching their 7475 destination. This means that a future failure to route copied 7476 packets to the destination faster than their original path will not 7477 prevent the original packets from reaching the destination. 7479 A limited on-path attacker can: 7481 * Inspect packets 7483 * Inject new packets 7485 * Modify unencrypted packet headers 7487 * Reorder packets 7489 A limited on-path attacker cannot: 7491 * Delay packets so that they arrive later than packets sent on the 7492 original path 7494 * Drop packets 7496 * Modify the authenticated and encrypted portion of a packet and 7497 cause the recipient to accept that packet 7499 A limited on-path attacker can only delay packets up to the point 7500 that the original packets arrive before the duplicate packets, 7501 meaning that it cannot offer routing with worse latency than the 7502 original path. If a limited on-path attacker drops packets, the 7503 original copy will still arrive at the destination endpoint. 7505 In the presence of a limited on-path attacker, QUIC aims to provide 7506 the following properties: 7508 1. A limited on-path attacker cannot cause a connection to close 7509 once the handshake has completed. 7511 2. A limited on-path attacker cannot cause an idle connection to 7512 close if the client is first to resume activity. 7514 3. A limited on-path attacker can cause an idle connection to be 7515 deemed lost if the server is the first to resume activity. 7517 Note that these guarantees are the same guarantees provided for any 7518 NAT, for the same reasons. 7520 22. IANA Considerations 7522 This document establishes several registries for the management of 7523 codepoints in QUIC. These registries operate on a common set of 7524 policies as defined in Section 22.1. 7526 22.1. Registration Policies for QUIC Registries 7528 All QUIC registries allow for both provisional and permanent 7529 registration of codepoints. This section documents policies that are 7530 common to these registries. 7532 22.1.1. Provisional Registrations 7534 Provisional registration of codepoints are intended to allow for 7535 private use and experimentation with extensions to QUIC. Provisional 7536 registrations only require the inclusion of the codepoint value and 7537 contact information. However, provisional registrations could be 7538 reclaimed and reassigned for another purpose. 7540 Provisional registrations require Expert Review, as defined in 7541 Section 4.5 of [RFC8126]. Designated expert(s) are advised that only 7542 registrations for an excessive proportion of remaining codepoint 7543 space or the very first unassigned value (see Section 22.1.2) can be 7544 rejected. 7546 Provisional registrations will include a date field that indicates 7547 when the registration was last updated. A request to update the date 7548 on any provisional registration can be made without review from the 7549 designated expert(s). 7551 All QUIC registries include the following fields to support 7552 provisional registration: 7554 Value: The assigned codepoint. 7556 Status: "Permanent" or "Provisional". 7558 Specification: A reference to a publicly available specification for 7559 the value. 7561 Date: The date of last update to the registration. 7563 Contact: Contact details for the registrant. 7565 Notes: Supplementary notes about the registration. 7567 Provisional registrations MAY omit the Specification and Notes 7568 fields, plus any additional fields that might be required for a 7569 permanent registration. The Date field is not required as part of 7570 requesting a registration as it is set to the date the registration 7571 is created or updated. 7573 22.1.2. Selecting Codepoints 7575 New uses of codepoints from QUIC registries SHOULD use a randomly 7576 selected codepoint that excludes both existing allocations and the 7577 first unallocated codepoint in the selected space. Requests for 7578 multiple codepoints MAY use a contiguous range. This minimizes the 7579 risk that differing semantics are attributed to the same codepoint by 7580 different implementations. Use of the first codepoint in a range is 7581 intended for use by specifications that are developed through the 7582 standards process [STD] and its allocation MUST be negotiated with 7583 IANA before use. 7585 For codepoints that are encoded in variable-length integers 7586 (Section 16), such as frame types, codepoints that encode to four or 7587 eight bytes (that is, values 2^14 and above) SHOULD be used unless 7588 the usage is especially sensitive to having a longer encoding. 7590 Applications to register codepoints in QUIC registries MAY include a 7591 codepoint as part of the registration. IANA MUST allocate the 7592 selected codepoint unless that codepoint is already assigned or the 7593 codepoint is the first unallocated codepoint in the registry. 7595 22.1.3. Reclaiming Provisional Codepoints 7597 A request might be made to remove an unused provisional registration 7598 from the registry to reclaim space in a registry, or portion of the 7599 registry (such as the 64-16383 range for codepoints that use 7600 variable-length encodings). This SHOULD be done only for the 7601 codepoints with the earliest recorded date and entries that have been 7602 updated less than a year prior SHOULD NOT be reclaimed. 7604 A request to remove a codepoint MUST be reviewed by the designated 7605 expert(s). The expert(s) MUST attempt to determine whether the 7606 codepoint is still in use. Experts are advised to contact the listed 7607 contacts for the registration, plus as wide a set of protocol 7608 implementers as possible in order to determine whether any use of the 7609 codepoint is known. The expert(s) are advised to allow at least four 7610 weeks for responses. 7612 If any use of the codepoints is identified by this search or a 7613 request to update the registration is made, the codepoint MUST NOT be 7614 reclaimed. Instead, the date on the registration is updated. A note 7615 might be added for the registration recording relevant information 7616 that was learned. 7618 If no use of the codepoint was identified and no request was made to 7619 update the registration, the codepoint MAY be removed from the 7620 registry. 7622 This process also applies to requests to change a provisional 7623 registration into a permanent registration, except that the goal is 7624 not to determine whether there is no use of the codepoint, but to 7625 determine that the registration is an accurate representation of any 7626 deployed usage. 7628 22.1.4. Permanent Registrations 7630 Permanent registrations in QUIC registries use the Specification 7631 Required policy ([RFC8126]), unless otherwise specified. The 7632 designated expert(s) verify that a specification exists and is 7633 readily accessible. Expert(s) are encouraged to be biased towards 7634 approving registrations unless they are abusive, frivolous, or 7635 actively harmful (not merely aesthetically displeasing, or 7636 architecturally dubious). The creation of a registry MAY specify 7637 additional constraints on permanent registrations. 7639 The creation of a registry MAY identify a range of codepoints where 7640 registrations are governed by a different registration policy. For 7641 instance, the registries for 62-bit codepoints in this document have 7642 stricter policies for codepoints in the range from 0 to 63. 7644 Any stricter requirements for permanent registrations do not prevent 7645 provisional registrations for affected codepoints. For instance, a 7646 provisional registration for a frame type (Section 22.3) of 61 could 7647 be requested. 7649 All registrations made by Standards Track publications MUST be 7650 permanent. 7652 All registrations in this document are assigned a permanent status 7653 and list as contact the IETF (quic@ietf.org). 7655 22.2. QUIC Transport Parameter Registry 7657 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 7658 under a "QUIC" heading. 7660 The "QUIC Transport Parameters" registry governs a 62-bit space. 7661 This registry follows the registration policy from Section 22.1. 7662 Permanent registrations in this registry are assigned using the 7663 Specification Required policy ([RFC8126]). 7665 In addition to the fields in Section 22.1.1, permanent registrations 7666 in this registry MUST include the following field: 7668 Parameter Name: A short mnemonic for the parameter. 7670 The initial contents of this registry are shown in Table 6. 7672 +=======+=====================================+===============+ 7673 | Value | Parameter Name | Specification | 7674 +=======+=====================================+===============+ 7675 | 0x00 | original_destination_connection_id | Section 18.2 | 7676 +-------+-------------------------------------+---------------+ 7677 | 0x01 | max_idle_timeout | Section 18.2 | 7678 +-------+-------------------------------------+---------------+ 7679 | 0x02 | stateless_reset_token | Section 18.2 | 7680 +-------+-------------------------------------+---------------+ 7681 | 0x03 | max_udp_payload_size | Section 18.2 | 7682 +-------+-------------------------------------+---------------+ 7683 | 0x04 | initial_max_data | Section 18.2 | 7684 +-------+-------------------------------------+---------------+ 7685 | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 | 7686 +-------+-------------------------------------+---------------+ 7687 | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 | 7688 +-------+-------------------------------------+---------------+ 7689 | 0x07 | initial_max_stream_data_uni | Section 18.2 | 7690 +-------+-------------------------------------+---------------+ 7691 | 0x08 | initial_max_streams_bidi | Section 18.2 | 7692 +-------+-------------------------------------+---------------+ 7693 | 0x09 | initial_max_streams_uni | Section 18.2 | 7694 +-------+-------------------------------------+---------------+ 7695 | 0x0a | ack_delay_exponent | Section 18.2 | 7696 +-------+-------------------------------------+---------------+ 7697 | 0x0b | max_ack_delay | Section 18.2 | 7698 +-------+-------------------------------------+---------------+ 7699 | 0x0c | disable_active_migration | Section 18.2 | 7700 +-------+-------------------------------------+---------------+ 7701 | 0x0d | preferred_address | Section 18.2 | 7702 +-------+-------------------------------------+---------------+ 7703 | 0x0e | active_connection_id_limit | Section 18.2 | 7704 +-------+-------------------------------------+---------------+ 7705 | 0x0f | initial_source_connection_id | Section 18.2 | 7706 +-------+-------------------------------------+---------------+ 7707 | 0x10 | retry_source_connection_id | Section 18.2 | 7708 +-------+-------------------------------------+---------------+ 7710 Table 6: Initial QUIC Transport Parameters Entries 7712 Additionally, each value of the format "31 * N + 27" for integer 7713 values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be 7714 assigned by IANA. 7716 22.3. QUIC Frame Types Registry 7718 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 7719 "QUIC" heading. 7721 The "QUIC Frame Types" registry governs a 62-bit space. This 7722 registry follows the registration policy from Section 22.1. 7723 Permanent registrations in this registry are assigned using the 7724 Specification Required policy ([RFC8126]), except for values between 7725 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 7726 Standards Action or IESG Approval as defined in Section 4.9 and 4.10 7727 of [RFC8126]. 7729 In addition to the fields in Section 22.1.1, permanent registrations 7730 in this registry MUST include the following field: 7732 Frame Name: A short mnemonic for the frame type. 7734 In addition to the advice in Section 22.1, specifications for new 7735 permanent registrations SHOULD describe the means by which an 7736 endpoint might determine that it can send the identified type of 7737 frame. An accompanying transport parameter registration is expected 7738 for most registrations; see Section 22.2. Specifications for 7739 permanent registrations also need to describe the format and assigned 7740 semantics of any fields in the frame. 7742 The initial contents of this registry are tabulated in Table 3. Note 7743 that the registry does not include the "Pkts" and "Spec" columns from 7744 Table 3. 7746 22.4. QUIC Transport Error Codes Registry 7748 IANA [SHALL add/has added] a registry for "QUIC Transport Error 7749 Codes" under a "QUIC" heading. 7751 The "QUIC Transport Error Codes" registry governs a 62-bit space. 7752 This space is split into three regions that are governed by different 7753 policies. Permanent registrations in this registry are assigned 7754 using the Specification Required policy ([RFC8126]), except for 7755 values between 0x00 and 0x3f (in hexadecimal; inclusive), which are 7756 assigned using Standards Action or IESG Approval as defined in 7757 Section 4.9 and 4.10 of [RFC8126]. 7759 In addition to the fields in Section 22.1.1, permanent registrations 7760 in this registry MUST include the following fields: 7762 Code: A short mnemonic for the parameter. 7764 Description: A brief description of the error code semantics, which 7765 MAY be a summary if a specification reference is provided. 7767 The initial contents of this registry are shown in Table 7. 7769 +======+===========================+================+===============+ 7770 |Value | Error |Description | Specification | 7771 +======+===========================+================+===============+ 7772 |0x0 | NO_ERROR |No error | Section 20 | 7773 +------+---------------------------+----------------+---------------+ 7774 |0x1 | INTERNAL_ERROR |Implementation | Section 20 | 7775 | | |error | | 7776 +------+---------------------------+----------------+---------------+ 7777 |0x2 | CONNECTION_REFUSED |Server refuses a| Section 20 | 7778 | | |connection | | 7779 +------+---------------------------+----------------+---------------+ 7780 |0x3 | FLOW_CONTROL_ERROR |Flow control | Section 20 | 7781 | | |error | | 7782 +------+---------------------------+----------------+---------------+ 7783 |0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 | 7784 | | |opened | | 7785 +------+---------------------------+----------------+---------------+ 7786 |0x5 | STREAM_STATE_ERROR |Frame received | Section 20 | 7787 | | |in invalid | | 7788 | | |stream state | | 7789 +------+---------------------------+----------------+---------------+ 7790 |0x6 | FINAL_SIZE_ERROR |Change to final | Section 20 | 7791 | | |size | | 7792 +------+---------------------------+----------------+---------------+ 7793 |0x7 | FRAME_ENCODING_ERROR |Frame encoding | Section 20 | 7794 | | |error | | 7795 +------+---------------------------+----------------+---------------+ 7796 |0x8 | TRANSPORT_PARAMETER_ERROR |Error in | Section 20 | 7797 | | |transport | | 7798 | | |parameters | | 7799 +------+---------------------------+----------------+---------------+ 7800 |0x9 | CONNECTION_ID_LIMIT_ERROR |Too many | Section 20 | 7801 | | |connection IDs | | 7802 | | |received | | 7803 +------+---------------------------+----------------+---------------+ 7804 |0xa | PROTOCOL_VIOLATION |Generic protocol| Section 20 | 7805 | | |violation | | 7806 +------+---------------------------+----------------+---------------+ 7807 |0xb | INVALID_TOKEN |Invalid Token | Section 20 | 7808 | | |Received | | 7809 +------+---------------------------+----------------+---------------+ 7810 |0xc | APPLICATION_ERROR |Application | Section 20 | 7811 | | |error | | 7812 +------+---------------------------+----------------+---------------+ 7813 |0xd | CRYPTO_BUFFER_EXCEEDED |CRYPTO data | Section 20 | 7814 | | |buffer | | 7815 | | |overflowed | | 7816 +------+---------------------------+----------------+---------------+ 7817 |0xe | KEY_UPDATE_ERROR |Invalid packet | Section 20 | 7818 | | |protection | | 7819 | | |update | | 7820 +------+---------------------------+----------------+---------------+ 7821 |0xf | AEAD_LIMIT_REACHED |Excessive use of| Section 20 | 7822 | | |packet | | 7823 | | |protection keys | | 7824 +------+---------------------------+----------------+---------------+ 7826 Table 7: Initial QUIC Transport Error Codes Entries 7828 23. References 7830 23.1. Normative References 7832 [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 7833 Völker, "Packetization Layer Path MTU Discovery for 7834 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 7835 September 2020, . 7837 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 7838 DOI 10.17487/RFC0791, September 1981, 7839 . 7841 [QUIC-RECOVERY] 7842 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 7843 and Congestion Control", Work in Progress, Internet-Draft, 7844 draft-ietf-quic-recovery-31, 25 September 2020, 7845 . 7847 [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport 7848 Layer Security (TLS) to Secure QUIC", Work in Progress, 7849 Internet-Draft, draft-ietf-quic-tls-31, 25 September 2020, 7850 . 7852 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 7853 DOI 10.17487/RFC1191, November 1990, 7854 . 7856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7857 Requirement Levels", BCP 14, RFC 2119, 7858 DOI 10.17487/RFC2119, March 1997, 7859 . 7861 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 7862 of Explicit Congestion Notification (ECN) to IP", 7863 RFC 3168, DOI 10.17487/RFC3168, September 2001, 7864 . 7866 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 7867 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 7868 2003, . 7870 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 7871 "Randomness Requirements for Security", BCP 106, RFC 4086, 7872 DOI 10.17487/RFC4086, June 2005, 7873 . 7875 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 7876 "IPv6 Flow Label Specification", RFC 6437, 7877 DOI 10.17487/RFC6437, November 2011, 7878 . 7880 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 7881 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 7882 March 2017, . 7884 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 7885 Writing an IANA Considerations Section in RFCs", BCP 26, 7886 RFC 8126, DOI 10.17487/RFC8126, June 2017, 7887 . 7889 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 7890 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 7891 May 2017, . 7893 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 7894 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 7895 DOI 10.17487/RFC8201, July 2017, 7896 . 7898 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 7899 Notification (ECN) Experimentation", RFC 8311, 7900 DOI 10.17487/RFC8311, January 2018, 7901 . 7903 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 7904 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 7905 . 7907 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 7908 DOI 10.17487/RFC0768, August 1980, 7909 . 7911 23.2. Informative References 7913 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 7914 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 7915 . 7917 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 7918 "Transport Layer Security (TLS) Application-Layer Protocol 7919 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 7920 July 2014, . 7922 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 7923 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 7924 April 2016, . 7926 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 7927 Defeating Denial of Service Attacks which employ IP Source 7928 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 7929 May 2000, . 7931 [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, 7932 DOI 10.17487/RFC6265, April 2011, 7933 . 7935 [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses 7936 for cross-site request forgery", Proceedings of the 15th 7937 ACM conference on Computer and communications security - 7938 CCS '08, DOI 10.1145/1455770.1455782, 2008, 7939 . 7941 [EARLY-DESIGN] 7942 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2 7943 December 2013, . 7945 [GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., 7946 Sarolahti, P., and M. Kojo, "An experimental study of home 7947 gateway characteristics", Proceedings of the 10th annual 7948 conference on Internet measurement - IMC '10, 7949 DOI 10.1145/1879141.1879174, 2010, 7950 . 7952 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 7953 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 7954 DOI 10.17487/RFC7540, May 2015, 7955 . 7957 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 7958 (IPv6) Specification", STD 86, RFC 8200, 7959 DOI 10.17487/RFC8200, July 2017, 7960 . 7962 [QUIC-INVARIANTS] 7963 Thomson, M., "Version-Independent Properties of QUIC", 7964 Work in Progress, Internet-Draft, draft-ietf-quic- 7965 invariants-11, 25 September 2020, 7966 . 7969 [QUIC-MANAGEABILITY] 7970 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 7971 Transport Protocol", Work in Progress, Internet-Draft, 7972 draft-ietf-quic-manageability-07, 8 July 2020, 7973 . 7976 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 7977 RFC 1812, DOI 10.17487/RFC1812, June 1995, 7978 . 7980 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 7981 J., and E. Lear, "Address Allocation for Private 7982 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 7983 February 1996, . 7985 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 7986 Selective Acknowledgment Options", RFC 2018, 7987 DOI 10.17487/RFC2018, October 1996, 7988 . 7990 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 7991 Hashing for Message Authentication", RFC 2104, 7992 DOI 10.17487/RFC2104, February 1997, 7993 . 7995 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 7996 Sooriyabandara, "TCP Performance Implications of Network 7997 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 7998 December 2002, . 8000 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 8001 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 8002 . 8004 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 8005 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 8006 2006, . 8008 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 8009 Control Message Protocol (ICMPv6) for the Internet 8010 Protocol Version 6 (IPv6) Specification", STD 89, 8011 RFC 4443, DOI 10.17487/RFC4443, March 2006, 8012 . 8014 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 8015 Translation (NAT) Behavioral Requirements for Unicast 8016 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 8017 2007, . 8019 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 8020 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 8021 . 8023 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 8024 Key Derivation Function (HKDF)", RFC 5869, 8025 DOI 10.17487/RFC5869, May 2010, 8026 . 8028 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 8029 Explicit Congestion Notification (ECN)", RFC 8087, 8030 DOI 10.17487/RFC8087, March 2017, 8031 . 8033 [SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 8034 Text on Security Considerations", BCP 72, RFC 3552, 8035 DOI 10.17487/RFC3552, July 2003, 8036 . 8038 [SLOWLORIS] 8039 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 8040 . 8043 [STD] Bradner, S., "The Internet Standards Process -- Revision 8044 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 8045 . 8047 Appendix A. Sample Packet Number Decoding Algorithm 8049 The pseudo-code in Figure 45 shows how an implementation can decode 8050 packet numbers after header protection has been removed. 8052 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 8053 expected_pn = largest_pn + 1 8054 pn_win = 1 << pn_nbits 8055 pn_hwin = pn_win / 2 8056 pn_mask = pn_win - 1 8057 // The incoming packet number should be greater than 8058 // expected_pn - pn_hwin and less than or equal to 8059 // expected_pn + pn_hwin 8060 // 8061 // This means we cannot just strip the trailing bits from 8062 // expected_pn and add the truncated_pn because that might 8063 // yield a value outside the window. 8064 // 8065 // The following code calculates a candidate value and 8066 // makes sure it's within the packet number window. 8067 // Note the extra checks to prevent overflow and underflow. 8068 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 8069 if candidate_pn <= expected_pn - pn_hwin and 8070 candidate_pn < (1 << 62) - pn_win: 8071 return candidate_pn + pn_win 8072 if candidate_pn > expected_pn + pn_hwin and 8073 candidate_pn >= pn_win: 8074 return candidate_pn - pn_win 8075 return candidate_pn 8077 Figure 45: Sample Packet Number Decoding Algorithm 8079 Appendix B. Sample ECN Validation Algorithm 8081 Each time an endpoint commences sending on a new network path, it 8082 determines whether the path supports ECN; see Section 13.4. If the 8083 path supports ECN, the goal is to use ECN. Endpoints might also 8084 periodically reassess a path that was determined to not support ECN. 8086 This section describes one method for testing new paths. This 8087 algorithm is intended to show how a path might be tested for ECN 8088 support. Endpoints can implement different methods. 8090 The path is assigned an ECN state that is one of "testing", 8091 "unknown", "failed", or "capable". On paths with a "testing" or 8092 "capable" state the endpoint sends packets with an ECT marking, by 8093 default ECT(0); otherwise, the endpoint sends unmarked packets. 8095 To start testing a path, the ECN state is set to "testing" and 8096 existing ECN counts are remembered as a baseline. 8098 The testing period runs for a number of packets or a limited time, as 8099 determined by the endpoint. The goal is not to limit the duration of 8100 the testing period, but to ensure that enough marked packets are sent 8101 for received ECN counts to provide a clear indication of how the path 8102 treats marked packets. Section 13.4.2 suggests limiting this to 10 8103 packets or 3 times the probe timeout. 8105 After the testing period ends, the ECN state for the path becomes 8106 "unknown". From the "unknown" state, successful validation of the 8107 ECN counts an ACK frame (see Section 13.4.2.1) causes the ECN state 8108 for the path to become "capable", unless no marked packet has been 8109 acknowledged. 8111 If validation of ECN counts fails at any time, the ECN state for the 8112 affected path becomes "failed". An endpoint can also mark the ECN 8113 state for a path as "failed" if marked packets are all declared lost 8114 or if they are all CE marked. 8116 Following this algorithm ensures that ECN is rarely disabled for 8117 paths that properly support ECN. Any path that incorrectly modifies 8118 markings will cause ECN to be disabled. For those rare cases where 8119 marked packets are discarded by the path, the short duration of the 8120 testing period limits the number of losses incurred. 8122 Appendix C. Change Log 8124 *RFC Editor's Note:* Please remove this section prior to 8125 publication of a final version of this document. 8127 Issue and pull request numbers are listed with a leading octothorp. 8129 C.1. Since draft-ietf-quic-transport-30 8131 * Use TRANSPORT_PARAMETER_ERROR for an invalid transport parameter 8132 (#4099, #4100) 8134 * Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict 8135 (#4087, #4088) 8137 * Allow use of address validation token when server address changes 8138 (#4076, #4089) 8140 C.2. Since draft-ietf-quic-transport-29 8142 * Require the same connection ID on coalesced packets (#3800, #3930) 8143 * Allow caching of packets that can't be decrypted, by allowing the 8144 reported acknowledgment delay to exceed max_ack_delay prior to 8145 confirming the handshake (#3821, #3980, #4035, #3874) 8147 * Allow connection ID to be used for address validation (#3834, 8148 #3924) 8150 * Required protocol operations are no longer directed at 8151 implementations, but are features provided to application 8152 protocols (#3838, #3935) 8154 * Narrow requirements for reset of congestion state on path change 8155 (#3842, #3945) 8157 * Add a three times amplification limit for sending of 8158 CONNECTION_CLOSE with reduced state (#3845, #3864) 8160 * Change error code for invalid RETIRE_CONNECTION_ID frames (#3860, 8161 #3861) 8163 * Recommend retention of state for lost packets to allow for late 8164 arrival and avoid unnecessary retransmission (#3956, #3957) 8166 * Allow a server to reject connections if a client reuses packet 8167 numbers after Retry (#3989, #3990) 8169 * Limit recommendation for immediate acknowledgment to when ack- 8170 eliciting packets are reordered (#4001, #4000) 8172 C.3. Since draft-ietf-quic-transport-28 8174 * Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED 8175 (#3709, #3690, #3694) 8177 * Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs 8178 (#3703, #3691) 8180 * Integrate QUIC-specific language from draft-ietf-tsvwg-datagram- 8181 plpmtud (#3695, #3702) 8183 * disable_active_migration does not apply to the addresses offered 8184 in server_preferred_address (#3608, #3670) 8186 C.4. Since draft-ietf-quic-transport-27 8187 * Allowed CONNECTION_CLOSE in any packet number space, with a 8188 requirement to use a new transport-level error for application- 8189 specific errors in Initial and Handshake packets (#3430, #3435, 8190 #3440) 8192 * Clearer requirements for address validation (#2125, #3327) 8194 * Security analysis of handshake and migration (#2143, #2387, #2925) 8196 * The entire payload of a datagram is used when counting bytes for 8197 mitigating amplification attacks (#3333, #3470) 8199 * Connection IDs can be used at any time, including in the handshake 8200 (#3348, #3560, #3438, #3565) 8202 * Only one ACK should be sent for each instance of reordering 8203 (#3357, #3361) 8205 * Remove text allowing a server to proceed with a bad Retry token 8206 (#3396, #3398) 8208 * Ignore active_connection_id_limit with a zero-length connection ID 8209 (#3427, #3426) 8211 * Require active_connection_id_limit be remembered for 0-RTT (#3423, 8212 #3425) 8214 * Require ack_delay not be remembered for 0-RTT (#3433, #3545) 8216 * Redefined max_packet_size to max_udp_datagram_size (#3471, #3473) 8218 * Guidance on limiting outstanding attempts to retire connection IDs 8219 (#3489, #3509, #3557, #3547) 8221 * Restored text on dropping bogus Version Negotiation packets 8222 (#3532, #3533) 8224 * Clarified that largest acknowledged needs to be saved, but not 8225 necessarily signaled in all cases (#3541, #3581) 8227 * Addressed linkability risk with the use of preferred_address 8228 (#3559, #3563) 8230 * Added authentication of handshake connection IDs (#3439, #3499) 8232 * Opening a stream in the wrong direction is an error (#3527) 8234 C.5. Since draft-ietf-quic-transport-26 8236 * Change format of transport parameters to use varints (#3294, 8237 #3169) 8239 C.6. Since draft-ietf-quic-transport-25 8241 * Define the use of CONNECTION_CLOSE prior to establishing 8242 connection state (#3269, #3297, #3292) 8244 * Allow use of address validation tokens after client address 8245 changes (#3307, #3308) 8247 * Define the timer for address validation (#2910, #3339) 8249 C.7. Since draft-ietf-quic-transport-24 8251 * Added HANDSHAKE_DONE to signal handshake confirmation (#2863, 8252 #3142, #3145) 8254 * Add integrity check to Retry packets (#3014, #3274, #3120) 8256 * Specify handling of reordered NEW_CONNECTION_ID frames (#3194, 8257 #3202) 8259 * Require checking of sequence numbers in RETIRE_CONNECTION_ID 8260 (#3037, #3036) 8262 * active_connection_id_limit is enforced (#3193, #3197, #3200, 8263 #3201) 8265 * Correct overflow in packet number decode algorithm (#3187, #3188) 8267 * Allow use of CRYPTO_BUFFER_EXCEEDED for CRYPTO frame errors 8268 (#3258, #3186) 8270 * Define applicability and scope of NEW_TOKEN (#3150, #3152, #3155, 8271 #3156) 8273 * Tokens from Retry and NEW_TOKEN must be differentiated (#3127, 8274 #3128) 8276 * Allow CONNECTION_CLOSE in response to invalid token (#3168, #3107) 8278 * Treat an invalid CONNECTION_CLOSE as an invalid frame (#2475, 8279 #3230, #3231) 8281 * Throttle when sending CONNECTION_CLOSE after discarding state 8282 (#3095, #3157) 8284 * Application-variant of CONNECTION_CLOSE can only be sent in 0-RTT 8285 or 1-RTT packets (#3158, #3164) 8287 * Advise sending while blocked to avoid idle timeout (#2744, #3266) 8289 * Define error codes for invalid frames (#3027, #3042) 8291 * Idle timeout is symmetric (#2602, #3099) 8293 * Prohibit IP fragmentation (#3243, #3280) 8295 * Define the use of provisional registration for all registries 8296 (#3109, #3020, #3102, #3170) 8298 * Packets on one path must not adjust values for a different path 8299 (#2909, #3139) 8301 C.8. Since draft-ietf-quic-transport-23 8303 * Allow ClientHello to span multiple packets (#2928, #3045) 8305 * Client Initial size constraints apply to UDP datagram payload 8306 (#3053, #3051) 8308 * Stateless reset changes (#2152, #2993) 8310 - tokens need to be compared in constant time 8312 - detection uses UDP datagrams, not packets 8314 - tokens cannot be reused (#2785, #2968) 8316 * Clearer rules for sharing of UDP ports and use of connection IDs 8317 when doing so (#2844, #2851) 8319 * A new connection ID is necessary when responding to migration 8320 (#2778, #2969) 8322 * Stronger requirements for connection ID retirement (#3046, #3096) 8324 * NEW_TOKEN cannot be empty (#2978, #2977) 8326 * PING can be sent at any encryption level (#3034, #3035) 8328 * CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) 8329 * Frame encoding error conditions updated (#3027, #3042) 8331 * Non-ack-eliciting packets cannot be sent in response to non-ack- 8332 eliciting packets (#3100, #3104) 8334 * Servers have to change connection IDs in Retry (#2837, #3147) 8336 C.9. Since draft-ietf-quic-transport-22 8338 * Rules for preventing correlation by connection ID tightened 8339 (#2084, #2929) 8341 * Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, 8342 #2541, #2688) 8344 * Discourage regressions of largest acknowledged in ACK (#2205, 8345 #2752) 8347 * Improved robustness of validation process for ECN counts (#2534, 8348 #2752) 8350 * Require endpoints to ignore spurious migration attempts (#2342, 8351 #2893) 8353 * Transport parameter for disabling migration clarified to allow NAT 8354 rebinding (#2389, #2893) 8356 * Document principles for defining new error codes (#2388, #2880) 8358 * Reserve transport parameters for greasing (#2550, #2873) 8360 * A maximum ACK delay of 0 is used for handshake packet number 8361 spaces (#2646, #2638) 8363 * Improved rules for use of congestion control state on new paths 8364 (#2685, #2918) 8366 * Removed recommendation to coordinate spin for multiple connections 8367 that share a path (#2763, #2882) 8369 * Allow smaller stateless resets and recommend a smaller minimum on 8370 packets that might trigger a stateless reset (#2770, #2869, #2927, 8371 #3007). 8373 * Provide guidance around the interface to QUIC as used by 8374 application protocols (#2805, #2857) 8376 * Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, 8377 #2826) 8379 * Tighter rules about processing of rejected 0-RTT packets (#2829, 8380 #2840, #2841) 8382 * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) 8384 * Cryptographic handshake needs to provide server transport 8385 parameter encryption (#2920, #2921) 8387 * Moved ACK generation guidance from recovery draft to transport 8388 draft (#1860, #2916). 8390 C.10. Since draft-ietf-quic-transport-21 8392 * Connection ID lengths are now one octet, but limited in version 1 8393 to 20 octets of length (#2736, #2749) 8395 C.11. Since draft-ietf-quic-transport-20 8397 * Error codes are encoded as variable-length integers (#2672, #2680) 8399 * NEW_CONNECTION_ID includes a request to retire old connection IDs 8400 (#2645, #2769) 8402 * Tighter rules for generating and explicitly eliciting ACK frames 8403 (#2546, #2794) 8405 * Recommend having only one packet per encryption level in a 8406 datagram (#2308, #2747) 8408 * More normative language about use of stateless reset (#2471, 8409 #2574) 8411 * Allow reuse of stateless reset tokens (#2732, #2733) 8413 * Allow, but not require, enforcing non-duplicate transport 8414 parameters (#2689, #2691) 8416 * Added an active_connection_id_limit transport parameter (#1994, 8417 #1998) 8419 * max_ack_delay transport parameter defaults to 0 (#2638, #2646) 8421 * When sending 0-RTT, only remembered transport parameters apply 8422 (#2458, #2360, #2466, #2461) 8424 * Define handshake completion and confirmation; define clearer rules 8425 when it encryption keys should be discarded (#2214, #2267, #2673) 8427 * Prohibit path migration prior to handshake confirmation (#2309, 8428 #2370) 8430 * PATH_RESPONSE no longer needs to be received on the validated path 8431 (#2582, #2580, #2579, #2637) 8433 * PATH_RESPONSE frames are not stored and retransmitted (#2724, 8434 #2729) 8436 * Document hack for enabling routing of ICMP when doing PMTU probing 8437 (#1243, #2402) 8439 C.12. Since draft-ietf-quic-transport-19 8441 * Refine discussion of 0-RTT transport parameters (#2467, #2464) 8443 * Fewer transport parameters need to be remembered for 0-RTT (#2624, 8444 #2467) 8446 * Spin bit text incorporated (#2564) 8448 * Close the connection when maximum stream ID in MAX_STREAMS exceeds 8449 2^62 - 1 (#2499, #2487) 8451 * New connection ID required for intentional migration (#2414, 8452 #2413) 8454 * Connection ID issuance can be rate-limited (#2436, #2428) 8456 * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) 8458 * Initial packets from clients need to be padded to 1200 unless a 8459 Handshake packet is sent as well (#2522, #2523) 8461 * CRYPTO frames can be discarded if too much data is buffered 8462 (#1834, #2524) 8464 * Stateless reset uses a short header packet (#2599, #2600) 8466 C.13. Since draft-ietf-quic-transport-18 8468 * Removed version negotiation; version negotiation, including 8469 authentication of the result, will be addressed in the next 8470 version of QUIC (#1773, #2313) 8472 * Added discussion of the use of IPv6 flow labels (#2348, #2399) 8474 * A connection ID can't be retired in a packet that uses that 8475 connection ID (#2101, #2420) 8477 * Idle timeout transport parameter is in milliseconds (from seconds) 8478 (#2453, #2454) 8480 * Endpoints are required to use new connection IDs when they use new 8481 network paths (#2413, #2414) 8483 * Increased the set of permissible frames in 0-RTT (#2344, #2355) 8485 C.14. Since draft-ietf-quic-transport-17 8487 * Stream-related errors now use STREAM_STATE_ERROR (#2305) 8489 * Endpoints discard initial keys as soon as handshake keys are 8490 available (#1951, #2045) 8492 * Expanded conditions for ignoring ICMP packet too big messages 8493 (#2108, #2161) 8495 * Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, 8496 #2241) 8498 * Endpoints are permitted to discard malformed initial packets 8499 (#2141) 8501 * Clarified ECN implementation and usage requirements (#2156, #2201) 8503 * Disable ECN count verification for packets that arrive out of 8504 order (#2198, #2215) 8506 * Use Probe Timeout (PTO) instead of RTO (#2206, #2238) 8508 * Loosen constraints on retransmission of ACK ranges (#2199, #2245) 8510 * Limit Retry and Version Negotiation to once per datagram (#2259, 8511 #2303) 8513 * Set a maximum value for max_ack_delay transport parameter (#2282, 8514 #2301) 8516 * Allow server preferred address for both IPv4 and IPv6 (#2122, 8517 #2296) 8519 * Corrected requirements for migration to a preferred address 8520 (#2146, #2349) 8522 * ACK of non-existent packet is illegal (#2298, #2302) 8524 C.15. Since draft-ietf-quic-transport-16 8526 * Stream limits are defined as counts, not maximums (#1850, #1906) 8528 * Require amplification attack defense after closing (#1905, #1911) 8530 * Remove reservation of application error code 0 for STOPPING 8531 (#1804, #1922) 8533 * Renumbered frames (#1945) 8535 * Renumbered transport parameters (#1946) 8537 * Numeric transport parameters are expressed as varints (#1608, 8538 #1947, #1955) 8540 * Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 8542 * Rework the first byte (#2006) 8544 - Fix the 0x40 bit 8546 - Change type values for long header 8548 - Add spin bit to short header (#631, #1988) 8550 - Encrypt the remainder of the first byte (#1322) 8552 - Move packet number length to first byte 8554 - Move ODCIL to first byte of retry packets 8556 - Simplify packet number protection (#1575) 8558 * Allow STOP_SENDING to open a remote bidirectional stream (#1797, 8559 #2013) 8561 * Added mitigation for off-path migration attacks (#1278, #1749, 8562 #2033) 8564 * Don't let the PMTU to drop below 1280 (#2063, #2069) 8566 * Require peers to replace retired connection IDs (#2085) 8567 * Servers are required to ignore Version Negotiation packets (#2088) 8569 * Tokens are repeated in all Initial packets (#2089) 8571 * Clarified how PING frames are sent after loss (#2094) 8573 * Initial keys are discarded once Handshake are available (#1951, 8574 #2045) 8576 * ICMP PTB validation clarifications (#2161, #2109, #2108) 8578 C.16. Since draft-ietf-quic-transport-15 8580 Substantial editorial reorganization; no technical changes. 8582 C.17. Since draft-ietf-quic-transport-14 8584 * Merge ACK and ACK_ECN (#1778, #1801) 8586 * Explicitly communicate max_ack_delay (#981, #1781) 8588 * Validate original connection ID after Retry packets (#1710, #1486, 8589 #1793) 8591 * Idle timeout is optional and has no specified maximum (#1765) 8593 * Update connection ID handling; add RETIRE_CONNECTION_ID type 8594 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 8595 #1821) 8597 * Include a Token in all Initial packets (#1649, #1794) 8599 * Prevent handshake deadlock (#1764, #1824) 8601 C.18. Since draft-ietf-quic-transport-13 8603 * Streams open when higher-numbered streams of the same type open 8604 (#1342, #1549) 8606 * Split initial stream flow control limit into 3 transport 8607 parameters (#1016, #1542) 8609 * All flow control transport parameters are optional (#1610) 8611 * Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 8613 * Permit stateless reset in response to any packet (#1348, #1553) 8614 * Recommended defense against stateless reset spoofing (#1386, 8615 #1554) 8617 * Prevent infinite stateless reset exchanges (#1443, #1627) 8619 * Forbid processing of the same packet number twice (#1405, #1624) 8621 * Added a packet number decoding example (#1493) 8623 * More precisely define idle timeout (#1429, #1614, #1652) 8625 * Corrected format of Retry packet and prevented looping (#1492, 8626 #1451, #1448, #1498) 8628 * Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 8629 #1514, #1621) 8631 * Permit Retry in response to 0-RTT (#1547, #1552) 8633 * Looser verification of ECN counters to account for ACK loss 8634 (#1555, #1481, #1565) 8636 * Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 8638 C.19. Since draft-ietf-quic-transport-12 8640 * Changes to integration of the TLS handshake (#829, #1018, #1094, 8641 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 8643 - The cryptographic handshake uses CRYPTO frames, not stream 0 8645 - QUIC packet protection is used in place of TLS record 8646 protection 8648 - Separate QUIC packet number spaces are used for the handshake 8650 - Changed Retry to be independent of the cryptographic handshake 8652 - Added NEW_TOKEN frame and Token fields to Initial packet 8654 - Limit the use of HelloRetryRequest to address TLS needs (like 8655 key shares) 8657 * Enable server to transition connections to a preferred address 8658 (#560, #1251, #1373) 8660 * Added ECN feedback mechanisms and handling; new ACK_ECN frame 8661 (#804, #805, #1372) 8663 * Changed rules and recommendations for use of new connection IDs 8664 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 8666 * Added a transport parameter to disable intentional connection 8667 migration (#1271, #1447) 8669 * Packets from different connection ID can't be coalesced (#1287, 8670 #1423) 8672 * Fixed sampling method for packet number encryption; the length 8673 field in long headers includes the packet number field in addition 8674 to the packet payload (#1387, #1389) 8676 * Stateless Reset is now symmetric and subject to size constraints 8677 (#466, #1346) 8679 * Added frame type extension mechanism (#58, #1473) 8681 C.20. Since draft-ietf-quic-transport-11 8683 * Enable server to transition connections to a preferred address 8684 (#560, #1251) 8686 * Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 8687 #990, #734, #1317, #1267, #1079) 8689 * Packet numbers use a variable-length encoding (#989, #1334) 8691 * STREAM frames can now be empty (#1350) 8693 C.21. Since draft-ietf-quic-transport-10 8695 * Swap payload length and packed number fields in long header 8696 (#1294) 8698 * Clarified that CONNECTION_CLOSE is allowed in Handshake packet 8699 (#1274) 8701 * Spin bit reserved (#1283) 8703 * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 8705 * A more complete connection migration (#1249) 8707 * Refine opportunistic ACK defense text (#305, #1030, #1185) 8709 * A Stateless Reset Token isn't mandatory (#818, #1191) 8710 * Removed implicit stream opening (#896, #1193) 8712 * An empty STREAM frame can be used to open a stream without sending 8713 data (#901, #1194) 8715 * Define stream counts in transport parameters rather than a maximum 8716 stream ID (#1023, #1065) 8718 * STOP_SENDING is now prohibited before streams are used (#1050) 8720 * Recommend including ACK in Retry packets and allow PADDING (#1067, 8721 #882) 8723 * Endpoints now become closing after an idle timeout (#1178, #1179) 8725 * Remove implication that Version Negotiation is sent when a packet 8726 of the wrong version is received (#1197) 8728 C.22. Since draft-ietf-quic-transport-09 8730 * Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 8731 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 8732 (#1091, #725, #1086) 8734 * A server can now only send 3 packets without validating the client 8735 address (#38, #1090) 8737 * Delivery order of stream data is no longer strongly specified 8738 (#252, #1070) 8740 * Rework of packet handling and version negotiation (#1038) 8742 * Stream 0 is now exempt from flow control until the handshake 8743 completes (#1074, #725, #825, #1082) 8745 * Improved retransmission rules for all frame types: information is 8746 retransmitted, not packets or frames (#463, #765, #1095, #1053) 8748 * Added an error code for server busy signals (#1137) 8750 * Endpoints now set the connection ID that their peer uses. 8751 Connection IDs are variable length. Removed the 8752 omit_connection_id transport parameter and the corresponding short 8753 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 8755 C.23. Since draft-ietf-quic-transport-08 8757 * Clarified requirements for BLOCKED usage (#65, #924) 8759 * BLOCKED frame now includes reason for blocking (#452, #924, #927, 8760 #928) 8762 * GAP limitation in ACK Frame (#613) 8764 * Improved PMTUD description (#614, #1036) 8766 * Clarified stream state machine (#634, #662, #743, #894) 8768 * Reserved versions don't need to be generated deterministically 8769 (#831, #931) 8771 * You don't always need the draining period (#871) 8773 * Stateless reset clarified as version-specific (#930, #986) 8775 * initial_max_stream_id_x transport parameters are optional (#970, 8776 #971) 8778 * ACK delay assumes a default value during the handshake (#1007, 8779 #1009) 8781 * Removed transport parameters from NewSessionTicket (#1015) 8783 C.24. Since draft-ietf-quic-transport-07 8785 * The long header now has version before packet number (#926, #939) 8787 * Rename and consolidate packet types (#846, #822, #847) 8789 * Packet types are assigned new codepoints and the Connection ID 8790 Flag is inverted (#426, #956) 8792 * Removed type for Version Negotiation and use Version 0 (#963, 8793 #968) 8795 * Streams are split into unidirectional and bidirectional (#643, 8796 #656, #720, #872, #175, #885) 8798 - Stream limits now have separate uni- and bi-directional 8799 transport parameters (#909, #958) 8801 - Stream limit transport parameters are now optional and default 8802 to 0 (#970, #971) 8804 * The stream state machine has been split into read and write (#634, 8805 #894) 8807 * Employ variable-length integer encodings throughout (#595) 8809 * Improvements to connection close 8811 - Added distinct closing and draining states (#899, #871) 8813 - Draining period can terminate early (#869, #870) 8815 - Clarifications about stateless reset (#889, #890) 8817 * Address validation for connection migration (#161, #732, #878) 8819 * Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 8821 * negotiated_version is sent in server transport parameters (#710, 8822 #959) 8824 * Increased the range over which packet numbers are randomized 8825 (#864, #850, #964) 8827 C.25. Since draft-ietf-quic-transport-06 8829 * Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 8831 * Split error code space between application and transport (#485) 8833 * Stateless reset token moved to end (#820) 8835 * 1-RTT-protected long header types removed (#848) 8837 * No acknowledgments during draining period (#852) 8839 * Remove "application close" as a separate close type (#854) 8841 * Remove timestamps from the ACK frame (#841) 8843 * Require transport parameters to only appear once (#792) 8845 C.26. Since draft-ietf-quic-transport-05 8847 * Stateless token is server-only (#726) 8849 * Refactor section on connection termination (#733, #748, #328, 8850 #177) 8852 * Limit size of Version Negotiation packet (#585) 8854 * Clarify when and what to ack (#736) 8856 * Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 8858 * Clarify Keep-alive requirements (#729) 8860 C.27. Since draft-ietf-quic-transport-04 8862 * Introduce STOP_SENDING frame, RESET_STREAM only resets in one 8863 direction (#165) 8865 * Removed GOAWAY; application protocols are responsible for graceful 8866 shutdown (#696) 8868 * Reduced the number of error codes (#96, #177, #184, #211) 8870 * Version validation fields can't move or change (#121) 8872 * Removed versions from the transport parameters in a 8873 NewSessionTicket message (#547) 8875 * Clarify the meaning of "bytes in flight" (#550) 8877 * Public reset is now stateless reset and not visible to the path 8878 (#215) 8880 * Reordered bits and fields in STREAM frame (#620) 8882 * Clarifications to the stream state machine (#572, #571) 8884 * Increased the maximum length of the Largest Acknowledged field in 8885 ACK frames to 64 bits (#629) 8887 * truncate_connection_id is renamed to omit_connection_id (#659) 8889 * CONNECTION_CLOSE terminates the connection like TCP RST (#330, 8890 #328) 8892 * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 8894 C.28. Since draft-ietf-quic-transport-03 8896 * Change STREAM and RESET_STREAM layout 8898 * Add MAX_STREAM_ID settings 8900 C.29. Since draft-ietf-quic-transport-02 8902 * The size of the initial packet payload has a fixed minimum (#267, 8903 #472) 8905 * Define when Version Negotiation packets are ignored (#284, #294, 8906 #241, #143, #474) 8908 * The 64-bit FNV-1a algorithm is used for integrity protection of 8909 unprotected packets (#167, #480, #481, #517) 8911 * Rework initial packet types to change how the connection ID is 8912 chosen (#482, #442, #493) 8914 * No timestamps are forbidden in unprotected packets (#542, #429) 8916 * Cryptographic handshake is now on stream 0 (#456) 8918 * Remove congestion control exemption for cryptographic handshake 8919 (#248, #476) 8921 * Version 1 of QUIC uses TLS; a new version is needed to use a 8922 different handshake protocol (#516) 8924 * STREAM frames have a reduced number of offset lengths (#543, #430) 8926 * Split some frames into separate connection- and stream- level 8927 frames (#443) 8929 - WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 8931 - BLOCKED split to match WINDOW_UPDATE split (#454) 8933 - Define STREAM_ID_NEEDED frame (#455) 8935 * A NEW_CONNECTION_ID frame supports connection migration without 8936 linkability (#232, #491, #496) 8938 * Transport parameters for 0-RTT are retained from a previous 8939 connection (#405, #513, #512) 8941 - A client in 0-RTT no longer required to reset excess streams 8942 (#425, #479) 8944 * Expanded security considerations (#440, #444, #445, #448) 8946 C.30. Since draft-ietf-quic-transport-01 8947 * Defined short and long packet headers (#40, #148, #361) 8949 * Defined a versioning scheme and stable fields (#51, #361) 8951 * Define reserved version values for "greasing" negotiation (#112, 8952 #278) 8954 * The initial packet number is randomized (#35, #283) 8956 * Narrow the packet number encoding range requirement (#67, #286, 8957 #299, #323, #356) 8959 * Defined client address validation (#52, #118, #120, #275) 8961 * Define transport parameters as a TLS extension (#49, #122) 8963 * SCUP and COPT parameters are no longer valid (#116, #117) 8965 * Transport parameters for 0-RTT are either remembered from before, 8966 or assume default values (#126) 8968 * The server chooses connection IDs in its final flight (#119, #349, 8969 #361) 8971 * The server echoes the Connection ID and packet number fields when 8972 sending a Version Negotiation packet (#133, #295, #244) 8974 * Defined a minimum packet size for the initial handshake packet 8975 from the client (#69, #136, #139, #164) 8977 * Path MTU Discovery (#64, #106) 8979 * The initial handshake packet from the client needs to fit in a 8980 single packet (#338) 8982 * Forbid acknowledgment of packets containing only ACK and PADDING 8983 (#291) 8985 * Require that frames are processed when packets are acknowledged 8986 (#381, #341) 8988 * Removed the STOP_WAITING frame (#66) 8990 * Don't require retransmission of old timestamps for lost ACK frames 8991 (#308) 8993 * Clarified that frames are not retransmitted, but the information 8994 in them can be (#157, #298) 8996 * Error handling definitions (#335) 8998 * Split error codes into four sections (#74) 9000 * Forbid the use of Public Reset where CONNECTION_CLOSE is possible 9001 (#289) 9003 * Define packet protection rules (#336) 9005 * Require that stream be entirely delivered or reset, including 9006 acknowledgment of all STREAM frames or the RESET_STREAM, before it 9007 closes (#381) 9009 * Remove stream reservation from state machine (#174, #280) 9011 * Only stream 1 does not contribute to connection-level flow control 9012 (#204) 9014 * Stream 1 counts towards the maximum concurrent stream limit (#201, 9015 #282) 9017 * Remove connection-level flow control exclusion for some streams 9018 (except 1) (#246) 9020 * RESET_STREAM affects connection-level flow control (#162, #163) 9022 * Flow control accounting uses the maximum data offset on each 9023 stream, rather than bytes received (#378) 9025 * Moved length-determining fields to the start of STREAM and ACK 9026 (#168, #277) 9028 * Added the ability to pad between frames (#158, #276) 9030 * Remove error code and reason phrase from GOAWAY (#352, #355) 9032 * GOAWAY includes a final stream number for both directions (#347) 9034 * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 9035 consistent offset (#249) 9037 * Defined priority as the responsibility of the application protocol 9038 (#104, #303) 9040 C.31. Since draft-ietf-quic-transport-00 9042 * Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 9043 * Defined versioning 9045 * Reworked description of packet and frame layout 9047 * Error code space is divided into regions for each component 9049 * Use big endian for all numeric values 9051 C.32. Since draft-hamilton-quic-transport-protocol-01 9053 * Adopted as base for draft-ietf-quic-tls 9055 * Updated authors/editors list 9057 * Added IANA Considerations section 9059 * Moved Contributors and Acknowledgments to appendices 9061 Contributors 9063 The original design and rationale behind this protocol draw 9064 significantly from work by Jim Roskind [EARLY-DESIGN]. 9066 The IETF QUIC Working Group received an enormous amount of support 9067 from many people. The following people provided substantive 9068 contributions to this document: 9070 * Alessandro Ghedini 9072 * Alyssa Wilk 9074 * Antoine Delignat-Lavaud 9076 * Brian Trammell 9078 * Christian Huitema 9080 * Colin Perkins 9082 * David Schinazi 9084 * Dmitri Tikhonov 9086 * Eric Kinnear 9088 * Eric Rescorla 9090 * Gorry Fairhurst 9091 * Ian Swett 9093 * Igor Lubashev 9095 * 奥 一穂 (Kazuho Oku) 9097 * Lars Eggert 9099 * Lucas Pardue 9101 * Magnus Westerlund 9103 * Marten Seemann 9105 * Martin Duke 9107 * Mike Bishop 9109 * Mikkel Fahnøe Jørgensen 9111 * Mirja Kühlewind 9113 * Nick Banks 9115 * Nick Harper 9117 * Patrick McManus 9119 * Roberto Peon 9121 * Ryan Hamilton 9123 * Subodh Iyengar 9125 * Tatsuhiro Tsujikawa 9127 * Ted Hardie 9129 * Tom Jones 9131 * Victor Vasiliev 9133 Authors' Addresses 9135 Jana Iyengar (editor) 9136 Fastly 9138 Email: jri.ietf@gmail.com 9139 Martin Thomson (editor) 9140 Mozilla 9142 Email: mt@lowentropy.net