draft-ietf-quic-transport-latest.txt   draft-ietf-quic-transport-auth48.txt 
skipping to change at page 2, line 7 skipping to change at line 52
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Overview
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7 1.1. Document Structure
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8 1.2. Terms and Definitions
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 1.3. Notational Conventions
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Streams
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11 2.1. Stream Types and Identifiers
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12 2.2. Sending and Receiving Data
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13 2.3. Stream Prioritization
2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 13 2.4. Operations on Streams
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Stream States
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15 3.1. Sending Stream States
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17 3.2. Receiving Stream States
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20 3.3. Permitted Frame Types
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20 3.4. Bidirectional Stream States
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22 3.5. Solicited State Transitions
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Flow Control
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23 4.1. Data Flow Control
4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 24 4.2. Increasing Flow Control Limits
4.3. Flow Control Performance . . . . . . . . . . . . . . . . 25 4.3. Flow Control Performance
4.4. Handling Stream Cancellation . . . . . . . . . . . . . . 25 4.4. Handling Stream Cancellation
4.5. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26 4.5. Stream Final Size
4.6. Controlling Concurrency . . . . . . . . . . . . . . . . . 27 4.6. Controlling Concurrency
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Connections
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Connection ID
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29 5.1.1. Issuing Connection IDs
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 31 5.1.2. Consuming and Retiring Connection IDs
5.2. Matching Packets to Connections . . . . . . . . . . . . . 32 5.2. Matching Packets to Connections
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33 5.2.1. Client Packet Handling
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 33 5.2.2. Server Packet Handling
5.2.3. Considerations for Simple Load Balancers . . . . . . 34 5.2.3. Considerations for Simple Load Balancers
5.3. Operations on Connections . . . . . . . . . . . . . . . . 34 5.3. Operations on Connections
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36 6. Version Negotiation
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 36 6.1. Sending Version Negotiation Packets
6.2. Handling Version Negotiation Packets . . . . . . . . . . 36 6.2. Handling Version Negotiation Packets
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37 6.3. Using Reserved Versions
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 37 7. Cryptographic and Transport Handshake
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 39 7.1. Example Handshake Flows
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 40 7.2. Negotiating Connection IDs
7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41 7.3. Authenticating Connection IDs
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43 7.4. Transport Parameters
7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 44 7.4.1. Values of Transport Parameters for 0-RTT
7.4.2. New Transport Parameters . . . . . . . . . . . . . . 46 7.4.2. New Transport Parameters
7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 47 7.5. Cryptographic Message Buffering
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 47 8. Address Validation
8.1. Address Validation during Connection Establishment . . . 48 8.1. Address Validation during Connection Establishment
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 49 8.1.1. Token Construction
8.1.2. Address Validation Using Retry Packets . . . . . . . 49 8.1.2. Address Validation Using Retry Packets
8.1.3. Address Validation for Future Connections . . . . . . 50 8.1.3. Address Validation for Future Connections
8.1.4. Address Validation Token Integrity . . . . . . . . . 52 8.1.4. Address Validation Token Integrity
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 53 8.2. Path Validation
8.2.1. Initiating Path Validation . . . . . . . . . . . . . 54 8.2.1. Initiating Path Validation
8.2.2. Path Validation Responses . . . . . . . . . . . . . . 55 8.2.2. Path Validation Responses
8.2.3. Successful Path Validation . . . . . . . . . . . . . 56 8.2.3. Successful Path Validation
8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 56 8.2.4. Failed Path Validation
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 57 9. Connection Migration
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 58 9.1. Probing a New Path
9.2. Initiating Connection Migration . . . . . . . . . . . . . 58 9.2. Initiating Connection Migration
9.3. Responding to Connection Migration . . . . . . . . . . . 59 9.3. Responding to Connection Migration
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 59 9.3.1. Peer Address Spoofing
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 60 9.3.2. On-Path Address Spoofing
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 60 9.3.3. Off-Path Packet Forwarding
9.4. Loss Detection and Congestion Control . . . . . . . . . . 61 9.4. Loss Detection and Congestion Control
9.5. Privacy Implications of Connection Migration . . . . . . 62 9.5. Privacy Implications of Connection Migration
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 64 9.6. Server's Preferred Address
9.6.1. Communicating a Preferred Address . . . . . . . . . . 64 9.6.1. Communicating a Preferred Address
9.6.2. Migration to a Preferred Address . . . . . . . . . . 64 9.6.2. Migration to a Preferred Address
9.6.3. Interaction of Client Migration and Preferred Address 65 9.6.3. Interaction of Client Migration and Preferred Address
9.7. Use of IPv6 Flow Label and Migration . . . . . . . . . . 66 9.7. Use of IPv6 Flow Label and Migration
10. Connection Termination . . . . . . . . . . . . . . . . . . . 66 10. Connection Termination
10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 66 10.1. Idle Timeout
10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 67 10.1.1. Liveness Testing
10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67 10.1.2. Deferring Idle Timeout
10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 68 10.2. Immediate Close
10.2.1. Closing Connection State . . . . . . . . . . . . . . 69 10.2.1. Closing Connection State
10.2.2. Draining Connection State . . . . . . . . . . . . . 70 10.2.2. Draining Connection State
10.2.3. Immediate Close during the Handshake . . . . . . . . 70 10.2.3. Immediate Close during the Handshake
10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 72 10.3. Stateless Reset
10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 74 10.3.1. Detecting a Stateless Reset
10.3.2. Calculating a Stateless Reset Token . . . . . . . . 75 10.3.2. Calculating a Stateless Reset Token
10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 76 10.3.3. Looping
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 77 11. Error Handling
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 77 11.1. Connection Errors
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 78 11.2. Stream Errors
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 79 12. Packets and Frames
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 79 12.1. Protected Packets
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 80 12.2. Coalescing Packets
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 81 12.3. Packet Numbers
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 82 12.4. Frames and Frame Types
12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 86 12.5. Frames and Number Spaces
13. Packetization and Reliability . . . . . . . . . . . . . . . . 87 13. Packetization and Reliability
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 87 13.1. Packet Processing
13.2. Generating Acknowledgments . . . . . . . . . . . . . . . 88 13.2. Generating Acknowledgments
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 88 13.2.1. Sending ACK Frames
13.2.2. Acknowledgment Frequency . . . . . . . . . . . . . . 89 13.2.2. Acknowledgment Frequency
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 90 13.2.3. Managing ACK Ranges
13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 91 13.2.4. Limiting Ranges by Tracking ACK Frames
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 92 13.2.5. Measuring and Reporting Host Delay
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 92 13.2.6. ACK Frames and Packet Protection
13.2.7. PADDING Frames Consume Congestion Window . . . . . . 92 13.2.7. PADDING Frames Consume Congestion Window
13.3. Retransmission of Information . . . . . . . . . . . . . 93 13.3. Retransmission of Information
13.4. Explicit Congestion Notification . . . . . . . . . . . . 95 13.4. Explicit Congestion Notification
13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 96 13.4.1. Reporting ECN Counts
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 96 13.4.2. ECN Validation
14. Datagram Size . . . . . . . . . . . . . . . . . . . . . . . . 98 14. Datagram Size
14.1. Initial Datagram Size . . . . . . . . . . . . . . . . . 99 14.1. Initial Datagram Size
14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 100 14.2. Path Maximum Transmission Unit
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 101 14.2.1. Handling of ICMP Messages by PMTUD
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 102 14.3. Datagram Packetization Layer PMTU Discovery
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 102 14.3.1. DPLPMTUD and Initial Connectivity
14.3.2. Validating the Network Path with DPLPMTUD . . . . . 102 14.3.2. Validating the Network Path with DPLPMTUD
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 102 14.3.3. Handling of ICMP Messages by DPLPMTUD
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 102 14.4. Sending QUIC PMTU Probes
14.4.1. PMTU Probes Containing Source Connection ID . . . . 103 14.4.1. PMTU Probes Containing Source Connection ID
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 103 15. Versions
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 104 16. Variable-Length Integer Encoding
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 105 17. Packet Formats
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 105 17.1. Packet Number Encoding and Decoding
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 106 17.2. Long Header Packets
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 109 17.2.1. Version Negotiation Packet
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 110 17.2.2. Initial Packet
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 112 17.2.3. 0-RTT
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114 17.2.4. Handshake Packet
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 115 17.2.5. Retry Packet
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117 17.3. Short Header Packets
17.3.1. 1-RTT Packet . . . . . . . . . . . . . . . . . . . . 117 17.3.1. 1-RTT Packet
17.4. Latency Spin Bit . . . . . . . . . . . . . . . . . . . . 119 17.4. Latency Spin Bit
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 120 18. Transport Parameter Encoding
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 121 18.1. Reserved Transport Parameters
18.2. Transport Parameter Definitions . . . . . . . . . . . . 121 18.2. Transport Parameter Definitions
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125 19. Frame Types and Formats
19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125 19.1. PADDING Frames
19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 126 19.2. PING Frames
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126 19.3. ACK Frames
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 128 19.3.1. ACK Ranges
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 129 19.3.2. ECN Counts
19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 130 19.4. RESET_STREAM Frames
19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 131 19.5. STOP_SENDING Frames
19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131 19.6. CRYPTO Frames
19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132 19.7. NEW_TOKEN Frames
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 133 19.8. STREAM Frames
19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 135 19.9. MAX_DATA Frames
19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 135 19.10. MAX_STREAM_DATA Frames
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 136 19.11. MAX_STREAMS Frames
19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 137 19.12. DATA_BLOCKED Frames
19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 138 19.13. STREAM_DATA_BLOCKED Frames
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 138 19.14. STREAMS_BLOCKED Frames
19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 139 19.15. NEW_CONNECTION_ID Frames
19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140 19.16. RETIRE_CONNECTION_ID Frames
19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141 19.17. PATH_CHALLENGE Frames
19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 142 19.18. PATH_RESPONSE Frames
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142 19.19. CONNECTION_CLOSE Frames
19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143 19.20. HANDSHAKE_DONE Frames
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 144 19.21. Extension Frames
20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144 20. Error Codes
20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 145 20.1. Transport Error Codes
20.2. Application Protocol Error Codes . . . . . . . . . . . . 146 20.2. Application Protocol Error Codes
21. Security Considerations . . . . . . . . . . . . . . . . . . . 147 21. Security Considerations
21.1. Overview of Security Properties . . . . . . . . . . . . 147 21.1. Overview of Security Properties
21.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . 147 21.1.1. Handshake
21.1.2. Protected Packets . . . . . . . . . . . . . . . . . 149 21.1.2. Protected Packets
21.1.3. Connection Migration . . . . . . . . . . . . . . . . 150 21.1.3. Connection Migration
21.2. Handshake Denial of Service . . . . . . . . . . . . . . 154 21.2. Handshake Denial of Service
21.3. Amplification Attack . . . . . . . . . . . . . . . . . . 155 21.3. Amplification Attack
21.4. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 155 21.4. Optimistic ACK Attack
21.5. Request Forgery Attacks . . . . . . . . . . . . . . . . 156 21.5. Request Forgery Attacks
21.5.1. Control Options for Endpoints . . . . . . . . . . . 157 21.5.1. Control Options for Endpoints
21.5.2. Request Forgery with Client Initial Packets . . . . 158 21.5.2. Request Forgery with Client Initial Packets
21.5.3. Request Forgery with Preferred Addresses . . . . . . 159 21.5.3. Request Forgery with Preferred Addresses
21.5.4. Request Forgery with Spoofed Migration . . . . . . . 159 21.5.4. Request Forgery with Spoofed Migration
21.5.5. Request Forgery with Version Negotiation . . . . . . 160 21.5.5. Request Forgery with Version Negotiation
21.5.6. Generic Request Forgery Countermeasures . . . . . . 160 21.5.6. Generic Request Forgery Countermeasures
21.6. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 161 21.6. Slowloris Attacks
21.7. Stream Fragmentation and Reassembly Attacks . . . . . . 161 21.7. Stream Fragmentation and Reassembly Attacks
21.8. Stream Commitment Attack . . . . . . . . . . . . . . . . 162 21.8. Stream Commitment Attack
21.9. Peer Denial of Service . . . . . . . . . . . . . . . . . 162 21.9. Peer Denial of Service
21.10. Explicit Congestion Notification Attacks . . . . . . . . 163 21.10. Explicit Congestion Notification Attacks
21.11. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 163 21.11. Stateless Reset Oracle
21.12. Version Downgrade . . . . . . . . . . . . . . . . . . . 164 21.12. Version Downgrade
21.13. Targeted Attacks by Routing . . . . . . . . . . . . . . 164 21.13. Targeted Attacks by Routing
21.14. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 164 21.14. Traffic Analysis
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 22. IANA Considerations
22.1. Registration Policies for QUIC Registries . . . . . . . 165 22.1. Registration Policies for QUIC Registries
22.1.1. Provisional Registrations . . . . . . . . . . . . . 165 22.1.1. Provisional Registrations
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 166 22.1.2. Selecting Codepoints
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 166 22.1.3. Reclaiming Provisional Codepoints
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 167 22.1.4. Permanent Registrations
22.2. QUIC Versions Registry . . . . . . . . . . . . . . . . . 167 22.2. QUIC Versions Registry
22.3. QUIC Transport Parameters Registry . . . . . . . . . . . 168 22.3. QUIC Transport Parameters Registry
22.4. QUIC Frame Types Registry . . . . . . . . . . . . . . . 170 22.4. QUIC Frame Types Registry
22.5. QUIC Transport Error Codes Registry . . . . . . . . . . 170 22.5. QUIC Transport Error Codes Registry
23. References
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 172 23.1. Normative References
23.1. Normative References . . . . . . . . . . . . . . . . . . 172 23.2. Informative References
23.2. Informative References . . . . . . . . . . . . . . . . . 174 Appendix A. Pseudocode
Appendix A. Pseudocode . . . . . . . . . . . . . . . . . . . . . 177 A.1. Sample Variable-Length Integer Decoding
A.1. Sample Variable-Length Integer Decoding . . . . . . . . . 177 A.2. Sample Packet Number Encoding Algorithm
A.2. Sample Packet Number Encoding Algorithm . . . . . . . . . 178 A.3. Sample Packet Number Decoding Algorithm
A.3. Sample Packet Number Decoding Algorithm . . . . . . . . . 179 A.4. Sample ECN Validation Algorithm
A.4. Sample ECN Validation Algorithm . . . . . . . . . . . . . 180 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184
1. Overview 1. Overview
QUIC is a secure general-purpose transport protocol. This document QUIC is a secure general-purpose transport protocol. This document
defines version 1 of QUIC, which conforms to the version-independent defines version 1 of QUIC, which conforms to the version-independent
properties of QUIC defined in [QUIC-INVARIANTS]. properties of QUIC defined in [QUIC-INVARIANTS].
QUIC is a connection-oriented protocol that creates a stateful QUIC is a connection-oriented protocol that creates a stateful
interaction between a client and server. interaction between a client and server.
skipping to change at page 7, line 25 skipping to change at line 310
termination. Applications can manage a graceful shutdown, endpoints termination. Applications can manage a graceful shutdown, endpoints
can negotiate a timeout period, errors can cause immediate connection can negotiate a timeout period, errors can cause immediate connection
teardown, and a stateless mechanism provides for termination of teardown, and a stateless mechanism provides for termination of
connections after one endpoint has lost state. connections after one endpoint has lost state.
1.1. Document Structure 1.1. Document Structure
This document describes the core QUIC protocol and is structured as This document describes the core QUIC protocol and is structured as
follows: follows:
o Streams are the basic service abstraction that QUIC provides. * Streams are the basic service abstraction that QUIC provides.
* Section 2 describes core concepts related to streams, - Section 2 describes core concepts related to streams,
* Section 3 provides a reference model for stream states, and - Section 3 provides a reference model for stream states, and
* Section 4 outlines the operation of flow control. - Section 4 outlines the operation of flow control.
o Connections are the context in which QUIC endpoints communicate. * Connections are the context in which QUIC endpoints communicate.
* Section 5 describes core concepts related to connections, - Section 5 describes core concepts related to connections,
* Section 6 describes version negotiation, - Section 6 describes version negotiation,
* Section 7 details the process for establishing connections, - Section 7 details the process for establishing connections,
* Section 8 describes address validation and critical denial-of- - Section 8 describes address validation and critical denial-of-
service mitigations, service mitigations,
* Section 9 describes how endpoints migrate a connection to a new - Section 9 describes how endpoints migrate a connection to a new
network path, network path,
* Section 10 lists the options for terminating an open - Section 10 lists the options for terminating an open
connection, and connection, and
* Section 11 provides guidance for stream and connection error - Section 11 provides guidance for stream and connection error
handling. handling.
o Packets and frames are the basic unit used by QUIC to communicate. * Packets and frames are the basic unit used by QUIC to communicate.
* Section 12 describes concepts related to packets and frames, - Section 12 describes concepts related to packets and frames,
* Section 13 defines models for the transmission, retransmission, - Section 13 defines models for the transmission, retransmission,
and acknowledgment of data, and and acknowledgment of data, and
* Section 14 specifies rules for managing the size of datagrams - Section 14 specifies rules for managing the size of datagrams
carrying QUIC packets. carrying QUIC packets.
o Finally, encoding details of QUIC protocol elements are described * Finally, encoding details of QUIC protocol elements are described
in: in:
* Section 15 (versions), - Section 15 (versions),
* Section 16 (integer encoding), - Section 16 (integer encoding),
* Section 17 (packet headers), - Section 17 (packet headers),
* Section 18 (transport parameters), - Section 18 (transport parameters),
* Section 19 (frames), and - Section 19 (frames), and
* Section 20 (errors). - Section 20 (errors).
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control [QUIC-RECOVERY], and the use of TLS and other cryptographic control [QUIC-RECOVERY], and the use of TLS and other cryptographic
mechanisms [QUIC-TLS]. mechanisms [QUIC-TLS].
This document defines QUIC version 1, which conforms to the protocol This document defines QUIC version 1, which conforms to the protocol
invariants in [QUIC-INVARIANTS]. invariants in [QUIC-INVARIANTS].
To refer to QUIC version 1, cite this document. References to the To refer to QUIC version 1, cite this document. References to the
limited set of version-independent properties of QUIC can cite limited set of version-independent properties of QUIC can cite
skipping to change at page 11, line 17 skipping to change at line 483
7-bit Field with Fixed Value (7) = 61, 7-bit Field with Fixed Value (7) = 61,
Field with Variable-Length Integer (i), Field with Variable-Length Integer (i),
Arbitrary-Length Field (..), Arbitrary-Length Field (..),
Variable-Length Field (8..24), Variable-Length Field (8..24),
Field With Minimum Length (16..), Field With Minimum Length (16..),
Field With Maximum Length (..128), Field With Maximum Length (..128),
[Optional Field (64)], [Optional Field (64)],
Repeated Field (8) ..., Repeated Field (8) ...,
} }
Figure 1: Example Format Figure 1: Example Format
When a single-bit field is referenced in prose, the position of that When a single-bit field is referenced in prose, the position of that
field can be clarified by using the value of the byte that carries field can be clarified by using the value of the byte that carries
the field with the field's value set. For example, the value 0x80 the field with the field's value set. For example, the value 0x80
could be used to refer to the single-bit field in the most could be used to refer to the single-bit field in the most
significant bit of the byte, such as One-bit Field in Figure 1. significant bit of the byte, such as One-bit Field in Figure 1.
2. Streams 2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
skipping to change at page 12, line 25 skipping to change at line 539
stream IDs (with the bit set to 0), and server-initiated streams have stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1). odd-numbered stream IDs (with the bit set to 1).
The second least significant bit (0x02) of the stream ID The second least significant bit (0x02) of the stream ID
distinguishes between bidirectional streams (with the bit set to 0) distinguishes between bidirectional streams (with the bit set to 0)
and unidirectional streams (with the bit set to 1). and unidirectional streams (with the bit set to 1).
The two least significant bits from a stream ID therefore identify a The two least significant bits from a stream ID therefore identify a
stream as one of four types, as summarized in Table 1. stream as one of four types, as summarized in Table 1.
+------+----------------------------------+ +======+==================================+
| Bits | Stream Type | | Bits | Stream Type |
+------+----------------------------------+ +======+==================================+
| 0x00 | Client-Initiated, Bidirectional | | 0x00 | Client-Initiated, Bidirectional |
| | | +------+----------------------------------+
| 0x01 | Server-Initiated, Bidirectional | | 0x01 | Server-Initiated, Bidirectional |
| | | +------+----------------------------------+
| 0x02 | Client-Initiated, Unidirectional | | 0x02 | Client-Initiated, Unidirectional |
| | | +------+----------------------------------+
| 0x03 | Server-Initiated, Unidirectional | | 0x03 | Server-Initiated, Unidirectional |
+------+----------------------------------+ +------+----------------------------------+
Table 1: Stream ID Types Table 1: Stream ID Types
The stream space for each type begins at the minimum value (0x00 The stream space for each type begins at the minimum value (0x00
through 0x03, respectively); successive streams of each type are through 0x03, respectively); successive streams of each type are
created with numerically increasing stream IDs. A stream ID that is created with numerically increasing stream IDs. A stream ID that is
used out of order results in all streams of that type with lower- used out of order results in all streams of that type with lower-
numbered stream IDs also being opened. numbered stream IDs also being opened.
2.2. Sending and Receiving Data 2.2. Sending and Receiving Data
STREAM frames (Section 19.8) encapsulate data sent by an application. STREAM frames (Section 19.8) encapsulate data sent by an application.
skipping to change at page 14, line 9 skipping to change at line 617
This document does not define an API for QUIC; it instead defines a This document does not define an API for QUIC; it instead defines a
set of functions on streams that application protocols can rely upon. set of functions on streams that application protocols can rely upon.
An application protocol can assume that a QUIC implementation An application protocol can assume that a QUIC implementation
provides an interface that includes the operations described in this provides an interface that includes the operations described in this
section. An implementation designed for use with a specific section. An implementation designed for use with a specific
application protocol might provide only those operations that are application protocol might provide only those operations that are
used by that protocol. used by that protocol.
On the sending part of a stream, an application protocol can: On the sending part of a stream, an application protocol can:
o write data, understanding when stream flow control credit * write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written (Section 4.1) has successfully been reserved to send the written
data; data;
o end the stream (clean termination), resulting in a STREAM frame * end the stream (clean termination), resulting in a STREAM frame
(Section 19.8) with the FIN bit set; and (Section 19.8) with the FIN bit set; and
o reset the stream (abrupt termination), resulting in a RESET_STREAM * reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (Section 19.4) if the stream was not already in a terminal frame (Section 19.4) if the stream was not already in a terminal
state. state.
On the receiving part of a stream, an application protocol can: On the receiving part of a stream, an application protocol can:
o read data; and * read data; and
o abort reading of the stream and request closure, possibly * abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (Section 19.5). resulting in a STOP_SENDING frame (Section 19.5).
An application protocol can also request to be informed of state An application protocol can also request to be informed of state
changes on streams, including when the peer has opened or reset a changes on streams, including when the peer has opened or reset a
stream, when a peer aborts reading on a stream, when new data is stream, when a peer aborts reading on a stream, when new data is
available, and when data can or cannot be written to the stream due available, and when data can or cannot be written to the stream due
to flow control. to flow control.
3. Stream States 3. Stream States
skipping to change at page 15, line 11 skipping to change at line 667
The state machines shown in this section are largely informative. The state machines shown in this section are largely informative.
This document uses stream states to describe rules for when and how This document uses stream states to describe rules for when and how
different types of frames can be sent and the reactions that are different types of frames can be sent and the reactions that are
expected when different types of frames are received. Though these expected when different types of frames are received. Though these
state machines are intended to be useful in implementing QUIC, these state machines are intended to be useful in implementing QUIC, these
states are not intended to constrain implementations. An states are not intended to constrain implementations. An
implementation can define a different state machine as long as its implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements these behavior is consistent with an implementation that implements these
states. states.
Note: In some cases, a single event or action can cause a | Note: In some cases, a single event or action can cause a
transition through multiple states. For instance, sending STREAM | transition through multiple states. For instance, sending
with a FIN bit set can cause two state transitions for a sending | STREAM with a FIN bit set can cause two state transitions for a
stream: from the "Ready" state to the "Send" state, and from the | sending stream: from the "Ready" state to the "Send" state, and
"Send" state to the "Data Sent" state. | from the "Send" state to the "Data Sent" state.
3.1. Sending Stream States 3.1. Sending Stream States
Figure 2 shows the states for the part of a stream that sends data to Figure 2 shows the states for the part of a stream that sends data to
a peer. a peer.
o o
| Create Stream (Sending) | Create Stream (Sending)
| Peer Creates Bidirectional Stream | Peer Creates Bidirectional Stream
v v
skipping to change at page 21, line 9 skipping to change at line 923
receiving streams are in terminal states. receiving streams are in terminal states.
Table 2 shows a more complex mapping of bidirectional stream states Table 2 shows a more complex mapping of bidirectional stream states
that loosely correspond to the stream states defined in HTTP/2 that loosely correspond to the stream states defined in HTTP/2
[HTTP2]. This shows that multiple states on sending or receiving [HTTP2]. This shows that multiple states on sending or receiving
parts of streams are mapped to the same composite state. Note that parts of streams are mapped to the same composite state. Note that
this is just one possibility for such a mapping; this mapping this is just one possibility for such a mapping; this mapping
requires that data be acknowledged before the transition to a requires that data be acknowledged before the transition to a
"closed" or "half-closed" state. "closed" or "half-closed" state.
+----------------------+-----------------------+--------------------+ +===================+=======================+=================+
| Sending Part | Receiving Part | Composite State | | Sending Part | Receiving Part | Composite State |
+----------------------+-----------------------+--------------------+ +===================+=======================+=================+
| No Stream / Ready | No Stream / Recv (*1) | idle | | No Stream / Ready | No Stream / Recv (*1) | idle |
| | | | +-------------------+-----------------------+-----------------+
| Ready / Send / Data | Recv / Size Known | open | | Ready / Send / | Recv / Size Known | open |
| Sent | | | | Data Sent | | |
| | | | +-------------------+-----------------------+-----------------+
| Ready / Send / Data | Data Recvd / Data | half-closed | | Ready / Send / | Data Recvd / Data | half-closed |
| Sent | Read | (remote) | | Data Sent | Read | (remote) |
| | | | +-------------------+-----------------------+-----------------+
| Ready / Send / Data | Reset Recvd / Reset | half-closed | | Ready / Send / | Reset Recvd / Reset | half-closed |
| Sent | Read | (remote) | | Data Sent | Read | (remote) |
| | | | +-------------------+-----------------------+-----------------+
| Data Recvd | Recv / Size Known | half-closed | | Data Recvd | Recv / Size Known | half-closed |
| | | (local) | | | | (local) |
| | | | +-------------------+-----------------------+-----------------+
| Reset Sent / Reset | Recv / Size Known | half-closed | | Reset Sent / | Recv / Size Known | half-closed |
| Recvd | | (local) | | Reset Recvd | | (local) |
| | | | +-------------------+-----------------------+-----------------+
| Reset Sent / Reset | Data Recvd / Data | closed | | Reset Sent / | Data Recvd / Data | closed |
| Recvd | Read | | | Reset Recvd | Read | |
| | | | +-------------------+-----------------------+-----------------+
| Reset Sent / Reset | Reset Recvd / Reset | closed | | Reset Sent / | Reset Recvd / Reset | closed |
| Recvd | Read | | | Reset Recvd | Read | |
| | | | +-------------------+-----------------------+-----------------+
| Data Recvd | Data Recvd / Data | closed | | Data Recvd | Data Recvd / Data | closed |
| | Read | | | | Read | |
| | | | +-------------------+-----------------------+-----------------+
| Data Recvd | Reset Recvd / Reset | closed | | Data Recvd | Reset Recvd / Reset | closed |
| | Read | | | | Read | |
+----------------------+-----------------------+--------------------+ +-------------------+-----------------------+-----------------+
Table 2: Possible Mapping of Stream States to HTTP/2 Table 2: Possible Mapping of Stream States to HTTP/2
Note (*1): A stream is considered "idle" if it has not yet been | Note (*1): A stream is considered "idle" if it has not yet been
created or if the receiving part of the stream is in the "Recv" | created or if the receiving part of the stream is in the "Recv"
state without yet having received any frames. | state without yet having received any frames.
3.5. Solicited State Transitions 3.5. Solicited State Transitions
If an application is no longer interested in the data it is receiving If an application is no longer interested in the data it is receiving
on a stream, it can abort reading the stream and specify an on a stream, it can abort reading the stream and specify an
application error code. application error code.
If the stream is in the "Recv" or "Size Known" state, the transport If the stream is in the "Recv" or "Size Known" state, the transport
SHOULD signal this by sending a STOP_SENDING frame to prompt closure SHOULD signal this by sending a STOP_SENDING frame to prompt closure
of the stream in the opposite direction. This typically indicates of the stream in the opposite direction. This typically indicates
skipping to change at page 23, line 34 skipping to change at line 1038
SHOULD provide an interface for the cryptographic protocol SHOULD provide an interface for the cryptographic protocol
implementation to communicate its buffering limits. implementation to communicate its buffering limits.
4.1. Data Flow Control 4.1. Data Flow Control
QUIC employs a limit-based flow control scheme where a receiver QUIC employs a limit-based flow control scheme where a receiver
advertises the limit of total bytes it is prepared to receive on a advertises the limit of total bytes it is prepared to receive on a
given stream or for the entire connection. This leads to two levels given stream or for the entire connection. This leads to two levels
of data flow control in QUIC: of data flow control in QUIC:
o Stream flow control, which prevents a single stream from consuming * Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount the entire receive buffer for a connection by limiting the amount
of data that can be sent on each stream. of data that can be sent on each stream.
o Connection flow control, which prevents senders from exceeding a * Connection flow control, which prevents senders from exceeding a
receiver's buffer capacity for the connection by limiting the receiver's buffer capacity for the connection by limiting the
total bytes of stream data sent in STREAM frames on all streams. total bytes of stream data sent in STREAM frames on all streams.
Senders MUST NOT send data in excess of either limit. Senders MUST NOT send data in excess of either limit.
A receiver sets initial limits for all streams through transport A receiver sets initial limits for all streams through transport
parameters during the handshake (Section 7.4). Subsequently, a parameters during the handshake (Section 7.4). Subsequently, a
receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA receiver sends MAX_STREAM_DATA frames (Section 19.10) or MAX_DATA
frames (Section 19.9) to the sender to advertise larger limits. frames (Section 19.9) to the sender to advertise larger limits.
skipping to change at page 28, line 10 skipping to change at line 1251
A QUIC connection is shared state between a client and a server. A QUIC connection is shared state between a client and a server.
Each connection starts with a handshake phase, during which the two Each connection starts with a handshake phase, during which the two
endpoints establish a shared secret using the cryptographic handshake endpoints establish a shared secret using the cryptographic handshake
protocol [QUIC-TLS] and negotiate the application protocol. The protocol [QUIC-TLS] and negotiate the application protocol. The
handshake (Section 7) confirms that both endpoints are willing to handshake (Section 7) confirms that both endpoints are willing to
communicate (Section 8.1) and establishes parameters for the communicate (Section 8.1) and establishes parameters for the
connection (Section 7.4). connection (Section 7.4).
An application protocol can use the connection during the handshake An application protocol can use the connection during the handshake
phase with some limitations. 0-RTT allows application data to be sent phase with some limitations. 0-RTT allows application data to be
by a client before receiving a response from the server. However, sent by a client before receiving a response from the server.
0-RTT provides no protection against replay attacks; see Section 9.2 However, 0-RTT provides no protection against replay attacks; see
of [QUIC-TLS]. A server can also send application data to a client Section 9.2 of [QUIC-TLS]. A server can also send application data
before it receives the final cryptographic handshake messages that to a client before it receives the final cryptographic handshake
allow it to confirm the identity and liveness of the client. These messages that allow it to confirm the identity and liveness of the
capabilities allow an application protocol to offer the option of client. These capabilities allow an application protocol to offer
trading some security guarantees for reduced latency. the option of trading some security guarantees for reduced latency.
The use of connection IDs (Section 5.1) allows connections to migrate The use of connection IDs (Section 5.1) allows connections to migrate
to a new network path, both as a direct choice of an endpoint and to a new network path, both as a direct choice of an endpoint and
when forced by a change in a middlebox. Section 9 describes when forced by a change in a middlebox. Section 9 describes
mitigations for the security and privacy issues associated with mitigations for the security and privacy issues associated with
migration. migration.
For connections that are no longer needed or desired, there are For connections that are no longer needed or desired, there are
several ways for a client and server to terminate a connection, as several ways for a client and server to terminate a connection, as
described in Section 10. described in Section 10.
skipping to change at page 34, line 26 skipping to change at line 1550
5.2.3. Considerations for Simple Load Balancers 5.2.3. Considerations for Simple Load Balancers
A server deployment could load-balance among servers using only A server deployment could load-balance among servers using only
source and destination IP addresses and ports. Changes to the source and destination IP addresses and ports. Changes to the
client's IP address or port could result in packets being forwarded client's IP address or port could result in packets being forwarded
to the wrong server. Such a server deployment could use one of the to the wrong server. Such a server deployment could use one of the
following methods for connection continuity when a client's address following methods for connection continuity when a client's address
changes. changes.
o Servers could use an out-of-band mechanism to forward packets to * Servers could use an out-of-band mechanism to forward packets to
the correct server based on connection ID. the correct server based on connection ID.
o If servers can use a dedicated server IP address or port, other * If servers can use a dedicated server IP address or port, other
than the one that the client initially connects to, they could use than the one that the client initially connects to, they could use
the preferred_address transport parameter to request that clients the preferred_address transport parameter to request that clients
move connections to that dedicated address. Note that clients move connections to that dedicated address. Note that clients
could choose not to use the preferred address. could choose not to use the preferred address.
A server in a deployment that does not implement a solution to A server in a deployment that does not implement a solution to
maintain connection continuity when the client address changes SHOULD maintain connection continuity when the client address changes SHOULD
indicate that migration is not supported by using the indicate that migration is not supported by using the
disable_active_migration transport parameter. The disable_active_migration transport parameter. The
disable_active_migration transport parameter does not prohibit disable_active_migration transport parameter does not prohibit
skipping to change at page 35, line 9 skipping to change at line 1582
This document does not define an API for QUIC; it instead defines a This document does not define an API for QUIC; it instead defines a
set of functions for QUIC connections that application protocols can set of functions for QUIC connections that application protocols can
rely upon. An application protocol can assume that an implementation rely upon. An application protocol can assume that an implementation
of QUIC provides an interface that includes the operations described of QUIC provides an interface that includes the operations described
in this section. An implementation designed for use with a specific in this section. An implementation designed for use with a specific
application protocol might provide only those operations that are application protocol might provide only those operations that are
used by that protocol. used by that protocol.
When implementing the client role, an application protocol can: When implementing the client role, an application protocol can:
o open a connection, which begins the exchange described in * open a connection, which begins the exchange described in
Section 7; Section 7;
o enable Early Data when available; and * enable Early Data when available; and
o be informed when Early Data has been accepted or rejected by a * be informed when Early Data has been accepted or rejected by a
server. server.
When implementing the server role, an application protocol can: When implementing the server role, an application protocol can:
o listen for incoming connections, which prepares for the exchange * listen for incoming connections, which prepares for the exchange
described in Section 7; described in Section 7;
o if Early Data is supported, embed application-controlled data in * if Early Data is supported, embed application-controlled data in
the TLS resumption ticket sent to the client; and the TLS resumption ticket sent to the client; and
o if Early Data is supported, retrieve application-controlled data * if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and accept or reject Early from the client's resumption ticket and accept or reject Early
Data based on that information. Data based on that information.
In either role, an application protocol can: In either role, an application protocol can:
o configure minimum values for the initial number of permitted * configure minimum values for the initial number of permitted
streams of each type, as communicated in the transport parameters streams of each type, as communicated in the transport parameters
(Section 7.4); (Section 7.4);
o control resource allocation for receive buffers by setting flow * control resource allocation for receive buffers by setting flow
control limits both for streams and for the connection; control limits both for streams and for the connection;
o identify whether the handshake has completed successfully or is * identify whether the handshake has completed successfully or is
still ongoing; still ongoing;
o keep a connection from silently closing, by either generating PING * keep a connection from silently closing, by either generating PING
frames (Section 19.2) or requesting that the transport send frames (Section 19.2) or requesting that the transport send
additional frames before the idle timeout expires (Section 10.1); additional frames before the idle timeout expires (Section 10.1);
and and
o immediately close (Section 10.2) the connection. * immediately close (Section 10.2) the connection.
6. Version Negotiation 6. Version Negotiation
Version negotiation allows a server to indicate that it does not Version negotiation allows a server to indicate that it does not
support the version the client used. A server sends a Version support the version the client used. A server sends a Version
Negotiation packet in response to each packet that might initiate a Negotiation packet in response to each packet that might initiate a
new connection; see Section 5.2 for details. new connection; see Section 5.2 for details.
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
skipping to change at page 37, line 44 skipping to change at line 1709
version of QUIC defined in this document is identified as 0x00000001 version of QUIC defined in this document is identified as 0x00000001
and uses TLS as described in [QUIC-TLS]; a different QUIC version and uses TLS as described in [QUIC-TLS]; a different QUIC version
could indicate that a different cryptographic handshake protocol is could indicate that a different cryptographic handshake protocol is
in use. in use.
QUIC provides reliable, ordered delivery of the cryptographic QUIC provides reliable, ordered delivery of the cryptographic
handshake data. QUIC packet protection is used to encrypt as much of handshake data. QUIC packet protection is used to encrypt as much of
the handshake protocol as possible. The cryptographic handshake MUST the handshake protocol as possible. The cryptographic handshake MUST
provide the following properties: provide the following properties:
o authenticated key exchange, where * authenticated key exchange, where
* a server is always authenticated, - a server is always authenticated,
* a client is optionally authenticated, - a client is optionally authenticated,
* every connection produces distinct and unrelated keys, and - every connection produces distinct and unrelated keys, and
* keying material is usable for packet protection for both 0-RTT
- keying material is usable for packet protection for both 0-RTT
and 1-RTT packets. and 1-RTT packets.
o authenticated exchange of values for transport parameters of both * authenticated exchange of values for transport parameters of both
endpoints, and confidentiality protection for server transport endpoints, and confidentiality protection for server transport
parameters (see Section 7.4). parameters (see Section 7.4).
o authenticated negotiation of an application protocol (TLS uses * authenticated negotiation of an application protocol (TLS uses
Application-Layer Protocol Negotiation (ALPN) [ALPN] for this Application-Layer Protocol Negotiation (ALPN) [ALPN] for this
purpose). purpose).
The CRYPTO frame can be sent in different packet number spaces The CRYPTO frame can be sent in different packet number spaces
(Section 12.3). The offsets used by CRYPTO frames to ensure ordered (Section 12.3). The offsets used by CRYPTO frames to ensure ordered
delivery of cryptographic handshake data start from zero in each delivery of cryptographic handshake data start from zero in each
packet number space. packet number space.
Figure 4 shows a simplified handshake and the exchange of packets and Figure 4 shows a simplified handshake and the exchange of packets and
frames that are used to advance the handshake. Exchange of frames that are used to advance the handshake. Exchange of
skipping to change at page 42, line 28 skipping to change at line 1934
An endpoint MUST treat the absence of the An endpoint MUST treat the absence of the
initial_source_connection_id transport parameter from either endpoint initial_source_connection_id transport parameter from either endpoint
or the absence of the original_destination_connection_id transport or the absence of the original_destination_connection_id transport
parameter from the server as a connection error of type parameter from the server as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
An endpoint MUST treat the following as a connection error of type An endpoint MUST treat the following as a connection error of type
TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION: TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
o absence of the retry_source_connection_id transport parameter from * absence of the retry_source_connection_id transport parameter from
the server after receiving a Retry packet, the server after receiving a Retry packet,
o presence of the retry_source_connection_id transport parameter * presence of the retry_source_connection_id transport parameter
when no Retry packet was received, or when no Retry packet was received, or
o a mismatch between values received from a peer in these transport * a mismatch between values received from a peer in these transport
parameters and the value sent in the corresponding Destination or parameters and the value sent in the corresponding Destination or
Source Connection ID fields of Initial packets. Source Connection ID fields of Initial packets.
If a zero-length connection ID is selected, the corresponding If a zero-length connection ID is selected, the corresponding
transport parameter is included with a zero-length value. transport parameter is included with a zero-length value.
Figure 7 shows the connection IDs (with DCID=Destination Connection Figure 7 shows the connection IDs (with DCID=Destination Connection
ID, SCID=Source Connection ID) that are used in a complete handshake. ID, SCID=Source Connection ID) that are used in a complete handshake.
The exchange of Initial packets is shown, plus the later exchange of The exchange of Initial packets is shown, plus the later exchange of
1-RTT packets that includes the connection ID established during the 1-RTT packets that includes the connection ID established during the
handshake. handshake.
Client Server Client Server
Initial: DCID=S1, SCID=C1 -> Initial: DCID=S1, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3 <- Initial: DCID=C1, SCID=S3
... ...
1-RTT: DCID=S3 -> 1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1 <- 1-RTT: DCID=C1
Figure 7: Use of Connection IDs in a Handshake Figure 7: Use of Connection IDs in a Handshake
Figure 8 shows a similar handshake that includes a Retry packet. Figure 8 shows a similar handshake that includes a Retry packet.
Client Server Client Server
Initial: DCID=S1, SCID=C1 -> Initial: DCID=S1, SCID=C1 ->
<- Retry: DCID=C1, SCID=S2 <- Retry: DCID=C1, SCID=S2
Initial: DCID=S2, SCID=C1 -> Initial: DCID=S2, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3 <- Initial: DCID=C1, SCID=S3
... ...
skipping to change at page 45, line 32 skipping to change at line 2077
integrity-protected copy of the values in the ticket and recover the integrity-protected copy of the values in the ticket and recover the
information when accepting 0-RTT data. A server uses the transport information when accepting 0-RTT data. A server uses the transport
parameters in determining whether to accept 0-RTT data. parameters in determining whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
with its 0-RTT data. In particular, a server that accepts 0-RTT data with its 0-RTT data. In particular, a server that accepts 0-RTT data
MUST NOT set values for the following parameters (Section 18.2) that MUST NOT set values for the following parameters (Section 18.2) that
are smaller than the remembered values of the parameters. are smaller than the remembered values of the parameters.
o active_connection_id_limit * active_connection_id_limit
o initial_max_data * initial_max_data
o initial_max_stream_data_bidi_local * initial_max_stream_data_bidi_local
o initial_max_stream_data_bidi_remote * initial_max_stream_data_bidi_remote
o initial_max_stream_data_uni * initial_max_stream_data_uni
o initial_max_streams_bidi * initial_max_streams_bidi
o initial_max_streams_uni * initial_max_streams_uni
Omitting or setting a zero value for certain transport parameters can Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled but not usable. The applicable result in 0-RTT data being enabled but not usable. The applicable
subset of transport parameters that permit the sending of application subset of transport parameters that permit the sending of application
data SHOULD be set to non-zero values for 0-RTT. This includes data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_data and either (1) initial_max_streams_bidi and initial_max_data and either (1) initial_max_streams_bidi and
initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni
and initial_max_stream_data_uni. and initial_max_stream_data_uni.
A server might provide larger initial stream flow control limits for A server might provide larger initial stream flow control limits for
skipping to change at page 50, line 31 skipping to change at line 2315
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
<- Retry+Token <- Retry+Token
Initial+Token[1]: CRYPTO[CH] -> Initial+Token[1]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[1] Initial[0]: CRYPTO[SH] ACK[1]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Figure 9: Example Handshake with Retry Figure 9: Example Handshake with Retry
8.1.3. Address Validation for Future Connections 8.1.3. Address Validation for Future Connections
A server MAY provide clients with an address validation token during A server MAY provide clients with an address validation token during
one connection that can be used on a subsequent connection. Address one connection that can be used on a subsequent connection. Address
validation is especially important with 0-RTT because a server validation is especially important with 0-RTT because a server
potentially sends a significant amount of data to a client in potentially sends a significant amount of data to a client in
response to 0-RTT data. response to 0-RTT data.
The server uses the NEW_TOKEN frame (Section 19.7) to provide the The server uses the NEW_TOKEN frame (Section 19.7) to provide the
skipping to change at page 52, line 21 skipping to change at line 2401
When a server receives an Initial packet with an address validation When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already token, it MUST attempt to validate the token, unless it has already
completed address validation. If the token is invalid, then the completed address validation. If the token is invalid, then the
server SHOULD proceed as if the client did not have a validated server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry packet. Tokens address, including potentially sending a Retry packet. Tokens
provided with NEW_TOKEN frames and Retry packets can be distinguished provided with NEW_TOKEN frames and Retry packets can be distinguished
by servers (see Section 8.1.1), and the latter can be validated more by servers (see Section 8.1.1), and the latter can be validated more
strictly. If the validation succeeds, the server SHOULD then allow strictly. If the validation succeeds, the server SHOULD then allow
the handshake to proceed. the handshake to proceed.
Note: The rationale for treating the client as unvalidated rather | Note: The rationale for treating the client as unvalidated
than discarding the packet is that the client might have received | rather than discarding the packet is that the client might have
the token in a previous connection using the NEW_TOKEN frame, and | received the token in a previous connection using the NEW_TOKEN
if the server has lost state, it might be unable to validate the | frame, and if the server has lost state, it might be unable to
token at all, leading to connection failure if the packet is | validate the token at all, leading to connection failure if the
discarded. | packet is discarded.
In a stateless design, a server can use encrypted and authenticated In a stateless design, a server can use encrypted and authenticated
tokens to pass information to clients that the server can later tokens to pass information to clients that the server can later
recover and use to validate a client address. Tokens are not recover and use to validate a client address. Tokens are not
integrated into the cryptographic handshake, and so they are not integrated into the cryptographic handshake, and so they are not
authenticated. For instance, a client might be able to reuse a authenticated. For instance, a client might be able to reuse a
token. To avoid attacks that exploit this property, a server can token. To avoid attacks that exploit this property, a server can
limit its use of tokens to only the information needed to validate limit its use of tokens to only the information needed to validate
client addresses. client addresses.
skipping to change at page 66, line 37 skipping to change at line 3085
labels ensures that changes are synchronized with changes in other labels ensures that changes are synchronized with changes in other
observable identifiers. A cryptographic hash function that combines observable identifiers. A cryptographic hash function that combines
these inputs with a local secret is one way this might be these inputs with a local secret is one way this might be
implemented. implemented.
10. Connection Termination 10. Connection Termination
An established QUIC connection can be terminated in one of three An established QUIC connection can be terminated in one of three
ways: ways:
o idle timeout (Section 10.1) * idle timeout (Section 10.1)
o immediate close (Section 10.2) * immediate close (Section 10.2)
o stateless reset (Section 10.3) * stateless reset (Section 10.3)
An endpoint MAY discard connection state if it does not have a An endpoint MAY discard connection state if it does not have a
validated path on which it can send packets; see Section 8.2. validated path on which it can send packets; see Section 8.2.
10.1. Idle Timeout 10.1. Idle Timeout
If a max_idle_timeout is specified by either endpoint in its If a max_idle_timeout is specified by either endpoint in its
transport parameters (Section 18.2), the connection is silently transport parameters (Section 18.2), the connection is silently
closed and its state is discarded when it remains idle for longer closed and its state is discarded when it remains idle for longer
than the minimum of the max_idle_timeout value advertised by both than the minimum of the max_idle_timeout value advertised by both
skipping to change at page 69, line 49 skipping to change at line 3242
state and send a packet containing a CONNECTION_CLOSE frame in state and send a packet containing a CONNECTION_CLOSE frame in
response to any UDP datagram that is received. However, an endpoint response to any UDP datagram that is received. However, an endpoint
that discards packet protection keys cannot identify and discard that discards packet protection keys cannot identify and discard
invalid packets. To avoid being used for an amplification attack, invalid packets. To avoid being used for an amplification attack,
such endpoints MUST limit the cumulative size of packets it sends to such endpoints MUST limit the cumulative size of packets it sends to
three times the cumulative size of the packets that are received and three times the cumulative size of the packets that are received and
attributed to the connection. To minimize the state that an endpoint attributed to the connection. To minimize the state that an endpoint
maintains for a closing connection, endpoints MAY send the exact same maintains for a closing connection, endpoints MAY send the exact same
packet in response to any received packet. packet in response to any received packet.
Note: Allowing retransmission of a closing packet is an exception | Note: Allowing retransmission of a closing packet is an
to the requirement that a new packet number be used for each | exception to the requirement that a new packet number be used
packet; see Section 12.3. Sending new packet numbers is primarily | for each packet; see Section 12.3. Sending new packet numbers
of advantage to loss recovery and congestion control, which are | is primarily of advantage to loss recovery and congestion
not expected to be relevant for a closed connection. | control, which are not expected to be relevant for a closed
Retransmitting the final packet requires less state. | connection. Retransmitting the final packet requires less
| state.
While in the closing state, an endpoint could receive packets from a While in the closing state, an endpoint could receive packets from a
new source address, possibly indicating a connection migration; see new source address, possibly indicating a connection migration; see
Section 9. An endpoint in the closing state MUST either discard Section 9. An endpoint in the closing state MUST either discard
packets received from an unvalidated address or limit the cumulative packets received from an unvalidated address or limit the cumulative
size of packets it sends to an unvalidated address to three times the size of packets it sends to an unvalidated address to three times the
size of packets it receives from that address. size of packets it receives from that address.
An endpoint is not expected to handle key updates when it is closing An endpoint is not expected to handle key updates when it is closing
(Section 6 of [QUIC-TLS]). A key update might prevent the endpoint (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint
skipping to change at page 71, line 9 skipping to change at line 3299
peer will process the frame. Generally, this means sending the frame peer will process the frame. Generally, this means sending the frame
in a packet with the highest level of packet protection to avoid the in a packet with the highest level of packet protection to avoid the
packet being discarded. After the handshake is confirmed (see packet being discarded. After the handshake is confirmed (see
Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any
CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to
confirming the handshake, it is possible that more advanced packet confirming the handshake, it is possible that more advanced packet
protection keys are not available to the peer, so another protection keys are not available to the peer, so another
CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower
packet protection level. More specifically: packet protection level. More specifically:
o A client will always know whether the server has Handshake keys * A client will always know whether the server has Handshake keys
(see Section 17.2.2.1), but it is possible that a server does not (see Section 17.2.2.1), but it is possible that a server does not
know whether the client has Handshake keys. Under these know whether the client has Handshake keys. Under these
circumstances, a server SHOULD send a CONNECTION_CLOSE frame in circumstances, a server SHOULD send a CONNECTION_CLOSE frame in
both Handshake and Initial packets to ensure that at least one of both Handshake and Initial packets to ensure that at least one of
them is processable by the client. them is processable by the client.
o A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet * A client that sends a CONNECTION_CLOSE frame in a 0-RTT packet
cannot be assured that the server has accepted 0-RTT. Sending a cannot be assured that the server has accepted 0-RTT. Sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the that the server can receive the close signal, even if the
application error code might not be received. application error code might not be received.
o Prior to confirming the handshake, a peer might be unable to * Prior to confirming the handshake, a peer might be unable to
process 1-RTT packets, so an endpoint SHOULD send a process 1-RTT packets, so an endpoint SHOULD send a
CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A CONNECTION_CLOSE frame in both Handshake and 1-RTT packets. A
server SHOULD also send a CONNECTION_CLOSE frame in an Initial server SHOULD also send a CONNECTION_CLOSE frame in an Initial
packet. packet.
Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake
packet could expose application state or be used to alter application packet could expose application state or be used to alter application
state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a
CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or
Handshake packets. Otherwise, information about the application Handshake packets. Otherwise, information about the application
skipping to change at page 72, line 52 skipping to change at line 3389
An endpoint that receives packets that it cannot process sends a An endpoint that receives packets that it cannot process sends a
packet in the following layout (see Section 1.3): packet in the following layout (see Section 1.3):
Stateless Reset { Stateless Reset {
Fixed Bits (2) = 1, Fixed Bits (2) = 1,
Unpredictable Bits (38..), Unpredictable Bits (38..),
Stateless Reset Token (128), Stateless Reset Token (128),
} }
Figure 10: Stateless Reset Figure 10: Stateless Reset
This design ensures that a Stateless Reset is -- to the extent This design ensures that a Stateless Reset is -- to the extent
possible -- indistinguishable from a regular packet with a short possible -- indistinguishable from a regular packet with a short
header. header.
A Stateless Reset uses an entire UDP datagram, starting with the A Stateless Reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it are set to values that and an arbitrary number of bytes following it are set to values that
SHOULD be indistinguishable from random. The last 16 bytes of the SHOULD be indistinguishable from random. The last 16 bytes of the
datagram contain a stateless reset token. datagram contain a stateless reset token.
skipping to change at page 74, line 24 skipping to change at line 3459
An endpoint cannot determine the Source Connection ID from a packet An endpoint cannot determine the Source Connection ID from a packet
with a short header, therefore it cannot set the Destination with a short header, therefore it cannot set the Destination
Connection ID in the Stateless Reset. The Destination Connection ID Connection ID in the Stateless Reset. The Destination Connection ID
will therefore differ from the value used in previous packets. A will therefore differ from the value used in previous packets. A
random Destination Connection ID makes the connection ID appear to be random Destination Connection ID makes the connection ID appear to be
the result of moving to a new connection ID that was provided using a the result of moving to a new connection ID that was provided using a
NEW_CONNECTION_ID frame; see Section 19.15. NEW_CONNECTION_ID frame; see Section 19.15.
Using a randomized connection ID results in two problems: Using a randomized connection ID results in two problems:
o The packet might not reach the peer. If the Destination * The packet might not reach the peer. If the Destination
Connection ID is critical for routing toward the peer, then this Connection ID is critical for routing toward the peer, then this
packet could be incorrectly routed. This might also trigger packet could be incorrectly routed. This might also trigger
another Stateless Reset in response; see Section 10.3.3. A another Stateless Reset in response; see Section 10.3.3. A
Stateless Reset that is not correctly routed is an ineffective Stateless Reset that is not correctly routed is an ineffective
error detection and recovery mechanism. In this case, endpoints error detection and recovery mechanism. In this case, endpoints
will need to rely on other methods -- such as timers -- to detect will need to rely on other methods -- such as timers -- to detect
that the connection has failed. that the connection has failed.
o The randomly generated connection ID can be used by entities other * The randomly generated connection ID can be used by entities other
than the peer to identify this as a potential Stateless Reset. An than the peer to identify this as a potential Stateless Reset. An
endpoint that occasionally uses different connection IDs might endpoint that occasionally uses different connection IDs might
introduce some uncertainty about this. introduce some uncertainty about this.
This stateless reset design is specific to QUIC version 1. An This stateless reset design is specific to QUIC version 1. An
endpoint that supports multiple versions of QUIC needs to generate a endpoint that supports multiple versions of QUIC needs to generate a
Stateless Reset that will be accepted by peers that support any Stateless Reset that will be accepted by peers that support any
version that the endpoint might support (or might have supported version that the endpoint might support (or might have supported
prior to losing state). Designers of new versions of QUIC need to be prior to losing state). Designers of new versions of QUIC need to be
aware of this and either (1) reuse this design or (2) use a portion aware of this and either (1) reuse this design or (2) use a portion
skipping to change at page 84, line 5 skipping to change at line 3883
Frame Type (i), Frame Type (i),
Type-Dependent Fields (..), Type-Dependent Fields (..),
} }
Figure 12: Generic Frame Layout Figure 12: Generic Frame Layout
Table 3 lists and summarizes information about each frame type that Table 3 lists and summarizes information about each frame type that
is defined in this specification. A description of this summary is is defined in this specification. A description of this summary is
included after the table. included after the table.
+------------+----------------------+----------------+------+------+ +============+======================+===============+======+======+
| Type Value | Frame Type Name | Definition | Pkts | Spec | | Type Value | Frame Type Name | Definition | Pkts | Spec |
+------------+----------------------+----------------+------+------+ +============+======================+===============+======+======+
| 0x00 | PADDING | Section 19.1 | IH01 | NP | | 0x00 | PADDING | Section 19.1 | IH01 | NP |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x01 | PING | Section 19.2 | IH01 | | | 0x01 | PING | Section 19.2 | IH01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC | | 0x02-0x03 | ACK | Section 19.3 | IH_1 | NC |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x04 | RESET_STREAM | Section 19.4 | __01 | | | 0x04 | RESET_STREAM | Section 19.4 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x05 | STOP_SENDING | Section 19.5 | __01 | | | 0x05 | STOP_SENDING | Section 19.5 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x06 | CRYPTO | Section 19.6 | IH_1 | | | 0x06 | CRYPTO | Section 19.6 | IH_1 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x07 | NEW_TOKEN | Section 19.7 | ___1 | | | 0x07 | NEW_TOKEN | Section 19.7 | ___1 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x08-0x0f | STREAM | Section 19.8 | __01 | F | | 0x08-0x0f | STREAM | Section 19.8 | __01 | F |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x10 | MAX_DATA | Section 19.9 | __01 | | | 0x10 | MAX_DATA | Section 19.9 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | | | 0x11 | MAX_STREAM_DATA | Section 19.10 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | | | 0x12-0x13 | MAX_STREAMS | Section 19.11 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x14 | DATA_BLOCKED | Section 19.12 | __01 | | | 0x14 | DATA_BLOCKED | Section 19.12 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | | | 0x15 | STREAM_DATA_BLOCKED | Section 19.13 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | | 0x16-0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P | | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | P |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P | | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P | | 0x1b | PATH_RESPONSE | Section 19.18 | ___1 | P |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N | | 0x1c-0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | N |
| | | | | | +------------+----------------------+---------------+------+------+
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |
+------------+----------------------+----------------+------+------+ +------------+----------------------+---------------+------+------+
Table 3: Frame Types Table 3: Frame Types
The format and semantics of each frame type are explained in more The format and semantics of each frame type are explained in more
detail in Section 19. The remainder of this section provides a detail in Section 19. The remainder of this section provides a
summary of important and general information. summary of important and general information.
The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
CONNECTION_CLOSE frames is used to carry other frame-specific flags. CONNECTION_CLOSE frames is used to carry other frame-specific flags.
For all other frames, the Frame Type field simply identifies the For all other frames, the Frame Type field simply identifies the
frame. frame.
skipping to change at page 86, line 33 skipping to change at line 4006
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
12.5. Frames and Number Spaces 12.5. Frames and Number Spaces
Some frames are prohibited in different packet number spaces. The Some frames are prohibited in different packet number spaces. The
rules here generalize those of TLS, in that frames associated with rules here generalize those of TLS, in that frames associated with
establishing the connection can usually appear in packets in any establishing the connection can usually appear in packets in any
packet number space, whereas those associated with transferring data packet number space, whereas those associated with transferring data
can only appear in the application data packet number space: can only appear in the application data packet number space:
o PADDING, PING, and CRYPTO frames MAY appear in any packet number * PADDING, PING, and CRYPTO frames MAY appear in any packet number
space. space.
o CONNECTION_CLOSE frames signaling errors at the QUIC layer (type * CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
0x1c) MAY appear in any packet number space. CONNECTION_CLOSE 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
frames signaling application errors (type 0x1d) MUST only appear frames signaling application errors (type 0x1d) MUST only appear
in the application data packet number space. in the application data packet number space.
o ACK frames MAY appear in any packet number space but can only * ACK frames MAY appear in any packet number space but can only
acknowledge packets that appeared in that packet number space. acknowledge packets that appeared in that packet number space.
However, as noted below, 0-RTT packets cannot contain ACK frames. However, as noted below, 0-RTT packets cannot contain ACK frames.
o All other frame types MUST only be sent in the application data * All other frame types MUST only be sent in the application data
packet number space. packet number space.
Note that it is not possible to send the following frames in 0-RTT Note that it is not possible to send the following frames in 0-RTT
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
skipping to change at page 88, line 27 skipping to change at line 4095
congestion response, but this has to be balanced against excessive congestion response, but this has to be balanced against excessive
load generated by a receiver that sends an ACK frame in response to load generated by a receiver that sends an ACK frame in response to
every ack-eliciting packet. The guidance offered below seeks to every ack-eliciting packet. The guidance offered below seeks to
strike this balance. strike this balance.
13.2.1. Sending ACK Frames 13.2.1. Sending ACK Frames
Every packet SHOULD be acknowledged at least once, and ack-eliciting Every packet SHOULD be acknowledged at least once, and ack-eliciting
packets MUST be acknowledged at least once within the maximum delay packets MUST be acknowledged at least once within the maximum delay
an endpoint communicated using the max_ack_delay transport parameter; an endpoint communicated using the max_ack_delay transport parameter;
see Section 18.2. max_ack_delay declares an explicit contract: an see Section 18.2. max_ack_delay declares an explicit contract: an
endpoint promises to never intentionally delay acknowledgments of an endpoint promises to never intentionally delay acknowledgments of an
ack-eliciting packet by more than the indicated value. If it does, ack-eliciting packet by more than the indicated value. If it does,
any excess accrues to the RTT estimate and could result in spurious any excess accrues to the RTT estimate and could result in spurious
or delayed retransmissions from the peer. A sender uses the or delayed retransmissions from the peer. A sender uses the
receiver's max_ack_delay value in determining timeouts for timer- receiver's max_ack_delay value in determining timeouts for timer-
based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY]. based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].
An endpoint MUST acknowledge all ack-eliciting Initial and Handshake An endpoint MUST acknowledge all ack-eliciting Initial and Handshake
packets immediately and all ack-eliciting 0-RTT and 1-RTT packets packets immediately and all ack-eliciting 0-RTT and 1-RTT packets
within its advertised max_ack_delay, with the following exception. within its advertised max_ack_delay, with the following exception.
skipping to change at page 89, line 24 skipping to change at line 4141
choose to occasionally add an ack-eliciting frame to those packets to choose to occasionally add an ack-eliciting frame to those packets to
ensure that it receives an acknowledgment; see Section 13.2.4. In ensure that it receives an acknowledgment; see Section 13.2.4. In
that case, an endpoint MUST NOT send an ack-eliciting frame in all that case, an endpoint MUST NOT send an ack-eliciting frame in all
packets that would otherwise be non-ack-eliciting, to avoid an packets that would otherwise be non-ack-eliciting, to avoid an
infinite feedback loop of acknowledgments. infinite feedback loop of acknowledgments.
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
generate and send an ACK frame without delay when it receives an ack- generate and send an ACK frame without delay when it receives an ack-
eliciting packet either: eliciting packet either:
o when the received packet has a packet number less than another * when the received packet has a packet number less than another
ack-eliciting packet that has been received, or ack-eliciting packet that has been received, or
o when the packet has a packet number larger than the highest- * when the packet has a packet number larger than the highest-
numbered ack-eliciting packet that has been received and there are numbered ack-eliciting packet that has been received and there are
missing packets between that packet and this packet. missing packets between that packet and this packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
The algorithms in [QUIC-RECOVERY] are expected to be resilient to The algorithms in [QUIC-RECOVERY] are expected to be resilient to
receivers that do not follow the guidance offered above. However, an receivers that do not follow the guidance offered above. However, an
implementation should only deviate from these requirements after implementation should only deviate from these requirements after
skipping to change at page 93, line 18 skipping to change at line 4324
whole. The same applies to the frames that are contained within lost whole. The same applies to the frames that are contained within lost
packets. Instead, the information that might be carried in frames is packets. Instead, the information that might be carried in frames is
sent again in new frames as needed. sent again in new frames as needed.
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
when a packet containing that information is determined to be lost, when a packet containing that information is determined to be lost,
and sending ceases when a packet containing that information is and sending ceases when a packet containing that information is
acknowledged. acknowledged.
o Data sent in CRYPTO frames is retransmitted according to the rules * Data sent in CRYPTO frames is retransmitted according to the rules
in [QUIC-RECOVERY], until all data has been acknowledged. Data in in [QUIC-RECOVERY], until all data has been acknowledged. Data in
CRYPTO frames for Initial and Handshake packets is discarded when CRYPTO frames for Initial and Handshake packets is discarded when
keys for the corresponding packet number space are discarded. keys for the corresponding packet number space are discarded.
o Application data sent in STREAM frames is retransmitted in new * Application data sent in STREAM frames is retransmitted in new
STREAM frames unless the endpoint has sent a RESET_STREAM for that STREAM frames unless the endpoint has sent a RESET_STREAM for that
stream. Once an endpoint sends a RESET_STREAM frame, no further stream. Once an endpoint sends a RESET_STREAM frame, no further
STREAM frames are needed. STREAM frames are needed.
o ACK frames carry the most recent set of acknowledgments and the * ACK frames carry the most recent set of acknowledgments and the
acknowledgment delay from the largest acknowledged packet, as acknowledgment delay from the largest acknowledged packet, as
described in Section 13.2.1. Delaying the transmission of packets described in Section 13.2.1. Delaying the transmission of packets
containing ACK frames or resending old ACK frames can cause the containing ACK frames or resending old ACK frames can cause the
peer to generate an inflated RTT sample or unnecessarily disable peer to generate an inflated RTT sample or unnecessarily disable
ECN. ECN.
o Cancellation of stream transmission, as carried in a RESET_STREAM * Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the sending part of the stream). "Data Recvd" state is reached on the sending part of the stream).
The content of a RESET_STREAM frame MUST NOT change when it is The content of a RESET_STREAM frame MUST NOT change when it is
sent again. sent again.
o Similarly, a request to cancel stream transmission, as encoded in * Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the a STOP_SENDING frame, is sent until the receiving part of the
stream enters either a "Data Recvd" or "Reset Recvd" state; see stream enters either a "Data Recvd" or "Reset Recvd" state; see
Section 3.5. Section 3.5.
o Connection close signals, including packets that contain * Connection close signals, including packets that contain
CONNECTION_CLOSE frames, are not sent again when packet loss is CONNECTION_CLOSE frames, are not sent again when packet loss is
detected. Resending these signals is described in Section 10. detected. Resending these signals is described in Section 10.
o The current connection maximum data is sent in MAX_DATA frames. * The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost containing the most recently sent MAX_DATA frame is declared lost
or when the endpoint decides to update the limit. Care is or when the endpoint decides to update the limit. Care is
necessary to avoid sending this frame too often, as the limit can necessary to avoid sending this frame too often, as the limit can
increase frequently and cause an unnecessarily large number of increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent; see Section 4.2. MAX_DATA frames to be sent; see Section 4.2.
o The current maximum stream data offset is sent in MAX_STREAM_DATA * The current maximum stream data offset is sent in MAX_STREAM_DATA
frames. Like MAX_DATA, an updated value is sent when the packet frames. Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the lost or when the limit is updated, with care taken to prevent the
frame from being sent too often. An endpoint SHOULD stop sending frame from being sent too often. An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receiving part of the stream MAX_STREAM_DATA frames when the receiving part of the stream
enters a "Size Known" or "Reset Recvd" state. enters a "Size Known" or "Reset Recvd" state.
o The limit on streams of a given type is sent in MAX_STREAMS * The limit on streams of a given type is sent in MAX_STREAMS
frames. Like MAX_DATA, an updated value is sent when a packet frames. Like MAX_DATA, an updated value is sent when a packet
containing the most recent MAX_STREAMS for a stream type frame is containing the most recent MAX_STREAMS for a stream type frame is
declared lost or when the limit is updated, with care taken to declared lost or when the limit is updated, with care taken to
prevent the frame from being sent too often. prevent the frame from being sent too often.
o Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED, * Blocked signals are carried in DATA_BLOCKED, STREAM_DATA_BLOCKED,
and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection and STREAMS_BLOCKED frames. DATA_BLOCKED frames have connection
scope, STREAM_DATA_BLOCKED frames have stream scope, and scope, STREAM_DATA_BLOCKED frames have stream scope, and
STREAMS_BLOCKED frames are scoped to a specific stream type. A STREAMS_BLOCKED frames are scoped to a specific stream type. A
new frame is sent if a packet containing the most recent frame for new frame is sent if a packet containing the most recent frame for
a scope is lost, but only while the endpoint is blocked on the a scope is lost, but only while the endpoint is blocked on the
corresponding limit. These frames always include the limit that corresponding limit. These frames always include the limit that
is causing blocking at the time that they are transmitted. is causing blocking at the time that they are transmitted.
o A liveness or path validation check using PATH_CHALLENGE frames is * A liveness or path validation check using PATH_CHALLENGE frames is
sent periodically until a matching PATH_RESPONSE frame is received sent periodically until a matching PATH_RESPONSE frame is received
or until there is no remaining need for liveness or path or until there is no remaining need for liveness or path
validation checking. PATH_CHALLENGE frames include a different validation checking. PATH_CHALLENGE frames include a different
payload each time they are sent. payload each time they are sent.
o Responses to path validation using PATH_RESPONSE frames are sent * Responses to path validation using PATH_RESPONSE frames are sent
just once. The peer is expected to send more PATH_CHALLENGE just once. The peer is expected to send more PATH_CHALLENGE
frames as necessary to evoke additional PATH_RESPONSE frames. frames as necessary to evoke additional PATH_RESPONSE frames.
o New connection IDs are sent in NEW_CONNECTION_ID frames and * New connection IDs are sent in NEW_CONNECTION_ID frames and
retransmitted if the packet containing them is lost. retransmitted if the packet containing them is lost.
Retransmissions of this frame carry the same sequence number Retransmissions of this frame carry the same sequence number
value. Likewise, retired connection IDs are sent in value. Likewise, retired connection IDs are sent in
RETIRE_CONNECTION_ID frames and retransmitted if the packet RETIRE_CONNECTION_ID frames and retransmitted if the packet
containing them is lost. containing them is lost.
o NEW_TOKEN frames are retransmitted if the packet containing them * NEW_TOKEN frames are retransmitted if the packet containing them
is lost. No special support is made for detecting reordered and is lost. No special support is made for detecting reordered and
duplicated NEW_TOKEN frames other than a direct comparison of the duplicated NEW_TOKEN frames other than a direct comparison of the
frame contents. frame contents.
o PING and PADDING frames contain no information, so lost PING or * PING and PADDING frames contain no information, so lost PING or
PADDING frames do not require repair. PADDING frames do not require repair.
o The HANDSHAKE_DONE frame MUST be retransmitted until it is * The HANDSHAKE_DONE frame MUST be retransmitted until it is
acknowledged. acknowledged.
Endpoints SHOULD prioritize retransmission of data over sending new Endpoints SHOULD prioritize retransmission of data over sending new
data, unless priorities specified by the application indicate data, unless priorities specified by the application indicate
otherwise; see Section 2.3. otherwise; see Section 2.3.
Even though a sender is encouraged to assemble frames containing up- Even though a sender is encouraged to assemble frames containing up-
to-date information every time it sends a packet, it is not forbidden to-date information every time it sends a packet, it is not forbidden
to retransmit copies of frames from lost packets. A sender that to retransmit copies of frames from lost packets. A sender that
retransmits copies of frames needs to handle decreases in available retransmits copies of frames needs to handle decreases in available
skipping to change at page 97, line 5 skipping to change at line 4501
13.4.2. ECN Validation 13.4.2. ECN Validation
It is possible for faulty network devices to corrupt or erroneously It is possible for faulty network devices to corrupt or erroneously
drop packets that carry a non-zero ECN codepoint. To ensure drop packets that carry a non-zero ECN codepoint. To ensure
connectivity in the presence of such devices, an endpoint validates connectivity in the presence of such devices, an endpoint validates
the ECN counts for each network path and disables the use of ECN on the ECN counts for each network path and disables the use of ECN on
that path if errors are detected. that path if errors are detected.
To perform ECN validation for a new path: To perform ECN validation for a new path:
o The endpoint sets an ECT(0) codepoint in the IP header of early * The endpoint sets an ECT(0) codepoint in the IP header of early
outgoing packets sent on a new path to the peer [RFC8311]. outgoing packets sent on a new path to the peer [RFC8311].
o The endpoint monitors whether all packets sent with an ECT * The endpoint monitors whether all packets sent with an ECT
codepoint are eventually deemed lost (Section 6 of codepoint are eventually deemed lost (Section 6 of
[QUIC-RECOVERY]), indicating that ECN validation has failed. [QUIC-RECOVERY]), indicating that ECN validation has failed.
If an endpoint has cause to expect that IP packets with an ECT If an endpoint has cause to expect that IP packets with an ECT
codepoint might be dropped by a faulty network element, the endpoint codepoint might be dropped by a faulty network element, the endpoint
could set an ECT codepoint for only the first ten outgoing packets on could set an ECT codepoint for only the first ten outgoing packets on
a path, or for a period of three PTOs (see Section 6.2 of a path, or for a period of three PTOs (see Section 6.2 of
[QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints [QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints
are subsequently lost, it can disable marking on the assumption that are subsequently lost, it can disable marking on the assumption that
the marking caused the loss. the marking caused the loss.
skipping to change at page 99, line 15 skipping to change at line 4607
maximum datagram size of at least 1200 bytes. maximum datagram size of at least 1200 bytes.
QUIC assumes a minimum IP packet size of at least 1280 bytes. This QUIC assumes a minimum IP packet size of at least 1280 bytes. This
is the IPv6 minimum size [IPv6] and is also supported by most modern is the IPv6 minimum size [IPv6] and is also supported by most modern
IPv4 networks. Assuming the minimum IP header size of 40 bytes for IPv4 networks. Assuming the minimum IP header size of 40 bytes for
IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this
results in a maximum datagram size of 1232 bytes for IPv6 and 1252 results in a maximum datagram size of 1232 bytes for IPv6 and 1252
bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are
expected to be able to support QUIC. expected to be able to support QUIC.
Note: This requirement to support a UDP payload of 1200 bytes | Note: This requirement to support a UDP payload of 1200 bytes
limits the space available for IPv6 extension headers to 32 bytes | limits the space available for IPv6 extension headers to 32
or IPv4 options to 52 bytes if the path only supports the IPv6 | bytes or IPv4 options to 52 bytes if the path only supports the
minimum MTU of 1280 bytes. This affects Initial packets and path | IPv6 minimum MTU of 1280 bytes. This affects Initial packets
validation. | and path validation.
Any maximum datagram size larger than 1200 bytes can be discovered Any maximum datagram size larger than 1200 bytes can be discovered
using Path Maximum Transmission Unit Discovery (PMTUD) (see using Path Maximum Transmission Unit Discovery (PMTUD) (see
Section 14.2.1) or Datagram Packetization Layer PMTU Discovery Section 14.2.1) or Datagram Packetization Layer PMTU Discovery
(DPLPMTUD) (see Section 14.3). (DPLPMTUD) (see Section 14.3).
Enforcement of the max_udp_payload_size transport parameter Enforcement of the max_udp_payload_size transport parameter
(Section 18.2) might act as an additional limit on the maximum (Section 18.2) might act as an additional limit on the maximum
datagram size. A sender can avoid exceeding this limit, once the datagram size. A sender can avoid exceeding this limit, once the
value is known. However, prior to learning the value of the value is known. However, prior to learning the value of the
skipping to change at page 103, line 30 skipping to change at line 4815
One way to construct a PMTU probe is to coalesce (see Section 12.2) a One way to construct a PMTU probe is to coalesce (see Section 12.2) a
packet with a long header, such as a Handshake or 0-RTT packet packet with a long header, such as a Handshake or 0-RTT packet
(Section 17.2), with a short header packet in a single UDP datagram. (Section 17.2), with a short header packet in a single UDP datagram.
If the resulting PMTU probe reaches the endpoint, the packet with the If the resulting PMTU probe reaches the endpoint, the packet with the
long header will be ignored, but the short header packet will be long header will be ignored, but the short header packet will be
acknowledged. If the PMTU probe causes an ICMP message to be sent, acknowledged. If the PMTU probe causes an ICMP message to be sent,
the first part of the probe will be quoted in that message. If the the first part of the probe will be quoted in that message. If the
Source Connection ID field is within the quoted portion of the probe, Source Connection ID field is within the quoted portion of the probe,
that could be used for routing or validation of the ICMP message. that could be used for routing or validation of the ICMP message.
Note: The purpose of using a packet with a long header is only to | Note: The purpose of using a packet with a long header is only
ensure that the quoted packet contained in the ICMP message | to ensure that the quoted packet contained in the ICMP message
contains a Source Connection ID field. This packet does not need | contains a Source Connection ID field. This packet does not
to be a valid packet, and it can be sent even if there is no | need to be a valid packet, and it can be sent even if there is
current use for packets of that type. | no current use for packets of that type.
15. Versions 15. Versions
QUIC versions are identified using a 32-bit unsigned number. QUIC versions are identified using a 32-bit unsigned number.
The version 0x00000000 is reserved to represent version negotiation. The version 0x00000000 is reserved to represent version negotiation.
This version of the specification is identified by the number This version of the specification is identified by the number
0x00000001. 0x00000001.
Other versions of QUIC might have different properties from this Other versions of QUIC might have different properties from this
skipping to change at page 104, line 35 skipping to change at line 4867
The QUIC variable-length integer encoding reserves the two most The QUIC variable-length integer encoding reserves the two most
significant bits of the first byte to encode the base-2 logarithm of significant bits of the first byte to encode the base-2 logarithm of
the integer encoding length in bytes. The integer value is encoded the integer encoding length in bytes. The integer value is encoded
on the remaining bits, in network byte order. on the remaining bits, in network byte order.
This means that integers are encoded on 1, 2, 4, or 8 bytes and can This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4 encode 6-, 14-, 30-, or 62-bit values, respectively. Table 4
summarizes the encoding properties. summarizes the encoding properties.
+------+--------+-------------+-----------------------+ +======+========+=============+=======================+
| 2MSB | Length | Usable Bits | Range | | 2MSB | Length | Usable Bits | Range |
+------+--------+-------------+-----------------------+ +======+========+=============+=======================+
| 00 | 1 | 6 | 0-63 | | 00 | 1 | 6 | 0-63 |
| | | | | +------+--------+-------------+-----------------------+
| 01 | 2 | 14 | 0-16383 | | 01 | 2 | 14 | 0-16383 |
| | | | | +------+--------+-------------+-----------------------+
| 10 | 4 | 30 | 0-1073741823 | | 10 | 4 | 30 | 0-1073741823 |
| | | | | +------+--------+-------------+-----------------------+
| 11 | 8 | 62 | 0-4611686018427387903 | | 11 | 8 | 62 | 0-4611686018427387903 |
+------+--------+-------------+-----------------------+ +------+--------+-------------+-----------------------+
Table 4: Summary of Integer Encodings Table 4: Summary of Integer Encodings
An example of a decoding algorithm and sample encodings are shown in An example of a decoding algorithm and sample encodings are shown in
Appendix A.1. Appendix A.1.
Values do not need to be encoded on the minimum number of bytes Values do not need to be encoded on the minimum number of bytes
necessary, with the sole exception of the Frame Type field; see necessary, with the sole exception of the Frame Type field; see
skipping to change at page 106, line 34 skipping to change at line 4960
Long Packet Type (2), Long Packet Type (2),
Type-Specific Bits (4), Type-Specific Bits (4),
Version (32), Version (32),
Destination Connection ID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
Source Connection ID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Type-Specific Payload (..), Type-Specific Payload (..),
} }
Figure 13: Long Header Packet Format Figure 13: Long Header Packet Format
Long headers are used for packets that are sent prior to the Long headers are used for packets that are sent prior to the
establishment of 1-RTT keys. Once 1-RTT keys are available, a sender establishment of 1-RTT keys. Once 1-RTT keys are available, a sender
switches to sending packets using the short header (Section 17.3). switches to sending packets using the short header (Section 17.3).
The long form allows for special packets -- such as the Version The long form allows for special packets -- such as the Version
Negotiation packet -- to be represented in this uniform fixed-length Negotiation packet -- to be represented in this uniform fixed-length
packet format. Packets that use the long header contain the packet format. Packets that use the long header contain the
following fields: following fields:
Header Form: The most significant bit (0x80) of byte 0 (the first Header Form: The most significant bit (0x80) of byte 0 (the first
skipping to change at page 108, line 5 skipping to change at line 5023
Source Connection ID Length field, which indicates the length of Source Connection ID Length field, which indicates the length of
this field. Section 7.2 describes the use of this field in more this field. Section 7.2 describes the use of this field in more
detail. detail.
Type-Specific Payload: The remainder of the packet, if any, is type Type-Specific Payload: The remainder of the packet, if any, is type
specific. specific.
In this version of QUIC, the following packet types with the long In this version of QUIC, the following packet types with the long
header are defined: header are defined:
+------+-----------+-----------------+ +======+===========+================+
| Type | Name | Section | | Type | Name | Section |
+------+-----------+-----------------+ +======+===========+================+
| 0x00 | Initial | Section 17.2.2 | | 0x00 | Initial | Section 17.2.2 |
| | | | +------+-----------+----------------+
| 0x01 | 0-RTT | Section 17.2.3 | | 0x01 | 0-RTT | Section 17.2.3 |
| | | | +------+-----------+----------------+
| 0x02 | Handshake | Section 17.2.4 | | 0x02 | Handshake | Section 17.2.4 |
| | | | +------+-----------+----------------+
| 0x03 | Retry | Section 17.2.5 | | 0x03 | Retry | Section 17.2.5 |
+------+-----------+-----------------+ +------+-----------+----------------+
Table 5: Long Header Packet Types Table 5: Long Header Packet Types
The header form bit, Destination and Source Connection ID lengths, The header form bit, Destination and Source Connection ID lengths,
Destination and Source Connection ID fields, and Version fields of a Destination and Source Connection ID fields, and Version fields of a
long header packet are version independent. The other fields in the long header packet are version independent. The other fields in the
first byte are version specific. See [QUIC-INVARIANTS] for details first byte are version specific. See [QUIC-INVARIANTS] for details
on how packets from different versions of QUIC are interpreted. on how packets from different versions of QUIC are interpreted.
The interpretation of the fields and the payload are specific to a The interpretation of the fields and the payload are specific to a
skipping to change at page 113, line 24 skipping to change at line 5267
Version (32), Version (32),
Destination Connection ID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
Source Connection ID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Length (i), Length (i),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (8..), Packet Payload (8..),
} }
0-RTT Packet Figure 16: 0-RTT Packet
Packet numbers for 0-RTT protected packets use the same space as Packet numbers for 0-RTT protected packets use the same space as
1-RTT protected packets. 1-RTT protected packets.
After a client receives a Retry packet, 0-RTT packets are likely to After a client receives a Retry packet, 0-RTT packets are likely to
have been lost or discarded by the server. A client SHOULD attempt have been lost or discarded by the server. A client SHOULD attempt
to resend data in 0-RTT packets after it sends a new Initial packet. to resend data in 0-RTT packets after it sends a new Initial packet.
New packet numbers MUST be used for any new packets that are sent; as New packet numbers MUST be used for any new packets that are sent; as
described in Section 17.2.5.3, reusing packet numbers could described in Section 17.2.5.3, reusing packet numbers could
compromise packet protection. compromise packet protection.
skipping to change at page 114, line 29 skipping to change at line 5317
Version (32), Version (32),
Destination Connection ID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
Source Connection ID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Length (i), Length (i),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (8..), Packet Payload (8..),
} }
Figure 16: Handshake Protected Packet Figure 17: Handshake Protected Packet
Once a client has received a Handshake packet from a server, it uses Once a client has received a Handshake packet from a server, it uses
Handshake packets to send subsequent cryptographic handshake messages Handshake packets to send subsequent cryptographic handshake messages
and acknowledgments to the server. and acknowledgments to the server.
The Destination Connection ID field in a Handshake packet contains a The Destination Connection ID field in a Handshake packet contains a
connection ID that is chosen by the recipient of the packet; the connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of Source Connection ID includes the connection ID that the sender of
the packet wishes to use; see Section 7.2. the packet wishes to use; see Section 7.2.
skipping to change at page 115, line 7 skipping to change at line 5344
CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt
of Handshake packets with other frames as a connection error of type of Handshake packets with other frames as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
for Handshake packets is discarded -- and no longer retransmitted -- for Handshake packets is discarded -- and no longer retransmitted --
when Handshake protection keys are discarded. when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
As shown in Figure 17, a Retry packet uses a long packet header with As shown in Figure 18, a Retry packet uses a long packet header with
a type value of 0x03. It carries an address validation token created a type value of 0x03. It carries an address validation token created
by the server. It is used by a server that wishes to perform a by the server. It is used by a server that wishes to perform a
retry; see Section 8.1. retry; see Section 8.1.
Retry Packet { Retry Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 3, Long Packet Type (2) = 3,
Unused (4), Unused (4),
Version (32), Version (32),
Destination Connection ID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
Source Connection ID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Retry Token (..), Retry Token (..),
Retry Integrity Tag (128), Retry Integrity Tag (128),
} }
Figure 17: Retry Packet Figure 18: Retry Packet
A Retry packet does not contain any protected fields. The value in A Retry packet does not contain any protected fields. The value in
the Unused field is set to an arbitrary value by the server; a client the Unused field is set to an arbitrary value by the server; a client
MUST ignore these bits. In addition to the fields from the long MUST ignore these bits. In addition to the fields from the long
header, it contains these additional fields: header, it contains these additional fields:
Retry Token: An opaque token that the server can use to validate the Retry Token: An opaque token that the server can use to validate the
client's address. client's address.
Retry Integrity Tag: Defined in Section "Retry Packet Integrity" Retry Integrity Tag: Defined in Section 5.8 ("Retry Packet
[QUIC-TLS] of [QUIC-TLS]. Integrity") of [QUIC-TLS].
17.2.5.1. Sending a Retry Packet 17.2.5.1. Sending a Retry Packet
The server populates the Destination Connection ID with the The server populates the Destination Connection ID with the
connection ID that the client included in the Source Connection ID of connection ID that the client included in the Source Connection ID of
the Initial packet. the Initial packet.
The server includes a connection ID of its choice in the Source 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. This value MUST NOT be equal to the Destination
Connection ID field of the packet sent by the client. A client MUST Connection ID field of the packet sent by the client. A client MUST
skipping to change at page 118, line 17 skipping to change at line 5487
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Spin Bit (1), Spin Bit (1),
Reserved Bits (2), Reserved Bits (2),
Key Phase (1), Key Phase (1),
Packet Number Length (2), Packet Number Length (2),
Destination Connection ID (0..160), Destination Connection ID (0..160),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (8..), Packet Payload (8..),
} }
1-RTT Packet Figure 19: 1-RTT Packet
1-RTT packets contain the following fields: 1-RTT packets contain the following fields:
Header Form: The most significant bit (0x80) of byte 0 is set to 0 Header Form: The most significant bit (0x80) of byte 0 is set to 0
for the short header. for the short header.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. A value of 1 for this bit allows version and MUST be discarded. A value of 1 for this bit allows
QUIC to coexist with other protocols; see [RFC7983]. QUIC to coexist with other protocols; see [RFC7983].
skipping to change at page 120, line 42 skipping to change at line 5609
bit in the received packet. bit in the received packet.
An endpoint resets the spin value for a network path to 0 when An endpoint resets the spin value for a network path to 0 when
changing the connection ID being used on that network path. changing the connection ID being used on that network path.
18. Transport Parameter Encoding 18. Transport Parameter Encoding
The extension_data field of the quic_transport_parameters extension The extension_data field of the quic_transport_parameters extension
defined in [QUIC-TLS] contains the QUIC transport parameters. They defined in [QUIC-TLS] contains the QUIC transport parameters. They
are encoded as a sequence of transport parameters, as shown in are encoded as a sequence of transport parameters, as shown in
Figure 18: Figure 20:
Transport Parameters { Transport Parameters {
Transport Parameter (..) ..., Transport Parameter (..) ...,
} }
Figure 18: Sequence of Transport Parameters Figure 20: Sequence of Transport Parameters
Each transport parameter is encoded as an (identifier, length, value) Each transport parameter is encoded as an (identifier, length, value)
tuple, as shown in Figure 19: tuple, as shown in Figure 21:
Transport Parameter { Transport Parameter {
Transport Parameter ID (i), Transport Parameter ID (i),
Transport Parameter Length (i), Transport Parameter Length (i),
Transport Parameter Value (..), Transport Parameter Value (..),
} }
Figure 19: Transport Parameter Encoding Figure 21: Transport Parameter Encoding
The Transport Parameter Length field contains the length of the The Transport Parameter Length field contains the length of the
Transport Parameter Value field in bytes. Transport Parameter Value field in bytes.
QUIC encodes transport parameters into a sequence of bytes, which is QUIC encodes transport parameters into a sequence of bytes, which is
then included in the cryptographic handshake. then included in the cryptographic handshake.
18.1. Reserved Transport Parameters 18.1. Reserved Transport Parameters
Transport parameters with an identifier of the form "31 * N + 27" for Transport parameters with an identifier of the form "31 * N + 27" for
skipping to change at page 124, line 21 skipping to change at line 5780
encoded in network byte order. encoded in network byte order.
The preferred_address transport parameter contains an address and The preferred_address transport parameter contains an address and
port for both IPv4 and IPv6. The four-byte IPv4 Address field is port for both IPv4 and IPv6. The four-byte IPv4 Address field is
followed by the associated two-byte IPv4 Port field. This is followed by the associated two-byte IPv4 Port field. This is
followed by a 16-byte IPv6 Address field and two-byte IPv6 Port followed by a 16-byte IPv6 Address field and two-byte IPv6 Port
field. After address and port pairs, a Connection ID Length field field. After address and port pairs, a Connection ID Length field
describes the length of the following Connection ID field. describes the length of the following Connection ID field.
Finally, a 16-byte Stateless Reset Token field includes the Finally, a 16-byte Stateless Reset Token field includes the
stateless reset token associated with the connection ID. The stateless reset token associated with the connection ID. The
format of this transport parameter is shown in Figure 20 below. format of this transport parameter is shown in Figure 22 below.
The Connection ID field and the Stateless Reset Token field The Connection ID field and the Stateless Reset Token field
contain an alternative connection ID that has a sequence number of contain an alternative connection ID that has a sequence number of
1; see Section 5.1.1. Having these values sent alongside the 1; see Section 5.1.1. Having these values sent alongside the
preferred address ensures that there will be at least one unused preferred address ensures that there will be at least one unused
active connection ID when the client initiates migration to the active connection ID when the client initiates migration to the
preferred address. preferred address.
The Connection ID and Stateless Reset Token fields of a preferred The Connection ID and Stateless Reset Token fields of a preferred
address are identical in syntax and semantics to the corresponding address are identical in syntax and semantics to the corresponding
skipping to change at page 124, line 49 skipping to change at line 5808
Preferred Address { Preferred Address {
IPv4 Address (32), IPv4 Address (32),
IPv4 Port (16), IPv4 Port (16),
IPv6 Address (128), IPv6 Address (128),
IPv6 Port (16), IPv6 Port (16),
Connection ID Length (8), Connection ID Length (8),
Connection ID (..), Connection ID (..),
Stateless Reset Token (128), Stateless Reset Token (128),
} }
Figure 20: Preferred Address Format Figure 22: Preferred Address Format
active_connection_id_limit (0x0e): This is an integer value active_connection_id_limit (0x0e): This is an integer value
specifying the maximum number of connection IDs from the peer that specifying the maximum number of connection IDs from the peer that
an endpoint is willing to store. This value includes the an endpoint is willing to store. This value includes the
connection ID received during the handshake, that received in the connection ID received during the handshake, that received in the
preferred_address transport parameter, and those received in preferred_address transport parameter, and those received in
NEW_CONNECTION_ID frames. The value of the NEW_CONNECTION_ID frames. The value of the
active_connection_id_limit parameter MUST be at least 2. An active_connection_id_limit parameter MUST be at least 2. An
endpoint that receives a value less than 2 MUST close the endpoint that receives a value less than 2 MUST close the
connection with an error of type TRANSPORT_PARAMETER_ERROR. If connection with an error of type TRANSPORT_PARAMETER_ERROR. If
skipping to change at page 126, line 5 skipping to change at line 5859
This section describes the format and semantics of the core QUIC This section describes the format and semantics of the core QUIC
frame types. frame types.
19.1. PADDING Frames 19.1. PADDING Frames
A PADDING frame (type=0x00) has no semantic value. PADDING frames A PADDING frame (type=0x00) has no semantic value. PADDING frames
can be used to increase the size of a packet. Padding can be used to can be used to increase the size of a packet. Padding can be used to
increase an Initial packet to the minimum required size or to provide increase an Initial packet to the minimum required size or to provide
protection against traffic analysis for protected packets. protection against traffic analysis for protected packets.
PADDING frames are formatted as shown in Figure 21, which shows that PADDING frames are formatted as shown in Figure 23, which shows that
PADDING frames have no content. That is, a PADDING frame consists of PADDING frames have no content. That is, a PADDING frame consists of
the single byte that identifies the frame as a PADDING frame. the single byte that identifies the frame as a PADDING frame.
PADDING Frame { PADDING Frame {
Type (i) = 0x00, Type (i) = 0x00,
} }
Figure 21: PADDING Frame Format Figure 23: PADDING Frame Format
19.2. PING Frames 19.2. PING Frames
Endpoints can use PING frames (type=0x01) to verify that their peers Endpoints can use PING frames (type=0x01) to verify that their peers
are still alive or to check reachability to the peer. are still alive or to check reachability to the peer.
PING frames are formatted as shown in Figure 22, which shows that PING frames are formatted as shown in Figure 24, which shows that
PING frames have no content. PING frames have no content.
PING Frame { PING Frame {
Type (i) = 0x01, Type (i) = 0x01,
} }
Figure 22: PING Frame Format Figure 24: PING Frame Format
The receiver of a PING frame simply needs to acknowledge the packet The receiver of a PING frame simply needs to acknowledge the packet
containing this frame. containing this frame.
The PING frame can be used to keep a connection alive when an The PING frame can be used to keep a connection alive when an
application or application protocol wishes to prevent the connection application or application protocol wishes to prevent the connection
from timing out; see Section 10.1.2. from timing out; see Section 10.1.2.
19.3. ACK Frames 19.3. ACK Frames
skipping to change at page 127, line 16 skipping to change at line 5918
the same numeric value. An acknowledgment for a packet needs to the same numeric value. An acknowledgment for a packet needs to
indicate both a packet number and a packet number space. This is indicate both a packet number and a packet number space. This is
accomplished by having each ACK frame only acknowledge packet numbers accomplished by having each ACK frame only acknowledge packet numbers
in the same space as the packet in which the ACK frame is contained. in the same space as the packet in which the ACK frame is contained.
Version Negotiation and Retry packets cannot be acknowledged because Version Negotiation and Retry packets cannot be acknowledged because
they do not contain a packet number. Rather than relying on ACK they do not contain a packet number. Rather than relying on ACK
frames, these packets are implicitly acknowledged by the next Initial frames, these packets are implicitly acknowledged by the next Initial
packet sent by the client. packet sent by the client.
ACK frames are formatted as shown in Figure 23. ACK frames are formatted as shown in Figure 25.
ACK Frame { ACK Frame {
Type (i) = 0x02..0x03, Type (i) = 0x02..0x03,
Largest Acknowledged (i), Largest Acknowledged (i),
ACK Delay (i), ACK Delay (i),
ACK Range Count (i), ACK Range Count (i),
First ACK Range (i), First ACK Range (i),
ACK Range (..) ..., ACK Range (..) ...,
[ECN Counts (..)], [ECN Counts (..)],
} }
Figure 23: ACK Frame Format Figure 25: ACK Frame Format
ACK frames contain the following fields: ACK frames contain the following fields:
Largest Acknowledged: A variable-length integer representing the Largest Acknowledged: A variable-length integer representing the
largest packet number the peer is acknowledging; this is usually largest packet number the peer is acknowledging; this is usually
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer encoding the acknowledgment ACK Delay: A variable-length integer encoding the acknowledgment
skipping to change at page 128, line 21 skipping to change at line 5972
ECN Counts: The three ECN Counts; see Section 19.3.2. ECN Counts: The three ECN Counts; see Section 19.3.2.
19.3.1. ACK Ranges 19.3.1. ACK Ranges
Each ACK Range consists of alternating Gap and ACK Range Length Each ACK Range consists of alternating Gap and ACK Range Length
values in descending packet number order. ACK Ranges can be values in descending packet number order. ACK Ranges can be
repeated. The number of Gap and ACK Range Length values is repeated. The number of Gap and ACK Range Length values is
determined by the ACK Range Count field; one of each value is present determined by the ACK Range Count field; one of each value is present
for each value in the ACK Range Count field. for each value in the ACK Range Count field.
ACK Ranges are structured as shown in Figure 24. ACK Ranges are structured as shown in Figure 26.
ACK Range { ACK Range {
Gap (i), Gap (i),
ACK Range Length (i), ACK Range Length (i),
} }
Figure 24: ACK Ranges Figure 26: ACK Ranges
The fields that form each ACK Range are: The fields that form each ACK Range are:
Gap: A variable-length integer indicating the number of contiguous Gap: A variable-length integer indicating the number of contiguous
unacknowledged packets preceding the packet number one lower than unacknowledged packets preceding the packet number one lower than
the smallest in the preceding ACK Range. the smallest in the preceding ACK Range.
ACK Range Length: A variable-length integer indicating the number of ACK Range Length: A variable-length integer indicating the number of
contiguous acknowledged packets preceding the largest packet contiguous acknowledged packets preceding the largest packet
number, as determined by the preceding Gap. number, as determined by the preceding Gap.
skipping to change at page 129, line 35 skipping to change at line 6033
a connection error of type FRAME_ENCODING_ERROR. a connection error of type FRAME_ENCODING_ERROR.
19.3.2. ECN Counts 19.3.2. ECN Counts
The ACK frame uses the least significant bit of the type value (that The ACK frame uses the least significant bit of the type value (that
is, type 0x03) to indicate ECN feedback and report receipt of QUIC is, type 0x03) to indicate ECN feedback and report receipt of QUIC
packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE
in the packet's IP header. ECN Counts are only present when the ACK in the packet's IP header. ECN Counts are only present when the ACK
frame type is 0x03. frame type is 0x03.
When present, there are three ECN counts, as shown in Figure 25. When present, there are three ECN counts, as shown in Figure 27.
ECN Counts { ECN Counts {
ECT0 Count (i), ECT0 Count (i),
ECT1 Count (i), ECT1 Count (i),
ECN-CE Count (i), ECN-CE Count (i),
} }
Figure 25: ECN Count Format Figure 27: ECN Count Format
The three ECN Counts are: The three ECN Counts are:
ECT0 Count: A variable-length integer representing the total number ECT0 Count: A variable-length integer representing the total number
of packets received with the ECT(0) codepoint in the packet number of packets received with the ECT(0) codepoint in the packet number
space of the ACK frame. space of the ACK frame.
ECT1 Count: A variable-length integer representing the total number ECT1 Count: A variable-length integer representing the total number
of packets received with the ECT(1) codepoint in the packet number of packets received with the ECT(1) codepoint in the packet number
space of the ACK frame. space of the ACK frame.
skipping to change at page 130, line 28 skipping to change at line 6072
terminate the sending part of a stream. terminate the sending part of a stream.
After sending a RESET_STREAM, an endpoint ceases transmission and After sending a RESET_STREAM, an endpoint ceases transmission and
retransmission of STREAM frames on the identified stream. A receiver retransmission of STREAM frames on the identified stream. A receiver
of RESET_STREAM can discard any data that it already received on that of RESET_STREAM can discard any data that it already received on that
stream. stream.
An endpoint that receives a RESET_STREAM frame for a send-only stream An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
RESET_STREAM frames are formatted as shown in Figure 26. RESET_STREAM frames are formatted as shown in Figure 28.
RESET_STREAM Frame { RESET_STREAM Frame {
Type (i) = 0x04, Type (i) = 0x04,
Stream ID (i), Stream ID (i),
Application Protocol Error Code (i), Application Protocol Error Code (i),
Final Size (i), Final Size (i),
} }
Figure 26: RESET_STREAM Frame Format Figure 28: RESET_STREAM Frame Format
RESET_STREAM frames contain the following fields: RESET_STREAM frames contain the following fields:
Stream ID: A variable-length integer encoding of the stream ID of Stream ID: A variable-length integer encoding of the stream ID of
the stream being terminated. the stream being terminated.
Application Protocol Error Code: A variable-length integer Application Protocol Error Code: A variable-length integer
containing the application protocol error code (see Section 20.2) containing the application protocol error code (see Section 20.2)
that indicates why the stream is being closed. that indicates why the stream is being closed.
skipping to change at page 131, line 18 skipping to change at line 6109
incoming data is being discarded on receipt per application request. incoming data is being discarded on receipt per application request.
STOP_SENDING requests that a peer cease transmission on a stream. STOP_SENDING requests that a peer cease transmission on a stream.
A STOP_SENDING frame can be sent for streams in the "Recv" or "Size A STOP_SENDING frame can be sent for streams in the "Recv" or "Size
Known" states; see Section 3.2. Receiving a STOP_SENDING frame for a Known" states; see Section 3.2. Receiving a STOP_SENDING frame for a
locally initiated stream that has not yet been created MUST be locally initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR. An treated as a connection error of type STREAM_STATE_ERROR. An
endpoint that receives a STOP_SENDING frame for a receive-only stream endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
STOP_SENDING frames are formatted as shown in Figure 27. STOP_SENDING frames are formatted as shown in Figure 29.
STOP_SENDING Frame { STOP_SENDING Frame {
Type (i) = 0x05, Type (i) = 0x05,
Stream ID (i), Stream ID (i),
Application Protocol Error Code (i), Application Protocol Error Code (i),
} }
Figure 27: STOP_SENDING Frame Format Figure 29: STOP_SENDING Frame Format
STOP_SENDING frames contain the following fields: STOP_SENDING frames contain the following fields:
Stream ID: A variable-length integer carrying the stream ID of the Stream ID: A variable-length integer carrying the stream ID of the
stream being ignored. stream being ignored.
Application Protocol Error Code: A variable-length integer Application Protocol Error Code: A variable-length integer
containing the application-specified reason the sender is ignoring containing the application-specified reason the sender is ignoring
the stream; see Section 20.2. the stream; see Section 20.2.
19.6. CRYPTO Frames 19.6. CRYPTO Frames
A CRYPTO frame (type=0x06) is used to transmit cryptographic A CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages. It can be sent in all packet types except 0-RTT. handshake messages. It can be sent in all packet types except 0-RTT.
The CRYPTO frame offers the cryptographic protocol an in-order stream The CRYPTO frame offers the cryptographic protocol an in-order stream
of bytes. CRYPTO frames are functionally identical to STREAM frames, of bytes. CRYPTO frames are functionally identical to STREAM frames,
except that they do not bear a stream identifier; they are not flow except that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset, controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream. optional length, and the end of the stream.
CRYPTO frames are formatted as shown in Figure 28. CRYPTO frames are formatted as shown in Figure 30.
CRYPTO Frame { CRYPTO Frame {
Type (i) = 0x06, Type (i) = 0x06,
Offset (i), Offset (i),
Length (i), Length (i),
Crypto Data (..), Crypto Data (..),
} }
Figure 28: CRYPTO Frame Format Figure 30: CRYPTO Frame Format
CRYPTO frames contain the following fields: CRYPTO frames contain the following fields:
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this CRYPTO frame. stream for the data in this CRYPTO frame.
Length: A variable-length integer specifying the length of the Length: A variable-length integer specifying the length of the
Crypto Data field in this CRYPTO frame. Crypto Data field in this CRYPTO frame.
Crypto Data: The cryptographic message data. Crypto Data: The cryptographic message data.
skipping to change at page 132, line 45 skipping to change at line 6180
stream the data belongs, the CRYPTO frame carries data for a single stream the data belongs, the CRYPTO frame carries data for a single
stream per encryption level. The stream does not have an explicit stream per encryption level. The stream does not have an explicit
end, so CRYPTO frames do not have a FIN bit. end, so CRYPTO frames do not have a FIN bit.
19.7. NEW_TOKEN Frames 19.7. NEW_TOKEN Frames
A server sends a NEW_TOKEN frame (type=0x07) to provide the client A server sends a NEW_TOKEN frame (type=0x07) to provide the client
with a token to send in the header of an Initial packet for a future with a token to send in the header of an Initial packet for a future
connection. connection.
NEW_TOKEN frames are formatted as shown in Figure 29. NEW_TOKEN frames are formatted as shown in Figure 31.
NEW_TOKEN Frame { NEW_TOKEN Frame {
Type (i) = 0x07, Type (i) = 0x07,
Token Length (i), Token Length (i),
Token (..), Token (..),
} }
Figure 29: NEW_TOKEN Frame Format Figure 31: NEW_TOKEN Frame Format
NEW_TOKEN frames contain the following fields: NEW_TOKEN frames contain the following fields:
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
token in bytes. token in bytes.
Token: An opaque blob that the client can use with a future Initial Token: An opaque blob that the client can use with a future Initial
packet. The token MUST NOT be empty. A client MUST treat receipt packet. The token MUST NOT be empty. A client MUST treat receipt
of a NEW_TOKEN frame with an empty Token field as a connection of a NEW_TOKEN frame with an empty Token field as a connection
error of type FRAME_ENCODING_ERROR. error of type FRAME_ENCODING_ERROR.
skipping to change at page 133, line 40 skipping to change at line 6217
of a NEW_TOKEN frame as a connection error of type of a NEW_TOKEN frame as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
19.8. STREAM Frames 19.8. STREAM Frames
STREAM frames implicitly create a stream and carry stream data. The STREAM frames implicitly create a stream and carry stream data. The
Type field in the STREAM frame takes the form 0b00001XXX (or the set Type field in the STREAM frame takes the form 0b00001XXX (or the set
of values from 0x08 to 0x0f). The three low-order bits of the frame of values from 0x08 to 0x0f). The three low-order bits of the frame
type determine the fields that are present in the frame: type determine the fields that are present in the frame:
o The OFF bit (0x04) in the frame type is set to indicate that there * The OFF bit (0x04) in the frame type is set to indicate that there
is an Offset field present. When set to 1, the Offset field is is an Offset field present. When set to 1, the Offset field is
present. When set to 0, the Offset field is absent and the Stream present. When set to 0, the Offset field is absent and the Stream
Data starts at an offset of 0 (that is, the frame contains the Data starts at an offset of 0 (that is, the frame contains the
first bytes of the stream, or the end of a stream that includes no first bytes of the stream, or the end of a stream that includes no
data). data).
o The LEN bit (0x02) in the frame type is set to indicate that there * The LEN bit (0x02) in the frame type is set to indicate that there
is a Length field present. If this bit is set to 0, the Length is a Length field present. If this bit is set to 0, the Length
field is absent and the Stream Data field extends to the end of field is absent and the Stream Data field extends to the end of
the packet. If this bit is set to 1, the Length field is present. the packet. If this bit is set to 1, the Length field is present.
o The FIN bit (0x01) indicates that the frame marks the end of the * The FIN bit (0x01) indicates that the frame marks the end of the
stream. The final size of the stream is the sum of the offset and stream. The final size of the stream is the sum of the offset and
the length of this frame. the length of this frame.
An endpoint MUST terminate the connection with error An endpoint MUST terminate the connection with error
STREAM_STATE_ERROR if it receives a STREAM frame for a locally STREAM_STATE_ERROR if it receives a STREAM frame for a locally
initiated stream that has not yet been created, or for a send-only initiated stream that has not yet been created, or for a send-only
stream. stream.
STREAM frames are formatted as shown in Figure 30. STREAM frames are formatted as shown in Figure 32.
STREAM Frame { STREAM Frame {
Type (i) = 0x08..0x0f, Type (i) = 0x08..0x0f,
Stream ID (i), Stream ID (i),
[Offset (i)], [Offset (i)],
[Length (i)], [Length (i)],
Stream Data (..), Stream Data (..),
} }
Figure 30: STREAM Frame Format Figure 32: STREAM Frame Format
STREAM frames contain the following fields: STREAM frames contain the following fields:
Stream ID: A variable-length integer indicating the stream ID of the Stream ID: A variable-length integer indicating the stream ID of the
stream; see Section 2.1. stream; see Section 2.1.
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this STREAM frame. This field is present stream for the data in this STREAM frame. This field is present
when the OFF bit is set to 1. When the Offset field is absent, when the OFF bit is set to 1. When the Offset field is absent,
the offset is 0. the offset is 0.
skipping to change at page 135, line 11 skipping to change at line 6283
credit for that data. Receipt of a frame that exceeds this limit credit for that data. Receipt of a frame that exceeds this limit
MUST be treated as a connection error of type FRAME_ENCODING_ERROR or MUST be treated as a connection error of type FRAME_ENCODING_ERROR or
FLOW_CONTROL_ERROR. FLOW_CONTROL_ERROR.
19.9. MAX_DATA Frames 19.9. MAX_DATA Frames
A MAX_DATA frame (type=0x10) is used in flow control to inform the A MAX_DATA frame (type=0x10) is used in flow control to inform the
peer of the maximum amount of data that can be sent on the connection peer of the maximum amount of data that can be sent on the connection
as a whole. as a whole.
MAX_DATA frames are formatted as shown in Figure 31. MAX_DATA frames are formatted as shown in Figure 33.
MAX_DATA Frame { MAX_DATA Frame {
Type (i) = 0x10, Type (i) = 0x10,
Maximum Data (i), Maximum Data (i),
} }
Figure 31: MAX_DATA Frame Format Figure 33: MAX_DATA Frame Format
MAX_DATA frames contain the following field: MAX_DATA frames contain the following field:
Maximum Data: A variable-length integer indicating the maximum Maximum Data: A variable-length integer indicating the maximum
amount of data that can be sent on the entire connection, in units amount of data that can be sent on the entire connection, in units
of bytes. of bytes.
All data sent in STREAM frames counts toward this limit. The sum of All data sent in STREAM frames counts toward this limit. The sum of
the final sizes on all streams -- including streams in terminal the final sizes on all streams -- including streams in terminal
states -- MUST NOT exceed the value advertised by a receiver. An states -- MUST NOT exceed the value advertised by a receiver. An
skipping to change at page 135, line 46 skipping to change at line 6318
A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform
a peer of the maximum amount of data that can be sent on a stream. a peer of the maximum amount of data that can be sent on a stream.
A MAX_STREAM_DATA frame can be sent for streams in the "Recv" state; A MAX_STREAM_DATA frame can be sent for streams in the "Recv" state;
see Section 3.2. Receiving a MAX_STREAM_DATA frame for a locally see Section 3.2. Receiving a MAX_STREAM_DATA frame for a locally
initiated stream that has not yet been created MUST be treated as a initiated stream that has not yet been created MUST be treated as a
connection error of type STREAM_STATE_ERROR. An endpoint that connection error of type STREAM_STATE_ERROR. An endpoint that
receives a MAX_STREAM_DATA frame for a receive-only stream MUST receives a MAX_STREAM_DATA frame for a receive-only stream MUST
terminate the connection with error STREAM_STATE_ERROR. terminate the connection with error STREAM_STATE_ERROR.
MAX_STREAM_DATA frames are formatted as shown in Figure 32. MAX_STREAM_DATA frames are formatted as shown in Figure 34.
MAX_STREAM_DATA Frame { MAX_STREAM_DATA Frame {
Type (i) = 0x11, Type (i) = 0x11,
Stream ID (i), Stream ID (i),
Maximum Stream Data (i), Maximum Stream Data (i),
} }
Figure 32: MAX_STREAM_DATA Frame Format Figure 34: MAX_STREAM_DATA Frame Format
MAX_STREAM_DATA frames contain the following fields: MAX_STREAM_DATA frames contain the following fields:
Stream ID: The stream ID of the affected stream, encoded as a Stream ID: The stream ID of the affected stream, encoded as a
variable-length integer. variable-length integer.
Maximum Stream Data: A variable-length integer indicating the Maximum Stream Data: A variable-length integer indicating the
maximum amount of data that can be sent on the identified stream, maximum amount of data that can be sent on the identified stream,
in units of bytes. in units of bytes.
skipping to change at page 136, line 44 skipping to change at line 6359
in Early Data; see Section 7.4.1. in Early Data; see Section 7.4.1.
19.11. MAX_STREAMS Frames 19.11. MAX_STREAMS Frames
A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the A MAX_STREAMS frame (type=0x12 or 0x13) informs the peer of the
cumulative number of streams of a given type it is permitted to open. cumulative number of streams of a given type it is permitted to open.
A MAX_STREAMS frame with a type of 0x12 applies to bidirectional A MAX_STREAMS frame with a type of 0x12 applies to bidirectional
streams, and a MAX_STREAMS frame with a type of 0x13 applies to streams, and a MAX_STREAMS frame with a type of 0x13 applies to
unidirectional streams. unidirectional streams.
MAX_STREAMS frames are formatted as shown in Figure 33. MAX_STREAMS frames are formatted as shown in Figure 35.
MAX_STREAMS Frame { MAX_STREAMS Frame {
Type (i) = 0x12..0x13, Type (i) = 0x12..0x13,
Maximum Streams (i), Maximum Streams (i),
} }
Figure 33: MAX_STREAMS Frame Format Figure 35: MAX_STREAMS Frame Format
MAX_STREAMS frames contain the following field: MAX_STREAMS frames contain the following field:
Maximum Streams: A count of the cumulative number of streams of the Maximum Streams: A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the corresponding type that can be opened over the lifetime of the
connection. This value cannot exceed 2^60, as it is not possible connection. This value cannot exceed 2^60, as it is not possible
to encode stream IDs larger than 2^62-1. Receipt of a frame that to encode stream IDs larger than 2^62-1. Receipt of a frame that
permits opening of a stream larger than this limit MUST be treated permits opening of a stream larger than this limit MUST be treated
as a connection error of type FRAME_ENCODING_ERROR. as a connection error of type FRAME_ENCODING_ERROR.
skipping to change at page 137, line 39 skipping to change at line 6402
concurrently. The limit includes streams that have been closed as concurrently. The limit includes streams that have been closed as
well as those that are open. well as those that are open.
19.12. DATA_BLOCKED Frames 19.12. DATA_BLOCKED Frames
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
to send data but is unable to do so due to connection-level flow to send data but is unable to do so due to connection-level flow
control; see Section 4. DATA_BLOCKED frames can be used as input to control; see Section 4. DATA_BLOCKED frames can be used as input to
tuning of flow control algorithms; see Section 4.2. tuning of flow control algorithms; see Section 4.2.
DATA_BLOCKED frames are formatted as shown in Figure 34. DATA_BLOCKED frames are formatted as shown in Figure 36.
DATA_BLOCKED Frame { DATA_BLOCKED Frame {
Type (i) = 0x14, Type (i) = 0x14,
Maximum Data (i), Maximum Data (i),
} }
Figure 34: DATA_BLOCKED Frame Format Figure 36: DATA_BLOCKED Frame Format
DATA_BLOCKED frames contain the following field: DATA_BLOCKED frames contain the following field:
Maximum Data: A variable-length integer indicating the connection- Maximum Data: A variable-length integer indicating the connection-
level limit at which blocking occurred. level limit at which blocking occurred.
19.13. STREAM_DATA_BLOCKED Frames 19.13. STREAM_DATA_BLOCKED Frames
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data but is unable to do so due to stream-level flow wishes to send data but is unable to do so due to stream-level flow
control. This frame is analogous to DATA_BLOCKED (Section 19.12). control. This frame is analogous to DATA_BLOCKED (Section 19.12).
An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
stream MUST terminate the connection with error STREAM_STATE_ERROR. stream MUST terminate the connection with error STREAM_STATE_ERROR.
STREAM_DATA_BLOCKED frames are formatted as shown in Figure 35. STREAM_DATA_BLOCKED frames are formatted as shown in Figure 37.
STREAM_DATA_BLOCKED Frame { STREAM_DATA_BLOCKED Frame {
Type (i) = 0x15, Type (i) = 0x15,
Stream ID (i), Stream ID (i),
Maximum Stream Data (i), Maximum Stream Data (i),
} }
Figure 35: STREAM_DATA_BLOCKED Frame Format Figure 37: STREAM_DATA_BLOCKED Frame Format
STREAM_DATA_BLOCKED frames contain the following fields: STREAM_DATA_BLOCKED frames contain the following fields:
Stream ID: A variable-length integer indicating the stream that is Stream ID: A variable-length integer indicating the stream that is
blocked due to flow control. blocked due to flow control.
Maximum Stream Data: A variable-length integer indicating the offset Maximum Stream Data: A variable-length integer indicating the offset
of the stream at which the blocking occurred. of the stream at which the blocking occurred.
19.14. STREAMS_BLOCKED Frames 19.14. STREAMS_BLOCKED Frames
skipping to change at page 138, line 45 skipping to change at line 6456
it wishes to open a stream but is unable to do so due to the maximum it wishes to open a stream but is unable to do so due to the maximum
stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED
frame of type 0x16 is used to indicate reaching the bidirectional frame of type 0x16 is used to indicate reaching the bidirectional
stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to
indicate reaching the unidirectional stream limit. indicate reaching the unidirectional stream limit.
A STREAMS_BLOCKED frame does not open the stream, but informs the A STREAMS_BLOCKED frame does not open the stream, but informs the
peer that a new stream was needed and the stream limit prevented the peer that a new stream was needed and the stream limit prevented the
creation of the stream. creation of the stream.
STREAMS_BLOCKED frames are formatted as shown in Figure 36. STREAMS_BLOCKED frames are formatted as shown in Figure 38.
STREAMS_BLOCKED Frame { STREAMS_BLOCKED Frame {
Type (i) = 0x16..0x17, Type (i) = 0x16..0x17,
Maximum Streams (i), Maximum Streams (i),
} }
Figure 36: STREAMS_BLOCKED Frame Format Figure 38: STREAMS_BLOCKED Frame Format
STREAMS_BLOCKED frames contain the following field: STREAMS_BLOCKED frames contain the following field:
Maximum Streams: A variable-length integer indicating the maximum Maximum Streams: A variable-length integer indicating the maximum
number of streams allowed at the time the frame was sent. This number of streams allowed at the time the frame was sent. This
value cannot exceed 2^60, as it is not possible to encode stream value cannot exceed 2^60, as it is not possible to encode stream
IDs larger than 2^62-1. Receipt of a frame that encodes a larger IDs larger than 2^62-1. Receipt of a frame that encodes a larger
stream ID MUST be treated as a connection error of type stream ID MUST be treated as a connection error of type
STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR. STREAM_LIMIT_ERROR or FRAME_ENCODING_ERROR.
19.15. NEW_CONNECTION_ID Frames 19.15. NEW_CONNECTION_ID Frames
An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
its peer with alternative connection IDs that can be used to break its peer with alternative connection IDs that can be used to break
linkability when migrating connections; see Section 9.5. linkability when migrating connections; see Section 9.5.
NEW_CONNECTION_ID frames are formatted as shown in Figure 37. NEW_CONNECTION_ID frames are formatted as shown in Figure 39.
NEW_CONNECTION_ID Frame { NEW_CONNECTION_ID Frame {
Type (i) = 0x18, Type (i) = 0x18,
Sequence Number (i), Sequence Number (i),
Retire Prior To (i), Retire Prior To (i),
Length (8), Length (8),
Connection ID (8..160), Connection ID (8..160),
Stateless Reset Token (128), Stateless Reset Token (128),
} }
Figure 37: NEW_CONNECTION_ID Frame Format Figure 39: NEW_CONNECTION_ID Frame Format
NEW_CONNECTION_ID frames contain the following fields: NEW_CONNECTION_ID frames contain the following fields:
Sequence Number: The sequence number assigned to the connection ID Sequence Number: The sequence number assigned to the connection ID
by the sender, encoded as a variable-length integer; see by the sender, encoded as a variable-length integer; see
Section 5.1.1. Section 5.1.1.
Retire Prior To: A variable-length integer indicating which Retire Prior To: A variable-length integer indicating which
connection IDs should be retired; see Section 5.1.2. connection IDs should be retired; see Section 5.1.2.
skipping to change at page 141, line 10 skipping to change at line 6566
indicate that it will no longer use a connection ID that was issued indicate that it will no longer use a connection ID that was issued
by its peer. This includes the connection ID provided during the by its peer. This includes the connection ID provided during the
handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use; request to the peer to send additional connection IDs for future use;
see Section 5.1. New connection IDs can be delivered to a peer using see Section 5.1. New connection IDs can be delivered to a peer using
the NEW_CONNECTION_ID frame (Section 19.15). the NEW_CONNECTION_ID frame (Section 19.15).
Retiring a connection ID invalidates the stateless reset token Retiring a connection ID invalidates the stateless reset token
associated with that connection ID. associated with that connection ID.
RETIRE_CONNECTION_ID frames are formatted as shown in Figure 38. RETIRE_CONNECTION_ID frames are formatted as shown in Figure 40.
RETIRE_CONNECTION_ID Frame { RETIRE_CONNECTION_ID Frame {
Type (i) = 0x19, Type (i) = 0x19,
Sequence Number (i), Sequence Number (i),
} }
Figure 38: RETIRE_CONNECTION_ID Frame Format Figure 40: RETIRE_CONNECTION_ID Frame Format
RETIRE_CONNECTION_ID frames contain the following field: RETIRE_CONNECTION_ID frames contain the following field:
Sequence Number: The sequence number of the connection ID being Sequence Number: The sequence number of the connection ID being
retired; see Section 5.1.2. retired; see Section 5.1.2.
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
greater than any previously sent to the peer MUST be treated as a greater than any previously sent to the peer MUST be treated as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
skipping to change at page 141, line 44 skipping to change at line 6600
length connection ID by its peer. An endpoint that provides a zero- length connection ID by its peer. An endpoint that provides a zero-
length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
frame as a connection error of type PROTOCOL_VIOLATION. frame as a connection error of type PROTOCOL_VIOLATION.
19.17. PATH_CHALLENGE Frames 19.17. PATH_CHALLENGE Frames
Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
reachability to the peer and for path validation during connection reachability to the peer and for path validation during connection
migration. migration.
PATH_CHALLENGE frames are formatted as shown in Figure 39. PATH_CHALLENGE frames are formatted as shown in Figure 41.
PATH_CHALLENGE Frame { PATH_CHALLENGE Frame {
Type (i) = 0x1a, Type (i) = 0x1a,
Data (64), Data (64),
} }
Figure 39: PATH_CHALLENGE Frame Format Figure 41: PATH_CHALLENGE Frame Format
PATH_CHALLENGE frames contain the following field: PATH_CHALLENGE frames contain the following field:
Data: This 8-byte field contains arbitrary data. Data: This 8-byte field contains arbitrary data.
Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that
it is easier to receive the packet than it is to guess the value it is easier to receive the packet than it is to guess the value
correctly. correctly.
The recipient of this frame MUST generate a PATH_RESPONSE frame The recipient of this frame MUST generate a PATH_RESPONSE frame
(Section 19.18) containing the same Data value. (Section 19.18) containing the same Data value.
19.18. PATH_RESPONSE Frames 19.18. PATH_RESPONSE Frames
A PATH_RESPONSE frame (type=0x1b) is sent in response to a A PATH_RESPONSE frame (type=0x1b) is sent in response to a
PATH_CHALLENGE frame. PATH_CHALLENGE frame.
PATH_RESPONSE frames are formatted as shown in Figure 40. The format PATH_RESPONSE frames are formatted as shown in Figure 42. The format
of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE of a PATH_RESPONSE frame is identical to that of the PATH_CHALLENGE
frame; see Section 19.17. frame; see Section 19.17.
PATH_RESPONSE Frame { PATH_RESPONSE Frame {
Type (i) = 0x1b, Type (i) = 0x1b,
Data (64), Data (64),
} }
Figure 40: PATH_RESPONSE Frame Format Figure 42: PATH_RESPONSE Frame Format
If the content of a PATH_RESPONSE frame does not match the content of If the content of a PATH_RESPONSE frame does not match the content of
a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint
MAY generate a connection error of type PROTOCOL_VIOLATION. MAY generate a connection error of type PROTOCOL_VIOLATION.
19.19. CONNECTION_CLOSE Frames 19.19. CONNECTION_CLOSE Frames
An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to
notify its peer that the connection is being closed. The notify its peer that the connection is being closed. The
CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors CONNECTION_CLOSE frame with a type of 0x1c is used to signal errors
at only the QUIC layer, or the absence of errors (with the NO_ERROR at only the QUIC layer, or the absence of errors (with the NO_ERROR
code). The CONNECTION_CLOSE frame with a type of 0x1d is used to code). The CONNECTION_CLOSE frame with a type of 0x1d is used to
signal an error with the application that uses QUIC. signal an error with the application that uses QUIC.
If there are open streams that have not been explicitly closed, they If there are open streams that have not been explicitly closed, they
are implicitly closed when the connection is closed. are implicitly closed when the connection is closed.
CONNECTION_CLOSE frames are formatted as shown in Figure 41. CONNECTION_CLOSE frames are formatted as shown in Figure 43.
CONNECTION_CLOSE Frame { CONNECTION_CLOSE Frame {
Type (i) = 0x1c..0x1d, Type (i) = 0x1c..0x1d,
Error Code (i), Error Code (i),
[Frame Type (i)], [Frame Type (i)],
Reason Phrase Length (i), Reason Phrase Length (i),
Reason Phrase (..), Reason Phrase (..),
} }
Figure 41: CONNECTION_CLOSE Frame Format Figure 43: CONNECTION_CLOSE Frame Format
CONNECTION_CLOSE frames contain the following fields: CONNECTION_CLOSE frames contain the following fields:
Error Code: A variable-length integer that indicates the reason for Error Code: A variable-length integer that indicates the reason for
closing this connection. A CONNECTION_CLOSE frame of type 0x1c closing this connection. A CONNECTION_CLOSE frame of type 0x1c
uses codes from the space defined in Section 20.1. A uses codes from the space defined in Section 20.1. A
CONNECTION_CLOSE frame of type 0x1d uses codes defined by the CONNECTION_CLOSE frame of type 0x1d uses codes defined by the
application protocol; see Section 20.2. application protocol; see Section 20.2.
Frame Type: A variable-length integer encoding the type of frame Frame Type: A variable-length integer encoding the type of frame
skipping to change at page 144, line 5 skipping to change at line 6701
only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an
application wishes to abandon a connection during the handshake, an application wishes to abandon a connection during the handshake, an
endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error
code of APPLICATION_ERROR in an Initial or Handshake packet. code of APPLICATION_ERROR in an Initial or Handshake packet.
19.20. HANDSHAKE_DONE Frames 19.20. HANDSHAKE_DONE Frames
The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal
confirmation of the handshake to the client. confirmation of the handshake to the client.
HANDSHAKE_DONE frames are formatted as shown in Figure 42, which HANDSHAKE_DONE frames are formatted as shown in Figure 44, which
shows that HANDSHAKE_DONE frames have no content. shows that HANDSHAKE_DONE frames have no content.
HANDSHAKE_DONE Frame { HANDSHAKE_DONE Frame {
Type (i) = 0x1e, Type (i) = 0x1e,
} }
Figure 42: HANDSHAKE_DONE Frame Format Figure 44: HANDSHAKE_DONE Frame Format
A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST
NOT send a HANDSHAKE_DONE frame before completing the handshake. A NOT send a HANDSHAKE_DONE frame before completing the handshake. A
server MUST treat receipt of a HANDSHAKE_DONE frame as a connection server MUST treat receipt of a HANDSHAKE_DONE frame as a connection
error of type PROTOCOL_VIOLATION. error of type PROTOCOL_VIOLATION.
19.21. Extension Frames 19.21. Extension Frames
QUIC frames do not use a self-describing encoding. An endpoint QUIC frames do not use a self-describing encoding. An endpoint
therefore needs to understand the syntax of all frames before it can therefore needs to understand the syntax of all frames before it can
skipping to change at page 148, line 31 skipping to change at line 6917
Address validation (Section 8) is used to verify that an entity that Address validation (Section 8) is used to verify that an entity that
claims a given address is able to receive packets at that address. claims a given address is able to receive packets at that address.
Address validation limits amplification attack targets to addresses Address validation limits amplification attack targets to addresses
for which an attacker can observe packets. for which an attacker can observe packets.
Prior to address validation, endpoints are limited in what they are Prior to address validation, endpoints are limited in what they are
able to send. Endpoints cannot send data toward an unvalidated able to send. Endpoints cannot send data toward an unvalidated
address in excess of three times the data received from that address. address in excess of three times the data received from that address.
Note: The anti-amplification limit only applies when an endpoint | Note: The anti-amplification limit only applies when an
responds to packets received from an unvalidated address. The | endpoint responds to packets received from an unvalidated
anti-amplification limit does not apply to clients when | address. The anti-amplification limit does not apply to
establishing a new connection or when initiating connection | clients when establishing a new connection or when initiating
migration. | connection migration.
21.1.1.2. Server-Side DoS 21.1.1.2. Server-Side DoS
Computing the server's first flight for a full handshake is Computing the server's first flight for a full handshake is
potentially expensive, requiring both a signature and a key exchange potentially expensive, requiring both a signature and a key exchange
computation. In order to prevent computational DoS attacks, the computation. In order to prevent computational DoS attacks, the
Retry packet provides a cheap token exchange mechanism that allows Retry packet provides a cheap token exchange mechanism that allows
servers to validate a client's IP address prior to doing any servers to validate a client's IP address prior to doing any
expensive computations at the cost of a single round trip. After a expensive computations at the cost of a single round trip. After a
successful handshake, servers can issue new tokens to a client, which successful handshake, servers can issue new tokens to a client, which
skipping to change at page 150, line 45 skipping to change at line 7028
21.1.3.1. On-Path Active Attacks 21.1.3.1. On-Path Active Attacks
An attacker that can cause a packet it observes to no longer reach An attacker that can cause a packet it observes to no longer reach
its intended destination is considered an on-path attacker. When an its intended destination is considered an on-path attacker. When an
attacker is present between a client and server, endpoints are attacker is present between a client and server, endpoints are
required to send packets through the attacker to establish required to send packets through the attacker to establish
connectivity on a given path. connectivity on a given path.
An on-path attacker can: An on-path attacker can:
o Inspect packets * Inspect packets
o Modify IP and UDP packet headers * Modify IP and UDP packet headers
o Inject new packets * Inject new packets
o Delay packets * Delay packets
o Reorder packets
o Drop packets * Reorder packets
o Split and merge datagrams along packet boundaries * Drop packets
* Split and merge datagrams along packet boundaries
An on-path attacker cannot: An on-path attacker cannot:
o Modify an authenticated portion of a packet and cause the * Modify an authenticated portion of a packet and cause the
recipient to accept that packet recipient to accept that packet
An on-path attacker has the opportunity to modify the packets that it An on-path attacker has the opportunity to modify the packets that it
observes; however, any modifications to an authenticated portion of a observes; however, any modifications to an authenticated portion of a
packet will cause it to be dropped by the receiving endpoint as packet will cause it to be dropped by the receiving endpoint as
invalid, as packet payloads are both authenticated and encrypted. invalid, as packet payloads are both authenticated and encrypted.
QUIC aims to constrain the capabilities of an on-path attacker as QUIC aims to constrain the capabilities of an on-path attacker as
follows: follows:
skipping to change at page 152, line 5 skipping to change at line 7084
21.1.3.2. Off-Path Active Attacks 21.1.3.2. Off-Path Active Attacks
An off-path attacker is not directly on the path between a client and An off-path attacker is not directly on the path between a client and
server but could be able to obtain copies of some or all packets sent server but could be able to obtain copies of some or all packets sent
between the client and the server. It is also able to send copies of between the client and the server. It is also able to send copies of
those packets to either endpoint. those packets to either endpoint.
An off-path attacker can: An off-path attacker can:
o Inspect packets * Inspect packets
o Inject new packets * Inject new packets
o Reorder injected packets * Reorder injected packets
An off-path attacker cannot: An off-path attacker cannot:
o Modify packets sent by endpoints * Modify packets sent by endpoints
o Delay packets * Delay packets
o Drop packets * Drop packets
o Reorder original packets * Reorder original packets
An off-path attacker can create modified copies of packets that it An off-path attacker can create modified copies of packets that it
has observed and inject those copies into the network, potentially has observed and inject those copies into the network, potentially
with spoofed source and destination addresses. with spoofed source and destination addresses.
For the purposes of this discussion, it is assumed that an off-path For the purposes of this discussion, it is assumed that an off-path
attacker has the ability to inject a modified copy of a packet into attacker has the ability to inject a modified copy of a packet into
the network that will reach the destination endpoint prior to the the network that will reach the destination endpoint prior to the
arrival of the original packet observed by the attacker. In other arrival of the original packet observed by the attacker. In other
words, an attacker has the ability to consistently "win" a race with words, an attacker has the ability to consistently "win" a race with
skipping to change at page 153, line 34 skipping to change at line 7160
A limited on-path attacker differs from an on-path attacker in that A limited on-path attacker differs from an on-path attacker in that
it is not on the original path between endpoints, and therefore the it is not on the original path between endpoints, and therefore the
original packets sent by an endpoint are still reaching their original packets sent by an endpoint are still reaching their
destination. This means that a future failure to route copied destination. This means that a future failure to route copied
packets to the destination faster than their original path will not packets to the destination faster than their original path will not
prevent the original packets from reaching the destination. prevent the original packets from reaching the destination.
A limited on-path attacker can: A limited on-path attacker can:
o Inspect packets * Inspect packets
o Inject new packets * Inject new packets
o Modify unencrypted packet headers * Modify unencrypted packet headers
o Reorder packets * Reorder packets
A limited on-path attacker cannot: A limited on-path attacker cannot:
o Delay packets so that they arrive later than packets sent on the * Delay packets so that they arrive later than packets sent on the
original path original path
o Drop packets * Drop packets
o Modify the authenticated and encrypted portion of a packet and * Modify the authenticated and encrypted portion of a packet and
cause the recipient to accept that packet cause the recipient to accept that packet
A limited on-path attacker can only delay packets up to the point A limited on-path attacker can only delay packets up to the point
that the original packets arrive before the duplicate packets, that the original packets arrive before the duplicate packets,
meaning that it cannot offer routing with worse latency than the meaning that it cannot offer routing with worse latency than the
original path. If a limited on-path attacker drops packets, the original path. If a limited on-path attacker drops packets, the
original copy will still arrive at the destination endpoint. original copy will still arrive at the destination endpoint.
QUIC aims to constrain the capabilities of a limited off-path QUIC aims to constrain the capabilities of a limited off-path
attacker as follows: attacker as follows:
skipping to change at page 157, line 18 skipping to change at line 7333
co-located with vulnerable endpoints, this version of QUIC does not co-located with vulnerable endpoints, this version of QUIC does not
allow servers to migrate, thus preventing spoofed migration attacks allow servers to migrate, thus preventing spoofed migration attacks
on clients. Any future extension that allows server migration MUST on clients. Any future extension that allows server migration MUST
also define countermeasures for forgery attacks. also define countermeasures for forgery attacks.
21.5.1. Control Options for Endpoints 21.5.1. Control Options for Endpoints
QUIC offers some opportunities for an attacker to influence or QUIC offers some opportunities for an attacker to influence or
control where its peer sends UDP datagrams: control where its peer sends UDP datagrams:
o initial connection establishment (Section 7), where a server is * initial connection establishment (Section 7), where a server is
able to choose where a client sends datagrams -- for example, by able to choose where a client sends datagrams -- for example, by
populating DNS records; populating DNS records;
o preferred addresses (Section 9.6), where a server is able to * preferred addresses (Section 9.6), where a server is able to
choose where a client sends datagrams; choose where a client sends datagrams;
o spoofed connection migrations (Section 9.3.1), where a client is * spoofed connection migrations (Section 9.3.1), where a client is
able to use source address spoofing to select where a server sends able to use source address spoofing to select where a server sends
subsequent datagrams; and subsequent datagrams; and
o spoofed packets that cause a server to send a Version Negotiation * spoofed packets that cause a server to send a Version Negotiation
packet (Section 21.5.5). packet (Section 21.5.5).
In all cases, the attacker can cause its peer to send datagrams to a In all cases, the attacker can cause its peer to send datagrams to a
victim that might not understand QUIC. That is, these packets are victim that might not understand QUIC. That is, these packets are
sent by the peer prior to address validation; see Section 8. sent by the peer prior to address validation; see Section 8.
Outside of the encrypted portion of packets, QUIC offers an endpoint Outside of the encrypted portion of packets, QUIC offers an endpoint
several options for controlling the content of UDP datagrams that its several options for controlling the content of UDP datagrams that its
peer sends. The Destination Connection ID field offers direct peer sends. The Destination Connection ID field offers direct
control over bytes that appear early in packets sent by the peer; see control over bytes that appear early in packets sent by the peer; see
skipping to change at page 161, line 18 skipping to change at line 7521
Endpoints are not expected to have specific information about the Endpoints are not expected to have specific information about the
location of servers that could be vulnerable targets of a request location of servers that could be vulnerable targets of a request
forgery attack. However, it might be possible over time to identify forgery attack. However, it might be possible over time to identify
specific UDP ports that are common targets of attacks or particular specific UDP ports that are common targets of attacks or particular
patterns in datagrams that are used for attacks. Endpoints MAY patterns in datagrams that are used for attacks. Endpoints MAY
choose to avoid sending datagrams to these ports or not send choose to avoid sending datagrams to these ports or not send
datagrams that match these patterns prior to validating the datagrams that match these patterns prior to validating the
destination address. Endpoints MAY retire connection IDs containing destination address. Endpoints MAY retire connection IDs containing
patterns known to be problematic without using them. patterns known to be problematic without using them.
Note: Modifying endpoints to apply these protections is more | Note: Modifying endpoints to apply these protections is more
efficient than deploying network-based protections, as endpoints | efficient than deploying network-based protections, as
do not need to perform any additional processing when sending to | endpoints do not need to perform any additional processing when
an address that has been validated. | sending to an address that has been validated.
21.6. Slowloris Attacks 21.6. Slowloris Attacks
The attacks commonly known as Slowloris [SLOWLORIS] try to keep many The attacks commonly known as Slowloris [SLOWLORIS] try to keep many
connections to the target endpoint open and hold them open as long as connections to the target endpoint open and hold them open as long as
possible. These attacks can be executed against a QUIC endpoint by possible. These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being generating the minimum amount of activity necessary to avoid being
closed for inactivity. This might involve sending small amounts of closed for inactivity. This might involve sending small amounts of
data, gradually opening flow control windows in order to control the data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss sender rate, or manufacturing ACK frames that simulate a high loss
skipping to change at page 169, line 5 skipping to change at line 7864
assigned using Standards Action or IESG Approval as defined in assigned using Standards Action or IESG Approval as defined in
Sections 4.9 and 4.10 of [RFC8126]. Sections 4.9 and 4.10 of [RFC8126].
In addition to the fields listed in Section 22.1.1, permanent In addition to the fields listed in Section 22.1.1, permanent
registrations in this registry MUST include the following field: registrations in this registry MUST include the following field:
Parameter Name: A short mnemonic for the parameter. Parameter Name: A short mnemonic for the parameter.
The initial contents of this registry are shown in Table 6. The initial contents of this registry are shown in Table 6.
+-------+-------------------------------------+---------------+ +=======+=====================================+===============+
| Value | Parameter Name | Specification | | Value | Parameter Name | Specification |
+-------+-------------------------------------+---------------+ +=======+=====================================+===============+
| 0x00 | original_destination_connection_id | Section 18.2 | | 0x00 | original_destination_connection_id | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x01 | max_idle_timeout | Section 18.2 | | 0x01 | max_idle_timeout | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x02 | stateless_reset_token | Section 18.2 | | 0x02 | stateless_reset_token | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x03 | max_udp_payload_size | Section 18.2 | | 0x03 | max_udp_payload_size | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x04 | initial_max_data | Section 18.2 | | 0x04 | initial_max_data | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x05 | initial_max_stream_data_bidi_local | Section 18.2 | | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 | | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x07 | initial_max_stream_data_uni | Section 18.2 | | 0x07 | initial_max_stream_data_uni | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x08 | initial_max_streams_bidi | Section 18.2 | | 0x08 | initial_max_streams_bidi | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x09 | initial_max_streams_uni | Section 18.2 | | 0x09 | initial_max_streams_uni | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x0a | ack_delay_exponent | Section 18.2 | | 0x0a | ack_delay_exponent | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x0b | max_ack_delay | Section 18.2 | | 0x0b | max_ack_delay | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x0c | disable_active_migration | Section 18.2 | | 0x0c | disable_active_migration | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x0d | preferred_address | Section 18.2 | | 0x0d | preferred_address | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x0e | active_connection_id_limit | Section 18.2 | | 0x0e | active_connection_id_limit | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x0f | initial_source_connection_id | Section 18.2 | | 0x0f | initial_source_connection_id | Section 18.2 |
| | | | +-------+-------------------------------------+---------------+
| 0x10 | retry_source_connection_id | Section 18.2 | | 0x10 | retry_source_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Registry Entries Table 6: Initial QUIC Transport Parameters Registry Entries
Each value of the form "31 * N + 27" for integer values of N (that Each value of the form "31 * N + 27" for integer values of N (that
is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned
by IANA and MUST NOT appear in the listing of assigned values. by IANA and MUST NOT appear in the listing of assigned values.
22.4. QUIC Frame Types Registry 22.4. QUIC Frame Types Registry
skipping to change at page 171, line 10 skipping to change at line 7961
In addition to the fields listed in Section 22.1.1, permanent In addition to the fields listed in Section 22.1.1, permanent
registrations in this registry MUST include the following fields: registrations in this registry MUST include the following fields:
Code: A short mnemonic for the parameter. Code: A short mnemonic for the parameter.
Description: A brief description of the error code semantics, which Description: A brief description of the error code semantics, which
MAY be a summary if a specification reference is provided. MAY be a summary if a specification reference is provided.
The initial contents of this registry are shown in Table 7. The initial contents of this registry are shown in Table 7.
+-------+--------------------------+----------------+---------------+ +======+===========================+================+===============+
| Value | Code | Description | Specification | |Value | Code |Description | Specification |
+-------+--------------------------+----------------+---------------+ +======+===========================+================+===============+
| 0x00 | NO_ERROR | No error | Section 20 | |0x00 | NO_ERROR |No error | Section 20 |
| | | | | +------+---------------------------+----------------+---------------+
| 0x01 | INTERNAL_ERROR | Implementation | Section 20 | |0x01 | INTERNAL_ERROR |Implementation | Section 20 |
| | | error | | | | |error | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x02 | CONNECTION_REFUSED | Server refuses | Section 20 | |0x02 | CONNECTION_REFUSED |Server refuses a| Section 20 |
| | | a connection | | | | |connection | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x03 | FLOW_CONTROL_ERROR | Flow control | Section 20 | |0x03 | FLOW_CONTROL_ERROR |Flow control | Section 20 |
| | | error | | | | |error | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x04 | STREAM_LIMIT_ERROR | Too many | Section 20 | |0x04 | STREAM_LIMIT_ERROR |Too many streams| Section 20 |
| | | streams opened | | | | |opened | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x05 | STREAM_STATE_ERROR | Frame received | Section 20 | |0x05 | STREAM_STATE_ERROR |Frame received | Section 20 |
| | | in invalid | | | | |in invalid | |
| | | stream state | | | | |stream state | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x06 | FINAL_SIZE_ERROR | Change to | Section 20 | |0x06 | FINAL_SIZE_ERROR |Change to final | Section 20 |
| | | final size | | | | |size | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x07 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | |0x07 | FRAME_ENCODING_ERROR |Frame encoding | Section 20 |
| | | error | | | | |error | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x08 | TRANSPORT_PARAMETER_ERRO | Error in | Section 20 | |0x08 | TRANSPORT_PARAMETER_ERROR |Error in | Section 20 |
| | R | transport | | | | |transport | |
| | | parameters | | | | |parameters | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x09 | CONNECTION_ID_LIMIT_ERRO | Too many | Section 20 | |0x09 | CONNECTION_ID_LIMIT_ERROR |Too many | Section 20 |
| | R | connection IDs | | | | |connection IDs | |
| | | received | | | | |received | |
| | | | | +------+---------------------------+----------------+---------------+
| 0x0a | PROTOCOL_VIOLATION | Generic | Section 20 | |0x0a | PROTOCOL_VIOLATION |Generic protocol| Section 20 |
| | | protocol | | | | |violation | |
| | | violation | | +------+---------------------------+----------------+---------------+
| | | | | |0x0b | INVALID_TOKEN |Invalid token | Section 20 |
| 0x0b | INVALID_TOKEN | Invalid token | Section 20 | | | |received | |
| | | received | | +------+---------------------------+----------------+---------------+
| | | | | |0x0c | APPLICATION_ERROR |Application | Section 20 |
| 0x0c | APPLICATION_ERROR | Application | Section 20 | | | |error | |
| | | error | | +------+---------------------------+----------------+---------------+
| | | | | |0x0d | CRYPTO_BUFFER_EXCEEDED |CRYPTO data | Section 20 |
| 0x0d | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | | | |buffer | |
| | | buffer | | | | |overflowed | |
| | | overflowed | | +------+---------------------------+----------------+---------------+
| | | | | |0x0e | KEY_UPDATE_ERROR |Invalid packet | Section 20 |
| 0x0e | KEY_UPDATE_ERROR | Invalid packet | Section 20 | | | |protection | |
| | | protection | | | | |update | |
| | | update | | +------+---------------------------+----------------+---------------+
| | | | | |0x0f | AEAD_LIMIT_REACHED |Excessive use of| Section 20 |
| 0x0f | AEAD_LIMIT_REACHED | Excessive use | Section 20 | | | |packet | |
| | | of packet | | | | |protection keys | |
| | | protection | | +------+---------------------------+----------------+---------------+
| | | keys | | |0x10 | NO_VIABLE_PATH |No viable | Section 20 |
| | | | | | | |network path | |
| 0x10 | NO_VIABLE_PATH | No viable | Section 20 | | | |exists | |
| | | network path | | +------+---------------------------+----------------+---------------+
| | | exists | | |0x0100| CRYPTO_ERROR |TLS alert code | Section 20 |
| | | | | |- | | | |
| 0x010 | CRYPTO_ERROR | TLS alert code | Section 20 | |0x01ff| | | |
| 0 - 0 | | | | +------+---------------------------+----------------+---------------+
| x01ff | | | |
+-------+--------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Registry Entries Table 7: Initial QUIC Transport Error Codes Registry Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[BCP145] Consisting of: [RFC8085], [BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
<https://www.rfc-editor.org/info/bcp145>. Guidelines", BCP 145, RFC 8085, March 2017.
[BCP38] Consisting of: [RFC2827], <https://www.rfc-editor.org/info/bcp145>
<https://www.rfc-editor.org/info/bcp38>.
[DPLPMTUD] [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Defeating Denial of Service Attacks which employ IP Source
T. Voelker, "Packetization Layer Path MTU Discovery for Address Spoofing", BCP 38, RFC 2827, May 2000.
<https://www.rfc-editor.org/info/bcp38>
[DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>. September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.
[EARLY-ASSIGN] [EARLY-ASSIGN]
Cotton, M., "Early IANA Allocation of Standards Track Code Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/rfc/rfc7120>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/rfc/rfc791>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
RFC 8999, DOI 10.17487/RFC8999, May 2021, RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/info/rfc8999>. <https://www.rfc-editor.org/rfc/rfc8999>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>. May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[QUIC-TLS] [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", RFC 9001, Layer Security (TLS) to Secure QUIC", RFC 9001,
DOI 10.17487/RFC9001, May 2021, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/rfc/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/rfc/rfc3168>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/rfc/rfc3629>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/rfc/rfc6437>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/rfc/rfc8201>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311, Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>. <https://www.rfc-editor.org/rfc/rfc8311>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/rfc/rfc768>.
23.2. Informative References 23.2. Informative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/rfc/rfc5116>.
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses
for cross-site request forgery", Proceedings of the 15th for cross-site request forgery", Proceedings of the 15th
ACM conference on Computer and communications security - ACM conference on Computer and communications security -
CCS '08, DOI 10.1145/1455770.1455782, 2008. CCS '08, DOI 10.1145/1455770.1455782, 2008,
<https://doi.org/10.1145/1455770.1455782>.
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Stream Transport Over Roskind, J., "QUIC: Multiplexed Stream Transport Over
UDP", December 2013, <https://docs.google.com/document/ UDP", 2 December 2013, <https://docs.google.com/document/
d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/ d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/
edit?usp=sharing>. edit?usp=sharing>.
[GATEWAY] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., [GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An experimental study of home Sarolahti, P., and M. Kojo, "An experimental study of home
gateway characteristics", DOI 10.1145/1879141.1879174, gateway characteristics", Proceedings of the 10th ACM
Proceedings of the 10th ACM SIGCOMM conference on Internet SIGCOMM conference on Internet measurement - IMC ‘10,
measurement - IMC '10, November 2010. DOI 10.1145/1879141.1879174, November 2010,
<https://doi.org/10.1145/1879141.1879174>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/rfc/rfc8200>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, draft-ietf-quic- Transport Protocol", Work in Progress, Internet-Draft,
manageability-11, April 2021. draft-ietf-quic-manageability-11, 21 April 2021,
<https://tools.ietf.org/html/draft-ietf-quic-
manageability-11>.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/rfc/rfc4086>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/rfc/rfc1812>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
and E. Lear, "Address Allocation for Private Internets", J., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
<https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/rfc/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>. December 2002, <https://www.rfc-editor.org/rfc/rfc3449>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/rfc/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/rfc/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/rfc/rfc4443>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/rfc/rfc4787>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/rfc/rfc5681>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP) Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)", Extension for Datagram Transport Layer Security (DTLS)",
RFC 7983, DOI 10.17487/RFC7983, September 2016, RFC 7983, DOI 10.17487/RFC7983, September 2016,
<https://www.rfc-editor.org/info/rfc7983>. <https://www.rfc-editor.org/rfc/rfc7983>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>. <https://www.rfc-editor.org/rfc/rfc8087>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>. <https://www.rfc-editor.org/rfc/rfc8981>.
[SEC-CONS] [SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/rfc/rfc3552>.
[SLOWLORIS] [SLOWLORIS]
"RSnake" Hansen, R., "Welcome to Slowloris - the low "RSnake" Hansen, R., "Welcome to Slowloris - the low
bandwidth, yet greedy and poisonous HTTP client!", June bandwidth, yet greedy and poisonous HTTP client!", June
2009, <https://web.archive.org/web/20150315054838/ 2009, <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
Appendix A. Pseudocode Appendix A. Pseudocode
The pseudocode in this section describes sample algorithms. These The pseudocode in this section describes sample algorithms. These
algorithms are intended to be correct and clear, rather than being algorithms are intended to be correct and clear, rather than being
optimally performant. optimally performant.
The pseudocode segments in this section are licensed as Code The pseudocode segments in this section are licensed as Code
Components; see the Copyright Notice. Components; see the Copyright Notice.
A.1. Sample Variable-Length Integer Decoding A.1. Sample Variable-Length Integer Decoding
The pseudocode in Figure 43 shows how a variable-length integer can The pseudocode in Figure 45 shows how a variable-length integer can
be read from a stream of bytes. The function ReadVarint takes a be read from a stream of bytes. The function ReadVarint takes a
single argument -- a sequence of bytes, which can be read in network single argument -- a sequence of bytes, which can be read in network
byte order. byte order.
ReadVarint(data): ReadVarint(data):
// The length of variable-length integers is encoded in the // The length of variable-length integers is encoded in the
// first two bits of the first byte. // first two bits of the first byte.
v = data.next_byte() v = data.next_byte()
prefix = v >> 6 prefix = v >> 6
length = 1 << prefix length = 1 << prefix
// Once the length is known, remove these bits and read any // Once the length is known, remove these bits and read any
// remaining bytes. // remaining bytes.
v = v & 0x3f v = v & 0x3f
repeat length-1 times: repeat length-1 times:
v = (v << 8) + data.next_byte() v = (v << 8) + data.next_byte()
return v return v
Figure 43: Sample Variable-Length Integer Decoding Algorithm Figure 45: Sample Variable-Length Integer Decoding Algorithm
For example, the eight-byte sequence 0xc2197c5eff14e88c decodes to For example, the eight-byte sequence 0xc2197c5eff14e88c decodes to
the decimal value 151,288,809,941,952,652; the four-byte sequence the decimal value 151,288,809,941,952,652; the four-byte sequence
0x9d7f3e7d decodes to 494,878,333; the two-byte sequence 0x7bbd 0x9d7f3e7d decodes to 494,878,333; the two-byte sequence 0x7bbd
decodes to 15,293; and the single byte 0x25 decodes to 37 (as does decodes to 15,293; and the single byte 0x25 decodes to 37 (as does
the two-byte sequence 0x4025). the two-byte sequence 0x4025).
A.2. Sample Packet Number Encoding Algorithm A.2. Sample Packet Number Encoding Algorithm
The pseudocode in Figure 44 shows how an implementation can select an The pseudocode in Figure 46 shows how an implementation can select an
appropriate size for packet number encodings. appropriate size for packet number encodings.
The EncodePacketNumber function takes two arguments: The EncodePacketNumber function takes two arguments:
o full_pn is the full packet number of the packet being sent. * full_pn is the full packet number of the packet being sent.
o largest_acked is the largest packet number that has been * largest_acked is the largest packet number that has been
acknowledged by the peer in the current packet number space, if acknowledged by the peer in the current packet number space, if
any. any.
EncodePacketNumber(full_pn, largest_acked): EncodePacketNumber(full_pn, largest_acked):
// The number of bits must be at least one more // The number of bits must be at least one more
// than the base-2 logarithm of the number of contiguous // than the base-2 logarithm of the number of contiguous
// unacknowledged packet numbers, including the new packet. // unacknowledged packet numbers, including the new packet.
if largest_acked is None: if largest_acked is None:
num_unacked = full_pn + 1 num_unacked = full_pn + 1
else: else:
num_unacked = full_pn - largest_acked num_unacked = full_pn - largest_acked
min_bits = log(num_unacked, 2) + 1 min_bits = log(num_unacked, 2) + 1
num_bytes = ceil(min_bits / 8) num_bytes = ceil(min_bits / 8)
// Encode the integer value and truncate to // Encode the integer value and truncate to
// the num_bytes least significant bytes. // the num_bytes least significant bytes.
return encode(full_pn, num_bytes) return encode(full_pn, num_bytes)
Figure 44: Sample Packet Number Encoding Algorithm Figure 46: Sample Packet Number Encoding Algorithm
For example, if an endpoint has received an acknowledgment for packet For example, if an endpoint has received an acknowledgment for packet
0xabe8b3 and is sending a packet with a number of 0xac5c02, there are 0xabe8b3 and is sending a packet with a number of 0xac5c02, there are
29,519 (0x734f) outstanding packet numbers. In order to represent at 29,519 (0x734f) outstanding packet numbers. In order to represent at
least twice this range (59,038 packets, or 0xe69e), 16 bits are least twice this range (59,038 packets, or 0xe69e), 16 bits are
required. required.
In the same state, sending a packet with a number of 0xace8fe uses In the same state, sending a packet with a number of 0xace8fe uses
the 24-bit encoding, because at least 18 bits are required to the 24-bit encoding, because at least 18 bits are required to
represent twice the range (131,222 packets, or 0x020096). represent twice the range (131,222 packets, or 0x020096).
A.3. Sample Packet Number Decoding Algorithm A.3. Sample Packet Number Decoding Algorithm
The pseudocode in Figure 45 includes an example algorithm for The pseudocode in Figure 47 includes an example algorithm for
decoding packet numbers after header protection has been removed. decoding packet numbers after header protection has been removed.
The DecodePacketNumber function takes three arguments: The DecodePacketNumber function takes three arguments:
o largest_pn is the largest packet number that has been successfully * largest_pn is the largest packet number that has been successfully
processed in the current packet number space. processed in the current packet number space.
o truncated_pn is the value of the Packet Number field. * truncated_pn is the value of the Packet Number field.
o pn_nbits is the number of bits in the Packet Number field (8, 16, * pn_nbits is the number of bits in the Packet Number field (8, 16,
24, or 32). 24, or 32).
DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
expected_pn = largest_pn + 1 expected_pn = largest_pn + 1
pn_win = 1 << pn_nbits pn_win = 1 << pn_nbits
pn_hwin = pn_win / 2 pn_hwin = pn_win / 2
pn_mask = pn_win - 1 pn_mask = pn_win - 1
// The incoming packet number should be greater than // The incoming packet number should be greater than
// expected_pn - pn_hwin and less than or equal to // expected_pn - pn_hwin and less than or equal to
// expected_pn + pn_hwin // expected_pn + pn_hwin
skipping to change at page 180, line 30 skipping to change at line 8382
// Note the extra checks to prevent overflow and underflow. // Note the extra checks to prevent overflow and underflow.
candidate_pn = (expected_pn & ~pn_mask) | truncated_pn candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
if candidate_pn <= expected_pn - pn_hwin and if candidate_pn <= expected_pn - pn_hwin and
candidate_pn < (1 << 62) - pn_win: candidate_pn < (1 << 62) - pn_win:
return candidate_pn + pn_win return candidate_pn + pn_win
if candidate_pn > expected_pn + pn_hwin and if candidate_pn > expected_pn + pn_hwin and
candidate_pn >= pn_win: candidate_pn >= pn_win:
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Figure 45: Sample Packet Number Decoding Algorithm Figure 47: Sample Packet Number Decoding Algorithm
For example, if the highest successfully authenticated packet had a For example, if the highest successfully authenticated packet had a
packet number of 0xa82f30ea, then a packet containing a 16-bit value packet number of 0xa82f30ea, then a packet containing a 16-bit value
of 0x9b32 will be decoded as 0xa82f9b32. of 0x9b32 will be decoded as 0xa82f9b32.
A.4. Sample ECN Validation Algorithm A.4. Sample ECN Validation Algorithm
Each time an endpoint commences sending on a new network path, it Each time an endpoint commences sending on a new network path, it
determines whether the path supports ECN; see Section 13.4. If the determines whether the path supports ECN; see Section 13.4. If the
path supports ECN, the goal is to use ECN. Endpoints might also path supports ECN, the goal is to use ECN. Endpoints might also
skipping to change at page 181, line 41 skipping to change at line 8440
Contributors Contributors
The original design and rationale behind this protocol draw The original design and rationale behind this protocol draw
significantly from work by Jim Roskind [EARLY-DESIGN]. significantly from work by Jim Roskind [EARLY-DESIGN].
The IETF QUIC Working Group received an enormous amount of support The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive from many people. The following people provided substantive
contributions to this document: contributions to this document:
o Alessandro Ghedini * Alessandro Ghedini
* Alyssa Wilk
o Alyssa Wilk * Antoine Delignat-Lavaud
* Brian Trammell
o Antoine Delignat-Lavaud * Christian Huitema
o Brian Trammell * Colin Perkins
* David Schinazi
o Christian Huitema * Dmitri Tikhonov
* Eric Kinnear
o Colin Perkins * Eric Rescorla
* Gorry Fairhurst
o David Schinazi * Ian Swett
* Igor Lubashev
o Dmitri Tikhonov * 奥 一穂 (Kazuho Oku)
* Lars Eggert
o Eric Kinnear * Lucas Pardue
* Magnus Westerlund
o Eric Rescorla * Marten Seemann
* Martin Duke
o Gorry Fairhurst * Mike Bishop
* Mikkel Fahnøe Jørgensen
o Ian Swett * Mirja Kühlewind
* Nick Banks
o Igor Lubashev * Nick Harper
* Patrick McManus
o Kazuho Oku * Roberto Peon
* Ryan Hamilton
o Lars Eggert * Subodh Iyengar
o Lucas Pardue * Tatsuhiro Tsujikawa
* Ted Hardie
o Magnus Westerlund * Tom Jones
* Victor Vasiliev
o Marten Seemann
o Martin Duke
o Mike Bishop
o Mikkel Fahnoee Joergensen
o Mirja Kuehlewind
o Nick Banks
o Nick Harper
o Patrick McManus
o Roberto Peon
o Ryan Hamilton
o Subodh Iyengar
o Tatsuhiro Tsujikawa
o Ted Hardie
o Tom Jones
o Victor Vasiliev
Authors' Addresses Authors' Addresses
Jana Iyengar (editor) Jana Iyengar (editor)
Fastly Fastly
Email: jri.ietf@gmail.com Email: jri.ietf@gmail.com
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
 End of changes. 288 change blocks. 
757 lines changed or deleted 726 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/