idnits 2.17.1 draft-ietf-quic-transport-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The server includes a connection ID of its choice in the Source Connection ID field. This value MUST not be equal to the Destination Connection ID field of the packet sent by the client. The client MUST use this connection ID in the Destination Connection ID of subsequent packets that it sends. -- The document date (January 23, 2019) is 1919 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 1819 == Missing Reference: 'CH' is mentioned on line 1815, but not defined == Missing Reference: 'SH' is mentioned on line 1817, but not defined == Missing Reference: 'EE' is mentioned on line 1818, but not defined == Missing Reference: 'CERT' is mentioned on line 1818, but not defined == Missing Reference: 'CV' is mentioned on line 1818, but not defined == Missing Reference: 'FIN' is mentioned on line 1818, but not defined -- Looks like a reference, but probably isn't: '1' on line 1499 -- Looks like a reference, but probably isn't: '2' on line 1498 -- Looks like a reference, but probably isn't: '4' on line 4475 -- Looks like a reference, but probably isn't: '16' on line 4480 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 ** Downref: Normative reference to an Experimental draft: draft-ietf-quic-spin-exp (ref. 'SPIN') -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-03 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 8 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: July 27, 2019 Mozilla 6 January 23, 2019 8 QUIC: A UDP-Based Multiplexed and Secure Transport 9 draft-ietf-quic-transport-18 11 Abstract 13 This document defines the core of the QUIC transport protocol. 14 Accompanying documents describe QUIC's loss detection and congestion 15 control and the use of TLS for key negotiation. 17 Note to Readers 19 Discussion of this draft takes place on the QUIC working group 20 mailing list (quic@ietf.org), which is archived at 21 . 23 Working Group information can be found at ; source code and issues list for this draft can be found at 25 . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 27, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 63 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 64 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 65 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 67 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 68 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10 69 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 11 71 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 13 72 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 73 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16 74 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 75 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 77 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 78 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 79 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 80 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 81 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 83 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 84 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 85 5.2. Matching Packets to Connections . . . . . . . . . . . . . 25 86 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26 87 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 26 88 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27 89 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 27 90 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 91 6.2. Handling Version Negotiation Packets . . . . . . . . . . 28 92 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 93 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30 94 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31 95 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 96 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34 97 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 98 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 99 7.3.3. Version Negotiation Validation . . . . . . . . . . . 36 100 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 101 8.1. Address Validation During Connection Establishment . . . 38 102 8.1.1. Address Validation using Retry Packets . . . . . . . 38 103 8.1.2. Address Validation for Future Connections . . . . . . 39 104 8.1.3. Address Validation Token Integrity . . . . . . . . . 41 105 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41 106 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 42 107 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 108 8.5. Successful Path Validation . . . . . . . . . . . . . . . 43 109 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 110 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44 111 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45 112 9.2. Initiating Connection Migration . . . . . . . . . . . . . 45 113 9.3. Responding to Connection Migration . . . . . . . . . . . 46 114 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 46 115 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47 116 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47 117 9.4. Loss Detection and Congestion Control . . . . . . . . . . 48 118 9.5. Privacy Implications of Connection Migration . . . . . . 49 119 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 120 9.6.1. Communicating A Preferred Address . . . . . . . . . . 50 121 9.6.2. Responding to Connection Migration . . . . . . . . . 51 122 9.6.3. Interaction of Client Migration and Preferred Address 51 123 10. Connection Termination . . . . . . . . . . . . . . . . . . . 52 124 10.1. Closing and Draining Connection States . . . . . . . . . 52 125 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53 126 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54 127 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55 128 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 57 129 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58 130 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59 131 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 59 132 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 60 133 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 60 134 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61 135 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61 136 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62 137 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 62 138 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64 139 13. Packetization and Reliability . . . . . . . . . . . . . . . . 66 140 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 67 141 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 67 142 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 68 143 13.2. Retransmission of Information . . . . . . . . . . . . . 68 144 13.3. Explicit Congestion Notification . . . . . . . . . . . . 71 145 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 71 146 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 72 147 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 73 148 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 74 149 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 75 150 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 76 151 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 76 152 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 77 153 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 78 154 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 78 155 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 79 156 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 82 157 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 83 158 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 86 159 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 87 160 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 88 161 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 90 162 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 92 163 18.1. Transport Parameter Definitions . . . . . . . . . . . . 94 164 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 97 165 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 97 166 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 97 167 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 97 168 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 99 169 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 101 170 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 102 171 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 102 172 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 103 173 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 104 174 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 104 175 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 106 176 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 106 177 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 107 178 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 108 179 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 109 180 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 109 181 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 110 182 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 111 183 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 112 184 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 112 185 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 113 186 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 114 187 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 114 188 20.1. Application Protocol Error Codes . . . . . . . . . . . . 115 189 21. Security Considerations . . . . . . . . . . . . . . . . . . . 116 190 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 116 191 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 117 192 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 117 193 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 117 194 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 118 195 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 118 196 21.7. Explicit Congestion Notification Attacks . . . . . . . . 119 197 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 119 198 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 199 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 119 200 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 121 201 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 122 202 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 125 203 23.1. Normative References . . . . . . . . . . . . . . . . . . 125 204 23.2. Informative References . . . . . . . . . . . . . . . . . 126 205 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 128 206 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 128 207 B.1. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 128 208 B.2. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 129 209 B.3. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 130 210 B.4. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 130 211 B.5. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 131 212 B.6. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 132 213 B.7. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 133 214 B.8. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 133 215 B.9. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 134 216 B.10. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 134 217 B.11. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 135 218 B.12. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 136 219 B.13. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 136 220 B.14. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 136 221 B.15. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 137 222 B.16. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 137 223 B.17. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 138 224 B.18. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 140 225 B.19. Since draft-hamilton-quic-transport-protocol-01 . . . . . 140 226 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 141 227 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 141 228 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 230 1. Introduction 232 QUIC is a multiplexed and secure general-purpose transport protocol 233 that provides: 235 o Stream multiplexing 237 o Stream and connection-level flow control 239 o Low-latency connection establishment 240 o Connection migration and resilience to NAT rebinding 242 o Authenticated and encrypted header and payload 244 QUIC uses UDP as a substrate to avoid requiring changes to legacy 245 client operating systems and middleboxes. QUIC authenticates all of 246 its headers and encrypts most of the data it exchanges, including its 247 signaling, to avoid incurring a dependency on middleboxes. 249 1.1. Document Structure 251 This document describes the core QUIC protocol and is structured as 252 follows. 254 o Streams are the basic service abstraction that QUIC provides. 256 * Section 2 describes core concepts related to streams, 258 * Section 3 provides a reference model for stream states, and 260 * Section 4 outlines the operation of flow control. 262 o Connections are the context in which QUIC endpoints communicate. 264 * Section 5 describes core concepts related to connections, 266 * Section 6 describes version negotiation, 268 * Section 7 details the process for establishing connections, 270 * Section 8 specifies critical denial of service mitigation 271 mechanisms, 273 * Section 9 describes how endpoints migrate a connection to a new 274 network path, 276 * Section 10 lists the options for terminating an open 277 connection, and 279 * Section 11 provides general guidance for error handling. 281 o Packets and frames are the basic unit used by QUIC to communicate. 283 * Section 12 describes concepts related to packets and frames, 285 * Section 13 defines models for the transmission, retransmission, 286 and acknowledgement of data, and 288 * Section 14 specifies rules for managing the size of packets. 290 o Finally, encoding details of QUIC protocol elements are described 291 in: 293 * Section 15 (Versions), 295 * Section 16 (Integer Encoding), 297 * Section 17 (Packet Headers), 299 * Section 18 (Transport Parameters), 301 * Section 19 (Frames), and 303 * Section 20 (Errors). 305 Accompanying documents describe QUIC's loss detection and congestion 306 control [QUIC-RECOVERY], and the use of TLS for key negotiation 307 [QUIC-TLS]. 309 This document defines QUIC version 1, which conforms to the protocol 310 invariants in [QUIC-INVARIANTS]. 312 1.2. Terms and Definitions 314 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 315 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 316 "OPTIONAL" in this document are to be interpreted as described in BCP 317 14 [RFC2119] [RFC8174] when, and only when, they appear in all 318 capitals, as shown here. 320 Commonly used terms in the document are described below. 322 QUIC: The transport protocol described by this document. QUIC is a 323 name, not an acronym. 325 QUIC packet: The smallest unit of QUIC that can be encapsulated in a 326 UDP datagram. Multiple QUIC packets can be encapsulated in a 327 single UDP datagram. 329 Endpoint: An entity that can participate in a QUIC connection by 330 generating, receiving, and processing QUIC packets. There are 331 only two types of endpoint in QUIC: client and server. 333 Client: The endpoint initiating a QUIC connection. 335 Server: The endpoint accepting incoming QUIC connections. 337 Connection ID: An opaque identifier that is used to identify a QUIC 338 connection at an endpoint. Each endpoint sets a value for its 339 peer to include in packets sent towards the endpoint. 341 Stream: A unidirectional or bidirectional channel of ordered bytes 342 within a QUIC connection. A QUIC connection can carry multiple 343 simultaneous streams. 345 Application: An entity that uses QUIC to send and receive data. 347 1.3. Notational Conventions 349 Packet and frame diagrams in this document use the format described 350 in Section 3.1 of [RFC2360], with the following additional 351 conventions: 353 [x]: Indicates that x is optional 355 x (A): Indicates that x is A bits long 357 x (A/B/C) ...: Indicates that x is one of A, B, or C bits long 359 x (i) ...: Indicates that x uses the variable-length encoding in 360 Section 16 362 x (*) ...: Indicates that x is variable-length 364 2. Streams 366 Streams in QUIC provide a lightweight, ordered byte-stream 367 abstraction to an application. An alternative view of QUIC streams 368 is as an elastic "message" abstraction. 370 Streams can be created by sending data. Other processes associated 371 with stream management - ending, cancelling, and managing flow 372 control - are all designed to impose minimal overheads. For 373 instance, a single STREAM frame (Section 19.8) can open, carry data 374 for, and close a stream. Streams can also be long-lived and can last 375 the entire duration of a connection. 377 Streams can be created by either endpoint, can concurrently send data 378 interleaved with other streams, and can be cancelled. Any stream can 379 be initiated by either endpoint. QUIC does not provide any means of 380 ensuring ordering between bytes on different streams. 382 QUIC allows for an arbitrary number of streams to operate 383 concurrently and for an arbitrary amount of data to be sent on any 384 stream, subject to flow control constraints (see Section 4) and 385 stream limits. 387 2.1. Stream Types and Identifiers 389 Streams can be unidirectional or bidirectional. Unidirectional 390 streams carry data in one direction: from the initiator of the stream 391 to its peer. Bidirectional streams allow for data to be sent in both 392 directions. 394 Streams are identified within a connection by a numeric value, 395 referred to as the stream ID. Stream IDs are unique to a stream. A 396 QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream 397 IDs are encoded as variable-length integers (see Section 16). 399 The least significant bit (0x1) of the stream ID identifies the 400 initiator of the stream. Client-initiated streams have even-numbered 401 stream IDs (with the bit set to 0), and server-initiated streams have 402 odd-numbered stream IDs (with the bit set to 1). 404 The second least significant bit (0x2) of the stream ID distinguishes 405 between bidirectional streams (with the bit set to 0) and 406 unidirectional streams (with the bit set to 1). 408 The least significant two bits from a stream ID therefore identify a 409 stream as one of four types, as summarized in Table 1. 411 +------+----------------------------------+ 412 | Bits | Stream Type | 413 +------+----------------------------------+ 414 | 0x0 | Client-Initiated, Bidirectional | 415 | | | 416 | 0x1 | Server-Initiated, Bidirectional | 417 | | | 418 | 0x2 | Client-Initiated, Unidirectional | 419 | | | 420 | 0x3 | Server-Initiated, Unidirectional | 421 +------+----------------------------------+ 423 Table 1: Stream ID Types 425 Within each type, streams are created with numerically increasing 426 stream IDs. A stream ID that is used out of order results in all 427 streams of that type with lower-numbered stream IDs also being 428 opened. 430 The first bidirectional stream opened by the client has a stream ID 431 of 0. 433 2.2. Sending and Receiving Data 435 STREAM frames (Section 19.8) encapsulate data sent by an application. 436 An endpoint uses the Stream ID and Offset fields in STREAM frames to 437 place data in order. 439 Endpoints MUST be able to deliver stream data to an application as an 440 ordered byte-stream. Delivering an ordered byte-stream requires that 441 an endpoint buffer any data that is received out of order, up to the 442 advertised flow control limit. 444 QUIC makes no specific allowances for delivery of stream data out of 445 order. However, implementations MAY choose to offer the ability to 446 deliver data out of order to a receiving application. 448 An endpoint could receive data for a stream at the same stream offset 449 multiple times. Data that has already been received can be 450 discarded. The data at a given offset MUST NOT change if it is sent 451 multiple times; an endpoint MAY treat receipt of different data at 452 the same offset within a stream as a connection error of type 453 PROTOCOL_VIOLATION. 455 Streams are an ordered byte-stream abstraction with no other 456 structure that is visible to QUIC. STREAM frame boundaries are not 457 expected to be preserved when data is transmitted, when data is 458 retransmitted after packet loss, or when data is delivered to the 459 application at a receiver. 461 An endpoint MUST NOT send data on any stream without ensuring that it 462 is within the flow control limits set by its peer. Flow control is 463 described in detail in Section 4. 465 2.3. Stream Prioritization 467 Stream multiplexing can have a significant effect on application 468 performance if resources allocated to streams are correctly 469 prioritized. 471 QUIC does not provide frames for exchanging prioritization 472 information. Instead it relies on receiving priority information 473 from the application that uses QUIC. 475 A QUIC implementation SHOULD provide ways in which an application can 476 indicate the relative priority of streams. When deciding which 477 streams to dedicate resources to, the implementation SHOULD use the 478 information provided by the application. 480 3. Stream States 482 This section describes streams in terms of their send or receive 483 components. Two state machines are described: one for the streams on 484 which an endpoint transmits data (Section 3.1), and another for 485 streams on which an endpoint receives data (Section 3.2). 487 Unidirectional streams use the applicable state machine directly. 488 Bidirectional streams use both state machines. For the most part, 489 the use of these state machines is the same whether the stream is 490 unidirectional or bidirectional. The conditions for opening a stream 491 are slightly more complex for a bidirectional stream because the 492 opening of either send or receive sides causes the stream to open in 493 both directions. 495 An endpoint MUST open streams of the same type in increasing order of 496 stream ID. 498 Note: These states are largely informative. This document uses 499 stream states to describe rules for when and how different types 500 of frames can be sent and the reactions that are expected when 501 different types of frames are received. Though these state 502 machines are intended to be useful in implementing QUIC, these 503 states aren't intended to constrain implementations. An 504 implementation can define a different state machine as long as its 505 behavior is consistent with an implementation that implements 506 these states. 508 3.1. Sending Stream States 510 Figure 1 shows the states for the part of a stream that sends data to 511 a peer. 513 o 514 | Create Stream (Sending) 515 | Peer Creates Bidirectional Stream 516 v 517 +-------+ 518 | Ready | Send RESET_STREAM 519 | |-----------------------. 520 +-------+ | 521 | | 522 | Send STREAM / | 523 | STREAM_DATA_BLOCKED | 524 | | 525 | Peer Creates | 526 | Bidirectional Stream | 527 v | 528 +-------+ | 529 | Send | Send RESET_STREAM | 530 | |---------------------->| 531 +-------+ | 532 | | 533 | Send STREAM + FIN | 534 v v 535 +-------+ +-------+ 536 | Data | Send RESET_STREAM | Reset | 537 | Sent |------------------>| Sent | 538 +-------+ +-------+ 539 | | 540 | Recv All ACKs | Recv ACK 541 v v 542 +-------+ +-------+ 543 | Data | | Reset | 544 | Recvd | | Recvd | 545 +-------+ +-------+ 547 Figure 1: States for Sending Parts of Streams 549 The sending part of stream that the endpoint initiates (types 0 and 2 550 for clients, 1 and 3 for servers) is opened by the application. The 551 "Ready" state represents a newly created stream that is able to 552 accept data from the application. Stream data might be buffered in 553 this state in preparation for sending. 555 Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a 556 sending part of a stream to enter the "Send" state. An 557 implementation might choose to defer allocating a stream ID to a 558 stream until it sends the first frame and enters this state, which 559 can allow for better stream prioritization. 561 The sending part of a bidirectional stream initiated by a peer (type 562 0 for a server, type 1 for a client) enters the "Ready" state then 563 immediately transitions to the "Send" state if the receiving part 564 enters the "Recv" state (Section 3.2). 566 In the "Send" state, an endpoint transmits - and retransmits as 567 necessary - stream data in STREAM frames. The endpoint respects the 568 flow control limits set by its peer, and continues to accept and 569 process MAX_STREAM_DATA frames. An endpoint in the "Send" state 570 generates STREAM_DATA_BLOCKED frames if it is blocked from sending by 571 stream or connection flow control limits Section 4.1. 573 After the application indicates that all stream data has been sent 574 and a STREAM frame containing the FIN bit is sent, the sending part 575 of the stream enters the "Data Sent" state. From this state, the 576 endpoint only retransmits stream data as necessary. The endpoint 577 does not need to check flow control limits or send 578 STREAM_DATA_BLOCKED frames for a stream in this state. 579 MAX_STREAM_DATA frames might be received until the peer receives the 580 final stream offset. The endpoint can safely ignore any 581 MAX_STREAM_DATA frames it receives from its peer for a stream in this 582 state. 584 Once all stream data has been successfully acknowledged, the sending 585 part of the stream enters the "Data Recvd" state, which is a terminal 586 state. 588 From any of the "Ready", "Send", or "Data Sent" states, an 589 application can signal that it wishes to abandon transmission of 590 stream data. Alternatively, an endpoint might receive a STOP_SENDING 591 frame from its peer. In either case, the endpoint sends a 592 RESET_STREAM frame, which causes the stream to enter the "Reset Sent" 593 state. 595 An endpoint MAY send a RESET_STREAM as the first frame that mentions 596 a stream; this causes the sending part of that stream to open and 597 then immediately transition to the "Reset Sent" state. 599 Once a packet containing a RESET_STREAM has been acknowledged, the 600 sending part of the stream enters the "Reset Recvd" state, which is a 601 terminal state. 603 3.2. Receiving Stream States 605 Figure 2 shows the states for the part of a stream that receives data 606 from a peer. The states for a receiving part of a stream mirror only 607 some of the states of the sending part of the stream at the peer. 608 The receiving part of a stream does not track states on the sending 609 part that cannot be observed, such as the "Ready" state. Instead, 610 the receiving part of a stream tracks the delivery of data to the 611 application, some of which cannot be observed by the sender. 613 o 614 | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM 615 | Create Bidirectional Stream (Sending) 616 | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional) 617 | Create Higher-Numbered Stream 618 v 619 +-------+ 620 | Recv | Recv RESET_STREAM 621 | |-----------------------. 622 +-------+ | 623 | | 624 | Recv STREAM + FIN | 625 v | 626 +-------+ | 627 | Size | Recv RESET_STREAM | 628 | Known |---------------------->| 629 +-------+ | 630 | | 631 | Recv All Data | 632 v v 633 +-------+ Recv RESET_STREAM +-------+ 634 | Data |--- (optional) --->| Reset | 635 | Recvd | Recv All Data | Recvd | 636 +-------+<-- (optional) ----+-------+ 637 | | 638 | App Read All Data | App Read RST 639 v v 640 +-------+ +-------+ 641 | Data | | Reset | 642 | Read | | Read | 643 +-------+ +-------+ 645 Figure 2: States for Receiving Parts of Streams 647 The receiving part of a stream initiated by a peer (types 1 and 3 for 648 a client, or 0 and 2 for a server) is created when the first STREAM, 649 STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. 650 For bidirectional streams initiated by a peer, receipt of a 651 MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the 652 stream also creates the receiving part. The initial state for the 653 receiving part of stream is "Recv". 655 The receiving part of a stream enters the "Recv" state when the 656 sending part of a bidirectional stream initiated by the endpoint 657 (type 0 for a client, type 1 for a server) enters the "Ready" state. 659 An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or 660 STOP_SENDING frame is received from the peer for that stream. 661 Receiving a MAX_STREAM_DATA frame for an unopened stream indicates 662 that the remote peer has opened the stream and is providing flow 663 control credit. Receiving a STOP_SENDING frame for an unopened 664 stream indicates that the remote peer no longer wishes to receive 665 data on this stream. Either frame might arrive before a STREAM or 666 STREAM_DATA_BLOCKED frame if packets are lost or reordered. 668 Before creating a stream, all streams of the same type with lower- 669 numbered stream IDs MUST be created. This ensures that the creation 670 order for streams is consistent on both endpoints. 672 In the "Recv" state, the endpoint receives STREAM and 673 STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be 674 reassembled into the correct order for delivery to the application. 675 As data is consumed by the application and buffer space becomes 676 available, the endpoint sends MAX_STREAM_DATA frames to allow the 677 peer to send more data. 679 When a STREAM frame with a FIN bit is received, the final size of the 680 stream is known (see Section 4.4). The receiving part of the stream 681 then enters the "Size Known" state. In this state, the endpoint no 682 longer needs to send MAX_STREAM_DATA frames, it only receives any 683 retransmissions of stream data. 685 Once all data for the stream has been received, the receiving part 686 enters the "Data Recvd" state. This might happen as a result of 687 receiving the same STREAM frame that causes the transition to "Size 688 Known". In this state, the endpoint has all stream data. Any STREAM 689 or STREAM_DATA_BLOCKED frames it receives for the stream can be 690 discarded. 692 The "Data Recvd" state persists until stream data has been delivered 693 to the application. Once stream data has been delivered, the stream 694 enters the "Data Read" state, which is a terminal state. 696 Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states 697 causes the stream to enter the "Reset Recvd" state. This might cause 698 the delivery of stream data to the application to be interrupted. 700 It is possible that all stream data is received when a RESET_STREAM 701 is received (that is, from the "Data Recvd" state). Similarly, it is 702 possible for remaining stream data to arrive after receiving a 703 RESET_STREAM frame (the "Reset Recvd" state). An implementation is 704 free to manage this situation as it chooses. Sending RESET_STREAM 705 means that an endpoint cannot guarantee delivery of stream data; 706 however there is no requirement that stream data not be delivered if 707 a RESET_STREAM is received. An implementation MAY interrupt delivery 708 of stream data, discard any data that was not consumed, and signal 709 the receipt of the RESET_STREAM immediately. Alternatively, the 710 RESET_STREAM signal might be suppressed or withheld if stream data is 711 completely received and is buffered to be read by the application. 712 In the latter case, the receiving part of the stream transitions from 713 "Reset Recvd" to "Data Recvd". 715 Once the application has been delivered the signal indicating that 716 the stream was reset, the receiving part of the stream transitions to 717 the "Reset Read" state, which is a terminal state. 719 3.3. Permitted Frame Types 721 The sender of a stream sends just three frame types that affect the 722 state of a stream at either sender or receiver: STREAM 723 (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM 724 (Section 19.4). 726 A sender MUST NOT send any of these frames from a terminal state 727 ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or 728 STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the 729 terminal states and in the "Reset Sent" state. A receiver could 730 receive any of these three frames in any state, due to the 731 possibility of delayed delivery of packets carrying them. 733 The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and 734 STOP_SENDING frames (Section 19.5). 736 The receiver only sends MAX_STREAM_DATA in the "Recv" state. A 737 receiver can send STOP_SENDING in any state where it has not received 738 a RESET_STREAM frame; that is states other than "Reset Recvd" or 739 "Reset Read". However there is little value in sending a 740 STOP_SENDING frame in the "Data Recvd" state, since all stream data 741 has been received. A sender could receive either of these two frames 742 in any state as a result of delayed delivery of packets. 744 3.4. Bidirectional Stream States 746 A bidirectional stream is composed of sending and receiving parts. 747 Implementations may represent states of the bidirectional stream as 748 composites of sending and receiving stream states. The simplest 749 model presents the stream as "open" when either sending or receiving 750 parts are in a non-terminal state and "closed" when both sending and 751 receiving streams are in terminal states. 753 Table 2 shows a more complex mapping of bidirectional stream states 754 that loosely correspond to the stream states in HTTP/2 [HTTP2]. This 755 shows that multiple states on sending or receiving parts of streams 756 are mapped to the same composite state. Note that this is just one 757 possibility for such a mapping; this mapping requires that data is 758 acknowledged before the transition to a "closed" or "half-closed" 759 state. 761 +-----------------------+---------------------+---------------------+ 762 | Sending Part | Receiving Part | Composite State | 763 +-----------------------+---------------------+---------------------+ 764 | No Stream/Ready | No Stream/Recv *1 | idle | 765 | | | | 766 | Ready/Send/Data Sent | Recv/Size Known | open | 767 | | | | 768 | Ready/Send/Data Sent | Data Recvd/Data | half-closed | 769 | | Read | (remote) | 770 | | | | 771 | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | 772 | | Read | (remote) | 773 | | | | 774 | Data Recvd | Recv/Size Known | half-closed (local) | 775 | | | | 776 | Reset Sent/Reset | Recv/Size Known | half-closed (local) | 777 | Recvd | | | 778 | | | | 779 | Reset Sent/Reset | Data Recvd/Data | closed | 780 | Recvd | Read | | 781 | | | | 782 | Reset Sent/Reset | Reset Recvd/Reset | closed | 783 | Recvd | Read | | 784 | | | | 785 | Data Recvd | Data Recvd/Data | closed | 786 | | Read | | 787 | | | | 788 | Data Recvd | Reset Recvd/Reset | closed | 789 | | Read | | 790 +-----------------------+---------------------+---------------------+ 792 Table 2: Possible Mapping of Stream States to HTTP/2 794 Note (*1): A stream is considered "idle" if it has not yet been 795 created, or if the receiving part of the stream is in the "Recv" 796 state without yet having received any frames. 798 3.5. Solicited State Transitions 800 If an endpoint is no longer interested in the data it is receiving on 801 a stream, it MAY send a STOP_SENDING frame identifying that stream to 802 prompt closure of the stream in the opposite direction. This 803 typically indicates that the receiving application is no longer 804 reading data it receives from the stream, but it is not a guarantee 805 that incoming data will be ignored. 807 STREAM frames received after sending STOP_SENDING are still counted 808 toward connection and stream flow control, even though these frames 809 will be discarded upon receipt. 811 A STOP_SENDING frame requests that the receiving endpoint send a 812 RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame 813 MUST send a RESET_STREAM frame if the stream is in the Ready or Send 814 state. If the stream is in the Data Sent state and any outstanding 815 data is declared lost, an endpoint SHOULD send a RESET_STREAM frame 816 in lieu of a retransmission. 818 An endpoint SHOULD copy the error code from the STOP_SENDING frame to 819 the RESET_STREAM frame it sends, but MAY use any application error 820 code. The endpoint that sends a STOP_SENDING frame MAY ignore the 821 error code carried in any RESET_STREAM frame it receives. 823 If the STOP_SENDING frame is received on a stream that is already in 824 the "Data Sent" state, an endpoint that wishes to cease 825 retransmission of previously-sent STREAM frames on that stream MUST 826 first send a RESET_STREAM frame. 828 STOP_SENDING SHOULD only be sent for a stream that has not been reset 829 by the peer. STOP_SENDING is most useful for streams in the "Recv" 830 or "Size Known" states. 832 An endpoint is expected to send another STOP_SENDING frame if a 833 packet containing a previous STOP_SENDING is lost. However, once 834 either all stream data or a RESET_STREAM frame has been received for 835 the stream - that is, the stream is in any state other than "Recv" or 836 "Size Known" - sending a STOP_SENDING frame is unnecessary. 838 An endpoint that wishes to terminate both directions of a 839 bidirectional stream can terminate one direction by sending a 840 RESET_STREAM, and it can encourage prompt termination in the opposite 841 direction by sending a STOP_SENDING frame. 843 4. Flow Control 845 It is necessary to limit the amount of data that a receiver could 846 buffer, to prevent a fast sender from overwhelming a slow receiver, 847 or to prevent a malicious sender from consuming a large amount of 848 memory at a receiver. To enable a receiver to limit memory 849 commitment to a connection and to apply back pressure on the sender, 850 streams are flow controlled both individually and as an aggregate. A 851 QUIC receiver controls the maximum amount of data the sender can send 852 on a stream at any time, as described in Section 4.1 and Section 4.2 854 Similarly, to limit concurrency within a connection, a QUIC endpoint 855 controls the maximum cumulative number of streams that its peer can 856 initiate, as described in Section 4.5. 858 Data sent in CRYPTO frames is not flow controlled in the same way as 859 stream data. QUIC relies on the cryptographic protocol 860 implementation to avoid excessive buffering of data, see [QUIC-TLS]. 861 The implementation SHOULD provide an interface to QUIC to tell it 862 about its buffering limits so that there is not excessive buffering 863 at multiple layers. 865 4.1. Data Flow Control 867 QUIC employs a credit-based flow-control scheme similar to that in 868 HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is 869 prepared to receive on a given stream and for the entire connection. 870 This leads to two levels of data flow control in QUIC: 872 o Stream flow control, which prevents a single stream from consuming 873 the entire receive buffer for a connection by limiting the amount 874 of data that can be sent on any stream. 876 o Connection flow control, which prevents senders from exceeding a 877 receiver's buffer capacity for the connection, by limiting the 878 total bytes of stream data sent in STREAM frames on all streams. 880 A receiver sets initial credits for all streams by sending transport 881 parameters during the handshake (Section 7.3). A receiver sends 882 MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to 883 the sender to advertise additional credit. 885 A receiver advertises credit for a stream by sending a 886 MAX_STREAM_DATA frame with the Stream ID field set appropriately. A 887 MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a 888 stream. A receiver could use the current offset of data consumed to 889 determine the flow control offset to be advertised. A receiver MAY 890 send MAX_STREAM_DATA frames in multiple packets in order to make sure 891 that the sender receives an update before running out of flow control 892 credit, even if one of the packets is lost. 894 A receiver advertises credit for a connection by sending a MAX_DATA 895 frame, which indicates the maximum of the sum of the absolute byte 896 offsets of all streams. A receiver maintains a cumulative sum of 897 bytes received on all streams, which is used to check for flow 898 control violations. A receiver might use a sum of bytes consumed on 899 all streams to determine the maximum data limit to be advertised. 901 A receiver can advertise a larger offset by sending MAX_STREAM_DATA 902 or MAX_DATA frames at any time during the connection. A receiver 903 cannot renege on an advertisement however. That is, once a receiver 904 advertises an offset, it MAY advertise a smaller offset, but this has 905 no effect. 907 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error 908 (Section 11) if the sender violates the advertised connection or 909 stream data limits. 911 A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do 912 not increase flow control limits. 914 If a sender runs out of flow control credit, it will be unable to 915 send new data and is considered blocked. A sender SHOULD send 916 STREAM_DATA_BLOCKED or DATA_BLOCKED frames to indicate it has data to 917 write but is blocked by flow control limits. These frames are 918 expected to be sent infrequently in common cases, but they are 919 considered useful for debugging and monitoring purposes. 921 A sender sends a single STREAM_DATA_BLOCKED or DATA_BLOCKED frame 922 only once when it reaches a data limit. A sender SHOULD NOT send 923 multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames for the same data 924 limit, unless the original frame is determined to be lost. Another 925 STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data 926 limit is increased. 928 4.2. Flow Credit Increments 930 This document leaves when and how many bytes to advertise in a 931 MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a 932 few considerations. These frames contribute to connection overhead. 933 Therefore frequently sending frames with small changes is 934 undesirable. At the same time, larger increments to limits are 935 necessary to avoid blocking if updates are less frequent, requiring 936 larger resource commitments at the receiver. Thus there is a trade- 937 off between resource commitment and overhead when determining how 938 large a limit is advertised. 940 A receiver can use an autotuning mechanism to tune the frequency and 941 amount of advertised additional credit based on a round-trip time 942 estimate and the rate at which the receiving application consumes 943 data, similar to common TCP implementations. As an optimization, 944 sending frames related to flow control only when there are other 945 frames to send or when a peer is blocked ensures that flow control 946 doesn't cause extra packets to be sent. 948 If a sender runs out of flow control credit, it will be unable to 949 send new data and is considered blocked. It is generally considered 950 best to not let the sender become blocked. To avoid blocking a 951 sender, and to reasonably account for the possibility of loss, a 952 receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two 953 round trips before it expects the sender to get blocked. 955 A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED 956 frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will 957 mean that a sender will be blocked for at least an entire round trip, 958 and potentially for longer if the peer chooses to not send 959 STREAM_DATA_BLOCKED or DATA_BLOCKED frames. 961 4.3. Handling Stream Cancellation 963 Endpoints need to eventually agree on the amount of flow control 964 credit that has been consumed, to avoid either exceeding flow control 965 limits or deadlocking. 967 On receipt of a RESET_STREAM frame, an endpoint will tear down state 968 for the matching stream and ignore further data arriving on that 969 stream. If a RESET_STREAM frame is reordered with stream data for 970 the same stream, the receiver's estimate of the number of bytes 971 received on that stream can be lower than the sender's estimate of 972 the number sent. As a result, the two endpoints could disagree on 973 the number of bytes that count towards connection flow control. 975 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes 976 the final size of data sent on the stream. On receiving a 977 RESET_STREAM frame, a receiver definitively knows how many bytes were 978 sent on that stream before the RESET_STREAM frame, and the receiver 979 MUST use the final size of the stream to account for all bytes sent 980 on the stream in its connection level flow controller. 982 RESET_STREAM terminates one direction of a stream abruptly. For a 983 bidirectional stream, RESET_STREAM has no effect on data flow in the 984 opposite direction. Both endpoints MUST maintain flow control state 985 for the stream in the unterminated direction until that direction 986 enters a terminal state, or until one of the endpoints sends 987 CONNECTION_CLOSE. 989 4.4. Stream Final Size 991 The final size is the amount of flow control credit that is consumed 992 by a stream. Assuming that every contiguous byte on the stream was 993 sent once, the final size is the number of bytes sent. More 994 generally, this is one higher than the largest byte offset sent on 995 the stream. 997 For a stream that is reset, the final size is carried explicitly in a 998 RESET_STREAM frame. Otherwise, the final size is the offset plus the 999 length of a STREAM frame marked with a FIN flag, or 0 in the case of 1000 incoming unidirectional streams. 1002 An endpoint will know the final size for a stream when the receiving 1003 part of the stream enters the "Size Known" or "Reset Recvd" state 1004 (Section 3). 1006 An endpoint MUST NOT send data on a stream at or beyond the final 1007 size. 1009 Once a final size for a stream is known, it cannot change. If a 1010 RESET_STREAM or STREAM frame is received indicating a change in the 1011 final size for the stream, an endpoint SHOULD respond with a 1012 FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat 1013 receipt of data at or beyond the final size as a FINAL_SIZE_ERROR 1014 error, even after a stream is closed. Generating these errors is not 1015 mandatory, but only because requiring that an endpoint generate these 1016 errors also means that the endpoint needs to maintain the final size 1017 state for closed streams, which could mean a significant state 1018 commitment. 1020 4.5. Controlling Concurrency 1022 An endpoint limits the cumulative number of incoming streams a peer 1023 can open. Only streams with a stream ID less than (max_stream * 4 + 1024 initial_stream_id_for_type) can be opened (see Table 5). Initial 1025 limits are set in the transport parameters (see Section 18.1) and 1026 subsequently limits are advertised using MAX_STREAMS frames 1027 (Section 19.11). Separate limits apply to unidirectional and 1028 bidirectional streams. 1030 Endpoints MUST NOT exceed the limit set by their peer. An endpoint 1031 that receives a STREAM frame with a stream ID exceeding the limit it 1032 has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR 1033 (Section 11). 1035 A receiver cannot renege on an advertisement. That is, once a 1036 receiver advertises a stream limit using the MAX_STREAMS frame, 1037 advertising a smaller limit has no effect. A receiver MUST ignore 1038 any MAX_STREAMS frame that does not increase the stream limit. 1040 As with stream and connection flow control, this document leaves when 1041 and how many streams to advertise to a peer via MAX_STREAMS to 1042 implementations. Implementations might choose to increase limits as 1043 streams close to keep the number of streams available to peers 1044 roughly consistent. 1046 An endpoint that is unable to open a new stream due to the peer's 1047 limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This 1048 signal is considered useful for debugging. An endpoint MUST NOT wait 1049 to receive this signal before advertising additional credit, since 1050 doing so will mean that the peer will be blocked for at least an 1051 entire round trip, and potentially for longer if the peer chooses to 1052 not send STREAMS_BLOCKED frames. 1054 5. Connections 1056 QUIC's connection establishment combines version negotiation with the 1057 cryptographic and transport handshakes to reduce connection 1058 establishment latency, as described in Section 7. Once established, 1059 a connection may migrate to a different IP or port at either endpoint 1060 as described in Section 9. Finally, a connection may be terminated 1061 by either endpoint, as described in Section 10. 1063 5.1. Connection ID 1065 Each connection possesses a set of connection identifiers, or 1066 connection IDs, each of which can identify the connection. 1067 Connection IDs are independently selected by endpoints; each endpoint 1068 selects the connection IDs that its peer uses. 1070 The primary function of a connection ID is to ensure that changes in 1071 addressing at lower protocol layers (UDP, IP) don't cause packets for 1072 a QUIC connection to be delivered to the wrong endpoint. Each 1073 endpoint selects connection IDs using an implementation-specific (and 1074 perhaps deployment-specific) method which will allow packets with 1075 that connection ID to be routed back to the endpoint and identified 1076 by the endpoint upon receipt. 1078 Connection IDs MUST NOT contain any information that can be used by 1079 an external observer to correlate them with other connection IDs for 1080 the same connection. As a trivial example, this means the same 1081 connection ID MUST NOT be issued more than once on the same 1082 connection. 1084 Packets with long headers include Source Connection ID and 1085 Destination Connection ID fields. These fields are used to set the 1086 connection IDs for new connections, see Section 7.2 for details. 1088 Packets with short headers (Section 17.3) only include the 1089 Destination Connection ID and omit the explicit length. The length 1090 of the Destination Connection ID field is expected to be known to 1091 endpoints. Endpoints using a load balancer that routes based on 1092 connection ID could agree with the load balancer on a fixed length 1093 for connection IDs, or agree on an encoding scheme. A fixed portion 1094 could encode an explicit length, which allows the entire connection 1095 ID to vary in length and still be used by the load balancer. 1097 A Version Negotiation (Section 17.2.1) packet echoes the connection 1098 IDs selected by the client, both to ensure correct routing toward the 1099 client and to allow the client to validate that the packet is in 1100 response to an Initial packet. 1102 A zero-length connection ID MAY be used when the connection ID is not 1103 needed for routing and the address/port tuple of packets is 1104 sufficient to identify a connection. An endpoint whose peer has 1105 selected a zero-length connection ID MUST continue to use a zero- 1106 length connection ID for the lifetime of the connection and MUST NOT 1107 send packets from any other local address. 1109 When an endpoint has requested a non-zero-length connection ID, it 1110 needs to ensure that the peer has a supply of connection IDs from 1111 which to choose for packets sent to the endpoint. These connection 1112 IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame 1113 (Section 19.15). 1115 5.1.1. Issuing Connection IDs 1117 Each Connection ID has an associated sequence number to assist in 1118 deduplicating messages. The initial connection ID issued by an 1119 endpoint is sent in the Source Connection ID field of the long packet 1120 header (Section 17.2) during the handshake. The sequence number of 1121 the initial connection ID is 0. If the preferred_address transport 1122 parameter is sent, the sequence number of the supplied connection ID 1123 is 1. 1125 Additional connection IDs are communicated to the peer using 1126 NEW_CONNECTION_ID frames (Section 19.15). The sequence number on 1127 each newly-issued connection ID MUST increase by 1. The connection 1128 ID randomly selected by the client in the Initial packet and any 1129 connection ID provided by a Retry packet are not assigned sequence 1130 numbers unless a server opts to retain them as its initial connection 1131 ID. 1133 When an endpoint issues a connection ID, it MUST accept packets that 1134 carry this connection ID for the duration of the connection or until 1135 its peer invalidates the connection ID via a RETIRE_CONNECTION_ID 1136 frame (Section 19.16). 1138 Endpoints store received connection IDs for future use. An endpoint 1139 that receives excessive connection IDs MAY discard those it cannot 1140 store without sending a RETIRE_CONNECTION_ID frame. An endpoint that 1141 issues connection IDs cannot expect its peer to store and use all 1142 issued connection IDs. 1144 An endpoint SHOULD ensure that its peer has a sufficient number of 1145 available and unused connection IDs. While each endpoint 1146 independently chooses how many connection IDs to issue, endpoints 1147 SHOULD provide and maintain at least eight connection IDs. The 1148 endpoint SHOULD do this by always supplying a new connection ID when 1149 a connection ID is retired by its peer or when the endpoint receives 1150 a packet with a previously unused connection ID. Endpoints that 1151 initiate migration and require non-zero-length connection IDs SHOULD 1152 provide their peers with new connection IDs before migration, or risk 1153 the peer closing the connection. 1155 5.1.2. Consuming and Retiring Connection IDs 1157 An endpoint can change the connection ID it uses for a peer to 1158 another available one at any time during the connection. An endpoint 1159 consumes connection IDs in response to a migrating peer, see 1160 Section 9.5 for more. 1162 An endpoint maintains a set of connection IDs received from its peer, 1163 any of which it can use when sending packets. When the endpoint 1164 wishes to remove a connection ID from use, it sends a 1165 RETIRE_CONNECTION_ID frame to its peer. Sending a 1166 RETIRE_CONNECTION_ID frame indicates that the connection ID won't be 1167 used again and requests that the peer replace it with a new 1168 connection ID using a NEW_CONNECTION_ID frame. 1170 As discussed in Section 9.5, each connection ID MUST be used on 1171 packets sent from only one local address. An endpoint that migrates 1172 away from a local address SHOULD retire all connection IDs used on 1173 that address once it no longer plans to use that address. 1175 5.2. Matching Packets to Connections 1177 Incoming packets are classified on receipt. Packets can either be 1178 associated with an existing connection, or - for servers - 1179 potentially create a new connection. 1181 Hosts try to associate a packet with an existing connection. If the 1182 packet has a Destination Connection ID corresponding to an existing 1183 connection, QUIC processes that packet accordingly. Note that more 1184 than one connection ID can be associated with a connection; see 1185 Section 5.1. 1187 If the Destination Connection ID is zero length and the packet 1188 matches the address/port tuple of a connection where the host did not 1189 require connection IDs, QUIC processes the packet as part of that 1190 connection. Endpoints SHOULD either reject connection attempts that 1191 use the same addresses as existing connections, or use a non-zero- 1192 length Destination Connection ID so that packets can be correctly 1193 attributed to connections. 1195 Endpoints can send a Stateless Reset (Section 10.4) for any packets 1196 that cannot be attributed to an existing connection. A stateless 1197 reset allows a peer to more quickly identify when a connection 1198 becomes unusable. 1200 Packets that are matched to an existing connection, but for which the 1201 endpoint cannot remove packet protection, are discarded. 1203 Invalid packets without packet protection, such as Initial, Retry, or 1204 Version Negotiation, MAY be discarded. An endpoint MUST generate a 1205 connection error if it commits changes to state before discovering an 1206 error. 1208 5.2.1. Client Packet Handling 1210 Valid packets sent to clients always include a Destination Connection 1211 ID that matches a value the client selects. Clients that choose to 1212 receive zero-length connection IDs can use the address/port tuple to 1213 identify a connection. Packets that don't match an existing 1214 connection are discarded. 1216 Due to packet reordering or loss, clients might receive packets for a 1217 connection that are encrypted with a key it has not yet computed. 1218 Clients MAY drop these packets, or MAY buffer them in anticipation of 1219 later packets that allow it to compute the key. 1221 If a client receives a packet that has an unsupported version, it 1222 MUST discard that packet. 1224 5.2.2. Server Packet Handling 1226 If a server receives a packet that has an unsupported version, but 1227 the packet is sufficiently large to initiate a new connection for any 1228 version supported by the server, it SHOULD send a Version Negotiation 1229 packet as described in Section 6.1. Servers MAY rate control these 1230 packets to avoid storms of Version Negotiation packets. 1232 The first packet for an unsupported version can use different 1233 semantics and encodings for any version-specific field. In 1234 particular, different packet protection keys might be used for 1235 different versions. Servers that do not support a particular version 1236 are unlikely to be able to decrypt the payload of the packet. 1237 Servers SHOULD NOT attempt to decode or decrypt a packet from an 1238 unknown version, but instead send a Version Negotiation packet, 1239 provided that the packet is sufficiently long. 1241 Servers MUST drop other packets that contain unsupported versions. 1243 Packets with a supported version, or no version field, are matched to 1244 a connection using the connection ID or - for packets with zero- 1245 length connection IDs - the address tuple. If the packet doesn't 1246 match an existing connection, the server continues below. 1248 If the packet is an Initial packet fully conforming with the 1249 specification, the server proceeds with the handshake (Section 7). 1250 This commits the server to the version that the client selected. 1252 If a server isn't currently accepting any new connections, it SHOULD 1253 send an Initial packet containing a CONNECTION_CLOSE frame with error 1254 code SERVER_BUSY. 1256 If the packet is a 0-RTT packet, the server MAY buffer a limited 1257 number of these packets in anticipation of a late-arriving Initial 1258 Packet. Clients are forbidden from sending Handshake packets prior 1259 to receiving a server response, so servers SHOULD ignore any such 1260 packets. 1262 Servers MUST drop incoming packets under all other circumstances. 1264 5.3. Life of a QUIC Connection 1266 TBD. 1268 6. Version Negotiation 1270 Version negotiation ensures that client and server agree to a QUIC 1271 version that is mutually supported. A server sends a Version 1272 Negotiation packet in response to each packet that might initiate a 1273 new connection, see Section 5.2 for details. 1275 The first few messages of an exchange between a client attempting to 1276 create a new connection with server is shown in Figure 3. After 1277 version negotiation completes, connection establishment can proceed, 1278 for example as shown in Section 7.1. 1280 Client Server 1282 Packet (v=X) -> 1284 <- Version Negotiation (supported=Y,Z) 1286 Packet (v=Y) -> 1288 <- Packet(s) (v=Y) 1290 Figure 3: Example Version Negotiation Exchange 1292 The size of the first packet sent by a client will determine whether 1293 a server sends a Version Negotiation packet. Clients that support 1294 multiple QUIC versions SHOULD pad the first packet they send to the 1295 largest of the minimum packet sizes across all versions they support. 1296 This ensures that the server responds if there is a mutually 1297 supported version. 1299 6.1. Sending Version Negotiation Packets 1301 If the version selected by the client is not acceptable to the 1302 server, the server responds with a Version Negotiation packet (see 1303 Section 17.2.1). This includes a list of versions that the server 1304 will accept. An endpoint MUST NOT send a Version Negotiation packet 1305 in response to receiving a Version Negotiation packet. 1307 This system allows a server to process packets with unsupported 1308 versions without retaining state. Though either the Initial packet 1309 or the Version Negotiation packet that is sent in response could be 1310 lost, the client will send new packets until it successfully receives 1311 a response or it abandons the connection attempt. 1313 A server MAY limit the number of Version Negotiation packets it 1314 sends. For instance, a server that is able to recognize packets as 1315 0-RTT might choose not to send Version Negotiation packets in 1316 response to 0-RTT packets with the expectation that it will 1317 eventually receive an Initial packet. 1319 6.2. Handling Version Negotiation Packets 1321 When the client receives a Version Negotiation packet, it first 1322 checks that the Destination and Source Connection ID fields match the 1323 Source and Destination Connection ID fields in a packet that the 1324 client sent. If this check fails, the packet MUST be discarded. 1326 Once the Version Negotiation packet is determined to be valid, the 1327 client then selects an acceptable protocol version from the list 1328 provided by the server. The client then attempts to create a 1329 connection using that version. Though the content of the Initial 1330 packet the client sends might not change in response to version 1331 negotiation, a client MUST increase the packet number it uses on 1332 every packet it sends. Packets MUST continue to use long headers 1333 (Section 17.2) and MUST include the new negotiated protocol version. 1335 The client MUST use the long header format and include its selected 1336 version on all packets until it has 1-RTT keys and it has received a 1337 packet from the server which is not a Version Negotiation packet. 1339 A client MUST NOT change the version it uses unless it is in response 1340 to a Version Negotiation packet from the server. Once a client 1341 receives a packet from the server which is not a Version Negotiation 1342 packet, it MUST discard other Version Negotiation packets on the same 1343 connection. Similarly, a client MUST ignore a Version Negotiation 1344 packet if it has already received and acted on a Version Negotiation 1345 packet. 1347 A client MUST ignore a Version Negotiation packet that lists the 1348 client's chosen version. If the client does not support any of the 1349 versions the server offers, it aborts the connection attempt. 1351 A client MAY attempt 0-RTT after receiving a Version Negotiation 1352 packet. A client that sends additional 0-RTT packets MUST NOT reset 1353 the packet number to 0 as a result, see Section 17.2.3. 1355 Version negotiation packets have no cryptographic protection. The 1356 result of the negotiation MUST be revalidated as part of the 1357 cryptographic handshake (see Section 7.3.3). 1359 6.3. Using Reserved Versions 1361 For a server to use a new version in the future, clients must 1362 correctly handle unsupported versions. To help ensure this, a server 1363 SHOULD include a reserved version (see Section 15) while generating a 1364 Version Negotiation packet. 1366 The design of version negotiation permits a server to avoid 1367 maintaining state for packets that it rejects in this fashion. The 1368 validation of version negotiation (see Section 7.3.3) only validates 1369 the result of version negotiation, which is the same no matter which 1370 reserved version was sent. A server MAY therefore send different 1371 reserved version numbers in the Version Negotiation Packet and in its 1372 transport parameters. 1374 A client MAY send a packet using a reserved version number. This can 1375 be used to solicit a list of supported versions from a server. 1377 7. Cryptographic and Transport Handshake 1379 QUIC relies on a combined cryptographic and transport handshake to 1380 minimize connection establishment latency. QUIC uses the CRYPTO 1381 frame Section 19.6 to transmit the cryptographic handshake. Version 1382 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 1383 QUIC version number could indicate that a different cryptographic 1384 handshake protocol is in use. 1386 QUIC provides reliable, ordered delivery of the cryptographic 1387 handshake data. QUIC packet protection is used to encrypt as much of 1388 the handshake protocol as possible. The cryptographic handshake MUST 1389 provide the following properties: 1391 o authenticated key exchange, where 1393 * a server is always authenticated, 1395 * a client is optionally authenticated, 1397 * every connection produces distinct and unrelated keys, 1399 * keying material is usable for packet protection for both 0-RTT 1400 and 1-RTT packets, and 1402 * 1-RTT keys have forward secrecy 1404 o authenticated values for the transport parameters of the peer (see 1405 Section 7.3) 1407 o authenticated confirmation of version negotiation (see 1408 Section 7.3.3) 1410 o authenticated negotiation of an application protocol (TLS uses 1411 ALPN [RFC7301] for this purpose) 1413 The first CRYPTO frame from a client MUST be sent in a single packet. 1414 Any second attempt that is triggered by address validation (see 1415 Section 8.1) MUST also be sent within a single packet. This avoids 1416 having to reassemble a message from multiple packets. 1418 The first client packet of the cryptographic handshake protocol MUST 1419 fit within a 1232 byte QUIC packet payload. This includes overheads 1420 that reduce the space available to the cryptographic handshake 1421 protocol. 1423 An endpoint can verify support for Explicit Congestion Notification 1424 (ECN) in the first packets it sends, as described in Section 13.3.2. 1426 The CRYPTO frame can be sent in different packet number spaces. The 1427 sequence numbers used by CRYPTO frames to ensure ordered delivery of 1428 cryptographic handshake data start from zero in each packet number 1429 space. 1431 Endpoints MUST explicitly negotiate an application protocol. This 1432 avoids situations where there is a disagreement about the protocol 1433 that is in use. 1435 7.1. Example Handshake Flows 1437 Details of how TLS is integrated with QUIC are provided in 1438 [QUIC-TLS], but some examples are provided here. An extension of 1439 this exchange to support client address validation is shown in 1440 Section 8.1.1. 1442 Once any version negotiation and address validation exchanges are 1443 complete, the cryptographic handshake is used to agree on 1444 cryptographic keys. The cryptographic handshake is carried in 1445 Initial (Section 17.2.2) and Handshake (Section 17.2.4) packets. 1447 Figure 4 provides an overview of the 1-RTT handshake. Each line 1448 shows a QUIC packet with the packet type and packet number shown 1449 first, followed by the frames that are typically contained in those 1450 packets. So, for instance the first packet is of type Initial, with 1451 packet number 0, and contains a CRYPTO frame carrying the 1452 ClientHello. 1454 Note that multiple QUIC packets - even of different encryption levels 1455 - may be coalesced into a single UDP datagram (see Section 12.2), and 1456 so this handshake may consist of as few as 4 UDP datagrams, or any 1457 number more. For instance, the server's first flight contains 1458 packets from the Initial encryption level (obfuscation), the 1459 Handshake level, and "0.5-RTT data" from the server at the 1-RTT 1460 encryption level. 1462 Client Server 1464 Initial[0]: CRYPTO[CH] -> 1466 Initial[0]: CRYPTO[SH] ACK[0] 1467 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1468 <- 1-RTT[0]: STREAM[1, "..."] 1470 Initial[1]: ACK[0] 1471 Handshake[0]: CRYPTO[FIN], ACK[0] 1472 1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1474 1-RTT[1]: STREAM[55, "..."], ACK[0] 1475 <- Handshake[1]: ACK[0] 1477 Figure 4: Example 1-RTT Handshake 1479 Figure 5 shows an example of a connection with a 0-RTT handshake and 1480 a single packet of 0-RTT data. Note that as described in 1481 Section 12.3, the server acknowledges 0-RTT data at the 1-RTT 1482 encryption level, and the client sends 1-RTT packets in the same 1483 packet number space. 1485 Client Server 1487 Initial[0]: CRYPTO[CH] 1488 0-RTT[0]: STREAM[0, "..."] -> 1490 Initial[0]: CRYPTO[SH] ACK[0] 1491 Handshake[0] CRYPTO[EE, CERT, CV, FIN] 1492 <- 1-RTT[0]: STREAM[1, "..."] ACK[0] 1494 Initial[1]: ACK[0] 1495 Handshake[0]: CRYPTO[FIN], ACK[0] 1496 1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1498 1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1499 <- Handshake[1]: ACK[0] 1501 Figure 5: Example 0-RTT Handshake 1503 7.2. Negotiating Connection IDs 1505 A connection ID is used to ensure consistent routing of packets, as 1506 described in Section 5.1. The long header contains two connection 1507 IDs: the Destination Connection ID is chosen by the recipient of the 1508 packet and is used to provide consistent routing; the Source 1509 Connection ID is used to set the Destination Connection ID used by 1510 the peer. 1512 During the handshake, packets with the long header (Section 17.2) are 1513 used to establish the connection ID that each endpoint uses. Each 1514 endpoint uses the Source Connection ID field to specify the 1515 connection ID that is used in the Destination Connection ID field of 1516 packets being sent to them. Upon receiving a packet, each endpoint 1517 sets the Destination Connection ID it sends to match the value of the 1518 Source Connection ID that they receive. 1520 When an Initial packet is sent by a client which has not previously 1521 received a Retry packet from the server, it populates the Destination 1522 Connection ID field with an unpredictable value. This MUST be at 1523 least 8 bytes in length. Until a packet is received from the server, 1524 the client MUST use the same value unless it abandons the connection 1525 attempt and starts a new one. The initial Destination Connection ID 1526 is used to determine packet protection keys for Initial packets. 1528 The final version used for a connection might be different from the 1529 version of the first Initial from the client. To enable consistent 1530 routing through the handshake, a client SHOULD select an initial 1531 Destination Connection ID length long enough to fulfill the minimum 1532 size for every QUIC version it supports. 1534 The client populates the Source Connection ID field with a value of 1535 its choosing and sets the SCIL field to match. 1537 The Destination Connection ID field in the server's Initial packet 1538 contains a connection ID that is chosen by the recipient of the 1539 packet (i.e., the client); the Source Connection ID includes the 1540 connection ID that the sender of the packet wishes to use (see 1541 Section 5.1). The server MUST use consistent Source Connection IDs 1542 during the handshake. 1544 On first receiving an Initial or Retry packet from the server, the 1545 client uses the Source Connection ID supplied by the server as the 1546 Destination Connection ID for subsequent packets. That means that a 1547 client might change the Destination Connection ID twice during 1548 connection establishment, once in response to a Retry and once in 1549 response to the first Initial packet from the server. Once a client 1550 has received an Initial packet from the server, it MUST discard any 1551 packet it receives with a different Source Connection ID. 1553 A client MUST only change the value it sends in the Destination 1554 Connection ID in response to the first packet of each type it 1555 receives from the server (Retry or Initial); a server MUST set its 1556 value based on the Initial packet. Any additional changes are not 1557 permitted; if subsequent packets of those types include a different 1558 Source Connection ID, they MUST be discarded. This avoids problems 1559 that might arise from stateless processing of multiple Initial 1560 packets producing different connection IDs. 1562 The connection ID can change over the lifetime of a connection, 1563 especially in response to connection migration (Section 9), see 1564 Section 5.1.1 for details. 1566 7.3. Transport Parameters 1568 During connection establishment, both endpoints make authenticated 1569 declarations of their transport parameters. These declarations are 1570 made unilaterally by each endpoint. Endpoints are required to comply 1571 with the restrictions implied by these parameters; the description of 1572 each parameter includes rules for its handling. 1574 The encoding of the transport parameters is detailed in Section 18. 1576 QUIC includes the encoded transport parameters in the cryptographic 1577 handshake. Once the handshake completes, the transport parameters 1578 declared by the peer are available. Each endpoint validates the 1579 value provided by its peer. In particular, version negotiation MUST 1580 be validated (see Section 7.3.3) before the connection establishment 1581 is considered properly complete. 1583 Definitions for each of the defined transport parameters are included 1584 in Section 18.1. An endpoint MUST treat receipt of a transport 1585 parameter with an invalid value as a connection error of type 1586 TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most 1587 once in a given transport parameters extension. An endpoint MUST 1588 treat receipt of duplicate transport parameters as a connection error 1589 of type TRANSPORT_PARAMETER_ERROR. 1591 A server MUST include the original_connection_id transport parameter 1592 (Section 18.1) if it sent a Retry packet to enable validation of the 1593 Retry, as described in Section 17.2.5. 1595 7.3.1. Values of Transport Parameters for 0-RTT 1597 A client that attempts to send 0-RTT data MUST remember the transport 1598 parameters used by the server. The transport parameters that the 1599 server advertises during connection establishment apply to all 1600 connections that are resumed using the keying material established 1601 during that handshake. Remembered transport parameters apply to the 1602 new connection until the handshake completes and new transport 1603 parameters from the server can be provided. 1605 A server can remember the transport parameters that it advertised, or 1606 store an integrity-protected copy of the values in the ticket and 1607 recover the information when accepting 0-RTT data. A server uses the 1608 transport parameters in determining whether to accept 0-RTT data. 1610 A server MAY accept 0-RTT and subsequently provide different values 1611 for transport parameters for use in the new connection. If 0-RTT 1612 data is accepted by the server, the server MUST NOT reduce any limits 1613 or alter any values that might be violated by the client with its 1614 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 1615 set values for the following parameters (Section 18.1) that are 1616 smaller than the remembered value of those parameters. 1618 o initial_max_data 1620 o initial_max_stream_data_bidi_local 1622 o initial_max_stream_data_bidi_remote 1624 o initial_max_stream_data_uni 1626 o initial_max_streams_bidi 1628 o initial_max_streams_uni 1630 Omitting or setting a zero value for certain transport parameters can 1631 result in 0-RTT data being enabled, but not usable. The applicable 1632 subset of transport parameters that permit sending of application 1633 data SHOULD be set to non-zero values for 0-RTT. This includes 1634 initial_max_data and either initial_max_streams_bidi and 1635 initial_max_stream_data_bidi_remote, or initial_max_streams_uni and 1636 initial_max_stream_data_uni. 1638 The value of the server's previous preferred_address MUST NOT be used 1639 when establishing a new connection; rather, the client should wait to 1640 observe the server's new preferred_address value in the handshake. 1642 A server MUST either reject 0-RTT data or abort a handshake if the 1643 implied values for transport parameters cannot be supported. 1645 7.3.2. New Transport Parameters 1647 New transport parameters can be used to negotiate new protocol 1648 behavior. An endpoint MUST ignore transport parameters that it does 1649 not support. Absence of a transport parameter therefore disables any 1650 optional protocol feature that is negotiated using the parameter. 1652 New transport parameters can be registered according to the rules in 1653 Section 22.1. 1655 7.3.3. Version Negotiation Validation 1657 Though the cryptographic handshake has integrity protection, two 1658 forms of QUIC version downgrade are possible. In the first, an 1659 attacker replaces the QUIC version in the Initial packet. In the 1660 second, a fake Version Negotiation packet is sent by an attacker. To 1661 protect against these attacks, the transport parameters include three 1662 fields that encode version information. These parameters are used to 1663 retroactively authenticate the choice of version (see Section 6). 1665 The cryptographic handshake provides integrity protection for the 1666 negotiated version as part of the transport parameters (see 1667 Section 18.1). As a result, attacks on version negotiation by an 1668 attacker can be detected. 1670 The client includes the initial_version field in its transport 1671 parameters. The initial_version is the version that the client 1672 initially attempted to use. If the server did not send a Version 1673 Negotiation packet Section 17.2.1, this will be identical to the 1674 negotiated_version field in the server transport parameters. 1676 A server that processes all packets in a stateful fashion can 1677 remember how version negotiation was performed and validate the 1678 initial_version value. 1680 A server that does not maintain state for every packet it receives 1681 (i.e., a stateless server) uses a different process. If the 1682 initial_version matches the version of QUIC that is in use, a 1683 stateless server can accept the value. 1685 If the initial_version is different from the version of QUIC that is 1686 in use, a stateless server MUST check that it would have sent a 1687 Version Negotiation packet if it had received a packet with the 1688 indicated initial_version. If a server would have accepted the 1689 version included in the initial_version and the value differs from 1690 the QUIC version that is in use, the server MUST terminate the 1691 connection with a VERSION_NEGOTIATION_ERROR error. 1693 The server includes both the version of QUIC that is in use and a 1694 list of the QUIC versions that the server supports (see 1695 Section 18.1). 1697 The negotiated_version field is the version that is in use. This 1698 MUST be set by the server to the value that is on the Initial packet 1699 that it accepts (not an Initial packet that triggers a Retry or 1700 Version Negotiation packet). A client that receives a 1701 negotiated_version that does not match the version of QUIC that is in 1702 use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR 1703 error code. 1705 The server includes a list of versions that it would send in any 1706 version negotiation packet (Section 17.2.1) in the supported_versions 1707 field. The server populates this field even if it did not send a 1708 version negotiation packet. 1710 The client validates that the negotiated_version is included in the 1711 supported_versions list and - if version negotiation was performed - 1712 that it would have selected the negotiated version. A client MUST 1713 terminate the connection with a VERSION_NEGOTIATION_ERROR error code 1714 if the current QUIC version is not listed in the supported_versions 1715 list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error 1716 code if version negotiation occurred but it would have selected a 1717 different version based on the value of the supported_versions list. 1719 When an endpoint accepts multiple QUIC versions, it can potentially 1720 interpret transport parameters as they are defined by any of the QUIC 1721 versions it supports. The version field in the QUIC packet header is 1722 authenticated using transport parameters. The position and the 1723 format of the version fields in transport parameters MUST either be 1724 identical across different QUIC versions, or be unambiguously 1725 different to ensure no confusion about their interpretation. One way 1726 that a new format could be introduced is to define a TLS extension 1727 with a different codepoint. 1729 8. Address Validation 1731 Address validation is used by QUIC to avoid being used for a traffic 1732 amplification attack. In such an attack, a packet is sent to a 1733 server with spoofed source address information that identifies a 1734 victim. If a server generates more or larger packets in response to 1735 that packet, the attacker can use the server to send more data toward 1736 the victim than it would be able to send on its own. 1738 The primary defense against amplification attack is verifying that an 1739 endpoint is able to receive packets at the transport address that it 1740 claims. Address validation is performed both during connection 1741 establishment (see Section 8.1) and during connection migration (see 1742 Section 8.2). 1744 8.1. Address Validation During Connection Establishment 1746 Connection establishment implicitly provides address validation for 1747 both endpoints. In particular, receipt of a packet protected with 1748 Handshake keys confirms that the client received the Initial packet 1749 from the server. Once the server has successfully processed a 1750 Handshake packet from the client, it can consider the client address 1751 to have been validated. 1753 Prior to validating the client address, servers MUST NOT send more 1754 than three times as many bytes as the number of bytes they have 1755 received. This limits the magnitude of any amplification attack that 1756 can be mounted using spoofed source addresses. In determining this 1757 limit, servers only count the size of successfully processed packets. 1759 Clients MUST pad UDP datagrams that contain only Initial packets to 1760 at least 1200 bytes. Once a client has received an acknowledgment 1761 for a Handshake packet it MAY send smaller datagrams. Sending padded 1762 datagrams ensures that the server is not overly constrained by the 1763 amplification restriction. 1765 Packet loss, in particular loss of a Handshake packet from the 1766 server, can cause a situation in which the server cannot send when 1767 the client has no data to send and the anti-amplification limit is 1768 reached. In order to avoid this causing a handshake deadlock, 1769 clients SHOULD send a packet upon a handshake timeout, as described 1770 in [QUIC-RECOVERY]. If the client has no data to retransmit and does 1771 not have Handshake keys, it SHOULD send an Initial packet in a UDP 1772 datagram of at least 1200 bytes. If the client has Handshake keys, 1773 it SHOULD send a Handshake packet. 1775 A server might wish to validate the client address before starting 1776 the cryptographic handshake. QUIC uses a token in the Initial packet 1777 to provide address validation prior to completing the handshake. 1778 This token is delivered to the client during connection establishment 1779 with a Retry packet (see Section 8.1.1) or in a previous connection 1780 using the NEW_TOKEN frame (see Section 8.1.2). 1782 In addition to sending limits imposed prior to address validation, 1783 servers are also constrained in what they can send by the limits set 1784 by the congestion controller. Clients are only constrained by the 1785 congestion controller. 1787 8.1.1. Address Validation using Retry Packets 1789 Upon receiving the client's Initial packet, the server can request 1790 address validation by sending a Retry packet (Section 17.2.5) 1791 containing a token. This token MUST be repeated by the client in all 1792 Initial packets it sends after it receives the Retry packet. In 1793 response to processing an Initial containing a token, a server can 1794 either abort the connection or permit it to proceed. 1796 As long as it is not possible for an attacker to generate a valid 1797 token for its own address (see Section 8.1.3) and the client is able 1798 to return that token, it proves to the server that it received the 1799 token. 1801 A server can also use a Retry packet to defer the state and 1802 processing costs of connection establishment. By giving the client a 1803 different connection ID to use, a server can cause the connection to 1804 be routed to a server instance with more resources available for new 1805 connections. 1807 A flow showing the use of a Retry packet is shown in Figure 6. 1809 Client Server 1811 Initial[0]: CRYPTO[CH] -> 1813 <- Retry+Token 1815 Initial+Token[0]: CRYPTO[CH] -> 1817 Initial[0]: CRYPTO[SH] ACK[0] 1818 Handshake[0]: CRYPTO[EE, CERT, CV, FIN] 1819 <- 1-RTT[0]: STREAM[1, "..."] 1821 Figure 6: Example Handshake with Retry 1823 8.1.2. Address Validation for Future Connections 1825 A server MAY provide clients with an address validation token during 1826 one connection that can be used on a subsequent connection. Address 1827 validation is especially important with 0-RTT because a server 1828 potentially sends a significant amount of data to a client in 1829 response to 0-RTT data. 1831 The server uses the NEW_TOKEN frame Section 19.7 to provide the 1832 client with an address validation token that can be used to validate 1833 future connections. The client includes this token in Initial 1834 packets to provide address validation in a future connection. The 1835 client MUST include the token in all Initial packets it sends, unless 1836 a Retry replaces the token with a newer token. The client MUST NOT 1837 use the token provided in a Retry for future connections. Servers 1838 MAY discard any Initial packet that does not carry the expected 1839 token. 1841 Unlike the token that is created for a Retry packet, there might be 1842 some time between when the token is created and when the token is 1843 subsequently used. Thus, a token SHOULD include an expiration time. 1844 The server MAY include either an explicit expiration time or an 1845 issued timestamp and dynamically calculate the expiration time. It 1846 is also unlikely that the client port number is the same on two 1847 different connections; validating the port is therefore unlikely to 1848 be successful. 1850 A token SHOULD be constructed to be easily distinguishable from 1851 tokens that are sent in Retry packets as they are carried in the same 1852 field. 1854 If the client has a token received in a NEW_TOKEN frame on a previous 1855 connection to what it believes to be the same server, it can include 1856 that value in the Token field of its Initial packet. 1858 A token allows a server to correlate activity between the connection 1859 where the token was issued and any connection where it is used. 1860 Clients that want to break continuity of identity with a server MAY 1861 discard tokens provided using the NEW_TOKEN frame. A token obtained 1862 in a Retry packet MUST be used immediately during the connection 1863 attempt and cannot be used in subsequent connection attempts. 1865 A client SHOULD NOT reuse a token in different connections. Reusing 1866 a token allows connections to be linked by entities on the network 1867 path (see Section 9.5). A client MUST NOT reuse a token if it 1868 believes that its point of network attachment has changed since the 1869 token was last used; that is, if there is a change in its local IP 1870 address or network interface. A client needs to start the connection 1871 process over if it migrates prior to completing the handshake. 1873 When a server receives an Initial packet with an address validation 1874 token, it SHOULD attempt to validate it, unless it has already 1875 completed address validation. If the token is invalid then the 1876 server SHOULD proceed as if the client did not have a validated 1877 address, including potentially sending a Retry. If the validation 1878 succeeds, the server SHOULD then allow the handshake to proceed. 1880 Note: The rationale for treating the client as unvalidated rather 1881 than discarding the packet is that the client might have received 1882 the token in a previous connection using the NEW_TOKEN frame, and 1883 if the server has lost state, it might be unable to validate the 1884 token at all, leading to connection failure if the packet is 1885 discarded. A server MAY encode tokens provided with NEW_TOKEN 1886 frames and Retry packets differently, and validate the latter more 1887 strictly. 1889 In a stateless design, a server can use encrypted and authenticated 1890 tokens to pass information to clients that the server can later 1891 recover and use to validate a client address. Tokens are not 1892 integrated into the cryptographic handshake and so they are not 1893 authenticated. For instance, a client might be able to reuse a 1894 token. To avoid attacks that exploit this property, a server can 1895 limit its use of tokens to only the information needed to validate 1896 client addresses. 1898 Attackers could replay tokens to use servers as amplifiers in DDoS 1899 attacks. To protect against such attacks, servers SHOULD ensure that 1900 tokens sent in Retry packets are only accepted for a short time. 1901 Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need 1902 to be valid for longer, but SHOULD NOT be accepted multiple times in 1903 a short period. Servers are encouraged to allow tokens to be used 1904 only once, if possible. 1906 8.1.3. Address Validation Token Integrity 1908 An address validation token MUST be difficult to guess. Including a 1909 large enough random value in the token would be sufficient, but this 1910 depends on the server remembering the value it sends to clients. 1912 A token-based scheme allows the server to offload any state 1913 associated with validation to the client. For this design to work, 1914 the token MUST be covered by integrity protection against 1915 modification or falsification by clients. Without integrity 1916 protection, malicious clients could generate or guess values for 1917 tokens that would be accepted by the server. Only the server 1918 requires access to the integrity protection key for tokens. 1920 There is no need for a single well-defined format for the token 1921 because the server that generates the token also consumes it. A 1922 token could include information about the claimed client address (IP 1923 and port), a timestamp, and any other supplementary information the 1924 server will need to validate the token in the future. 1926 8.2. Path Validation 1928 Path validation is used during connection migration (see Section 9 1929 and Section 9.6) by the migrating endpoint to verify reachability of 1930 a peer from a new local address. In path validation, endpoints test 1931 reachability between a specific local address and a specific peer 1932 address, where an address is the two-tuple of IP address and port. 1934 Path validation tests that packets (PATH_CHALLENGE) can be both sent 1935 to and received (PATH_RESPONSE) from a peer on the path. 1937 Importantly, it validates that the packets received from the 1938 migrating endpoint do not carry a spoofed source address. 1940 Path validation can be used at any time by either endpoint. For 1941 instance, an endpoint might check that a peer is still in possession 1942 of its address after a period of quiescence. 1944 Path validation is not designed as a NAT traversal mechanism. Though 1945 the mechanism described here might be effective for the creation of 1946 NAT bindings that support NAT traversal, the expectation is that one 1947 or other peer is able to receive packets without first having sent a 1948 packet on that path. Effective NAT traversal needs additional 1949 synchronization mechanisms that are not provided here. 1951 An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that 1952 are used for path validation with other frames. In particular, an 1953 endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU 1954 discovery, or an endpoint may bundle a PATH_RESPONSE with its own 1955 PATH_CHALLENGE. 1957 When probing a new path, an endpoint might want to ensure that its 1958 peer has an unused connection ID available for responses. The 1959 endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the 1960 same packet. This ensures that an unused connection ID will be 1961 available to the peer when sending a response. 1963 8.3. Initiating Path Validation 1965 To initiate path validation, an endpoint sends a PATH_CHALLENGE frame 1966 containing a random payload on the path to be validated. 1968 An endpoint MAY send multiple PATH_CHALLENGE frames to guard against 1969 packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more 1970 frequently than it would an Initial packet, ensuring that connection 1971 migration is no more load on a new path than establishing a new 1972 connection. 1974 The endpoint MUST use unpredictable data in every PATH_CHALLENGE 1975 frame so that it can associate the peer's response with the 1976 corresponding PATH_CHALLENGE. 1978 8.4. Path Validation Responses 1980 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond 1981 immediately by echoing the data contained in the PATH_CHALLENGE frame 1982 in a PATH_RESPONSE frame. 1984 To ensure that packets can be both sent to and received from the 1985 peer, the PATH_RESPONSE MUST be sent on the same path as the 1986 triggering PATH_CHALLENGE. That is, from the same local address on 1987 which the PATH_CHALLENGE was received, to the same remote address 1988 from which the PATH_CHALLENGE was received. 1990 8.5. Successful Path Validation 1992 A new address is considered valid when a PATH_RESPONSE frame is 1993 received that meets the following criteria: 1995 o It contains the data that was sent in a previous PATH_CHALLENGE. 1996 Receipt of an acknowledgment for a packet containing a 1997 PATH_CHALLENGE frame is not adequate validation, since the 1998 acknowledgment can be spoofed by a malicious peer. 2000 o It was sent from the same remote address to which the 2001 corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame 2002 is received from a different remote address than the one to which 2003 the PATH_CHALLENGE was sent, path validation is considered to have 2004 failed, even if the data matches that sent in the PATH_CHALLENGE. 2006 o It was received on the same local address from which the 2007 corresponding PATH_CHALLENGE was sent. 2009 Note that receipt on a different local address does not result in 2010 path validation failure, as it might be a result of a forwarded 2011 packet (see Section 9.3.3) or misrouting. It is possible that a 2012 valid PATH_RESPONSE might be received in the future. 2014 8.6. Failed Path Validation 2016 Path validation only fails when the endpoint attempting to validate 2017 the path abandons its attempt to validate the path. 2019 Endpoints SHOULD abandon path validation based on a timer. When 2020 setting this timer, implementations are cautioned that the new path 2021 could have a longer round-trip time than the original. A value of 2022 three times the larger of the current Probe Timeout (PTO) or the 2023 initial timeout (that is, 2*kInitialRtt) as defined in 2024 [QUIC-RECOVERY] is RECOMMENDED. That is: 2026 validation_timeout = max(3*PTO, 6*kInitialRtt) 2028 Note that the endpoint might receive packets containing other frames 2029 on the new path, but a PATH_RESPONSE frame with appropriate data is 2030 required for path validation to succeed. 2032 When an endpoint abandons path validation, it determines that the 2033 path is unusable. This does not necessarily imply a failure of the 2034 connection - endpoints can continue sending packets over other paths 2035 as appropriate. If no paths are available, an endpoint can wait for 2036 a new path to become available or close the connection. 2038 A path validation might be abandoned for other reasons besides 2039 failure. Primarily, this happens if a connection migration to a new 2040 path is initiated while a path validation on the old path is in 2041 progress. 2043 9. Connection Migration 2045 The use of a connection ID allows connections to survive changes to 2046 endpoint addresses (that is, IP address and/or port), such as those 2047 caused by an endpoint migrating to a new network. This section 2048 describes the process by which an endpoint migrates to a new address. 2050 An endpoint MUST NOT initiate connection migration before the 2051 handshake is finished and the endpoint has 1-RTT keys. The design of 2052 QUIC relies on endpoints retaining a stable address for the duration 2053 of the handshake. 2055 An endpoint also MUST NOT initiate connection migration if the peer 2056 sent the "disable_migration" transport parameter during the 2057 handshake. An endpoint which has sent this transport parameter, but 2058 detects that a peer has nonetheless migrated to a different network 2059 MAY treat this as a connection error of type INVALID_MIGRATION. 2061 Not all changes of peer address are intentional migrations. The peer 2062 could experience NAT rebinding: a change of address due to a 2063 middlebox, usually a NAT, allocating a new outgoing port or even a 2064 new outgoing IP address for a flow. NAT rebinding is not connection 2065 migration as defined in this section, though an endpoint SHOULD 2066 perform path validation (Section 8.2) if it detects a change in the 2067 IP address of its peer. 2069 This document limits migration of connections to new client 2070 addresses, except as described in Section 9.6. Clients are 2071 responsible for initiating all migrations. Servers do not send non- 2072 probing packets (see Section 9.1) toward a client address until they 2073 see a non-probing packet from that address. If a client receives 2074 packets from an unknown server address, the client MUST discard these 2075 packets. 2077 9.1. Probing a New Path 2079 An endpoint MAY probe for peer reachability from a new local address 2080 using path validation Section 8.2 prior to migrating the connection 2081 to the new local address. Failure of path validation simply means 2082 that the new path is not usable for this connection. Failure to 2083 validate a path does not cause the connection to end unless there are 2084 no valid alternative paths available. 2086 An endpoint uses a new connection ID for probes sent from a new local 2087 address, see Section 9.5 for further discussion. An endpoint that 2088 uses a new local address needs to ensure that at least one new 2089 connection ID is available at the peer. That can be achieved by 2090 including a NEW_CONNECTION_ID frame in the probe. 2092 Receiving a PATH_CHALLENGE frame from a peer indicates that the peer 2093 is probing for reachability on a path. An endpoint sends a 2094 PATH_RESPONSE in response as per Section 8.2. 2096 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames 2097 are "probing frames", and all other frames are "non-probing frames". 2098 A packet containing only probing frames is a "probing packet", and a 2099 packet containing any other frame is a "non-probing packet". 2101 9.2. Initiating Connection Migration 2103 An endpoint can migrate a connection to a new local address by 2104 sending packets containing non-probing frames from that address. 2106 Each endpoint validates its peer's address during connection 2107 establishment. Therefore, a migrating endpoint can send to its peer 2108 knowing that the peer is willing to receive at the peer's current 2109 address. Thus an endpoint can migrate to a new local address without 2110 first validating the peer's address. 2112 When migrating, the new path might not support the endpoint's current 2113 sending rate. Therefore, the endpoint resets its congestion 2114 controller, as described in Section 9.4. 2116 The new path might not have the same ECN capability. Therefore, the 2117 endpoint verifies ECN capability as described in Section 13.3. 2119 Receiving acknowledgments for data sent on the new path serves as 2120 proof of the peer's reachability from the new address. Note that 2121 since acknowledgments may be received on any path, return 2122 reachability on the new path is not established. To establish return 2123 reachability on the new path, an endpoint MAY concurrently initiate 2124 path validation Section 8.2 on the new path. 2126 9.3. Responding to Connection Migration 2128 Receiving a packet from a new peer address containing a non-probing 2129 frame indicates that the peer has migrated to that address. 2131 In response to such a packet, an endpoint MUST start sending 2132 subsequent packets to the new peer address and MUST initiate path 2133 validation (Section 8.2) to verify the peer's ownership of the 2134 unvalidated address. 2136 An endpoint MAY send data to an unvalidated peer address, but it MUST 2137 protect against potential attacks as described in Section 9.3.1 and 2138 Section 9.3.2. An endpoint MAY skip validation of a peer address if 2139 that address has been seen recently. 2141 An endpoint only changes the address that it sends packets to in 2142 response to the highest-numbered non-probing packet. This ensures 2143 that an endpoint does not send packets to an old peer address in the 2144 case that it receives reordered packets. 2146 After changing the address to which it sends non-probing packets, an 2147 endpoint could abandon any path validation for other addresses. 2149 Receiving a packet from a new peer address might be the result of a 2150 NAT rebinding at the peer. 2152 After verifying a new client address, the server SHOULD send new 2153 address validation tokens (Section 8) to the client. 2155 9.3.1. Peer Address Spoofing 2157 It is possible that a peer is spoofing its source address to cause an 2158 endpoint to send excessive amounts of data to an unwilling host. If 2159 the endpoint sends significantly more data than the spoofing peer, 2160 connection migration might be used to amplify the volume of data that 2161 an attacker can generate toward a victim. 2163 As described in Section 9.3, an endpoint is required to validate a 2164 peer's new address to confirm the peer's possession of the new 2165 address. Until a peer's address is deemed valid, an endpoint MUST 2166 limit the rate at which it sends data to this address. The endpoint 2167 MUST NOT send more than a minimum congestion window's worth of data 2168 per estimated round-trip time (kMinimumWindow, as defined in 2169 [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks 2170 being used for a denial of service attack against an unsuspecting 2171 victim. Note that since the endpoint will not have any round-trip 2172 time measurements to this address, the estimate SHOULD be the default 2173 initial value (see [QUIC-RECOVERY]). 2175 If an endpoint skips validation of a peer address as described in 2176 Section 9.3, it does not need to limit its sending rate. 2178 9.3.2. On-Path Address Spoofing 2180 An on-path attacker could cause a spurious connection migration by 2181 copying and forwarding a packet with a spoofed address such that it 2182 arrives before the original packet. The packet with the spoofed 2183 address will be seen to come from a migrating connection, and the 2184 original packet will be seen as a duplicate and dropped. After a 2185 spurious migration, validation of the source address will fail 2186 because the entity at the source address does not have the necessary 2187 cryptographic keys to read or respond to the PATH_CHALLENGE frame 2188 that is sent to it even if it wanted to. 2190 To protect the connection from failing due to such a spurious 2191 migration, an endpoint MUST revert to using the last validated peer 2192 address when validation of a new peer address fails. 2194 If an endpoint has no state about the last validated peer address, it 2195 MUST close the connection silently by discarding all connection 2196 state. This results in new packets on the connection being handled 2197 generically. For instance, an endpoint MAY send a stateless reset in 2198 response to any further incoming packets. 2200 Note that receipt of packets with higher packet numbers from the 2201 legitimate peer address will trigger another connection migration. 2202 This will cause the validation of the address of the spurious 2203 migration to be abandoned. 2205 9.3.3. Off-Path Packet Forwarding 2207 An off-path attacker that can observe packets might forward copies of 2208 genuine packets to endpoints. If the copied packet arrives before 2209 the genuine packet, this will appear as a NAT rebinding. Any genuine 2210 packet will be discarded as a duplicate. If the attacker is able to 2211 continue forwarding packets, it might be able to cause migration to a 2212 path via the attacker. This places the attacker on path, giving it 2213 the ability to observe or drop all subsequent packets. 2215 Unlike the attack described in Section 9.3.2, the attacker can ensure 2216 that the new path is successfully validated. 2218 This style of attack relies on the attacker using a path that is 2219 approximately as fast as the direct path between endpoints. The 2220 attack is more reliable if relatively few packets are sent or if 2221 packet loss coincides with the attempted attack. 2223 A non-probing packet received on the original path that increases the 2224 maximum received packet number will cause the endpoint to move back 2225 to that path. Eliciting packets on this path increases the 2226 likelihood that the attack is unsuccessful. Therefore, mitigation of 2227 this attack relies on triggering the exchange of packets. 2229 In response to an apparent migration, endpoints MUST validate the 2230 previously active path using a PATH_CHALLENGE frame. This induces 2231 the sending of new packets on that path. If the path is no longer 2232 viable, the validation attempt will time out and fail; if the path is 2233 viable, but no longer desired, the validation will succeed, but only 2234 results in probing packets being sent on the path. 2236 An endpoint that receives a PATH_CHALLENGE on an active path SHOULD 2237 send a non-probing packet in response. If the non-probing packet 2238 arrives before any copy made by an attacker, this results in the 2239 connection being migrated back to the original path. Any subsequent 2240 migration to another path restarts this entire process. 2242 This defense is imperfect, but this is not considered a serious 2243 problem. If the path via the attack is reliably faster than the 2244 original path despite multiple attempts to use that original path, it 2245 is not possible to distinguish between attack and an improvement in 2246 routing. 2248 An endpoint could also use heuristics to improve detection of this 2249 style of attack. For instance, NAT rebinding is improbable if 2250 packets were recently received on the old path, similarly rebinding 2251 is rare on IPv6 paths. Endpoints can also look for duplicated 2252 packets. Conversely, a change in connection ID is more likely to 2253 indicate an intentional migration rather than an attack. 2255 9.4. Loss Detection and Congestion Control 2257 The capacity available on the new path might not be the same as the 2258 old path. Packets sent on the old path SHOULD NOT contribute to 2259 congestion control or RTT estimation for the new path. 2261 On confirming a peer's ownership of its new address, an endpoint 2262 SHOULD immediately reset the congestion controller and round-trip 2263 time estimator for the new path. 2265 An endpoint MUST NOT return to the send rate used for the previous 2266 path unless it is reasonably sure that the previous send rate is 2267 valid for the new path. For instance, a change in the client's port 2268 number is likely indicative of a rebinding in a middlebox and not a 2269 complete change in path. This determination likely depends on 2270 heuristics, which could be imperfect; if the new path capacity is 2271 significantly reduced, ultimately this relies on the congestion 2272 controller responding to congestion signals and reducing send rates 2273 appropriately. 2275 There may be apparent reordering at the receiver when an endpoint 2276 sends data and probes from/to multiple addresses during the migration 2277 period, since the two resulting paths may have different round-trip 2278 times. A receiver of packets on multiple paths will still send ACK 2279 frames covering all received packets. 2281 While multiple paths might be used during connection migration, a 2282 single congestion control context and a single loss recovery context 2283 (as described in [QUIC-RECOVERY]) may be adequate. For instance, an 2284 endpoint might delay switching to a new congestion control context 2285 until it is confirmed that an old path is no longer needed (such as 2286 the case in Section 9.3.3). 2288 A sender can make exceptions for probe packets so that their loss 2289 detection is independent and does not unduly cause the congestion 2290 controller to reduce its sending rate. An endpoint might set a 2291 separate timer when a PATH_CHALLENGE is sent, which is cancelled when 2292 the corresponding PATH_RESPONSE is received. If the timer fires 2293 before the PATH_RESPONSE is received, the endpoint might send a new 2294 PATH_CHALLENGE, and restart the timer for a longer period of time. 2296 9.5. Privacy Implications of Connection Migration 2298 Using a stable connection ID on multiple network paths allows a 2299 passive observer to correlate activity between those paths. An 2300 endpoint that moves between networks might not wish to have their 2301 activity correlated by any entity other than their peer, so different 2302 connection IDs are used when sending from different local addresses, 2303 as discussed in Section 5.1. For this to be effective endpoints need 2304 to ensure that connections IDs they provide cannot be linked by any 2305 other entity. 2307 This eliminates the use of the connection ID for linking activity 2308 from the same connection on different networks. Header protection 2309 ensures that packet numbers cannot be used to correlate activity. 2310 This does not prevent other properties of packets, such as timing and 2311 size, from being used to correlate activity. 2313 Clients MAY move to a new connection ID at any time based on 2314 implementation-specific concerns. For example, after a period of 2315 network inactivity NAT rebinding might occur when the client begins 2316 sending data again. 2318 A client might wish to reduce linkability by employing a new 2319 connection ID and source UDP port when sending traffic after a period 2320 of inactivity. Changing the UDP port from which it sends packets at 2321 the same time might cause the packet to appear as a connection 2322 migration. This ensures that the mechanisms that support migration 2323 are exercised even for clients that don't experience NAT rebindings 2324 or genuine migrations. Changing port number can cause a peer to 2325 reset its congestion state (see Section 9.4), so the port SHOULD only 2326 be changed infrequently. 2328 Endpoints that use connection IDs with length greater than zero could 2329 have their activity correlated if their peers keep using the same 2330 destination connection ID after migration. Endpoints that receive 2331 packets with a previously unused Destination Connection ID SHOULD 2332 change to sending packets with a connection ID that has not been used 2333 on any other network path. The goal here is to ensure that packets 2334 sent on different paths cannot be correlated. To fulfill this 2335 privacy requirement, endpoints that initiate migration and use 2336 connection IDs with length greater than zero SHOULD provide their 2337 peers with new connection IDs before migration. 2339 Caution: If both endpoints change connection ID in response to 2340 seeing a change in connection ID from their peer, then this can 2341 trigger an infinite sequence of changes. 2343 9.6. Server's Preferred Address 2345 QUIC allows servers to accept connections on one IP address and 2346 attempt to transfer these connections to a more preferred address 2347 shortly after the handshake. This is particularly useful when 2348 clients initially connect to an address shared by multiple servers 2349 but would prefer to use a unicast address to ensure connection 2350 stability. This section describes the protocol for migrating a 2351 connection to a preferred server address. 2353 Migrating a connection to a new server address mid-connection is left 2354 for future work. If a client receives packets from a new server 2355 address not indicated by the preferred_address transport parameter, 2356 the client SHOULD discard these packets. 2358 9.6.1. Communicating A Preferred Address 2360 A server conveys a preferred address by including the 2361 preferred_address transport parameter in the TLS handshake. 2363 Servers MAY communicate a preferred address of each address family 2364 (IPv4 and IPv6) to allow clients to pick the one most suited to their 2365 network attachment. 2367 Once the handshake is finished, the client SHOULD select one of the 2368 two server's preferred addresses and initiate path validation (see 2369 Section 8.2) of that address using the connection ID provided in the 2370 preferred_address transport parameter. 2372 If path validation succeeds, the client SHOULD immediately begin 2373 sending all future packets to the new server address using the new 2374 connection ID and discontinue use of the old server address. If path 2375 validation fails, the client MUST continue sending all future packets 2376 to the server's original IP address. 2378 9.6.2. Responding to Connection Migration 2380 A server might receive a packet addressed to its preferred IP address 2381 at any time after it accepts a connection. If this packet contains a 2382 PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per 2383 Section 8.2. The server MUST send other non-probing frames from its 2384 original address until it receives a non-probing packet from the 2385 client at its preferred address and until the server has validated 2386 the new path. 2388 The server MUST probe on the path toward the client from its 2389 preferred address. This helps to guard against spurious migration 2390 initiated by an attacker. 2392 Once the server has completed its path validation and has received a 2393 non-probing packet with a new largest packet number on its preferred 2394 address, the server begins sending non-probing packets to the client 2395 exclusively from its preferred IP address. It SHOULD drop packets 2396 for this connection received on the old IP address, but MAY continue 2397 to process delayed packets. 2399 9.6.3. Interaction of Client Migration and Preferred Address 2401 A client might need to perform a connection migration before it has 2402 migrated to the server's preferred address. In this case, the client 2403 SHOULD perform path validation to both the original and preferred 2404 server address from the client's new address concurrently. 2406 If path validation of the server's preferred address succeeds, the 2407 client MUST abandon validation of the original address and migrate to 2408 using the server's preferred address. If path validation of the 2409 server's preferred address fails but validation of the server's 2410 original address succeeds, the client MAY migrate to its new address 2411 and continue sending to the server's original address. 2413 If the connection to the server's preferred address is not from the 2414 same client address, the server MUST protect against potential 2415 attacks as described in Section 9.3.1 and Section 9.3.2. In addition 2416 to intentional simultaneous migration, this might also occur because 2417 the client's access network used a different NAT binding for the 2418 server's preferred address. 2420 Servers SHOULD initiate path validation to the client's new address 2421 upon receiving a probe packet from a different address. Servers MUST 2422 NOT send more than a minimum congestion window's worth of non-probing 2423 packets to the new address before path validation is complete. 2425 A client that migrates to a new address SHOULD use a preferred 2426 address from the same address family for the server. 2428 10. Connection Termination 2430 Connections should remain open until they become idle for a pre- 2431 negotiated period of time. A QUIC connection, once established, can 2432 be terminated in one of three ways: 2434 o idle timeout (Section 10.2) 2436 o immediate close (Section 10.3) 2438 o stateless reset (Section 10.4) 2440 10.1. Closing and Draining Connection States 2442 The closing and draining connection states exist to ensure that 2443 connections close cleanly and that delayed or reordered packets are 2444 properly discarded. These states SHOULD persist for three times the 2445 current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY]. 2447 An endpoint enters a closing period after initiating an immediate 2448 close (Section 10.3). While closing, an endpoint MUST NOT send 2449 packets unless they contain a CONNECTION_CLOSE frame (see 2450 Section 10.3 for details). An endpoint retains only enough 2451 information to generate a packet containing a CONNECTION_CLOSE frame 2452 and to identify packets as belonging to the connection. The 2453 connection ID and QUIC version is sufficient information to identify 2454 packets for a closing connection; an endpoint can discard all other 2455 connection state. An endpoint MAY retain packet protection keys for 2456 incoming packets to allow it to read and process a CONNECTION_CLOSE 2457 frame. 2459 The draining state is entered once an endpoint receives a signal that 2460 its peer is closing or draining. While otherwise identical to the 2461 closing state, an endpoint in the draining state MUST NOT send any 2462 packets. Retaining packet protection keys is unnecessary once a 2463 connection is in the draining state. 2465 An endpoint MAY transition from the closing period to the draining 2466 period if it can confirm that its peer is also closing or draining. 2467 Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is 2468 receiving a stateless reset. The draining period SHOULD end when the 2469 closing period would have ended. In other words, the endpoint can 2470 use the same end time, but cease retransmission of the closing 2471 packet. 2473 Disposing of connection state prior to the end of the closing or 2474 draining period could cause delayed or reordered packets to be 2475 handled poorly. Endpoints that have some alternative means to ensure 2476 that late-arriving packets on the connection do not create QUIC 2477 state, such as those that are able to close the UDP socket, MAY use 2478 an abbreviated draining period which can allow for faster resource 2479 recovery. Servers that retain an open socket for accepting new 2480 connections SHOULD NOT exit the closing or draining period early. 2482 Once the closing or draining period has ended, an endpoint SHOULD 2483 discard all connection state. This results in new packets on the 2484 connection being handled generically. For instance, an endpoint MAY 2485 send a stateless reset in response to any further incoming packets. 2487 The draining and closing periods do not apply when a stateless reset 2488 (Section 10.4) is sent. 2490 An endpoint is not expected to handle key updates when it is closing 2491 or draining. A key update might prevent the endpoint from moving 2492 from the closing state to draining, but it otherwise has no impact. 2494 While in the closing period, an endpoint could receive packets from a 2495 new source address, indicating a client connection migration 2496 (Section 9). An endpoint in the closing state MUST strictly limit 2497 the number of packets it sends to this new address until the address 2498 is validated (see Section 8.2). A server in the closing state MAY 2499 instead choose to discard packets received from a new source address. 2501 10.2. Idle Timeout 2503 If the idle timeout is enabled, a connection that remains idle for 2504 longer than the advertised idle timeout (see Section 18.1) is closed. 2505 A connection enters the draining state when the idle timeout expires. 2507 Each endpoint advertises its own idle timeout to its peer. An 2508 enpdpoint restarts any timer it maintains when a packet from its peer 2509 is received and processed successfully. The timer is also restarted 2510 when sending a packet containing frames other than ACK or PADDING (an 2511 ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK- 2512 eliciting packets have been sent since last receiving a packet. 2513 Restarting when sending packets ensures that connections do not 2514 prematurely time out when initiating new activity. 2516 The value for an idle timeout can be asymmetric. The value 2517 advertised by an endpoint is only used to determine whether the 2518 connection is live at that endpoint. An endpoint that sends packets 2519 near the end of the idle timeout period of a peer risks having those 2520 packets discarded if its peer enters the draining state before the 2521 packets arrive. If a peer could timeout within an Probe Timeout 2522 (PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test 2523 for liveness before sending any data that cannot be retried safely. 2525 10.3. Immediate Close 2527 An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to 2528 terminate the connection immediately. A CONNECTION_CLOSE frame 2529 causes all streams to immediately become closed; open streams can be 2530 assumed to be implicitly reset. 2532 After sending a CONNECTION_CLOSE frame, endpoints immediately enter 2533 the closing state. During the closing period, an endpoint that sends 2534 a CONNECTION_CLOSE frame SHOULD respond to any packet that it 2535 receives with another packet containing a CONNECTION_CLOSE frame. To 2536 minimize the state that an endpoint maintains for a closing 2537 connection, endpoints MAY send the exact same packet. However, 2538 endpoints SHOULD limit the number of packets they generate containing 2539 a CONNECTION_CLOSE frame. For instance, an endpoint could 2540 progressively increase the number of packets that it receives before 2541 sending additional packets or increase the time between packets. 2543 Note: Allowing retransmission of a closing packet contradicts other 2544 advice in this document that recommends the creation of new packet 2545 numbers for every packet. Sending new packet numbers is primarily 2546 of advantage to loss recovery and congestion control, which are 2547 not expected to be relevant for a closed connection. 2548 Retransmitting the final packet requires less state. 2550 New packets from unverified addresses could be used to create an 2551 amplification attack (see Section 8). To avoid this, endpoints MUST 2552 either limit transmission of CONNECTION_CLOSE frames to validated 2553 addresses or drop packets without response if the response would be 2554 more than three times larger than the received packet. 2556 After receiving a CONNECTION_CLOSE frame, endpoints enter the 2557 draining state. An endpoint that receives a CONNECTION_CLOSE frame 2558 MAY send a single packet containing a CONNECTION_CLOSE frame before 2559 entering the draining state, using a CONNECTION_CLOSE frame and a 2560 NO_ERROR code if appropriate. An endpoint MUST NOT send further 2561 packets, which could result in a constant exchange of 2562 CONNECTION_CLOSE frames until the closing period on either peer 2563 ended. 2565 An immediate close can be used after an application protocol has 2566 arranged to close a connection. This might be after the application 2567 protocols negotiates a graceful shutdown. The application protocol 2568 exchanges whatever messages that are needed to cause both endpoints 2569 to agree to close the connection, after which the application 2570 requests that the connection be closed. The application protocol can 2571 use an CONNECTION_CLOSE frame with an appropriate error code to 2572 signal closure. 2574 If the connection has been successfully established, endpoints MUST 2575 send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to 2576 connection establishment a peer might not have 1-RTT keys, so 2577 endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. 2578 If the endpoint does not have Handshake keys, or it is not certain 2579 that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames 2580 in an Initial packet. If multiple packets are sent, they can be 2581 coalesced (see Section 12.2) to facilitate retransmission. 2583 10.4. Stateless Reset 2585 A stateless reset is provided as an option of last resort for an 2586 endpoint that does not have access to the state of a connection. A 2587 crash or outage might result in peers continuing to send data to an 2588 endpoint that is unable to properly continue the connection. A 2589 stateless reset is not appropriate for signaling error conditions. 2590 An endpoint that wishes to communicate a fatal connection error MUST 2591 use a CONNECTION_CLOSE frame if it has sufficient state to do so. 2593 To support this process, a token is sent by endpoints. The token is 2594 carried in the NEW_CONNECTION_ID frame sent by either peer, and 2595 servers can specify the stateless_reset_token transport parameter 2596 during the handshake (clients cannot because their transport 2597 parameters don't have confidentiality protection). This value is 2598 protected by encryption, so only client and server know this value. 2599 Tokens are invalidated when their associated connection ID is retired 2600 via a RETIRE_CONNECTION_ID frame (Section 19.16). 2602 An endpoint that receives packets that it cannot process sends a 2603 packet in the following layout: 2605 0 1 2 3 2606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 |0|1| Unpredictable Bits (182..) ... 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | | 2611 + + 2612 | | 2613 + Stateless Reset Token (128) + 2614 | | 2615 + + 2616 | | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 Figure 7: Stateless Reset Packet 2621 This design ensures that a stateless reset packet is - to the extent 2622 possible - indistinguishable from a regular packet with a short 2623 header. 2625 A stateless reset uses an entire UDP datagram, starting with the 2626 first two bits of the packet header. The remainder of the first byte 2627 and an arbitrary number of bytes following it that are set to 2628 unpredictable values. The last 16 bytes of the datagram contain a 2629 Stateless Reset Token. 2631 A stateless reset will be interpreted by a recipient as a packet with 2632 a short header. For the packet to appear as valid, the Random Bits 2633 field needs to include at least 182 bits of data (or 23 bytes, less 2634 the two fixed bits). This is intended to allow for a Destination 2635 Connection ID of the maximum length permitted, with a minimal packet 2636 number, and payload. The Stateless Reset Token corresponds to the 2637 minimum expansion of the packet protection AEAD. More unpredictable 2638 bytes might be necessary if the endpoint could have negotiated a 2639 packet protection scheme with a larger minimum AEAD expansion. 2641 An endpoint SHOULD NOT send a stateless reset that is significantly 2642 larger than the packet it receives. Endpoints MUST discard packets 2643 that are too small to be valid QUIC packets. With the set of AEAD 2644 functions defined in [QUIC-TLS], packets that are smaller than 21 2645 bytes are never valid. 2647 An endpoint MAY send a stateless reset in response to a packet with a 2648 long header. This would not be effective if the stateless reset 2649 token was not yet available to a peer. In this QUIC version, packets 2650 with a long header are only used during connection establishment. 2651 Because the stateless reset token is not available until connection 2652 establishment is complete or near completion, ignoring an unknown 2653 packet with a long header might be more effective. 2655 An endpoint cannot determine the Source Connection ID from a packet 2656 with a short header, therefore it cannot set the Destination 2657 Connection ID in the stateless reset packet. The Destination 2658 Connection ID will therefore differ from the value used in previous 2659 packets. A random Destination Connection ID makes the connection ID 2660 appear to be the result of moving to a new connection ID that was 2661 provided using a NEW_CONNECTION_ID frame (Section 19.15). 2663 Using a randomized connection ID results in two problems: 2665 o The packet might not reach the peer. If the Destination 2666 Connection ID is critical for routing toward the peer, then this 2667 packet could be incorrectly routed. This might also trigger 2668 another Stateless Reset in response, see Section 10.4.3. A 2669 Stateless Reset that is not correctly routed is an ineffective 2670 error detection and recovery mechanism. In this case, endpoints 2671 will need to rely on other methods - such as timers - to detect 2672 that the connection has failed. 2674 o The randomly generated connection ID can be used by entities other 2675 than the peer to identify this as a potential stateless reset. An 2676 endpoint that occasionally uses different connection IDs might 2677 introduce some uncertainty about this. 2679 Finally, the last 16 bytes of the packet are set to the value of the 2680 Stateless Reset Token. 2682 This stateless reset design is specific to QUIC version 1. An 2683 endpoint that supports multiple versions of QUIC needs to generate a 2684 stateless reset that will be accepted by peers that support any 2685 version that the endpoint might support (or might have supported 2686 prior to losing state). Designers of new versions of QUIC need to be 2687 aware of this and either reuse this design, or use a portion of the 2688 packet other than the last 16 bytes for carrying data. 2690 10.4.1. Detecting a Stateless Reset 2692 An endpoint detects a potential stateless reset when a incoming 2693 packet with a short header either cannot be associated with a 2694 connection, cannot be decrypted, or is marked as a duplicate packet. 2695 The endpoint then compares the last 16 bytes of the packet with the 2696 Stateless Reset Token provided by its peer, either in a 2697 NEW_CONNECTION_ID frame or the server's transport parameters. If 2698 these values are identical, the endpoint MUST enter the draining 2699 period and not send any further packets on this connection. If the 2700 comparison fails, the packet can be discarded. 2702 10.4.2. Calculating a Stateless Reset Token 2704 The stateless reset token MUST be difficult to guess. In order to 2705 create a Stateless Reset Token, an endpoint could randomly generate 2706 [RFC4086] a secret for every connection that it creates. However, 2707 this presents a coordination problem when there are multiple 2708 instances in a cluster or a storage problem for an endpoint that 2709 might lose state. Stateless reset specifically exists to handle the 2710 case where state is lost, so this approach is suboptimal. 2712 A single static key can be used across all connections to the same 2713 endpoint by generating the proof using a second iteration of a 2714 preimage-resistant function that takes a static key and the 2715 connection ID chosen by the endpoint (see Section 5.1) as input. An 2716 endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, 2717 connection_id)) or HKDF [RFC5869] (for example, using the static key 2718 as input keying material, with the connection ID as salt). The 2719 output of this function is truncated to 16 bytes to produce the 2720 Stateless Reset Token for that connection. 2722 An endpoint that loses state can use the same method to generate a 2723 valid Stateless Reset Token. The connection ID comes from the packet 2724 that the endpoint receives. 2726 This design relies on the peer always sending a connection ID in its 2727 packets so that the endpoint can use the connection ID from a packet 2728 to reset the connection. An endpoint that uses this design MUST 2729 either use the same connection ID length for all connections or 2730 encode the length of the connection ID such that it can be recovered 2731 without state. In addition, it cannot provide a zero-length 2732 connection ID. 2734 Revealing the Stateless Reset Token allows any entity to terminate 2735 the connection, so a value can only be used once. This method for 2736 choosing the Stateless Reset Token means that the combination of 2737 connection ID and static key cannot occur for another connection. A 2738 denial of service attack is possible if the same connection ID is 2739 used by instances that share a static key, or if an attacker can 2740 cause a packet to be routed to an instance that has no state but the 2741 same static key (see Section 21.8). A connection ID from a 2742 connection that is reset by revealing the Stateless Reset Token 2743 cannot be reused for new connections at nodes that share a static 2744 key. 2746 Note that Stateless Reset packets do not have any cryptographic 2747 protection. 2749 10.4.3. Looping 2751 The design of a Stateless Reset is such that without knowing the 2752 stateless reset token it is indistinguishable from a valid packet. 2753 For instance, if a server sends a Stateless Reset to another server 2754 it might receive another Stateless Reset in response, which could 2755 lead to an infinite exchange. 2757 An endpoint MUST ensure that every Stateless Reset that it sends is 2758 smaller than the packet which triggered it, unless it maintains state 2759 sufficient to prevent looping. In the event of a loop, this results 2760 in packets eventually being too small to trigger a response. 2762 An endpoint can remember the number of Stateless Reset packets that 2763 it has sent and stop generating new Stateless Reset packets once a 2764 limit is reached. Using separate limits for different remote 2765 addresses will ensure that Stateless Reset packets can be used to 2766 close connections when other peers or connections have exhausted 2767 limits. 2769 Reducing the size of a Stateless Reset below the recommended minimum 2770 size of 39 bytes could mean that the packet could reveal to an 2771 observer that it is a Stateless Reset. Conversely, refusing to send 2772 a Stateless Reset in response to a small packet might result in 2773 Stateless Reset not being useful in detecting cases of broken 2774 connections where only very small packets are sent; such failures 2775 might only be detected by other means, such as timers. 2777 An endpoint can increase the odds that a packet will trigger a 2778 Stateless Reset if it cannot be processed by padding it to at least 2779 40 bytes. 2781 11. Error Handling 2783 An endpoint that detects an error SHOULD signal the existence of that 2784 error to its peer. Both transport-level and application-level errors 2785 can affect an entire connection (see Section 11.1), while only 2786 application-level errors can be isolated to a single stream (see 2787 Section 11.2). 2789 The most appropriate error code (Section 20) SHOULD be included in 2790 the frame that signals the error. Where this specification 2791 identifies error conditions, it also identifies the error code that 2792 is used. 2794 A stateless reset (Section 10.4) is not suitable for any error that 2795 can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A 2796 stateless reset MUST NOT be used by an endpoint that has the state 2797 necessary to send a frame on the connection. 2799 11.1. Connection Errors 2801 Errors that result in the connection being unusable, such as an 2802 obvious violation of protocol semantics or corruption of state that 2803 affects an entire connection, MUST be signaled using a 2804 CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the 2805 connection in this manner even if the error only affects a single 2806 stream. 2808 Application protocols can signal application-specific protocol errors 2809 using the application-specific variant of the CONNECTION_CLOSE frame. 2810 Errors that are specific to the transport, including all those 2811 described in this document, are carried the QUIC-specific variant of 2812 the CONNECTION_CLOSE frame. 2814 A CONNECTION_CLOSE frame could be sent in a packet that is lost. An 2815 endpoint SHOULD be prepared to retransmit a packet containing 2816 containing a CONNECTION_CLOSE frame if it receives more packets on a 2817 terminated connection. Limiting the number of retransmissions and 2818 the time over which this final packet is sent limits the effort 2819 expended on terminated connections. 2821 An endpoint that chooses not to retransmit packets containing a 2822 CONNECTION_CLOSE frame risks a peer missing the first such packet. 2823 The only mechanism available to an endpoint that continues to receive 2824 data for a terminated connection is to use the stateless reset 2825 process (Section 10.4). 2827 An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT 2828 signal the existence of the error to its peer. 2830 11.2. Stream Errors 2832 If an application-level error affects a single stream, but otherwise 2833 leaves the connection in a recoverable state, the endpoint can send a 2834 RESET_STREAM frame (Section 19.4) with an appropriate error code to 2835 terminate just the affected stream. 2837 RESET_STREAM MUST be instigated by the protocol using QUIC, either 2838 directly or through the receipt of a STOP_SENDING frame from a peer. 2839 RESET_STREAM carries an application error code. Resetting a stream 2840 without knowledge of the application protocol could cause the 2841 protocol to enter an unrecoverable state. Application protocols 2842 might require certain streams to be reliably delivered in order to 2843 guarantee consistent state between endpoints. 2845 12. Packets and Frames 2847 QUIC endpoints communicate by exchanging packets. Packets have 2848 confidentiality and integrity protection (see Section 12.1) and are 2849 carried in UDP datagrams (see Section 12.2). 2851 This version of QUIC uses the long packet header (see Section 17.2) 2852 during connection establishment. Packets with the long header are 2853 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake 2854 (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation 2855 uses a version-independent packet with a long header (see 2856 Section 17.2.1). 2858 Packets with the short header (Section 17.3) are designed for minimal 2859 overhead and are used after a connection is established and 1-RTT 2860 keys are available. 2862 12.1. Protected Packets 2864 All QUIC packets except Version Negotiation and Retry packets use 2865 authenticated encryption with additional data (AEAD) [RFC5116] to 2866 provide confidentiality and integrity protection. Details of packet 2867 protection are found in [QUIC-TLS]; this section includes an overview 2868 of the process. 2870 Initial packets are protected using keys that are statically derived. 2871 This packet protection is not effective confidentiality protection. 2872 Initial protection only exists to ensure that the sender of the 2873 packet is on the network path. Any entity that receives the Initial 2874 packet from a client can recover the keys necessary to remove packet 2875 protection or to generate packets that will be successfully 2876 authenticated. 2878 All other packets are protected with keys derived from the 2879 cryptographic handshake. The type of the packet from the long header 2880 or key phase from the short header are used to identify which 2881 encryption level - and therefore the keys - that are used. Packets 2882 protected with 0-RTT and 1-RTT keys are expected to have 2883 confidentiality and data origin authentication; the cryptographic 2884 handshake ensures that only the communicating endpoints receive the 2885 corresponding keys. 2887 The packet number field contains a packet number, which has 2888 additional confidentiality protection that is applied after packet 2889 protection is applied (see [QUIC-TLS] for details). The underlying 2890 packet number increases with each packet sent in a given packet 2891 number space, see Section 12.3 for details. 2893 12.2. Coalescing Packets 2895 Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake 2896 (Section 17.2.4) packets contain a Length field, which determines the 2897 end of the packet. The length includes both the Packet Number and 2898 Payload fields, both of which are confidentiality protected and 2899 initially of unknown length. The length of the Payload field is 2900 learned once header protection is removed. 2902 Using the Length field, a sender can coalesce multiple QUIC packets 2903 into one UDP datagram. This can reduce the number of UDP datagrams 2904 needed to complete the cryptographic handshake and starting sending 2905 data. Receivers MUST be able to process coalesced packets. 2907 Coalescing packets in order of increasing encryption levels (Initial, 2908 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 2909 able to process all the packets in a single pass. A packet with a 2910 short header does not include a length, so it can only be the last 2911 packet included in a UDP datagram. 2913 Senders MUST NOT coalesce QUIC packets for different connections into 2914 a single UDP datagram. Receivers SHOULD ignore any subsequent 2915 packets with a different Destination Connection ID than the first 2916 packet in the datagram. 2918 Every QUIC packet that is coalesced into a single UDP datagram is 2919 separate and complete. Though the values of some fields in the 2920 packet header might be redundant, no fields are omitted. The 2921 receiver of coalesced QUIC packets MUST individually process each 2922 QUIC packet and separately acknowledge them, as if they were received 2923 as the payload of different UDP datagrams. For example, if 2924 decryption fails (because the keys are not available or any other 2925 reason), the the receiver MAY either discard or buffer the packet for 2926 later processing and MUST attempt to process the remaining packets. 2928 Retry packets (Section 17.2.5), Version Negotiation packets 2929 (Section 17.2.1), and packets with a short header (Section 17.3) do 2930 not contain a Length field and so cannot be followed by other packets 2931 in the same UDP datagram. 2933 12.3. Packet Numbers 2935 The packet number is an integer in the range 0 to 2^62-1. This 2936 number is used in determining the cryptographic nonce for packet 2937 protection. Each endpoint maintains a separate packet number for 2938 sending and receiving. 2940 Packet numbers are limited to this range because they need to be 2941 representable in whole in the Largest Acknowledged field of an ACK 2942 frame (Section 19.3). When present in a long or short header 2943 however, packet numbers are reduced and encoded in 1 to 4 bytes, see 2944 Section 17.1). 2946 Version Negotiation (Section 17.2.1) and Retry Section 17.2.5 packets 2947 do not include a packet number. 2949 Packet numbers are divided into 3 spaces in QUIC: 2951 o Initial space: All Initial packets Section 17.2.2 are in this 2952 space. 2954 o Handshake space: All Handshake packets Section 17.2.4 are in this 2955 space. 2957 o Application data space: All 0-RTT and 1-RTT encrypted packets 2958 Section 12.1 are in this space. 2960 As described in [QUIC-TLS], each packet type uses different 2961 protection keys. 2963 Conceptually, a packet number space is the context in which a packet 2964 can be processed and acknowledged. Initial packets can only be sent 2965 with Initial packet protection keys and acknowledged in packets which 2966 are also Initial packets. Similarly, Handshake packets are sent at 2967 the Handshake encryption level and can only be acknowledged in 2968 Handshake packets. 2970 This enforces cryptographic separation between the data sent in the 2971 different packet sequence number spaces. Packet numbers in each 2972 space start at packet number 0. Subsequent packets sent in the same 2973 packet number space MUST increase the packet number by at least one. 2975 0-RTT and 1-RTT data exist in the same packet number space to make 2976 loss recovery algorithms easier to implement between the two packet 2977 types. 2979 A QUIC endpoint MUST NOT reuse a packet number within the same packet 2980 number space in one connection (that is, under the same cryptographic 2981 keys). If the packet number for sending reaches 2^62 - 1, the sender 2982 MUST close the connection without sending a CONNECTION_CLOSE frame or 2983 any further packets; an endpoint MAY send a Stateless Reset 2984 (Section 10.4) in response to further packets that it receives. 2986 A receiver MUST discard a newly unprotected packet unless it is 2987 certain that it has not processed another packet with the same packet 2988 number from the same packet number space. Duplicate suppression MUST 2989 happen after removing packet protection for the reasons described in 2990 Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate 2991 suppression can be found in Section 3.4.3 of [RFC4303]. 2993 Packet number encoding at a sender and decoding at a receiver are 2994 described in Section 17.1. 2996 12.4. Frames and Frame Types 2998 The payload of QUIC packets, after removing packet protection, 2999 commonly consists of a sequence of frames, as shown in Figure 8. 3000 Version Negotiation, Stateless Reset, and Retry packets do not 3001 contain frames. 3003 0 1 2 3 3004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | Frame 1 (*) ... 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | Frame 2 (*) ... 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 ... 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | Frame N (*) ... 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 Figure 8: QUIC Payload 3017 QUIC payloads MUST contain at least one frame, and MAY contain 3018 multiple frames and multiple frame types. 3020 Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC 3021 packet boundary. Each frame begins with a Frame Type, indicating its 3022 type, followed by additional type-dependent fields: 3024 0 1 2 3 3025 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3027 | Frame Type (i) ... 3028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3029 | Type-Dependent Fields (*) ... 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 Figure 9: Generic Frame Layout 3034 The frame types defined in this specification are listed in Table 3. 3035 The Frame Type in STREAM frames is used to carry other frame-specific 3036 flags. For all other frames, the Frame Type field simply identifies 3037 the frame. These frames are explained in more detail in Section 19. 3039 +-------------+----------------------+---------------+ 3040 | Type Value | Frame Type Name | Definition | 3041 +-------------+----------------------+---------------+ 3042 | 0x00 | PADDING | Section 19.1 | 3043 | | | | 3044 | 0x01 | PING | Section 19.2 | 3045 | | | | 3046 | 0x02 - 0x03 | ACK | Section 19.3 | 3047 | | | | 3048 | 0x04 | RESET_STREAM | Section 19.4 | 3049 | | | | 3050 | 0x05 | STOP_SENDING | Section 19.5 | 3051 | | | | 3052 | 0x06 | CRYPTO | Section 19.6 | 3053 | | | | 3054 | 0x07 | NEW_TOKEN | Section 19.7 | 3055 | | | | 3056 | 0x08 - 0x0f | STREAM | Section 19.8 | 3057 | | | | 3058 | 0x10 | MAX_DATA | Section 19.9 | 3059 | | | | 3060 | 0x11 | MAX_STREAM_DATA | Section 19.10 | 3061 | | | | 3062 | 0x12 - 0x13 | MAX_STREAMS | Section 19.11 | 3063 | | | | 3064 | 0x14 | DATA_BLOCKED | Section 19.12 | 3065 | | | | 3066 | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | 3067 | | | | 3068 | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | 3069 | | | | 3070 | 0x18 | NEW_CONNECTION_ID | Section 19.15 | 3071 | | | | 3072 | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | 3073 | | | | 3074 | 0x1a | PATH_CHALLENGE | Section 19.17 | 3075 | | | | 3076 | 0x1b | PATH_RESPONSE | Section 19.18 | 3077 | | | | 3078 | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | 3079 +-------------+----------------------+---------------+ 3081 Table 3: Frame Types 3083 All QUIC frames are idempotent in this version of QUIC. That is, a 3084 valid frame does not cause undesirable side effects or errors when 3085 received more than once. 3087 The Frame Type field uses a variable length integer encoding (see 3088 Section 16) with one exception. To ensure simple and efficient 3089 implementations of frame parsing, a frame type MUST use the shortest 3090 possible encoding. Though a two-, four- or eight-byte encoding of 3091 the frame types defined in this document is possible, the Frame Type 3092 field for these frames is encoded on a single byte. For instance, 3093 though 0x4001 is a legitimate two-byte encoding for a variable-length 3094 integer with a value of 1, PING frames are always encoded as a single 3095 byte with the value 0x01. An endpoint MAY treat the receipt of a 3096 frame type that uses a longer encoding than necessary as a connection 3097 error of type PROTOCOL_VIOLATION. 3099 13. Packetization and Reliability 3101 A sender bundles one or more frames in a QUIC packet (see 3102 Section 12.4). 3104 A sender can minimize per-packet bandwidth and computational costs by 3105 bundling as many frames as possible within a QUIC packet. A sender 3106 MAY wait for a short period of time to bundle multiple frames before 3107 sending a packet that is not maximally packed, to avoid sending out 3108 large numbers of small packets. An implementation MAY use knowledge 3109 about application sending behavior or heuristics to determine whether 3110 and for how long to wait. This waiting period is an implementation 3111 decision, and an implementation should be careful to delay 3112 conservatively, since any delay is likely to increase application- 3113 visible latency. 3115 Stream multiplexing is achieved by interleaving STREAM frames from 3116 multiple streams into one or more QUIC packets. A single QUIC packet 3117 can include multiple STREAM frames from one or more streams. 3119 One of the benefits of QUIC is avoidance of head-of-line blocking 3120 across multiple streams. When a packet loss occurs, only streams 3121 with data in that packet are blocked waiting for a retransmission to 3122 be received, while other streams can continue making progress. Note 3123 that when data from multiple streams is bundled into a single QUIC 3124 packet, loss of that packet blocks all those streams from making 3125 progress. Implementations are advised to bundle as few streams as 3126 necessary in outgoing packets without losing transmission efficiency 3127 to underfilled packets. 3129 13.1. Packet Processing and Acknowledgment 3131 A packet MUST NOT be acknowledged until packet protection has been 3132 successfully removed and all frames contained in the packet have been 3133 processed. For STREAM frames, this means the data has been enqueued 3134 in preparation to be received by the application protocol, but it 3135 does not require that data is delivered and consumed. 3137 Once the packet has been fully processed, a receiver acknowledges 3138 receipt by sending one or more ACK frames containing the packet 3139 number of the received packet. 3141 13.1.1. Sending ACK Frames 3143 An endpoint MUST NOT send more than one packet containing only an ACK 3144 frame per received packet that contains frames other than ACK and 3145 PADDING frames. An endpoint MUST NOT send a packet containing only 3146 an ACK frame in response to a packet containing only ACK or PADDING 3147 frames, even if there are packet gaps which precede the received 3148 packet. This prevents an indefinite feedback loop of ACKs. The 3149 endpoint MUST however acknowledge packets containing only ACK or 3150 PADDING frames when sending ACK frames in response to other packets. 3152 Packets containing PADDING frames are considered to be in flight for 3153 congestion control purposes [QUIC-RECOVERY]. Sending only PADDING 3154 frames might cause the sender to become limited by the congestion 3155 controller (as described in [QUIC-RECOVERY]) with no acknowledgments 3156 forthcoming from the receiver. Therefore, a sender SHOULD ensure 3157 that other frames are sent in addition to PADDING frames to elicit 3158 acknowledgments from the receiver. 3160 The receiver's delayed acknowledgment timer SHOULD NOT exceed the 3161 current RTT estimate or the value it indicates in the "max_ack_delay" 3162 transport parameter. This ensures an acknowledgment is sent at least 3163 once per RTT when packets needing acknowledgement are received. The 3164 sender can use the receiver's "max_ack_delay" value in determining 3165 timeouts for timer-based retransmission. 3167 Strategies and implications of the frequency of generating 3168 acknowledgments are discussed in more detail in [QUIC-RECOVERY]. 3170 To limit ACK Ranges (see Section 19.3.1) to those that have not yet 3171 been received by the sender, the receiver SHOULD track which ACK 3172 frames have been acknowledged by its peer. The receiver SHOULD 3173 exclude already acknowledged packets from future ACK frames whenever 3174 these packets would unnecessarily contribute to the ACK frame size. 3176 Because ACK frames are not sent in response to ACK-only packets, a 3177 receiver that is only sending ACK frames will only receive 3178 acknowledgements for its packets if the sender includes them in 3179 packets with non-ACK frames. A sender SHOULD bundle ACK frames with 3180 other frames when possible. 3182 To limit receiver state or the size of ACK frames, a receiver MAY 3183 limit the number of ACK Ranges it sends. A receiver can do this even 3184 without receiving acknowledgment of its ACK frames, with the 3185 knowledge this could cause the sender to unnecessarily retransmit 3186 some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets 3187 lost after sufficiently newer packets are acknowledged. Therefore, 3188 the receiver SHOULD repeatedly acknowledge newly received packets in 3189 preference to packets received in the past. 3191 An endpoint SHOULD treat receipt of an acknowledgment for a packet it 3192 did not send as a connection error of type PROTOCOL_VIOLATION, if it 3193 is able to detect the condition. 3195 13.1.2. ACK Frames and Packet Protection 3197 ACK frames MUST only be carried in a packet that has the same packet 3198 number space as the packet being ACKed (see Section 12.1). For 3199 instance, packets that are protected with 1-RTT keys MUST be 3200 acknowledged in packets that are also protected with 1-RTT keys. 3202 Packets that a client sends with 0-RTT packet protection MUST be 3203 acknowledged by the server in packets protected by 1-RTT keys. This 3204 can mean that the client is unable to use these acknowledgments if 3205 the server cryptographic handshake messages are delayed or lost. 3206 Note that the same limitation applies to other data sent by the 3207 server protected by the 1-RTT keys. 3209 Endpoints SHOULD send acknowledgments for packets containing CRYPTO 3210 frames with a reduced delay; see Section 6.2.1 of [QUIC-RECOVERY]. 3212 13.2. Retransmission of Information 3214 QUIC packets that are determined to be lost are not retransmitted 3215 whole. The same applies to the frames that are contained within lost 3216 packets. Instead, the information that might be carried in frames is 3217 sent again in new frames as needed. 3219 New frames and packets are used to carry information that is 3220 determined to have been lost. In general, information is sent again 3221 when a packet containing that information is determined to be lost 3222 and sending ceases when a packet containing that information is 3223 acknowledged. 3225 o Data sent in CRYPTO frames is retransmitted according to the rules 3226 in [QUIC-RECOVERY], until all data has been acknowledged. Data in 3227 CRYPTO frames for Initial and Handshake packets is discarded when 3228 keys for the corresponding encryption level are discarded. 3230 o Application data sent in STREAM frames is retransmitted in new 3231 STREAM frames unless the endpoint has sent a RESET_STREAM for that 3232 stream. Once an endpoint sends a RESET_STREAM frame, no further 3233 STREAM frames are needed. 3235 o The most recent set of acknowledgments are sent in ACK frames. An 3236 ACK frame SHOULD contain all unacknowledged acknowledgments, as 3237 described in Section 13.1.1. 3239 o Cancellation of stream transmission, as carried in a RESET_STREAM 3240 frame, is sent until acknowledged or until all stream data is 3241 acknowledged by the peer (that is, either the "Reset Recvd" or 3242 "Data Recvd" state is reached on the sending part of the stream). 3243 The content of a RESET_STREAM frame MUST NOT change when it is 3244 sent again. 3246 o Similarly, a request to cancel stream transmission, as encoded in 3247 a STOP_SENDING frame, is sent until the receiving part of the 3248 stream enters either a "Data Recvd" or "Reset Recvd" state, see 3249 Section 3.5. 3251 o Connection close signals, including packets that contain 3252 CONNECTION_CLOSE frames, are not sent again when packet loss is 3253 detected, but as described in Section 10. 3255 o The current connection maximum data is sent in MAX_DATA frames. 3256 An updated value is sent in a MAX_DATA frame if the packet 3257 containing the most recently sent MAX_DATA frame is declared lost, 3258 or when the endpoint decides to update the limit. Care is 3259 necessary to avoid sending this frame too often as the limit can 3260 increase frequently and cause an unnecessarily large number of 3261 MAX_DATA frames to be sent. 3263 o The current maximum stream data offset is sent in MAX_STREAM_DATA 3264 frames. Like MAX_DATA, an updated value is sent when the packet 3265 containing the most recent MAX_STREAM_DATA frame for a stream is 3266 lost or when the limit is updated, with care taken to prevent the 3267 frame from being sent too often. An endpoint SHOULD stop sending 3268 MAX_STREAM_DATA frames when the receiving part of the stream 3269 enters a "Size Known" state. 3271 o The limit on streams of a given type is sent in MAX_STREAMS 3272 frames. Like MAX_DATA, an updated value is sent when a packet 3273 containing the most recent MAX_STREAMS for a stream type frame is 3274 declared lost or when the limit is updated, with care taken to 3275 prevent the frame from being sent too often. 3277 o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, 3278 and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection 3279 scope, STREAM_DATA_BLOCKED frames have stream scope, and 3280 STREAMS_BLOCKED frames are scoped to a specific stream type. New 3281 frames are sent if packets containing the most recent frame for a 3282 scope is lost, but only while the endpoint is blocked on the 3283 corresponding limit. These frames always include the limit that 3284 is causing blocking at the time that they are transmitted. 3286 o A liveness or path validation check using PATH_CHALLENGE frames is 3287 sent periodically until a matching PATH_RESPONSE frame is received 3288 or until there is no remaining need for liveness or path 3289 validation checking. PATH_CHALLENGE frames include a different 3290 payload each time they are sent. 3292 o Responses to path validation using PATH_RESPONSE frames are sent 3293 just once. A new PATH_CHALLENGE frame will be sent if another 3294 PATH_RESPONSE frame is needed. 3296 o New connection IDs are sent in NEW_CONNECTION_ID frames and 3297 retransmitted if the packet containing them is lost. 3298 Retransmissions of this frame carry the same sequence number 3299 value. Likewise, retired connection IDs are sent in 3300 RETIRE_CONNECTION_ID frames and retransmitted if the packet 3301 containing them is lost. 3303 o PING and PADDING frames contain no information, so lost PING or 3304 PADDING frames do not require repair. 3306 Endpoints SHOULD prioritize retransmission of data over sending new 3307 data, unless priorities specified by the application indicate 3308 otherwise (see Section 2.3). 3310 Even though a sender is encouraged to assemble frames containing up- 3311 to-date information every time it sends a packet, it is not forbidden 3312 to retransmit copies of frames from lost packets. A receiver MUST 3313 accept packets containing an outdated frame, such as a MAX_DATA frame 3314 carrying a smaller maximum data than one found in an older packet. 3316 Upon detecting losses, a sender MUST take appropriate congestion 3317 control action. The details of loss detection and congestion control 3318 are described in [QUIC-RECOVERY]. 3320 13.3. Explicit Congestion Notification 3322 QUIC endpoints can use Explicit Congestion Notification (ECN) 3323 [RFC3168] to detect and respond to network congestion. ECN allows a 3324 network node to indicate congestion in the network by setting a 3325 codepoint in the IP header of a packet instead of dropping it. 3326 Endpoints react to congestion by reducing their sending rate in 3327 response, as described in [QUIC-RECOVERY]. 3329 To use ECN, QUIC endpoints first determine whether a path supports 3330 ECN marking and the peer is able to access the ECN codepoint in the 3331 IP header. A network path does not support ECN if ECN marked packets 3332 get dropped or ECN markings are rewritten on the path. An endpoint 3333 verifies the path, both during connection establishment and when 3334 migrating to a new path (see Section 9). 3336 13.3.1. ECN Counts 3338 On receiving a QUIC packet with an ECT or CE codepoint, an ECN- 3339 enabled endpoint that can access the ECN codepoints from the 3340 enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE 3341 count, and includes these counts in subsequent ACK frames (see 3342 Section 13.1 and Section 19.3). Note that this requires being able 3343 to read the ECN codepoints from the enclosing IP packet, which is not 3344 possible on all platforms. 3346 A packet detected by a receiver as a duplicate does not affect the 3347 receiver's local ECN codepoint counts; see (Section 21.7) for 3348 relevant security concerns. 3350 If an endpoint receives a QUIC packet without an ECT or CE codepoint 3351 in the IP packet header, it responds per Section 13.1 with an ACK 3352 frame without increasing any ECN counts. If an endpoint does not 3353 implement ECN support or does not have access to received ECN 3354 codepoints, it does not increase ECN counts. 3356 Coalesced packets (see Section 12.2) mean that several packets can 3357 share the same IP header. The ECN counter for the ECN codepoint 3358 received in the associated IP header are incremented once for each 3359 QUIC packet, not per enclosing IP packet or UDP datagram. 3361 Each packet number space maintains separate acknowledgement state and 3362 separate ECN counts. For example, if one each of an Initial, 0-RTT, 3363 Handshake, and 1-RTT QUIC packet are coalesced, the corresponding 3364 counts for the Initial and Handshake packet number space will be 3365 incremented by one and the counts for the 1-RTT packet number space 3366 will be increased by two. 3368 13.3.2. ECN Verification 3370 Each endpoint independently verifies and enables use of ECN by 3371 setting the IP header ECN codepoint to ECN Capable Transport (ECT) 3372 for the path from it to the other peer. Even if not setting ECN 3373 codepoints on packets it transmits, the endpoint SHOULD provide 3374 feedback about ECN markings received (if accessible). 3376 To verify both that a path supports ECN and the peer can provide ECN 3377 feedback, an endpoint sets the ECT(0) codepoint in the IP header of 3378 all outgoing packets [RFC8311]. 3380 If an ECT codepoint set in the IP header is not corrupted by a 3381 network device, then a received packet contains either the codepoint 3382 sent by the peer or the Congestion Experienced (CE) codepoint set by 3383 a network device that is experiencing congestion. 3385 If a QUIC packet sent with an ECT codepoint is newly acknowledged by 3386 the peer in an ACK frame without ECN feedback, the endpoint stops 3387 setting ECT codepoints in subsequent IP packets, with the expectation 3388 that either the network path or the peer no longer supports ECN. 3390 Network devices that corrupt or apply non-standard ECN markings might 3391 result in reduced throughput or other undesirable side-effects. To 3392 reduce this risk, an endpoint uses the following steps to verify the 3393 counts it receives in an ACK frame. 3395 o The total increase in ECT(0), ECT(1), and CE counts MUST be no 3396 smaller than the total number of QUIC packets sent with an ECT 3397 codepoint that are newly acknowledged in this ACK frame. This 3398 step detects any network remarking from ECT(0), ECT(1), or CE 3399 codepoints to Not-ECT. 3401 o Any increase in either ECT(0) or ECT(1) counts, plus any increase 3402 in the CE count, MUST be no smaller than the number of packets 3403 sent with the corresponding ECT codepoint that are newly 3404 acknowledged in this ACK frame. This step detects any erroneous 3405 network remarking from ECT(0) to ECT(1) (or vice versa). 3407 An endpoint could miss acknowledgements for a packet when ACK frames 3408 are lost. It is therefore possible for the total increase in ECT(0), 3409 ECT(1), and CE counts to be greater than the number of packets 3410 acknowledged in an ACK frame. When this happens, and if verification 3411 succeeds, the local reference counts MUST be increased to match the 3412 counts in the ACK frame. 3414 Processing counts out of order can result in verification failure. 3415 An endpoint SHOULD NOT perform this verification if the ACK frame is 3416 received in a packet with packet number lower than a previously 3417 received ACK frame. Verifying based on ACK frames that arrive out of 3418 order can result in disabling ECN unnecessarily. 3420 Upon successful verification, an endpoint continues to set ECT 3421 codepoints in subsequent packets with the expectation that the path 3422 is ECN-capable. 3424 If verification fails, then the endpoint ceases setting ECT 3425 codepoints in subsequent IP packets with the expectation that either 3426 the network path or the peer does not support ECN. 3428 If an endpoint sets ECT codepoints on outgoing IP packets and 3429 encounters a retransmission timeout due to the absence of 3430 acknowledgments from the peer (see [QUIC-RECOVERY]), or if an 3431 endpoint has reason to believe that an element on the network path 3432 might be corrupting ECN codepoints, the endpoint MAY cease setting 3433 ECT codepoints in subsequent packets. Doing so allows the connection 3434 to be resilient to network elements that corrupt ECN codepoints in 3435 the IP header or drop packets with ECT or CE codepoints in the IP 3436 header. 3438 14. Packet Size 3440 The QUIC packet size includes the QUIC header and protected payload, 3441 but not the UDP or IP header. 3443 Clients MUST ensure they send the first Initial packet in a single IP 3444 packet. Similarly, the first Initial packet sent after receiving a 3445 Retry packet MUST be sent in a single IP packet. 3447 The payload of a UDP datagram carrying the first Initial packet MUST 3448 be expanded to at least 1200 bytes, by adding PADDING frames to the 3449 Initial packet and/or by combining the Initial packet with a 0-RTT 3450 packet (see Section 12.2). Sending a UDP datagram of this size 3451 ensures that the network path supports a reasonable Maximum 3452 Transmission Unit (MTU), and helps reduce the amplitude of 3453 amplification attacks caused by server responses toward an unverified 3454 client address, see Section 8. 3456 The datagram containing the first Initial packet from a client MAY 3457 exceed 1200 bytes if the client believes that the Path Maximum 3458 Transmission Unit (PMTU) supports the size that it chooses. 3460 A server MAY send a CONNECTION_CLOSE frame with error code 3461 PROTOCOL_VIOLATION in response to the first Initial packet it 3462 receives from a client if the UDP datagram is smaller than 1200 3463 bytes. It MUST NOT send any other frame type in response, or 3464 otherwise behave as if any part of the offending packet was processed 3465 as valid. 3467 The server MUST also limit the number of bytes it sends before 3468 validating the address of the client, see Section 8. 3470 14.1. Path Maximum Transmission Unit (PMTU) 3472 The PMTU is the maximum size of the entire IP packet including the IP 3473 header, UDP header, and UDP payload. The UDP payload includes the 3474 QUIC packet header, protected payload, and any authentication fields. 3475 The PMTU can depend upon the current path characteristics. 3476 Therefore, the current largest UDP payload an implementation will 3477 send is referred to as the QUIC maximum packet size. 3479 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 3480 minimum size [RFC8200] and is also supported by most modern IPv4 3481 networks. All QUIC packets (except for PMTU probe packets) SHOULD be 3482 sized to fit within the maximum packet size to avoid the packet being 3483 fragmented or dropped [RFC8085]. 3485 An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery 3486 ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] 3487 [RFC8201] to determine whether the path to a destination will support 3488 a desired message size without fragmentation. 3490 In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP 3491 packets larger than 1280 bytes. Assuming the minimum IP header size, 3492 this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 3493 1252 bytes for IPv4. A QUIC implementation MAY be more conservative 3494 in computing the QUIC maximum packet size to allow for unknown tunnel 3495 overheads or IP header options/extensions. 3497 Each pair of local and remote addresses could have a different PMTU. 3498 QUIC implementations that implement any kind of PMTU discovery 3499 therefore SHOULD maintain a maximum packet size for each combination 3500 of local and remote IP addresses. 3502 If a QUIC endpoint determines that the PMTU between any pair of local 3503 and remote IP addresses has fallen below the size needed to support 3504 the smallest allowed maximum packet size, it MUST immediately cease 3505 sending QUIC packets, except for PMTU probe packets, on the affected 3506 path. An endpoint MAY terminate the connection if an alternative 3507 path cannot be found. 3509 14.2. ICMP Packet Too Big Messages 3511 PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP 3512 messages (e.g., IPv6 Packet Too Big messages) that indicate when a 3513 packet is dropped because it is larger than the local router MTU. 3514 DPLPMTUD can also optionally use these messages. This use of ICMP 3515 messages is potentially vulnerable to off-path attacks that 3516 successfully guess the addresses used on the path and reduce the PMTU 3517 to a bandwidth-inefficient value. 3519 An endpoint MUST ignore an ICMP message that claims the PMTU has 3520 decreased below 1280 bytes. 3522 The requirements for generating ICMP ([RFC1812], [RFC4443]) state 3523 that the quoted packet should contain as much of the original packet 3524 as possible without exceeding the minimum MTU for the IP version. 3525 The size of the quoted packet can actually be smaller, or the 3526 information unintelligible, as described in Section 1.1 of 3527 [DPLPMTUD]. 3529 QUIC endpoints SHOULD validate ICMP messages to protect from off-path 3530 injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. 3531 This validation SHOULD use the quoted packet supplied in the payload 3532 of an ICMP message to associate the message with a corresponding 3533 transport connection [DPLPMTUD]. 3535 ICMP message validation MUST include matching IP addresses and UDP 3536 ports [RFC8085] and, when possible, connection IDs to an active QUIC 3537 session. 3539 Further validation can also be provided: 3541 o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small 3542 proportion of packets, so that most invalid ICMP messages arrive 3543 when there are no DF packets outstanding, and can therefore be 3544 identified as spurious. 3546 o An endpoint could store additional information from the IP or UDP 3547 headers to use for validation (for example, the IP ID or UDP 3548 checksum). 3550 The endpoint SHOULD ignore all ICMP messages that fail validation. 3552 An endpoint MUST NOT increase PMTU based on ICMP messages. Any 3553 reduction in the QUIC maximum packet size MAY be provisional until 3554 QUIC's loss detection algorithm determines that the quoted packet has 3555 actually been lost. 3557 14.3. Datagram Packetization Layer PMTU Discovery 3559 Section 6.4 of [DPLPMTUD] provides considerations for implementing 3560 Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. 3562 When implementing the algorithm in Section 5.3 of [DPLPMTUD], the 3563 initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC 3564 packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). 3566 PING and PADDING frames can be used to generate PMTU probe packets. 3567 These frames might not be retransmitted if a probe packet containing 3568 them is lost. However, these frames do consume congestion window, 3569 which could delay the transmission of subsequent application data. 3571 A PING frame can be included in a PMTU probe to ensure that a valid 3572 probe is acknowledged. 3574 The considerations for processing ICMP messages in the previous 3575 section also apply if these messages are used by DPLPMTUD. 3577 15. Versions 3579 QUIC versions are identified using a 32-bit unsigned number. 3581 The version 0x00000000 is reserved to represent version negotiation. 3582 This version of the specification is identified by the number 3583 0x00000001. 3585 Other versions of QUIC might have different properties to this 3586 version. The properties of QUIC that are guaranteed to be consistent 3587 across all versions of the protocol are described in 3588 [QUIC-INVARIANTS]. 3590 Version 0x00000001 of QUIC uses TLS as a cryptographic handshake 3591 protocol, as described in [QUIC-TLS]. 3593 Versions with the most significant 16 bits of the version number 3594 cleared are reserved for use in future IETF consensus documents. 3596 Versions that follow the pattern 0x?a?a?a?a are reserved for use in 3597 forcing version negotiation to be exercised. That is, any version 3598 number where the low four bits of all bytes is 1010 (in binary). A 3599 client or server MAY advertise support for any of these reserved 3600 versions. 3602 Reserved version numbers will probably never represent a real 3603 protocol; a client MAY use one of these version numbers with the 3604 expectation that the server will initiate version negotiation; a 3605 server MAY advertise support for one of these versions and can expect 3606 that clients ignore the value. 3608 [[RFC editor: please remove the remainder of this section before 3609 publication.]] 3611 The version number for the final version of this specification 3612 (0x00000001), is reserved for the version of the protocol that is 3613 published as an RFC. 3615 Version numbers used to identify IETF drafts are created by adding 3616 the draft number to 0xff000000. For example, draft-ietf-quic- 3617 transport-13 would be identified as 0xff00000D. 3619 Implementors are encouraged to register version numbers of QUIC that 3620 they are using for private experimentation on the GitHub wiki at 3621 . 3623 16. Variable-Length Integer Encoding 3625 QUIC packets and frames commonly use a variable-length encoding for 3626 non-negative integer values. This encoding ensures that smaller 3627 integer values need fewer bytes to encode. 3629 The QUIC variable-length integer encoding reserves the two most 3630 significant bits of the first byte to encode the base 2 logarithm of 3631 the integer encoding length in bytes. The integer value is encoded 3632 on the remaining bits, in network byte order. 3634 This means that integers are encoded on 1, 2, 4, or 8 bytes and can 3635 encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes 3636 the encoding properties. 3638 +------+--------+-------------+-----------------------+ 3639 | 2Bit | Length | Usable Bits | Range | 3640 +------+--------+-------------+-----------------------+ 3641 | 00 | 1 | 6 | 0-63 | 3642 | | | | | 3643 | 01 | 2 | 14 | 0-16383 | 3644 | | | | | 3645 | 10 | 4 | 30 | 0-1073741823 | 3646 | | | | | 3647 | 11 | 8 | 62 | 0-4611686018427387903 | 3648 +------+--------+-------------+-----------------------+ 3650 Table 4: Summary of Integer Encodings 3652 For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in 3653 hexadecimal) decodes to the decimal value 151288809941952652; the 3654 four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 3655 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 3656 (as does the two byte sequence 40 25). 3658 Error codes (Section 20) and versions Section 15 are described using 3659 integers, but do not use this encoding. 3661 17. Packet Formats 3663 All numeric values are encoded in network byte order (that is, big- 3664 endian) and all field sizes are in bits. Hexadecimal notation is 3665 used for describing the value of fields. 3667 17.1. Packet Number Encoding and Decoding 3669 Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). 3670 When present in long or short packet headers, they are encoded in 1 3671 to 4 bytes. The number of bits required to represent the packet 3672 number is reduced by including the least significant bits of the 3673 packet number. 3675 The encoded packet number is protected as described in Section 5.4 of 3676 [QUIC-TLS]. 3678 The sender MUST use a packet number size able to represent more than 3679 twice as large a range than the difference between the largest 3680 acknowledged packet and packet number being sent. A peer receiving 3681 the packet will then correctly decode the packet number, unless the 3682 packet is delayed in transit such that it arrives after many higher- 3683 numbered packets have been received. An endpoint SHOULD use a large 3684 enough packet number encoding to allow the packet number to be 3685 recovered even if the packet arrives after packets that are sent 3686 afterwards. 3688 As a result, the size of the packet number encoding is at least one 3689 bit more than the base-2 logarithm of the number of contiguous 3690 unacknowledged packet numbers, including the new packet. 3692 For example, if an endpoint has received an acknowledgment for packet 3693 0xabe8bc, sending a packet with a number of 0xac5c02 requires a 3694 packet number encoding with 16 bits or more; whereas the 24-bit 3695 packet number encoding is needed to send a packet with a number of 3696 0xace8fe. 3698 At a receiver, protection of the packet number is removed prior to 3699 recovering the full packet number. The full packet number is then 3700 reconstructed based on the number of significant bits present, the 3701 value of those bits, and the largest packet number received on a 3702 successfully authenticated packet. Recovering the full packet number 3703 is necessary to successfully remove packet protection. 3705 Once header protection is removed, the packet number is decoded by 3706 finding the packet number value that is closest to the next expected 3707 packet. The next expected packet is the highest received packet 3708 number plus one. For example, if the highest successfully 3709 authenticated packet had a packet number of 0xa82f30ea, then a packet 3710 containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. 3711 Example pseudo-code for packet number decoding can be found in 3712 Appendix A. 3714 17.2. Long Header Packets 3716 0 1 2 3 3717 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3718 +-+-+-+-+-+-+-+-+ 3719 |1|1|T T|X X X X| 3720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3721 | Version (32) | 3722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3723 |DCIL(4)|SCIL(4)| 3724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3725 | Destination Connection ID (0/32..144) ... 3726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3727 | Source Connection ID (0/32..144) ... 3728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3730 Figure 10: Long Header Packet Format 3732 Long headers are used for packets that are sent prior to the 3733 completion of version negotiation and establishment of 1-RTT keys. 3734 Once both conditions are met, a sender switches to sending packets 3735 using the short header (Section 17.3). The long form allows for 3736 special packets - such as the Version Negotiation packet - to be 3737 represented in this uniform fixed-length packet format. Packets that 3738 use the long header contain the following fields: 3740 Header Form: The most significant bit (0x80) of byte 0 (the first 3741 byte) is set to 1 for long headers. 3743 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 3744 containing a zero value for this bit are not valid packets in this 3745 version and MUST be discarded. 3747 Long Packet Type (T): The next two bits (those with a mask of 0x30) 3748 of byte 0 contain a packet type. Packet types are listed in 3749 Table 5. 3751 Type-Specific Bits (X): The lower four bits (those with a mask of 3752 0x0f) of byte 0 are type-specific. 3754 Version: The QUIC Version is a 32-bit field that follows the first 3755 byte. This field indicates which version of QUIC is in use and 3756 determines how the rest of the protocol fields are interpreted. 3758 DCIL and SCIL: The byte following the version contains the lengths 3759 of the two connection ID fields that follow it. These lengths are 3760 encoded as two 4-bit unsigned integers. The Destination 3761 Connection ID Length (DCIL) field occupies the 4 high bits of the 3762 byte and the Source Connection ID Length (SCIL) field occupies the 3763 4 low bits of the byte. An encoded length of 0 indicates that the 3764 connection ID is also 0 bytes in length. Non-zero encoded lengths 3765 are increased by 3 to get the full length of the connection ID, 3766 producing a length between 4 and 18 bytes inclusive. For example, 3767 an byte with the value 0x50 describes an 8-byte Destination 3768 Connection ID and a zero-length Source Connection ID. 3770 Destination Connection ID: The Destination Connection ID field 3771 follows the connection ID lengths and is either 0 bytes in length 3772 or between 4 and 18 bytes. Section 7.2 describes the use of this 3773 field in more detail. 3775 Source Connection ID: The Source Connection ID field follows the 3776 Destination Connection ID and is either 0 bytes in length or 3777 between 4 and 18 bytes. Section 7.2 describes the use of this 3778 field in more detail. 3780 In this version of QUIC, the following packet types with the long 3781 header are defined: 3783 +------+-----------+----------------+ 3784 | Type | Name | Section | 3785 +------+-----------+----------------+ 3786 | 0x0 | Initial | Section 17.2.2 | 3787 | | | | 3788 | 0x1 | 0-RTT | Section 17.2.3 | 3789 | | | | 3790 | 0x2 | Handshake | Section 17.2.4 | 3791 | | | | 3792 | 0x3 | Retry | Section 17.2.5 | 3793 +------+-----------+----------------+ 3795 Table 5: Long Header Packet Types 3797 The header form bit, connection ID lengths byte, Destination and 3798 Source Connection ID fields, and Version fields of a long header 3799 packet are version-independent. The other fields in the first byte 3800 are version-specific. See [QUIC-INVARIANTS] for details on how 3801 packets from different versions of QUIC are interpreted. 3803 The interpretation of the fields and the payload are specific to a 3804 version and packet type. While type-specific semantics for this 3805 version are described in the following sections, several long-header 3806 packets in this version of QUIC contain these additional fields: 3808 Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 3809 are reserved across multiple packet types. These bits are 3810 protected using header protection (see Section 5.4 of [QUIC-TLS]). 3811 The value included prior to protection MUST be set to 0. An 3812 endpoint MUST treat receipt of a packet that has a non-zero value 3813 for these bits after removing protection as a connection error of 3814 type PROTOCOL_VIOLATION. 3816 Packet Number Length (P): In packet types which contain a Packet 3817 Number field, the least significant two bits (those with a mask of 3818 0x03) of byte 0 contain the length of the packet number, encoded 3819 as an unsigned, two-bit integer that is one less than the length 3820 of the packet number field in bytes. That is, the length of the 3821 packet number field is the value of this field, plus one. These 3822 bits are protected using header protection (see Section 5.4 of 3823 [QUIC-TLS]). 3825 Length: The length of the remainder of the packet (that is, the 3826 Packet Number and Payload fields) in bytes, encoded as a variable- 3827 length integer (Section 16). 3829 Packet Number: The packet number field is 1 to 4 bytes long. The 3830 packet number has confidentiality protection separate from packet 3831 protection, as described in Section 5.4 of [QUIC-TLS]. The length 3832 of the packet number field is encoded in the Packet Number Length 3833 bits of byte 0 (see above). 3835 17.2.1. Version Negotiation Packet 3837 A Version Negotiation packet is inherently not version-specific. 3838 Upon receipt by a client, it will be identified as a Version 3839 Negotiation packet based on the Version field having a value of 0. 3841 The Version Negotiation packet is a response to a client packet that 3842 contains a version that is not supported by the server, and is only 3843 sent by servers. 3845 The layout of a Version Negotiation packet is: 3847 0 1 2 3 3848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3849 +-+-+-+-+-+-+-+-+ 3850 |1| Unused (7) | 3851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3852 | Version (32) | 3853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3854 |DCIL(4)|SCIL(4)| 3855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3856 | Destination Connection ID (0/32..144) ... 3857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3858 | Source Connection ID (0/32..144) ... 3859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3860 | Supported Version 1 (32) ... 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3862 | [Supported Version 2 (32)] ... 3863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3864 ... 3865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3866 | [Supported Version N (32)] ... 3867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 Figure 11: Version Negotiation Packet 3871 The value in the Unused field is selected randomly by the server. 3873 The Version field of a Version Negotiation packet MUST be set to 3874 0x00000000. 3876 The server MUST include the value from the Source Connection ID field 3877 of the packet it receives in the Destination Connection ID field. 3878 The value for Source Connection ID MUST be copied from the 3879 Destination Connection ID of the received packet, which is initially 3880 randomly selected by a client. Echoing both connection IDs gives 3881 clients some assurance that the server received the packet and that 3882 the Version Negotiation packet was not generated by an off-path 3883 attacker. 3885 The remainder of the Version Negotiation packet is a list of 32-bit 3886 versions which the server supports. 3888 A Version Negotiation packet cannot be explicitly acknowledged in an 3889 ACK frame by a client. Receiving another Initial packet implicitly 3890 acknowledges a Version Negotiation packet. 3892 The Version Negotiation packet does not include the Packet Number and 3893 Length fields present in other packets that use the long header form. 3894 Consequently, a Version Negotiation packet consumes an entire UDP 3895 datagram. 3897 A server MUST NOT send more than one Version Negotiation packet in 3898 response to a single UDP datagram. 3900 See Section 6 for a description of the version negotiation process. 3902 17.2.2. Initial Packet 3904 An Initial packet uses long headers with a type value of 0x0. It 3905 carries the first CRYPTO frames sent by the client and server to 3906 perform key exchange, and carries ACKs in either direction. 3908 +-+-+-+-+-+-+-+-+ 3909 |1|1| 0 |R R|P P| 3910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3911 | Version (32) | 3912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3913 |DCIL(4)|SCIL(4)| 3914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 | Destination Connection ID (0/32..144) ... 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 | Source Connection ID (0/32..144) ... 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | Token Length (i) ... 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3921 | Token (*) ... 3922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3923 | Length (i) ... 3924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3925 | Packet Number (8/16/24/32) ... 3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3927 | Payload (*) ... 3928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3930 Figure 12: Initial Packet 3932 The Initial packet contains a long header as well as the Length and 3933 Packet Number fields. The first byte contains the Reserved and 3934 Packet Number Length bits. Between the SCID and Length fields, there 3935 are two additional field specific to the Initial packet. 3937 Token Length: A variable-length integer specifying the length of the 3938 Token field, in bytes. This value is zero if no token is present. 3939 Initial packets sent by the server MUST set the Token Length field 3940 to zero; clients that receive an Initial packet with a non-zero 3941 Token Length field MUST either discard the packet or generate a 3942 connection error of type PROTOCOL_VIOLATION. 3944 Token: The value of the token that was previously provided in a 3945 Retry packet or NEW_TOKEN frame. 3947 Payload: The payload of the packet. 3949 In order to prevent tampering by version-unaware middleboxes, Initial 3950 packets are protected with connection- and version-specific keys 3951 (Initial keys) as described in [QUIC-TLS]. This protection does not 3952 provide confidentiality or integrity against on-path attackers, but 3953 provides some level of protection against off-path attackers. 3955 The client and server use the Initial packet type for any packet that 3956 contains an initial cryptographic handshake message. This includes 3957 all cases where a new packet containing the initial cryptographic 3958 message needs to be created, such as the packets sent after receiving 3959 a Version Negotiation (Section 17.2.1) or Retry packet 3960 (Section 17.2.5). 3962 A server sends its first Initial packet in response to a client 3963 Initial. A server may send multiple Initial packets. The 3964 cryptographic key exchange could require multiple round trips or 3965 retransmissions of this data. 3967 The payload of an Initial packet includes a CRYPTO frame (or frames) 3968 containing a cryptographic handshake message, ACK frames, or both. 3969 PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint 3970 that receives an Initial packet containing other frames can either 3971 discard the packet as spurious or treat it as a connection error. 3973 The first packet sent by a client always includes a CRYPTO frame that 3974 contains the entirety of the first cryptographic handshake message. 3975 This packet, and the cryptographic handshake message, MUST fit in a 3976 single UDP datagram (see Section 7). The first CRYPTO frame sent 3977 always begins at an offset of 0 (see Section 7). 3979 Note that if the server sends a HelloRetryRequest, the client will 3980 send a second Initial packet. This Initial packet will continue the 3981 cryptographic handshake and will contain a CRYPTO frame with an 3982 offset matching the size of the CRYPTO frame sent in the first 3983 Initial packet. Cryptographic handshake messages subsequent to the 3984 first do not need to fit within a single UDP datagram. 3986 17.2.2.1. Abandoning Initial Packets 3988 A client stops both sending and processing Initial packets when it 3989 sends its first Handshake packet. A server stops sending and 3990 processing Initial packets when it receives its first Handshake 3991 packet. Though packets might still be in flight or awaiting 3992 acknowledgment, no further Initial packets need to be exchanged 3993 beyond this point. Initial packet protection keys are discarded (see 3994 Section 4.10 of [QUIC-TLS]) along with any loss recovery and 3995 congestion control state (see Sections 5.3.1.2 and 6.9 of 3996 [QUIC-RECOVERY]). 3998 Any data in CRYPTO frames is discarded - and no longer retransmitted 3999 - when Initial keys are discarded. 4001 17.2.3. 0-RTT 4003 A 0-RTT packet uses long headers with a type value of 0x1, followed 4004 by the Length and Packet Number fields. The first byte contains the 4005 Reserved and Packet Number Length bits. It is used to carry "early" 4006 data from the client to the server as part of the first flight, prior 4007 to handshake completion. As part of the TLS handshake, the server 4008 can accept or reject this early data. 4010 See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its 4011 limitations. 4013 +-+-+-+-+-+-+-+-+ 4014 |1|1| 1 |R R|P P| 4015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4016 | Version (32) | 4017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4018 |DCIL(4)|SCIL(4)| 4019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4020 | Destination Connection ID (0/32..144) ... 4021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4022 | Source Connection ID (0/32..144) ... 4023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4024 | Length (i) ... 4025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4026 | Packet Number (8/16/24/32) ... 4027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4028 | Payload (*) ... 4029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4031 0-RTT Packet 4033 Packet numbers for 0-RTT protected packets use the same space as 4034 1-RTT protected packets. 4036 After a client receives a Retry or Version Negotiation packet, 0-RTT 4037 packets are likely to have been lost or discarded by the server. A 4038 client MAY attempt to resend data in 0-RTT packets after it sends a 4039 new Initial packet. 4041 A client MUST NOT reset the packet number it uses for 0-RTT packets. 4042 The keys used to protect 0-RTT packets will not change as a result of 4043 responding to a Retry or Version Negotiation packet unless the client 4044 also regenerates the cryptographic handshake message. Sending 4045 packets with the same packet number in that case is likely to 4046 compromise the packet protection for all 0-RTT packets because the 4047 same key and nonce could be used to protect different content. 4049 Receiving a Retry or Version Negotiation packet, especially a Retry 4050 that changes the connection ID used for subsequent packets, indicates 4051 a strong possibility that 0-RTT packets could be lost. A client only 4052 receives acknowledgments for its 0-RTT packets once the handshake is 4053 complete. Consequently, a server might expect 0-RTT packets to start 4054 with a packet number of 0. Therefore, in determining the length of 4055 the packet number encoding for 0-RTT packets, a client MUST assume 4056 that all packets up to the current packet number are in flight, 4057 starting from a packet number of 0. Thus, 0-RTT packets could need 4058 to use a longer packet number encoding. 4060 A client SHOULD instead generate a fresh cryptographic handshake 4061 message and start packet numbers from 0. This ensures that new 0-RTT 4062 packets will not use the same keys, avoiding any risk of key and 4063 nonce reuse; this also prevents 0-RTT packets from previous handshake 4064 attempts from being accepted as part of the connection. 4066 17.2.4. Handshake Packet 4068 A Handshake packet uses long headers with a type value of 0x2, 4069 followed by the Length and Packet Number fields. The first byte 4070 contains the Reserved and Packet Number Length bits. It is used to 4071 carry acknowledgments and cryptographic handshake messages from the 4072 server and client. 4074 +-+-+-+-+-+-+-+-+ 4075 |1|1| 2 |R R|P P| 4076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4077 | Version (32) | 4078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4079 |DCIL(4)|SCIL(4)| 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 | Destination Connection ID (0/32..144) ... 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4083 | Source Connection ID (0/32..144) ... 4084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4085 | Length (i) ... 4086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4087 | Packet Number (8/16/24/32) ... 4088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4089 | Payload (*) ... 4090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4092 Figure 13: Handshake Protected Packet 4094 Once a client has received a Handshake packet from a server, it uses 4095 Handshake packets to send subsequent cryptographic handshake messages 4096 and acknowledgments to the server. 4098 The Destination Connection ID field in a Handshake packet contains a 4099 connection ID that is chosen by the recipient of the packet; the 4100 Source Connection ID includes the connection ID that the sender of 4101 the packet wishes to use (see Section 7.2). 4103 Handshake packets are their own packet number space, and thus the 4104 first Handshake packet sent by a server contains a packet number of 4105 0. 4107 The payload of this packet contains CRYPTO frames and could contain 4108 PADDING, or ACK frames. Handshake packets MAY contain 4109 CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake 4110 packets with other frames as a connection error. 4112 Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at 4113 the Handshake encryption level is discarded - and no longer 4114 retransmitted - when Handshake protection keys are discarded. 4116 17.2.5. Retry Packet 4118 A Retry packet uses a long packet header with a type value of 0x3. 4119 It carries an address validation token created by the server. It is 4120 used by a server that wishes to perform a stateless retry (see 4121 Section 8.1). 4123 0 1 2 3 4124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4125 +-+-+-+-+-+-+-+-+ 4126 |1|1| 3 | ODCIL | 4127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4128 | Version (32) | 4129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4130 |DCIL(4)|SCIL(4)| 4131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 | Destination Connection ID (0/32..144) ... 4133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4134 | Source Connection ID (0/32..144) ... 4135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4136 | Original Destination Connection ID (0/32..144) ... 4137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4138 | Retry Token (*) ... 4139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4141 Figure 14: Retry Packet 4143 A Retry packet (shown in Figure 14) does not contain any protected 4144 fields. In addition to the long header, it contains these additional 4145 fields: 4147 ODCIL: The four least-significant bits of the first byte of a Retry 4148 packet are not protected as they are for other packets with the 4149 long header, because Retry packets don't contain a protected 4150 payload. These bits instead encode the length of the Original 4151 Destination Connection ID field. The length uses the same 4152 encoding as the DCIL and SCIL fields. 4154 Original Destination Connection ID: The Original Destination 4155 Connection ID contains the value of the Destination Connection ID 4156 from the Initial packet that this Retry is in response to. The 4157 length of this field is given in ODCIL. 4159 Retry Token: An opaque token that the server can use to validate the 4160 client's address. 4162 The server populates the Destination Connection ID with the 4163 connection ID that the client included in the Source Connection ID of 4164 the Initial packet. 4166 The server includes a connection ID of its choice in the Source 4167 Connection ID field. This value MUST not be equal to the Destination 4168 Connection ID field of the packet sent by the client. The client 4169 MUST use this connection ID in the Destination Connection ID of 4170 subsequent packets that it sends. 4172 A server MAY send Retry packets in response to Initial and 0-RTT 4173 packets. A server can either discard or buffer 0-RTT packets that it 4174 receives. A server can send multiple Retry packets as it receives 4175 Initial or 0-RTT packets. A server MUST NOT send more than one Retry 4176 packet in response to a single UDP datagram. 4178 A client MUST accept and process at most one Retry packet for each 4179 connection attempt. After the client has received and processed an 4180 Initial or Retry packet from the server, it MUST discard any 4181 subsequent Retry packets that it receives. 4183 Clients MUST discard Retry packets that contain an Original 4184 Destination Connection ID field that does not match the Destination 4185 Connection ID from its Initial packet. This prevents an off-path 4186 attacker from injecting a Retry packet. 4188 The client responds to a Retry packet with an Initial packet that 4189 includes the provided Retry Token to continue connection 4190 establishment. 4192 A client sets the Destination Connection ID field of this Initial 4193 packet to the value from the Source Connection ID in the Retry 4194 packet. Changing Destination Connection ID also results in a change 4195 to the keys used to protect the Initial packet. It also sets the 4196 Token field to the token provided in the Retry. The client MUST NOT 4197 change the Source Connection ID because the server could include the 4198 connection ID as part of its token validation logic (see 4199 Section 8.1.2). 4201 The next Initial packet from the client uses the connection ID and 4202 token values from the Retry packet (see Section 7.2). Aside from 4203 this, the Initial packet sent by the client is subject to the same 4204 restrictions as the first Initial packet. A client can either reuse 4205 the cryptographic handshake message or construct a new one at its 4206 discretion. 4208 A client MAY attempt 0-RTT after receiving a Retry packet by sending 4209 0-RTT packets to the connection ID provided by the server. A client 4210 that sends additional 0-RTT packets without constructing a new 4211 cryptographic handshake message MUST NOT reset the packet number to 0 4212 after a Retry packet, see Section 17.2.3. 4214 A server acknowledges the use of a Retry packet for a connection 4215 using the original_connection_id transport parameter (see 4216 Section 18.1). If the server sends a Retry packet, it MUST include 4217 the value of the Original Destination Connection ID field of the 4218 Retry packet (that is, the Destination Connection ID field from the 4219 client's first Initial packet) in the transport parameter. 4221 If the client received and processed a Retry packet, it MUST validate 4222 that the original_connection_id transport parameter is present and 4223 correct; otherwise, it MUST validate that the transport parameter is 4224 absent. A client MUST treat a failed validation as a connection 4225 error of type TRANSPORT_PARAMETER_ERROR. 4227 A Retry packet does not include a packet number and cannot be 4228 explicitly acknowledged by a client. 4230 17.3. Short Header Packets 4232 This version of QUIC defines a single packet type which uses the 4233 short packet header. 4235 0 1 2 3 4236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4237 +-+-+-+-+-+-+-+-+ 4238 |0|1|S|R|R|K|P P| 4239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4240 | Destination Connection ID (0..144) ... 4241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4242 | Packet Number (8/16/24/32) ... 4243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4244 | Protected Payload (*) ... 4245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4247 Figure 15: Short Header Packet Format 4249 The short header can be used after the version and 1-RTT keys are 4250 negotiated. Packets that use the short header contain the following 4251 fields: 4253 Header Form: The most significant bit (0x80) of byte 0 is set to 0 4254 for the short header. 4256 Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets 4257 containing a zero value for this bit are not valid packets in this 4258 version and MUST be discarded. 4260 Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin 4261 Bit, set as described in [SPIN]. 4263 Reserved Bits (R): The next two bits (those with a mask of 0x18) of 4264 byte 0 are reserved. These bits are protected using header 4265 protection (see Section 5.4 of [QUIC-TLS]). The value included 4266 prior to protection MUST be set to 0. An endpoint MUST treat 4267 receipt of a packet that has a non-zero value for these bits after 4268 removing protection as a connection error of type 4269 PROTOCOL_VIOLATION. 4271 Key Phase (K): The next bit (0x04) of byte 0 indicates the key 4272 phase, which allows a recipient of a packet to identify the packet 4273 protection keys that are used to protect the packet. See 4274 [QUIC-TLS] for details. This bit is protected using header 4275 protection (see Section 5.4 of [QUIC-TLS]). 4277 Packet Number Length (P): The least significant two bits (those with 4278 a mask of 0x03) of byte 0 contain the length of the packet number, 4279 encoded as an unsigned, two-bit integer that is one less than the 4280 length of the packet number field in bytes. That is, the length 4281 of the packet number field is the value of this field, plus one. 4283 These bits are protected using header protection (see Section 5.4 4284 of [QUIC-TLS]). 4286 Destination Connection ID: The Destination Connection ID is a 4287 connection ID that is chosen by the intended recipient of the 4288 packet. See Section 5.1 for more details. 4290 Packet Number: The packet number field is 1 to 4 bytes long. The 4291 packet number has confidentiality protection separate from packet 4292 protection, as described in Section 5.4 of [QUIC-TLS]. The length 4293 of the packet number field is encoded in Packet Number Length 4294 field. See Section 17.1 for details. 4296 Protected Payload: Packets with a short header always include a 4297 1-RTT protected payload. 4299 The header form bit and the connection ID field of a short header 4300 packet are version-independent. The remaining fields are specific to 4301 the selected QUIC version. See [QUIC-INVARIANTS] for details on how 4302 packets from different versions of QUIC are interpreted. 4304 18. Transport Parameter Encoding 4306 The format of the transport parameters is the TransportParameters 4307 struct from Figure 16. This is described using the presentation 4308 language from Section 3 of [TLS13]. 4310 uint32 QuicVersion; 4312 enum { 4313 original_connection_id(0), 4314 idle_timeout(1), 4315 stateless_reset_token(2), 4316 max_packet_size(3), 4317 initial_max_data(4), 4318 initial_max_stream_data_bidi_local(5), 4319 initial_max_stream_data_bidi_remote(6), 4320 initial_max_stream_data_uni(7), 4321 initial_max_streams_bidi(8), 4322 initial_max_streams_uni(9), 4323 ack_delay_exponent(10), 4324 max_ack_delay(11), 4325 disable_migration(12), 4326 preferred_address(13), 4327 (65535) 4328 } TransportParameterId; 4330 struct { 4331 TransportParameterId parameter; 4332 opaque value<0..2^16-1>; 4333 } TransportParameter; 4335 struct { 4336 select (Handshake.msg_type) { 4337 case client_hello: 4338 QuicVersion initial_version; 4340 case encrypted_extensions: 4341 QuicVersion negotiated_version; 4342 QuicVersion supported_versions<4..2^8-4>; 4343 }; 4344 TransportParameter parameters<0..2^16-1>; 4345 } TransportParameters; 4347 Figure 16: Definition of TransportParameters 4349 The "extension_data" field of the quic_transport_parameters extension 4350 defined in [QUIC-TLS] contains a TransportParameters value. TLS 4351 encoding rules are therefore used to describe the encoding of 4352 transport parameters. 4354 QUIC encodes transport parameters into a sequence of bytes, which are 4355 then included in the cryptographic handshake. 4357 18.1. Transport Parameter Definitions 4359 This section details the transport parameters defined in this 4360 document. 4362 Many transport parameters listed here have integer values. Those 4363 transport parameters that are identified as integers use a variable- 4364 length integer encoding (see Section 16) and have a default value of 4365 0 if the transport parameter is absent, unless otherwise stated. 4367 The following transport parameters are defined: 4369 original_connection_id (0x0000): The value of the Destination 4370 Connection ID field from the first Initial packet sent by the 4371 client. This transport parameter is only sent by a server. A 4372 server MUST include the original_connection_id transport parameter 4373 if it sent a Retry packet. 4375 idle_timeout (0x0001): The idle timeout is a value in seconds that 4376 is encoded as an integer, see (Section 10.2). If this parameter 4377 is absent or zero then the idle timeout is disabled. 4379 stateless_reset_token (0x0002): A stateless reset token is used in 4380 verifying a stateless reset, see Section 10.4. This parameter is 4381 a sequence of 16 bytes. This transport parameter is only sent by 4382 a server. 4384 max_packet_size (0x0003): The maximum packet size parameter is an 4385 integer value that limits the size of packets that the endpoint is 4386 willing to receive. This indicates that packets larger than this 4387 limit will be dropped. The default for this parameter is the 4388 maximum permitted UDP payload of 65527. Values below 1200 are 4389 invalid. This limit only applies to protected packets 4390 (Section 12.1). 4392 initial_max_data (0x0004): The initial maximum data parameter is an 4393 integer value that contains the initial value for the maximum 4394 amount of data that can be sent on the connection. This is 4395 equivalent to sending a MAX_DATA (Section 19.9) for the connection 4396 immediately after completing the handshake. 4398 initial_max_stream_data_bidi_local (0x0005): This parameter is an 4399 integer value specifying the initial flow control limit for 4400 locally-initiated bidirectional streams. This limit applies to 4401 newly created bidirectional streams opened by the endpoint that 4402 sends the transport parameter. In client transport parameters, 4403 this applies to streams with an identifier with the least 4404 significant two bits set to 0x0; in server transport parameters, 4405 this applies to streams with the least significant two bits set to 4406 0x1. 4408 initial_max_stream_data_bidi_remote (0x0006): This parameter is an 4409 integer value specifying the initial flow control limit for peer- 4410 initiated bidirectional streams. This limit applies to newly 4411 created bidirectional streams opened by the endpoint that receives 4412 the transport parameter. In client transport parameters, this 4413 applies to streams with an identifier with the least significant 4414 two bits set to 0x1; in server transport parameters, this applies 4415 to streams with the least significant two bits set to 0x0. 4417 initial_max_stream_data_uni (0x0007): This parameter is an integer 4418 value specifying the initial flow control limit for unidirectional 4419 streams. This limit applies to newly created unidirectional 4420 streams opened by the endpoint that receives the transport 4421 parameter. In client transport parameters, this applies to 4422 streams with an identifier with the least significant two bits set 4423 to 0x3; in server transport parameters, this applies to streams 4424 with the least significant two bits set to 0x2. 4426 initial_max_streams_bidi (0x0008): The initial maximum bidirectional 4427 streams parameter is an integer value that contains the initial 4428 maximum number of bidirectional streams the peer may initiate. If 4429 this parameter is absent or zero, the peer cannot open 4430 bidirectional streams until a MAX_STREAMS frame is sent. Setting 4431 this parameter is equivalent to sending a MAX_STREAMS 4432 (Section 19.11) of the corresponding type with the same value. 4434 initial_max_streams_uni (0x0009): The initial maximum unidirectional 4435 streams parameter is an integer value that contains the initial 4436 maximum number of unidirectional streams the peer may initiate. 4437 If this parameter is absent or zero, the peer cannot open 4438 unidirectional streams until a MAX_STREAMS frame is sent. Setting 4439 this parameter is equivalent to sending a MAX_STREAMS 4440 (Section 19.11) of the corresponding type with the same value. 4442 ack_delay_exponent (0x000a): The ACK delay exponent is an integer 4443 value indicating an exponent used to decode the ACK Delay field in 4444 the ACK frame (Section 19.3). If this value is absent, a default 4445 value of 3 is assumed (indicating a multiplier of 8). The default 4446 value is also used for ACK frames that are sent in Initial and 4447 Handshake packets. Values above 20 are invalid. 4449 max_ack_delay (0x000b): The maximum ACK delay is an integer value 4450 indicating the maximum amount of time in milliseconds by which the 4451 endpoint will delay sending acknowledgments. This value SHOULD 4452 include the receiver's expected delays in alarms firing. For 4453 example, if a receiver sets a timer for 5ms and alarms commonly 4454 fire up to 1ms late, then it should send a max_ack_delay of 6ms. 4455 If this value is absent, a default of 25 milliseconds is assumed. 4456 Values of 2^14 or greater are invalid. 4458 disable_migration (0x000c): The disable migration transport 4459 parameter is included if the endpoint does not support connection 4460 migration (Section 9). Peers of an endpoint that sets this 4461 transport parameter MUST NOT send any packets, including probing 4462 packets (Section 9.1), from a local address other than that used 4463 to perform the handshake. This parameter is a zero-length value. 4465 preferred_address (0x000d): The server's preferred address is used 4466 to effect a change in server address at the end of the handshake, 4467 as described in Section 9.6. The format of this transport 4468 parameter is the PreferredAddress struct shown in Figure 17. This 4469 transport parameter is only sent by a server. Servers MAY choose 4470 to only send a preferred address of one address family by sending 4471 an all-zero address and port (0.0.0.0:0 or ::.0) for the other 4472 family. 4474 struct { 4475 opaque ipv4Address[4]; 4476 uint16 ipv4Port; 4477 opaque ipv6Address[16]; 4478 uint16 ipv6Port; 4479 opaque connectionId<0..18>; 4480 opaque statelessResetToken[16]; 4481 } PreferredAddress; 4483 Figure 17: Preferred Address format 4485 If present, transport parameters that set initial flow control limits 4486 (initial_max_stream_data_bidi_local, 4487 initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) 4488 are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on 4489 every stream of the corresponding type immediately after opening. If 4490 the transport parameter is absent, streams of that type start with a 4491 flow control limit of 0. 4493 A client MUST NOT include an original connection ID, a stateless 4494 reset token, or a preferred address. A server MUST treat receipt of 4495 any of these transport parameters as a connection error of type 4496 TRANSPORT_PARAMETER_ERROR. 4498 19. Frame Types and Formats 4500 As described in Section 12.4, packets contain one or more frames. 4501 This section describes the format and semantics of the core QUIC 4502 frame types. 4504 19.1. PADDING Frame 4506 The PADDING frame (type=0x00) has no semantic value. PADDING frames 4507 can be used to increase the size of a packet. Padding can be used to 4508 increase an initial client packet to the minimum required size, or to 4509 provide protection against traffic analysis for protected packets. 4511 A PADDING frame has no content. That is, a PADDING frame consists of 4512 the single byte that identifies the frame as a PADDING frame. 4514 19.2. PING Frame 4516 Endpoints can use PING frames (type=0x01) to verify that their peers 4517 are still alive or to check reachability to the peer. The PING frame 4518 contains no additional fields. 4520 The receiver of a PING frame simply needs to acknowledge the packet 4521 containing this frame. 4523 The PING frame can be used to keep a connection alive when an 4524 application or application protocol wishes to prevent the connection 4525 from timing out. An application protocol SHOULD provide guidance 4526 about the conditions under which generating a PING is recommended. 4527 This guidance SHOULD indicate whether it is the client or the server 4528 that is expected to send the PING. Having both endpoints send PING 4529 frames without coordination can produce an excessive number of 4530 packets and poor performance. 4532 A connection will time out if no packets are sent or received for a 4533 period longer than the time specified in the idle_timeout transport 4534 parameter (see Section 10). However, state in middleboxes might time 4535 out earlier than that. Though REQ-5 in [RFC4787] recommends a 2 4536 minute timeout interval, experience shows that sending packets every 4537 15 to 30 seconds is necessary to prevent the majority of middleboxes 4538 from losing state for UDP flows. 4540 19.3. ACK Frames 4542 Receivers send ACK frames (types 0x02 and 0x03) to inform senders of 4543 packets they have received and processed. The ACK frame contains one 4544 or more ACK Ranges. ACK Ranges identify acknowledged packets. If 4545 the frame type is 0x03, ACK frames also contain the sum of QUIC 4546 packets with associated ECN marks received on the connection up until 4547 this point. QUIC implementations MUST properly handle both types 4548 and, if they have enabled ECN for packets they send, they SHOULD use 4549 the information in the ECN section to manage their congestion state. 4551 QUIC acknowledgements are irrevocable. Once acknowledged, a packet 4552 remains acknowledged, even if it does not appear in a future ACK 4553 frame. This is unlike TCP SACKs ([RFC2018]). 4555 It is expected that a sender will reuse the same packet number across 4556 different packet number spaces. ACK frames only acknowledge the 4557 packet numbers that were transmitted by the sender in the same packet 4558 number space of the packet that the ACK was received in. 4560 Version Negotiation and Retry packets cannot be acknowledged because 4561 they do not contain a packet number. Rather than relying on ACK 4562 frames, these packets are implicitly acknowledged by the next Initial 4563 packet sent by the client. 4565 An ACK frame is as follows: 4567 0 1 2 3 4568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4570 | Largest Acknowledged (i) ... 4571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4572 | ACK Delay (i) ... 4573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4574 | ACK Range Count (i) ... 4575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4576 | First ACK Range (i) ... 4577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4578 | ACK Ranges (*) ... 4579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4580 | [ECN Counts] ... 4581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4583 Figure 18: ACK Frame Format 4585 ACK frames contain the following fields: 4587 Largest Acknowledged: A variable-length integer representing the 4588 largest packet number the peer is acknowledging; this is usually 4589 the largest packet number that the peer has received prior to 4590 generating the ACK frame. Unlike the packet number in the QUIC 4591 long or short header, the value in an ACK frame is not truncated. 4593 ACK Delay: A variable-length integer including the time in 4594 microseconds that the largest acknowledged packet, as indicated in 4595 the Largest Acknowledged field, was received by this peer to when 4596 this ACK was sent. The value of the ACK Delay field is scaled by 4597 multiplying the encoded value by 2 to the power of the value of 4598 the "ack_delay_exponent" transport parameter set by the sender of 4599 the ACK frame. The "ack_delay_exponent" defaults to 3, or a 4600 multiplier of 8 (see Section 18.1). Scaling in this fashion 4601 allows for a larger range of values with a shorter encoding at the 4602 cost of lower resolution. 4604 ACK Range Count: A variable-length integer specifying the number of 4605 Gap and ACK Range fields in the frame. 4607 First ACK Range: A variable-length integer indicating the number of 4608 contiguous packets preceding the Largest Acknowledged that are 4609 being acknowledged. The First ACK Range is encoded as an ACK 4610 Range (see Section 19.3.1) starting from the Largest Acknowledged. 4611 That is, the smallest packet acknowledged in the range is 4612 determined by subtracting the First ACK Range value from the 4613 Largest Acknowledged. 4615 ACK Ranges: Contains additional ranges of packets which are 4616 alternately not acknowledged (Gap) and acknowledged (ACK Range), 4617 see Section 19.3.1. 4619 ECN Counts: The three ECN Counts, see Section 19.3.2. 4621 19.3.1. ACK Ranges 4623 The ACK Ranges field consists of alternating Gap and ACK Range values 4624 in descending packet number order. The number of Gap and ACK Range 4625 values is determined by the ACK Range Count field; one of each value 4626 is present for each value in the ACK Range Count field. 4628 ACK Ranges are structured as follows: 4630 0 1 2 3 4631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4633 | [Gap (i)] ... 4634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4635 | [ACK Range (i)] ... 4636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4637 | [Gap (i)] ... 4638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4639 | [ACK Range (i)] ... 4640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4641 ... 4642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4643 | [Gap (i)] ... 4644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4645 | [ACK Range (i)] ... 4646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4648 Figure 19: ACK Ranges 4650 The fields that form the ACK Ranges are: 4652 Gap (repeated): A variable-length integer indicating the number of 4653 contiguous unacknowledged packets preceding the packet number one 4654 lower than the smallest in the preceding ACK Range. 4656 ACK Range (repeated): A variable-length integer indicating the 4657 number of contiguous acknowledged packets preceding the largest 4658 packet number, as determined by the preceding Gap. 4660 Gap and ACK Range value use a relative integer encoding for 4661 efficiency. Though each encoded value is positive, the values are 4662 subtracted, so that each ACK Range describes progressively lower- 4663 numbered packets. 4665 Each ACK Range acknowledges a contiguous range of packets by 4666 indicating the number of acknowledged packets that precede the 4667 largest packet number in that range. A value of zero indicates that 4668 only the largest packet number is acknowledged. Larger ACK Range 4669 values indicate a larger range, with corresponding lower values for 4670 the smallest packet number in the range. Thus, given a largest 4671 packet number for the range, the smallest value is determined by the 4672 formula: 4674 smallest = largest - ack_range 4676 An ACK Range acknowledges all packets between the smallest packet 4677 number and the largest, inclusive. 4679 The largest value for an ACK Range is determined by cumulatively 4680 subtracting the size of all preceding ACK Ranges and Gaps. 4682 Each Gap indicates a range of packets that are not being 4683 acknowledged. The number of packets in the gap is one higher than 4684 the encoded value of the Gap field. 4686 The value of the Gap field establishes the largest packet number 4687 value for the subsequent ACK Range using the following formula: 4689 largest = previous_smallest - gap - 2 4691 If any computed packet number is negative, an endpoint MUST generate 4692 a connection error of type FRAME_ENCODING_ERROR indicating an error 4693 in an ACK frame. 4695 19.3.2. ECN Counts 4697 The ACK frame uses the least significant bit (that is, type 0x03) to 4698 indicate ECN feedback and report receipt of QUIC packets with 4699 associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP 4700 header. ECN Counts are only present when the ACK frame type is 0x03. 4702 ECN Counts are only parsed when the ACK frame type is 0x03. There 4703 are 3 ECN counts, as follows: 4705 0 1 2 3 4706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4708 | ECT(0) Count (i) ... 4709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4710 | ECT(1) Count (i) ... 4711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4712 | ECN-CE Count (i) ... 4713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4715 The three ECN Counts are: 4717 ECT(0) Count: A variable-length integer representing the total 4718 number packets received with the ECT(0) codepoint. 4720 ECT(1) Count: A variable-length integer representing the total 4721 number packets received with the ECT(1) codepoint. 4723 CE Count: A variable-length integer representing the total number 4724 packets received with the CE codepoint. 4726 ECN counts are maintained separately for each packet number space. 4728 19.4. RESET_STREAM Frame 4730 An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly 4731 terminate a stream. 4733 After sending a RESET_STREAM, an endpoint ceases transmission and 4734 retransmission of STREAM frames on the identified stream. A receiver 4735 of RESET_STREAM can discard any data that it already received on that 4736 stream. 4738 An endpoint that receives a RESET_STREAM frame for a send-only stream 4739 MUST terminate the connection with error STREAM_STATE_ERROR. 4741 The RESET_STREAM frame is as follows: 4743 0 1 2 3 4744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4746 | Stream ID (i) ... 4747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4748 | Application Error Code (16) | 4749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4750 | Final Size (i) ... 4751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4753 RESET_STREAM frames contain the following fields: 4755 Stream ID: A variable-length integer encoding of the Stream ID of 4756 the stream being terminated. 4758 Application Protocol Error Code: A 16-bit application protocol error 4759 code (see Section 20.1) which indicates why the stream is being 4760 closed. 4762 Final Size: A variable-length integer indicating the final size of 4763 the stream by the RESET_STREAM sender, in unit of bytes. 4765 19.5. STOP_SENDING Frame 4767 An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that 4768 incoming data is being discarded on receipt at application request. 4769 STOP_SENDING requests that a peer cease transmission on a stream. 4771 A STOP_SENDING frame can be sent for streams in the Recv or Size 4772 Known states (see Section 3.1). Receiving a STOP_SENDING frame for a 4773 locally-initiated stream that has not yet been created MUST be 4774 treated as a connection error of type STREAM_STATE_ERROR. An 4775 endpoint that receives a STOP_SENDING frame for a receive-only stream 4776 MUST terminate the connection with error STREAM_STATE_ERROR. 4778 The STOP_SENDING frame is as follows: 4780 0 1 2 3 4781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4783 | Stream ID (i) ... 4784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4785 | Application Error Code (16) | 4786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4788 STOP_SENDING frames contain the following fields: 4790 Stream ID: A variable-length integer carrying the Stream ID of the 4791 stream being ignored. 4793 Application Error Code: A 16-bit, application-specified reason the 4794 sender is ignoring the stream (see Section 20.1). 4796 19.6. CRYPTO Frame 4798 The CRYPTO frame (type=0x06) is used to transmit cryptographic 4799 handshake messages. It can be sent in all packet types. The CRYPTO 4800 frame offers the cryptographic protocol an in-order stream of bytes. 4801 CRYPTO frames are functionally identical to STREAM frames, except 4802 that they do not bear a stream identifier; they are not flow 4803 controlled; and they do not carry markers for optional offset, 4804 optional length, and the end of the stream. 4806 The CRYPTO frame is as follows: 4808 0 1 2 3 4809 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4811 | Offset (i) ... 4812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4813 | Length (i) ... 4814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4815 | Crypto Data (*) ... 4816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4818 Figure 20: CRYPTO Frame Format 4820 CRYPTO frames contain the following fields: 4822 Offset: A variable-length integer specifying the byte offset in the 4823 stream for the data in this CRYPTO frame. 4825 Length: A variable-length integer specifying the length of the 4826 Crypto Data field in this CRYPTO frame. 4828 Crypto Data: The cryptographic message data. 4830 There is a separate flow of cryptographic handshake data in each 4831 encryption level, each of which starts at an offset of 0. This 4832 implies that each encryption level is treated as a separate CRYPTO 4833 stream of data. 4835 Unlike STREAM frames, which include a Stream ID indicating to which 4836 stream the data belongs, the CRYPTO frame carries data for a single 4837 stream per encryption level. The stream does not have an explicit 4838 end, so CRYPTO frames do not have a FIN bit. 4840 19.7. NEW_TOKEN Frame 4842 A server sends a NEW_TOKEN frame (type=0x07) to provide the client 4843 with a token to send in the header of an Initial packet for a future 4844 connection. 4846 The NEW_TOKEN frame is as follows: 4848 0 1 2 3 4849 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4851 | Token Length (i) ... 4852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4853 | Token (*) ... 4854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4856 NEW_TOKEN frames contain the following fields: 4858 Token Length: A variable-length integer specifying the length of the 4859 token in bytes. 4861 Token: An opaque blob that the client may use with a future Initial 4862 packet. 4864 19.8. STREAM Frames 4866 STREAM frames implicitly create a stream and carry stream data. The 4867 STREAM frame takes the form 0b00001XXX (or the set of values from 4868 0x08 to 0x0f). The value of the three low-order bits of the frame 4869 type determine the fields that are present in the frame. 4871 o The OFF bit (0x04) in the frame type is set to indicate that there 4872 is an Offset field present. When set to 1, the Offset field is 4873 present. When set to 0, the Offset field is absent and the Stream 4874 Data starts at an offset of 0 (that is, the frame contains the 4875 first bytes of the stream, or the end of a stream that includes no 4876 data). 4878 o The LEN bit (0x02) in the frame type is set to indicate that there 4879 is a Length field present. If this bit is set to 0, the Length 4880 field is absent and the Stream Data field extends to the end of 4881 the packet. If this bit is set to 1, the Length field is present. 4883 o The FIN bit (0x01) of the frame type is set only on frames that 4884 contain the final size of the stream. Setting this bit indicates 4885 that the frame marks the end of the stream. 4887 An endpoint that receives a STREAM frame for a send-only stream MUST 4888 terminate the connection with error STREAM_STATE_ERROR. 4890 The STREAM frames are as follows: 4892 0 1 2 3 4893 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4895 | Stream ID (i) ... 4896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4897 | [Offset (i)] ... 4898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4899 | [Length (i)] ... 4900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4901 | Stream Data (*) ... 4902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4904 Figure 21: STREAM Frame Format 4906 STREAM frames contain the following fields: 4908 Stream ID: A variable-length integer indicating the stream ID of the 4909 stream (see Section 2.1). 4911 Offset: A variable-length integer specifying the byte offset in the 4912 stream for the data in this STREAM frame. This field is present 4913 when the OFF bit is set to 1. When the Offset field is absent, 4914 the offset is 0. 4916 Length: A variable-length integer specifying the length of the 4917 Stream Data field in this STREAM frame. This field is present 4918 when the LEN bit is set to 1. When the LEN bit is set to 0, the 4919 Stream Data field consumes all the remaining bytes in the packet. 4921 Stream Data: The bytes from the designated stream to be delivered. 4923 When a Stream Data field has a length of 0, the offset in the STREAM 4924 frame is the offset of the next byte that would be sent. 4926 The first byte in the stream has an offset of 0. The largest offset 4927 delivered on a stream - the sum of the offset and data length - MUST 4928 be less than 2^62. 4930 19.9. MAX_DATA Frame 4932 The MAX_DATA frame (type=0x10) is used in flow control to inform the 4933 peer of the maximum amount of data that can be sent on the connection 4934 as a whole. 4936 The MAX_DATA frame is as follows: 4938 0 1 2 3 4939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4941 | Maximum Data (i) ... 4942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4944 MAX_DATA frames contain the following fields: 4946 Maximum Data: A variable-length integer indicating the maximum 4947 amount of data that can be sent on the entire connection, in units 4948 of bytes. 4950 All data sent in STREAM frames counts toward this limit. The sum of 4951 the largest received offsets on all streams - including streams in 4952 terminal states - MUST NOT exceed the value advertised by a receiver. 4953 An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR 4954 error if it receives more data than the maximum data value that it 4955 has sent, unless this is a result of a change in the initial limits 4956 (see Section 7.3.1). 4958 19.10. MAX_STREAM_DATA Frame 4960 The MAX_STREAM_DATA frame (type=0x11) is used in flow control to 4961 inform a peer of the maximum amount of data that can be sent on a 4962 stream. 4964 A MAX_STREAM_DATA frame can be sent for streams in the Recv state 4965 (see Section 3.1). Receiving a MAX_STREAM_DATA frame for a locally- 4966 initiated stream that has not yet been created MUST be treated as a 4967 connection error of type STREAM_STATE_ERROR. An endpoint that 4968 receives a MAX_STREAM_DATA frame for a receive-only stream MUST 4969 terminate the connection with error STREAM_STATE_ERROR. 4971 The MAX_STREAM_DATA frame is as follows: 4973 0 1 2 3 4974 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4976 | Stream ID (i) ... 4977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4978 | Maximum Stream Data (i) ... 4979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4981 MAX_STREAM_DATA frames contain the following fields: 4983 Stream ID: The stream ID of the stream that is affected encoded as a 4984 variable-length integer. 4986 Maximum Stream Data: A variable-length integer indicating the 4987 maximum amount of data that can be sent on the identified stream, 4988 in units of bytes. 4990 When counting data toward this limit, an endpoint accounts for the 4991 largest received offset of data that is sent or received on the 4992 stream. Loss or reordering can mean that the largest received offset 4993 on a stream can be greater than the total size of data received on 4994 that stream. Receiving STREAM frames might not increase the largest 4995 received offset. 4997 The data sent on a stream MUST NOT exceed the largest maximum stream 4998 data value advertised by the receiver. An endpoint MUST terminate a 4999 connection with a FLOW_CONTROL_ERROR error if it receives more data 5000 than the largest maximum stream data that it has sent for the 5001 affected stream, unless this is a result of a change in the initial 5002 limits (see Section 7.3.1). 5004 19.11. MAX_STREAMS Frames 5006 The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the 5007 cumulative number of streams of a given type it is permitted to open. 5008 A MAX_STREAMS frame with a type of 0x12 applies to bidirectional 5009 streams, and a MAX_STREAMS frame with a type of 0x13 applies to 5010 unidirectional streams. 5012 The MAX_STREAMS frames are as follows: 5014 0 1 2 3 5015 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5017 | Maximum Streams (i) ... 5018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5020 MAX_STREAMS frames contain the following fields: 5022 Maximum Streams: A count of the cumulative number of streams of the 5023 corresponding type that can be opened over the lifetime of the 5024 connection. 5026 Loss or reordering can cause a MAX_STREAMS frame to be received which 5027 states a lower stream limit than an endpoint has previously received. 5028 MAX_STREAMS frames which do not increase the stream limit MUST be 5029 ignored. 5031 An endpoint MUST NOT open more streams than permitted by the current 5032 stream limit set by its peer. For instance, a server that receives a 5033 unidirectional stream limit of 3 is permitted to open stream 3, 7, 5034 and 11, but not stream 15. An endpoint MUST terminate a connection 5035 with a STREAM_LIMIT_ERROR error if a peer opens more streams than was 5036 permitted. 5038 Note that these frames (and the corresponding transport parameters) 5039 do not describe the number of streams that can be opened 5040 concurrently. The limit includes streams that have been closed as 5041 well as those that are open. 5043 19.12. DATA_BLOCKED Frame 5045 A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes 5046 to send data, but is unable to due to connection-level flow control 5047 (see Section 4). DATA_BLOCKED frames can be used as input to tuning 5048 of flow control algorithms (see Section 4.2). 5050 The DATA_BLOCKED frame is as follows: 5052 0 1 2 3 5053 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5055 | Data Limit (i) ... 5056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5058 DATA_BLOCKED frames contain the following fields: 5060 Data Limit: A variable-length integer indicating the connection- 5061 level limit at which blocking occurred. 5063 19.13. STREAM_DATA_BLOCKED Frame 5065 A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it 5066 wishes to send data, but is unable to due to stream-level flow 5067 control. This frame is analogous to DATA_BLOCKED (Section 19.12). 5069 An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only 5070 stream MUST terminate the connection with error STREAM_STATE_ERROR. 5072 The STREAM_DATA_BLOCKED frame is as follows: 5074 0 1 2 3 5075 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5077 | Stream ID (i) ... 5078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5079 | Stream Data Limit (i) ... 5080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5082 STREAM_DATA_BLOCKED frames contain the following fields: 5084 Stream ID: A variable-length integer indicating the stream which is 5085 flow control blocked. 5087 Stream Data Limit: A variable-length integer indicating the offset 5088 of the stream at which the blocking occurred. 5090 19.14. STREAMS_BLOCKED Frames 5092 A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when 5093 it wishes to open a stream, but is unable to due to the maximum 5094 stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED 5095 frame of type 0x16 is used to indicate reaching the bidirectional 5096 stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates 5097 reaching the unidirectional stream limit. 5099 A STREAMS_BLOCKED frame does not open the stream, but informs the 5100 peer that a new stream was needed and the stream limit prevented the 5101 creation of the stream. 5103 The STREAMS_BLOCKED frames are as follows: 5105 0 1 2 3 5106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5108 | Stream Limit (i) ... 5109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5110 STREAMS_BLOCKED frames contain the following fields: 5112 Stream Limit: A variable-length integer indicating the stream limit 5113 at the time the frame was sent. 5115 19.15. NEW_CONNECTION_ID Frame 5117 An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide 5118 its peer with alternative connection IDs that can be used to break 5119 linkability when migrating connections (see Section 9.5). 5121 The NEW_CONNECTION_ID frame is as follows: 5123 0 1 2 3 5124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5126 | Sequence Number (i) ... 5127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5128 | Length (8) | | 5129 +-+-+-+-+-+-+-+-+ Connection ID (32..144) + 5130 | ... 5131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5132 | | 5133 + + 5134 | | 5135 + Stateless Reset Token (128) + 5136 | | 5137 + + 5138 | | 5139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5141 NEW_CONNECTION_ID frames contain the following fields: 5143 Sequence Number: The sequence number assigned to the connection ID 5144 by the sender. See Section 5.1.1. 5146 Length: An 8-bit unsigned integer containing the length of the 5147 connection ID. Values less than 4 and greater than 18 are invalid 5148 and MUST be treated as a connection error of type 5149 PROTOCOL_VIOLATION. 5151 Connection ID: A connection ID of the specified length. 5153 Stateless Reset Token: A 128-bit value that will be used for a 5154 stateless reset when the associated connection ID is used (see 5155 Section 10.4). 5157 An endpoint MUST NOT send this frame if it currently requires that 5158 its peer send packets with a zero-length Destination Connection ID. 5159 Changing the length of a connection ID to or from zero-length makes 5160 it difficult to identify when the value of the connection ID changed. 5161 An endpoint that is sending packets with a zero-length Destination 5162 Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a 5163 connection error of type PROTOCOL_VIOLATION. 5165 Transmission errors, timeouts and retransmissions might cause the 5166 same NEW_CONNECTION_ID frame to be received multiple times. Receipt 5167 of the same frame multiple times MUST NOT be treated as a connection 5168 error. A receiver can use the sequence number supplied in the 5169 NEW_CONNECTION_ID frame to identify new connection IDs from old ones. 5171 If an endpoint receives a NEW_CONNECTION_ID frame that repeats a 5172 previously issued connection ID with a different Stateless Reset 5173 Token or a different sequence number, or if a sequence number is used 5174 for different connection IDs, the endpoint MAY treat that receipt as 5175 a connection error of type PROTOCOL_VIOLATION. 5177 19.16. RETIRE_CONNECTION_ID Frame 5179 An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to 5180 indicate that it will no longer use a connection ID that was issued 5181 by its peer. This may include the connection ID provided during the 5182 handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a 5183 request to the peer to send additional connection IDs for future use 5184 (see Section 5.1). New connection IDs can be delivered to a peer 5185 using the NEW_CONNECTION_ID frame (Section 19.15). 5187 Retiring a connection ID invalidates the stateless reset token 5188 associated with that connection ID. 5190 The RETIRE_CONNECTION_ID frame is as follows: 5192 0 1 2 3 5193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5195 | Sequence Number (i) ... 5196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5198 RETIRE_CONNECTION_ID frames contain the following fields: 5200 Sequence Number: The sequence number of the connection ID being 5201 retired. See Section 5.1.2. 5203 Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number 5204 greater than any previously sent to the peer MAY be treated as a 5205 connection error of type PROTOCOL_VIOLATION. 5207 An endpoint cannot send this frame if it was provided with a zero- 5208 length connection ID by its peer. An endpoint that provides a zero- 5209 length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID 5210 frame as a connection error of type PROTOCOL_VIOLATION. 5212 19.17. PATH_CHALLENGE Frame 5214 Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check 5215 reachability to the peer and for path validation during connection 5216 migration. 5218 The PATH_CHALLENGE frames are as follows: 5220 0 1 2 3 5221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5223 | | 5224 + Data (64) + 5225 | | 5226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5228 PATH_CHALLENGE frames contain the following fields: 5230 Data: This 8-byte field contains arbitrary data. 5232 A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is 5233 sufficient to ensure that it is easier to receive the packet than it 5234 is to guess the value correctly. 5236 The recipient of this frame MUST generate a PATH_RESPONSE frame 5237 (Section 19.18) containing the same Data. 5239 19.18. PATH_RESPONSE Frame 5241 The PATH_RESPONSE frame (type=0x1b) is sent in response to a 5242 PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE 5243 frame (Section 19.17). 5245 If the content of a PATH_RESPONSE frame does not match the content of 5246 a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint 5247 MAY generate a connection error of type PROTOCOL_VIOLATION. 5249 19.19. CONNECTION_CLOSE Frames 5251 An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to 5252 notify its peer that the connection is being closed. The 5253 CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors 5254 at only the QUIC layer, or the absence of errors (with the NO_ERROR 5255 code). The CONNECTION_CLOSE frame with a type of 0x1d is used to 5256 signal an error with the application that uses QUIC. 5258 If there are open streams that haven't been explicitly closed, they 5259 are implicitly closed when the connection is closed. 5261 The CONNECTION_CLOSE frames are as follows: 5263 0 1 2 3 5264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 5265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5266 | Error Code (16) | [ Frame Type (i) ] ... 5267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5268 | Reason Phrase Length (i) ... 5269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5270 | Reason Phrase (*) ... 5271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5273 CONNECTION_CLOSE frames contain the following fields: 5275 Error Code: A 16-bit error code which indicates the reason for 5276 closing this connection. A CONNECTION_CLOSE frame of type 0x1c 5277 uses codes from the space defined in Section 20. A 5278 CONNECTION_CLOSE frame of type 0x1d uses codes from the 5279 application protocol error code space, see Section 20.1 5281 Frame Type: A variable-length integer encoding the type of frame 5282 that triggered the error. A value of 0 (equivalent to the mention 5283 of the PADDING frame) is used when the frame type is unknown. The 5284 application-specific variant of CONNECTION_CLOSE (type 0x1d) does 5285 not include this field. 5287 Reason Phrase Length: A variable-length integer specifying the 5288 length of the reason phrase in bytes. Because a CONNECTION_CLOSE 5289 frame cannot be split between packets, any limits on packet size 5290 will also limit the space available for a reason phrase. 5292 Reason Phrase: A human-readable explanation for why the connection 5293 was closed. This can be zero length if the sender chooses to not 5294 give details beyond the Error Code. This SHOULD be a UTF-8 5295 encoded string [RFC3629]. 5297 19.20. Extension Frames 5299 QUIC frames do not use a self-describing encoding. An endpoint 5300 therefore needs to understand the syntax of all frames before it can 5301 successfully process a packet. This allows for efficient encoding of 5302 frames, but it means that an endpoint cannot send a frame of a type 5303 that is unknown to its peer. 5305 An extension to QUIC that wishes to use a new type of frame MUST 5306 first ensure that a peer is able to understand the frame. An 5307 endpoint can use a transport parameter to signal its willingness to 5308 receive one or more extension frame types with the one transport 5309 parameter. 5311 Extension frames MUST be congestion controlled and MUST cause an ACK 5312 frame to be sent. The exception is extension frames that replace or 5313 supplement the ACK frame. Extension frames are not included in flow 5314 control unless specified in the extension. 5316 An IANA registry is used to manage the assignment of frame types, see 5317 Section 22.2. 5319 20. Transport Error Codes 5321 QUIC error codes are 16-bit unsigned integers. 5323 This section lists the defined QUIC transport error codes that may be 5324 used in a CONNECTION_CLOSE frame. These errors apply to the entire 5325 connection. 5327 NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to 5328 signal that the connection is being closed abruptly in the absence 5329 of any error. 5331 INTERNAL_ERROR (0x1): The endpoint encountered an internal error and 5332 cannot continue with the connection. 5334 SERVER_BUSY (0x2): The server is currently busy and does not accept 5335 any new connections. 5337 FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it 5338 permitted in its advertised data limits (see Section 4). 5340 STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream 5341 identifier that exceeded its advertised stream limit for the 5342 corresponding stream type. 5344 STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream 5345 that was not in a state that permitted that frame (see Section 3). 5347 FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame 5348 containing data that exceeded the previously established final 5349 size. Or an endpoint received a STREAM frame or a RESET_STREAM 5350 frame containing a final size that was lower than the size of 5351 stream data that was already received. Or an endpoint received a 5352 STREAM frame or a RESET_STREAM frame containing a different final 5353 size to the one already established. 5355 FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was 5356 badly formatted. For instance, a frame of an unknown type, or an 5357 ACK frame that has more acknowledgment ranges than the remainder 5358 of the packet could carry. 5360 TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport 5361 parameters that were badly formatted, included an invalid value, 5362 was absent even though it is mandatory, was present though it is 5363 forbidden, or is otherwise in error. 5365 VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport 5366 parameters that contained version negotiation parameters that 5367 disagreed with the version negotiation that it performed. This 5368 error code indicates a potential version downgrade attack. 5370 PROTOCOL_VIOLATION (0xA): An endpoint detected an error with 5371 protocol compliance that was not covered by more specific error 5372 codes. 5374 INVALID_MIGRATION (0xC): A peer has migrated to a different network 5375 when the endpoint had disabled migration. 5377 CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range 5378 of 256 values is reserved for carrying error codes specific to the 5379 cryptographic handshake that is used. Codes for errors occurring 5380 when TLS is used for the crypto handshake are described in 5381 Section 4.8 of [QUIC-TLS]. 5383 See Section 22.3 for details of registering new error codes. 5385 20.1. Application Protocol Error Codes 5387 Application protocol error codes are 16-bit unsigned integers, but 5388 the management of application error codes are left to application 5389 protocols. Application protocol error codes are used for the 5390 RESET_STREAM frame (Section 19.4) and the CONNECTION_CLOSE frame with 5391 a type of 0x1d (Section 19.19). 5393 21. Security Considerations 5395 21.1. Handshake Denial of Service 5397 As an encrypted and authenticated transport QUIC provides a range of 5398 protections against denial of service. Once the cryptographic 5399 handshake is complete, QUIC endpoints discard most packets that are 5400 not authenticated, greatly limiting the ability of an attacker to 5401 interfere with existing connections. 5403 Once a connection is established QUIC endpoints might accept some 5404 unauthenticated ICMP packets (see Section 14.2), but the use of these 5405 packets is extremely limited. The only other type of packet that an 5406 endpoint might accept is a stateless reset (Section 10.4) which 5407 relies on the token being kept secret until it is used. 5409 During the creation of a connection, QUIC only provides protection 5410 against attack from off the network path. All QUIC packets contain 5411 proof that the recipient saw a preceding packet from its peer. 5413 The first mechanism used is the source and destination connection 5414 IDs, which are required to match those set by a peer. Except for an 5415 Initial and stateless reset packets, an endpoint only accepts packets 5416 that include a destination connection that matches a connection ID 5417 the endpoint previously chose. This is the only protection offered 5418 for Version Negotiation packets. 5420 The destination connection ID in an Initial packet is selected by a 5421 client to be unpredictable, which serves an additional purpose. The 5422 packets that carry the cryptographic handshake are protected with a 5423 key that is derived from this connection ID and salt specific to the 5424 QUIC version. This allows endpoints to use the same process for 5425 authenticating packets that they receive as they use after the 5426 cryptographic handshake completes. Packets that cannot be 5427 authenticated are discarded. Protecting packets in this fashion 5428 provides a strong assurance that the sender of the packet saw the 5429 Initial packet and understood it. 5431 These protections are not intended to be effective against an 5432 attacker that is able to receive QUIC packets prior to the connection 5433 being established. Such an attacker can potentially send packets 5434 that will be accepted by QUIC endpoints. This version of QUIC 5435 attempts to detect this sort of attack, but it expects that endpoints 5436 will fail to establish a connection rather than recovering. For the 5437 most part, the cryptographic handshake protocol [QUIC-TLS] is 5438 responsible for detecting tampering during the handshake, though 5439 additional validation is required for version negotiation (see 5440 Section 7.3.3). 5442 Endpoints are permitted to use other methods to detect and attempt to 5443 recover from interference with the handshake. Invalid packets may be 5444 identified and discarded using other methods, but no specific method 5445 is mandated in this document. 5447 21.2. Amplification Attack 5449 An attacker might be able to receive an address validation token 5450 (Section 8) from a server and then release the IP address it used to 5451 acquire that token. At a later time, the attacker may initiate a 5452 0-RTT connection with a server by spoofing this same address, which 5453 might now address a different (victim) endpoint. The attacker can 5454 thus potentially cause the server to send an initial congestion 5455 window's worth of data towards the victim. 5457 Servers SHOULD provide mitigations for this attack by limiting the 5458 usage and lifetime of address validation tokens (see Section 8.1.2). 5460 21.3. Optimistic ACK Attack 5462 An endpoint that acknowledges packets it has not received might cause 5463 a congestion controller to permit sending at rates beyond what the 5464 network supports. An endpoint MAY skip packet numbers when sending 5465 packets to detect this behavior. An endpoint can then immediately 5466 close the connection with a connection error of type 5467 PROTOCOL_VIOLATION (see Section 10.3). 5469 21.4. Slowloris Attacks 5471 The attacks commonly known as Slowloris [SLOWLORIS] try to keep many 5472 connections to the target endpoint open and hold them open as long as 5473 possible. These attacks can be executed against a QUIC endpoint by 5474 generating the minimum amount of activity necessary to avoid being 5475 closed for inactivity. This might involve sending small amounts of 5476 data, gradually opening flow control windows in order to control the 5477 sender rate, or manufacturing ACK frames that simulate a high loss 5478 rate. 5480 QUIC deployments SHOULD provide mitigations for the Slowloris 5481 attacks, such as increasing the maximum number of clients the server 5482 will allow, limiting the number of connections a single IP address is 5483 allowed to make, imposing restrictions on the minimum transfer speed 5484 a connection is allowed to have, and restricting the length of time 5485 an endpoint is allowed to stay connected. 5487 21.5. Stream Fragmentation and Reassembly Attacks 5489 An adversarial sender might intentionally send fragments of stream 5490 data in order to cause disproportionate receive buffer memory 5491 commitment and/or creation of a large and inefficient data structure. 5493 An adversarial receiver might intentionally not acknowledge packets 5494 containing stream data in order to force the sender to store the 5495 unacknowledged stream data for retransmission. 5497 The attack on receivers is mitigated if flow control windows 5498 correspond to available memory. However, some receivers will over- 5499 commit memory and advertise flow control offsets in the aggregate 5500 that exceed actual available memory. The over-commitment strategy 5501 can lead to better performance when endpoints are well behaved, but 5502 renders endpoints vulnerable to the stream fragmentation attack. 5504 QUIC deployments SHOULD provide mitigations against stream 5505 fragmentation attacks. Mitigations could consist of avoiding over- 5506 committing memory, limiting the size of tracking data structures, 5507 delaying reassembly of STREAM frames, implementing heuristics based 5508 on the age and duration of reassembly holes, or some combination. 5510 21.6. Stream Commitment Attack 5512 An adversarial endpoint can open lots of streams, exhausting state on 5513 an endpoint. The adversarial endpoint could repeat the process on a 5514 large number of connections, in a manner similar to SYN flooding 5515 attacks in TCP. 5517 Normally, clients will open streams sequentially, as explained in 5518 Section 2.1. However, when several streams are initiated at short 5519 intervals, transmission error may cause STREAM DATA frames opening 5520 streams to be received out of sequence. A receiver is obligated to 5521 open intervening streams if a higher-numbered stream ID is received. 5522 Thus, on a new connection, opening stream 2000001 opens 1 million 5523 streams, as required by the specification. 5525 The number of active streams is limited by the concurrent stream 5526 limit transport parameter, as explained in Section 4.5. If chosen 5527 judiciously, this limit mitigates the effect of the stream commitment 5528 attack. However, setting the limit too low could affect performance 5529 when applications expect to open large number of streams. 5531 21.7. Explicit Congestion Notification Attacks 5533 An on-path attacker could manipulate the value of ECN codepoints in 5534 the IP header to influence the sender's rate. [RFC3168] discusses 5535 manipulations and their effects in more detail. 5537 An on-the-side attacker can duplicate and send packets with modified 5538 ECN codepoints to affect the sender's rate. If duplicate packets are 5539 discarded by a receiver, an off-path attacker will need to race the 5540 duplicate packet against the original to be successful in this 5541 attack. Therefore, QUIC receivers ignore ECN codepoints set in 5542 duplicate packets (see Section 13.3). 5544 21.8. Stateless Reset Oracle 5546 Stateless resets create a possible denial of service attack analogous 5547 to a TCP reset injection. This attack is possible if an attacker is 5548 able to cause a stateless reset token to be generated for a 5549 connection with a selected connection ID. An attacker that can cause 5550 this token to be generated can reset an active connection with the 5551 same connection ID. 5553 If a packet can be routed to different instances that share a static 5554 key, for example by changing an IP address or port, then an attacker 5555 can cause the server to send a stateless reset. To defend against 5556 this style of denial service, endpoints that share a static key for 5557 stateless reset (see Section 10.4.2) MUST be arranged so that packets 5558 with a given connection ID always arrive at an instance that has 5559 connection state, unless that connection is no longer active. 5561 In the case of a cluster that uses dynamic load balancing, it's 5562 possible that a change in load balancer configuration could happen 5563 while an active instance retains connection state; even if an 5564 instance retains connection state, the change in routing and 5565 resulting stateless reset will result in the connection being 5566 terminated. If there is no chance in the packet being routed to the 5567 correct instance, it is better to send a stateless reset than wait 5568 for connections to time out. However, this is acceptable only if the 5569 routing cannot be influenced by an attacker. 5571 22. IANA Considerations 5573 22.1. QUIC Transport Parameter Registry 5575 IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" 5576 under a "QUIC Protocol" heading. 5578 The "QUIC Transport Parameters" registry governs a 16-bit space. 5579 This space is split into two spaces that are governed by different 5580 policies. Values with the first byte in the range 0x00 to 0xfe (in 5581 hexadecimal) are assigned via the Specification Required policy 5582 [RFC8126]. Values with the first byte 0xff are reserved for Private 5583 Use [RFC8126]. 5585 Registrations MUST include the following fields: 5587 Value: The numeric value of the assignment (registrations will be 5588 between 0x0000 and 0xfeff). 5590 Parameter Name: A short mnemonic for the parameter. 5592 Specification: A reference to a publicly available specification for 5593 the value. 5595 The nominated expert(s) verify that a specification exists and is 5596 readily accessible. Expert(s) are encouraged to be biased towards 5597 approving registrations unless they are abusive, frivolous, or 5598 actively harmful (not merely aesthetically displeasing, or 5599 architecturally dubious). 5601 The initial contents of this registry are shown in Table 6. 5603 +--------+-------------------------------------+---------------+ 5604 | Value | Parameter Name | Specification | 5605 +--------+-------------------------------------+---------------+ 5606 | 0x0000 | original_connection_id | Section 18.1 | 5607 | | | | 5608 | 0x0001 | idle_timeout | Section 18.1 | 5609 | | | | 5610 | 0x0002 | stateless_reset_token | Section 18.1 | 5611 | | | | 5612 | 0x0003 | max_packet_size | Section 18.1 | 5613 | | | | 5614 | 0x0004 | initial_max_data | Section 18.1 | 5615 | | | | 5616 | 0x0005 | initial_max_stream_data_bidi_local | Section 18.1 | 5617 | | | | 5618 | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.1 | 5619 | | | | 5620 | 0x0007 | initial_max_stream_data_uni | Section 18.1 | 5621 | | | | 5622 | 0x0008 | initial_max_streams_bidi | Section 18.1 | 5623 | | | | 5624 | 0x0009 | initial_max_streams_uni | Section 18.1 | 5625 | | | | 5626 | 0x000a | ack_delay_exponent | Section 18.1 | 5627 | | | | 5628 | 0x000b | max_ack_delay | Section 18.1 | 5629 | | | | 5630 | 0x000c | disable_migration | Section 18.1 | 5631 | | | | 5632 | 0x000d | preferred_address | Section 18.1 | 5633 +--------+-------------------------------------+---------------+ 5635 Table 6: Initial QUIC Transport Parameters Entries 5637 22.2. QUIC Frame Type Registry 5639 IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a 5640 "QUIC Protocol" heading. 5642 The "QUIC Frame Types" registry governs a 62-bit space. This space 5643 is split into three spaces that are governed by different policies. 5644 Values between 0x00 and 0x3f (in hexadecimal) are assigned via the 5645 Standards Action or IESG Review policies [RFC8126]. Values from 0x40 5646 to 0x3fff operate on the Specification Required policy [RFC8126]. 5647 All other values are assigned to Private Use [RFC8126]. 5649 Registrations MUST include the following fields: 5651 Value: The numeric value of the assignment (registrations will be 5652 between 0x00 and 0x3fff). A range of values MAY be assigned. 5654 Frame Name: A short mnemonic for the frame type. 5656 Specification: A reference to a publicly available specification for 5657 the value. 5659 The nominated expert(s) verify that a specification exists and is 5660 readily accessible. Specifications for new registrations need to 5661 describe the means by which an endpoint might determine that it can 5662 send the identified type of frame. An accompanying transport 5663 parameter registration (see Section 22.1) is expected for most 5664 registrations. The specification needs to describe the format and 5665 assigned semantics of any fields in the frame. 5667 Expert(s) are encouraged to be biased towards approving registrations 5668 unless they are abusive, frivolous, or actively harmful (not merely 5669 aesthetically displeasing, or architecturally dubious). 5671 The initial contents of this registry are tabulated in Table 3. 5673 22.3. QUIC Transport Error Codes Registry 5675 IANA [SHALL add/has added] a registry for "QUIC Transport Error 5676 Codes" under a "QUIC Protocol" heading. 5678 The "QUIC Transport Error Codes" registry governs a 16-bit space. 5679 This space is split into two spaces that are governed by different 5680 policies. Values with the first byte in the range 0x00 to 0xfe (in 5681 hexadecimal) are assigned via the Specification Required policy 5682 [RFC8126]. Values with the first byte 0xff are reserved for Private 5683 Use [RFC8126]. 5685 Registrations MUST include the following fields: 5687 Value: The numeric value of the assignment (registrations will be 5688 between 0x0000 and 0xfeff). 5690 Code: A short mnemonic for the parameter. 5692 Description: A brief description of the error code semantics, which 5693 MAY be a summary if a specification reference is provided. 5695 Specification: A reference to a publicly available specification for 5696 the value. 5698 The initial contents of this registry are shown in Table 7. Values 5699 from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. 5701 +------+---------------------------+----------------+---------------+ 5702 | Valu | Error | Description | Specification | 5703 | e | | | | 5704 +------+---------------------------+----------------+---------------+ 5705 | 0x0 | NO_ERROR | No error | Section 20 | 5706 | | | | | 5707 | 0x1 | INTERNAL_ERROR | Implementation | Section 20 | 5708 | | | error | | 5709 | | | | | 5710 | 0x2 | SERVER_BUSY | Server | Section 20 | 5711 | | | currently busy | | 5712 | | | | | 5713 | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | 5714 | | | error | | 5715 | | | | | 5716 | 0x4 | STREAM_LIMIT_ERROR | Too many | Section 20 | 5717 | | | streams opened | | 5718 | | | | | 5719 | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | 5720 | | | in invalid | | 5721 | | | stream state | | 5722 | | | | | 5723 | 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 | 5724 | | | final size | | 5725 | | | | | 5726 | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | 5727 | | | error | | 5728 | | | | | 5729 | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | 5730 | | | transport | | 5731 | | | parameters | | 5732 | | | | | 5733 | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 20 | 5734 | | | negotiation | | 5735 | | | failure | | 5736 | | | | | 5737 | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | 5738 | | | protocol | | 5739 | | | violation | | 5740 | | | | | 5741 | 0xC | INVALID_MIGRATION | Violated | Section 20 | 5742 | | | disabled | | 5743 | | | migration | | 5744 +------+---------------------------+----------------+---------------+ 5746 Table 7: Initial QUIC Transport Error Codes Entries 5748 23. References 5750 23.1. Normative References 5752 [DPLPMTUD] 5753 Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, 5754 "Packetization Layer Path MTU Discovery for Datagram 5755 Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in 5756 progress), November 2018. 5758 [QUIC-RECOVERY] 5759 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5760 and Congestion Control", draft-ietf-quic-recovery-18 (work 5761 in progress), January 2019. 5763 [QUIC-TLS] 5764 Thomson, M., Ed. and S. Turner, Ed., "Using Transport 5765 Layer Security (TLS) to Secure QUIC", draft-ietf-quic- 5766 tls-18 (work in progress), January 2019. 5768 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5769 DOI 10.17487/RFC1191, November 1990, 5770 . 5772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5773 Requirement Levels", BCP 14, RFC 2119, 5774 DOI 10.17487/RFC2119, March 1997, 5775 . 5777 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5778 of Explicit Congestion Notification (ECN) to IP", 5779 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5780 . 5782 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 5783 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 5784 2003, . 5786 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5787 "Randomness Requirements for Security", BCP 106, RFC 4086, 5788 DOI 10.17487/RFC4086, June 2005, 5789 . 5791 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 5792 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 5793 . 5795 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 5796 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 5797 March 2017, . 5799 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5800 Writing an IANA Considerations Section in RFCs", BCP 26, 5801 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5802 . 5804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5806 May 2017, . 5808 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5809 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5810 DOI 10.17487/RFC8201, July 2017, 5811 . 5813 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 5814 Notification (ECN) Experimentation", RFC 8311, 5815 DOI 10.17487/RFC8311, January 2018, 5816 . 5818 [SPIN] Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 5819 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 5820 October 2018. 5822 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5823 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5824 . 5826 23.2. Informative References 5828 [EARLY-DESIGN] 5829 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 5830 December 2013, . 5832 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 5833 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 5834 DOI 10.17487/RFC7540, May 2015, 5835 . 5837 [QUIC-INVARIANTS] 5838 Thomson, M., "Version-Independent Properties of QUIC", 5839 draft-ietf-quic-invariants-03 (work in progress), January 5840 2019. 5842 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 5843 RFC 1812, DOI 10.17487/RFC1812, June 1995, 5844 . 5846 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 5847 Selective Acknowledgment Options", RFC 2018, 5848 DOI 10.17487/RFC2018, October 1996, 5849 . 5851 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5852 Hashing for Message Authentication", RFC 2104, 5853 DOI 10.17487/RFC2104, February 1997, 5854 . 5856 [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, 5857 RFC 2360, DOI 10.17487/RFC2360, June 1998, 5858 . 5860 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 5861 RFC 4303, DOI 10.17487/RFC4303, December 2005, 5862 . 5864 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 5865 Control Message Protocol (ICMPv6) for the Internet 5866 Protocol Version 6 (IPv6) Specification", STD 89, 5867 RFC 4443, DOI 10.17487/RFC4443, March 2006, 5868 . 5870 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 5871 Translation (NAT) Behavioral Requirements for Unicast 5872 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 5873 2007, . 5875 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5876 Key Derivation Function (HKDF)", RFC 5869, 5877 DOI 10.17487/RFC5869, May 2010, 5878 . 5880 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5881 "Transport Layer Security (TLS) Application-Layer Protocol 5882 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5883 July 2014, . 5885 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5886 (IPv6) Specification", STD 86, RFC 8200, 5887 DOI 10.17487/RFC8200, July 2017, 5888 . 5890 [SLOWLORIS] 5891 RSnake Hansen, R., "Welcome to Slowloris...", June 2009, 5892 . 5895 Appendix A. Sample Packet Number Decoding Algorithm 5897 The following pseudo-code shows how an implementation can decode 5898 packet numbers after header protection has been removed. 5900 DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): 5901 expected_pn = largest_pn + 1 5902 pn_win = 1 << pn_nbits 5903 pn_hwin = pn_win / 2 5904 pn_mask = pn_win - 1 5905 // The incoming packet number should be greater than 5906 // expected_pn - pn_hwin and less than or equal to 5907 // expected_pn + pn_hwin 5908 // 5909 // This means we can't just strip the trailing bits from 5910 // expected_pn and add the truncated_pn because that might 5911 // yield a value outside the window. 5912 // 5913 // The following code calculates a candidate value and 5914 // makes sure it's within the packet number window. 5915 candidate_pn = (expected_pn & ~pn_mask) | truncated_pn 5916 if candidate_pn <= expected_pn - pn_hwin: 5917 return candidate_pn + pn_win 5918 // Note the extra check for underflow when candidate_pn 5919 // is near zero. 5920 if candidate_pn > expected_pn + pn_hwin and 5921 candidate_pn > pn_win: 5922 return candidate_pn - pn_win 5923 return candidate_pn 5925 Appendix B. Change Log 5927 *RFC Editor's Note:* Please remove this section prior to 5928 publication of a final version of this document. 5930 Issue and pull request numbers are listed with a leading octothorp. 5932 B.1. Since draft-ietf-quic-transport-17 5934 o Stream-related errors now use STREAM_STATE_ERROR (#2305) 5936 o Endpoints discard initial keys as soon as handshake keys are 5937 available (#1951, #2045) 5939 o Expanded conditions for ignoring ICMP packet too big messages 5940 (#2108, #2161) 5942 o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, 5943 #2241) 5945 o Endpoints are permitted to discard malformed initial packets 5946 (#2141) 5948 o Clarified ECN implementation and usage requirements (#2156, #2201) 5950 o Disable ECN count verification for packets that arrive out of 5951 order (#2198, #2215) 5953 o Use Probe Timeout (PTO) instead of RTO (#2206, #2238) 5955 o Loosen constraints on retransmission of ACK ranges (#2199, #2245) 5957 o Limit Retry and Version Negotiation to once per datagram (#2259, 5958 #2303) 5960 o Set a maximum value for max_ack_delay transport parameter (#2282, 5961 #2301) 5963 o Allow server preferred address for both IPv4 and IPv6 (#2122, 5964 #2296) 5966 o Corrected requirements for migration to a preferred address 5967 (#2146, #2349) 5969 B.2. Since draft-ietf-quic-transport-16 5971 o Stream limits are defined as counts, not maximums (#1850, #1906) 5973 o Require amplification attack defense after closing (#1905, #1911) 5975 o Remove reservation of application error code 0 for STOPPING 5976 (#1804, #1922) 5978 o Renumbered frames (#1945) 5980 o Renumbered transport parameters (#1946) 5982 o Numeric transport parameters are expressed as varints (#1608, 5983 #1947, #1955) 5985 o Reorder the NEW_CONNECTION_ID frame (#1952, #1963) 5986 o Rework the first byte (#2006) 5988 * Fix the 0x40 bit 5990 * Change type values for long header 5992 * Add spin bit to short header (#631, #1988) 5994 * Encrypt the remainder of the first byte (#1322) 5996 * Move packet number length to first byte 5998 * Move ODCIL to first byte of retry packets 6000 * Simplify packet number protection (#1575) 6002 o Allow STOP_SENDING to open a remote bidirectional stream (#1797, 6003 #2013) 6005 o Added mitigation for off-path migration attacks (#1278, #1749, 6006 #2033) 6008 o Don't let the PMTU to drop below 1280 (#2063, #2069) 6010 o Require peers to replace retired connection IDs (#2085) 6012 o Servers are required to ignore Version Negotiation packets (#2088) 6014 o Tokens are repeated in all Initial packets (#2089) 6016 o Clarified how PING frames are sent after loss (#2094) 6018 o Initial keys are discarded once Handshake are available (#1951, 6019 #2045) 6021 o ICMP PTB validation clarifications (#2161, #2109, #2108) 6023 B.3. Since draft-ietf-quic-transport-15 6025 Substantial editorial reorganization; no technical changes. 6027 B.4. Since draft-ietf-quic-transport-14 6029 o Merge ACK and ACK_ECN (#1778, #1801) 6031 o Explicitly communicate max_ack_delay (#981, #1781) 6032 o Validate original connection ID after Retry packets (#1710, #1486, 6033 #1793) 6035 o Idle timeout is optional and has no specified maximum (#1765) 6037 o Update connection ID handling; add RETIRE_CONNECTION_ID type 6038 (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, 6039 #1821) 6041 o Include a Token in all Initial packets (#1649, #1794) 6043 o Prevent handshake deadlock (#1764, #1824) 6045 B.5. Since draft-ietf-quic-transport-13 6047 o Streams open when higher-numbered streams of the same type open 6048 (#1342, #1549) 6050 o Split initial stream flow control limit into 3 transport 6051 parameters (#1016, #1542) 6053 o All flow control transport parameters are optional (#1610) 6055 o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) 6057 o Permit stateless reset in response to any packet (#1348, #1553) 6059 o Recommended defense against stateless reset spoofing (#1386, 6060 #1554) 6062 o Prevent infinite stateless reset exchanges (#1443, #1627) 6064 o Forbid processing of the same packet number twice (#1405, #1624) 6066 o Added a packet number decoding example (#1493) 6068 o More precisely define idle timeout (#1429, #1614, #1652) 6070 o Corrected format of Retry packet and prevented looping (#1492, 6071 #1451, #1448, #1498) 6073 o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, 6074 #1514, #1621) 6076 o Permit Retry in response to 0-RTT (#1547, #1552) 6078 o Looser verification of ECN counters to account for ACK loss 6079 (#1555, #1481, #1565) 6081 o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) 6083 B.6. Since draft-ietf-quic-transport-12 6085 o Changes to integration of the TLS handshake (#829, #1018, #1094, 6086 #1165, #1190, #1233, #1242, #1252, #1450, #1458) 6088 * The cryptographic handshake uses CRYPTO frames, not stream 0 6090 * QUIC packet protection is used in place of TLS record 6091 protection 6093 * Separate QUIC packet number spaces are used for the handshake 6095 * Changed Retry to be independent of the cryptographic handshake 6097 * Added NEW_TOKEN frame and Token fields to Initial packet 6099 * Limit the use of HelloRetryRequest to address TLS needs (like 6100 key shares) 6102 o Enable server to transition connections to a preferred address 6103 (#560, #1251, #1373) 6105 o Added ECN feedback mechanisms and handling; new ACK_ECN frame 6106 (#804, #805, #1372) 6108 o Changed rules and recommendations for use of new connection IDs 6109 (#1258, #1264, #1276, #1280, #1419, #1452, #1453, #1465) 6111 o Added a transport parameter to disable intentional connection 6112 migration (#1271, #1447) 6114 o Packets from different connection ID can't be coalesced (#1287, 6115 #1423) 6117 o Fixed sampling method for packet number encryption; the length 6118 field in long headers includes the packet number field in addition 6119 to the packet payload (#1387, #1389) 6121 o Stateless Reset is now symmetric and subject to size constraints 6122 (#466, #1346) 6124 o Added frame type extension mechanism (#58, #1473) 6126 B.7. Since draft-ietf-quic-transport-11 6128 o Enable server to transition connections to a preferred address 6129 (#560, #1251) 6131 o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, 6132 #990, #734, #1317, #1267, #1079) 6134 o Packet numbers use a variable-length encoding (#989, #1334) 6136 o STREAM frames can now be empty (#1350) 6138 B.8. Since draft-ietf-quic-transport-10 6140 o Swap payload length and packed number fields in long header 6141 (#1294) 6143 o Clarified that CONNECTION_CLOSE is allowed in Handshake packet 6144 (#1274) 6146 o Spin bit reserved (#1283) 6148 o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) 6150 o A more complete connection migration (#1249) 6152 o Refine opportunistic ACK defense text (#305, #1030, #1185) 6154 o A Stateless Reset Token isn't mandatory (#818, #1191) 6156 o Removed implicit stream opening (#896, #1193) 6158 o An empty STREAM frame can be used to open a stream without sending 6159 data (#901, #1194) 6161 o Define stream counts in transport parameters rather than a maximum 6162 stream ID (#1023, #1065) 6164 o STOP_SENDING is now prohibited before streams are used (#1050) 6166 o Recommend including ACK in Retry packets and allow PADDING (#1067, 6167 #882) 6169 o Endpoints now become closing after an idle timeout (#1178, #1179) 6171 o Remove implication that Version Negotiation is sent when a packet 6172 of the wrong version is received (#1197) 6174 B.9. Since draft-ietf-quic-transport-09 6176 o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with 6177 Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. 6178 (#1091, #725, #1086) 6180 o A server can now only send 3 packets without validating the client 6181 address (#38, #1090) 6183 o Delivery order of stream data is no longer strongly specified 6184 (#252, #1070) 6186 o Rework of packet handling and version negotiation (#1038) 6188 o Stream 0 is now exempt from flow control until the handshake 6189 completes (#1074, #725, #825, #1082) 6191 o Improved retransmission rules for all frame types: information is 6192 retransmitted, not packets or frames (#463, #765, #1095, #1053) 6194 o Added an error code for server busy signals (#1137) 6196 o Endpoints now set the connection ID that their peer uses. 6197 Connection IDs are variable length. Removed the 6198 omit_connection_id transport parameter and the corresponding short 6199 header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) 6201 B.10. Since draft-ietf-quic-transport-08 6203 o Clarified requirements for BLOCKED usage (#65, #924) 6205 o BLOCKED frame now includes reason for blocking (#452, #924, #927, 6206 #928) 6208 o GAP limitation in ACK Frame (#613) 6210 o Improved PMTUD description (#614, #1036) 6212 o Clarified stream state machine (#634, #662, #743, #894) 6214 o Reserved versions don't need to be generated deterministically 6215 (#831, #931) 6217 o You don't always need the draining period (#871) 6219 o Stateless reset clarified as version-specific (#930, #986) 6220 o initial_max_stream_id_x transport parameters are optional (#970, 6221 #971) 6223 o Ack Delay assumes a default value during the handshake (#1007, 6224 #1009) 6226 o Removed transport parameters from NewSessionTicket (#1015) 6228 B.11. Since draft-ietf-quic-transport-07 6230 o The long header now has version before packet number (#926, #939) 6232 o Rename and consolidate packet types (#846, #822, #847) 6234 o Packet types are assigned new codepoints and the Connection ID 6235 Flag is inverted (#426, #956) 6237 o Removed type for Version Negotiation and use Version 0 (#963, 6238 #968) 6240 o Streams are split into unidirectional and bidirectional (#643, 6241 #656, #720, #872, #175, #885) 6243 * Stream limits now have separate uni- and bi-directional 6244 transport parameters (#909, #958) 6246 * Stream limit transport parameters are now optional and default 6247 to 0 (#970, #971) 6249 o The stream state machine has been split into read and write (#634, 6250 #894) 6252 o Employ variable-length integer encodings throughout (#595) 6254 o Improvements to connection close 6256 * Added distinct closing and draining states (#899, #871) 6258 * Draining period can terminate early (#869, #870) 6260 * Clarifications about stateless reset (#889, #890) 6262 o Address validation for connection migration (#161, #732, #878) 6264 o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) 6266 o negotiated_version is sent in server transport parameters (#710, 6267 #959) 6269 o Increased the range over which packet numbers are randomized 6270 (#864, #850, #964) 6272 B.12. Since draft-ietf-quic-transport-06 6274 o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) 6276 o Split error code space between application and transport (#485) 6278 o Stateless reset token moved to end (#820) 6280 o 1-RTT-protected long header types removed (#848) 6282 o No acknowledgments during draining period (#852) 6284 o Remove "application close" as a separate close type (#854) 6286 o Remove timestamps from the ACK frame (#841) 6288 o Require transport parameters to only appear once (#792) 6290 B.13. Since draft-ietf-quic-transport-05 6292 o Stateless token is server-only (#726) 6294 o Refactor section on connection termination (#733, #748, #328, 6295 #177) 6297 o Limit size of Version Negotiation packet (#585) 6299 o Clarify when and what to ack (#736) 6301 o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED 6303 o Clarify Keep-alive requirements (#729) 6305 B.14. Since draft-ietf-quic-transport-04 6307 o Introduce STOP_SENDING frame, RESET_STREAM only resets in one 6308 direction (#165) 6310 o Removed GOAWAY; application protocols are responsible for graceful 6311 shutdown (#696) 6313 o Reduced the number of error codes (#96, #177, #184, #211) 6315 o Version validation fields can't move or change (#121) 6316 o Removed versions from the transport parameters in a 6317 NewSessionTicket message (#547) 6319 o Clarify the meaning of "bytes in flight" (#550) 6321 o Public reset is now stateless reset and not visible to the path 6322 (#215) 6324 o Reordered bits and fields in STREAM frame (#620) 6326 o Clarifications to the stream state machine (#572, #571) 6328 o Increased the maximum length of the Largest Acknowledged field in 6329 ACK frames to 64 bits (#629) 6331 o truncate_connection_id is renamed to omit_connection_id (#659) 6333 o CONNECTION_CLOSE terminates the connection like TCP RST (#330, 6334 #328) 6336 o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) 6338 B.15. Since draft-ietf-quic-transport-03 6340 o Change STREAM and RESET_STREAM layout 6342 o Add MAX_STREAM_ID settings 6344 B.16. Since draft-ietf-quic-transport-02 6346 o The size of the initial packet payload has a fixed minimum (#267, 6347 #472) 6349 o Define when Version Negotiation packets are ignored (#284, #294, 6350 #241, #143, #474) 6352 o The 64-bit FNV-1a algorithm is used for integrity protection of 6353 unprotected packets (#167, #480, #481, #517) 6355 o Rework initial packet types to change how the connection ID is 6356 chosen (#482, #442, #493) 6358 o No timestamps are forbidden in unprotected packets (#542, #429) 6360 o Cryptographic handshake is now on stream 0 (#456) 6362 o Remove congestion control exemption for cryptographic handshake 6363 (#248, #476) 6365 o Version 1 of QUIC uses TLS; a new version is needed to use a 6366 different handshake protocol (#516) 6368 o STREAM frames have a reduced number of offset lengths (#543, #430) 6370 o Split some frames into separate connection- and stream- level 6371 frames (#443) 6373 * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) 6375 * BLOCKED split to match WINDOW_UPDATE split (#454) 6377 * Define STREAM_ID_NEEDED frame (#455) 6379 o A NEW_CONNECTION_ID frame supports connection migration without 6380 linkability (#232, #491, #496) 6382 o Transport parameters for 0-RTT are retained from a previous 6383 connection (#405, #513, #512) 6385 * A client in 0-RTT no longer required to reset excess streams 6386 (#425, #479) 6388 o Expanded security considerations (#440, #444, #445, #448) 6390 B.17. Since draft-ietf-quic-transport-01 6392 o Defined short and long packet headers (#40, #148, #361) 6394 o Defined a versioning scheme and stable fields (#51, #361) 6396 o Define reserved version values for "greasing" negotiation (#112, 6397 #278) 6399 o The initial packet number is randomized (#35, #283) 6401 o Narrow the packet number encoding range requirement (#67, #286, 6402 #299, #323, #356) 6404 o Defined client address validation (#52, #118, #120, #275) 6406 o Define transport parameters as a TLS extension (#49, #122) 6408 o SCUP and COPT parameters are no longer valid (#116, #117) 6410 o Transport parameters for 0-RTT are either remembered from before, 6411 or assume default values (#126) 6413 o The server chooses connection IDs in its final flight (#119, #349, 6414 #361) 6416 o The server echoes the Connection ID and packet number fields when 6417 sending a Version Negotiation packet (#133, #295, #244) 6419 o Defined a minimum packet size for the initial handshake packet 6420 from the client (#69, #136, #139, #164) 6422 o Path MTU Discovery (#64, #106) 6424 o The initial handshake packet from the client needs to fit in a 6425 single packet (#338) 6427 o Forbid acknowledgment of packets containing only ACK and PADDING 6428 (#291) 6430 o Require that frames are processed when packets are acknowledged 6431 (#381, #341) 6433 o Removed the STOP_WAITING frame (#66) 6435 o Don't require retransmission of old timestamps for lost ACK frames 6436 (#308) 6438 o Clarified that frames are not retransmitted, but the information 6439 in them can be (#157, #298) 6441 o Error handling definitions (#335) 6443 o Split error codes into four sections (#74) 6445 o Forbid the use of Public Reset where CONNECTION_CLOSE is possible 6446 (#289) 6448 o Define packet protection rules (#336) 6450 o Require that stream be entirely delivered or reset, including 6451 acknowledgment of all STREAM frames or the RESET_STREAM, before it 6452 closes (#381) 6454 o Remove stream reservation from state machine (#174, #280) 6456 o Only stream 1 does not contribute to connection-level flow control 6457 (#204) 6459 o Stream 1 counts towards the maximum concurrent stream limit (#201, 6460 #282) 6462 o Remove connection-level flow control exclusion for some streams 6463 (except 1) (#246) 6465 o RESET_STREAM affects connection-level flow control (#162, #163) 6467 o Flow control accounting uses the maximum data offset on each 6468 stream, rather than bytes received (#378) 6470 o Moved length-determining fields to the start of STREAM and ACK 6471 (#168, #277) 6473 o Added the ability to pad between frames (#158, #276) 6475 o Remove error code and reason phrase from GOAWAY (#352, #355) 6477 o GOAWAY includes a final stream number for both directions (#347) 6479 o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a 6480 consistent offset (#249) 6482 o Defined priority as the responsibility of the application protocol 6483 (#104, #303) 6485 B.18. Since draft-ietf-quic-transport-00 6487 o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag 6489 o Defined versioning 6491 o Reworked description of packet and frame layout 6493 o Error code space is divided into regions for each component 6495 o Use big endian for all numeric values 6497 B.19. Since draft-hamilton-quic-transport-protocol-01 6499 o Adopted as base for draft-ietf-quic-tls 6501 o Updated authors/editors list 6503 o Added IANA Considerations section 6505 o Moved Contributors and Acknowledgments to appendices 6507 Acknowledgments 6509 Special thanks are due to the following for helping shape pre-IETF 6510 QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, 6511 Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. 6513 This document has benefited immensely from various private 6514 discussions and public ones on the quic@ietf.org and proto- 6515 quic@chromium.org mailing lists. Our thanks to all. 6517 Contributors 6519 The original authors of this specification were Ryan Hamilton, Jana 6520 Iyengar, Ian Swett, and Alyssa Wilk. 6522 The original design and rationale behind this protocol draw 6523 significantly from work by Jim Roskind [EARLY-DESIGN]. In 6524 alphabetical order, the contributors to the pre-IETF QUIC project at 6525 Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar, 6526 Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind, 6527 Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti, 6528 Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale 6529 Worley, Fan Yang, Dan Zhang, Daniel Ziegler. 6531 Authors' Addresses 6533 Jana Iyengar (editor) 6534 Fastly 6536 Email: jri.ietf@gmail.com 6538 Martin Thomson (editor) 6539 Mozilla 6541 Email: mt@lowentropy.net