draft-ietf-quic-transport-29.txt   draft-ietf-quic-transport-30.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: 12 December 2020 Mozilla Expires: March 14, 2021 Mozilla
10 June 2020 September 10, 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-29 draft-ietf-quic-transport-30
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 December 2020. This Internet-Draft will expire on March 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 8
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 9
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 12
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 13
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13
2.4. Required Operations on Streams . . . . . . . . . . . . . 13 2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 14
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 18
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 21
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 21 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 24
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 24 4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 25
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 25 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 26
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 27 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 27
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Flow Control Performance . . . . . . . . . . . . . . . . 28
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 28 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 29
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 30 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 30
5.2. Matching Packets to Connections . . . . . . . . . . . . . 31 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 31
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 32 5.2. Matching Packets to Connections . . . . . . . . . . . . . 33
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 32 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33
5.2.3. Considerations for Simple Load Balancers . . . . . . 33 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 34
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 34 5.2.3. Considerations for Simple Load Balancers . . . . . . 35
5.4. Required Operations on Connections . . . . . . . . . . . 35 5.3. Operations on Connections . . . . . . . . . . . . . . . . 35
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 36 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 37
6.2. Handling Version Negotiation Packets . . . . . . . . . . 36 6.2. Handling Version Negotiation Packets . . . . . . . . . . 37
6.2.1. Version Negotiation Between Draft Versions . . . . . 37 6.2.1. Version Negotiation Between Draft Versions . . . . . 37
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 38
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 38 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 38
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 39 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 40
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 40 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 41
7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41 7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 42
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 44
7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 44 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 45
7.4.2. New Transport Parameters . . . . . . . . . . . . . . 46 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 47
7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 46 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 47
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 46 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 48
8.1. Address Validation During Connection Establishment . . . 47 8.1. Address Validation During Connection Establishment . . . 48
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 48 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 49
8.1.2. Address Validation using Retry Packets . . . . . . . 48 8.1.2. Address Validation using Retry Packets . . . . . . . 50
8.1.3. Address Validation for Future Connections . . . . . . 49 8.1.3. Address Validation for Future Connections . . . . . . 51
8.1.4. Address Validation Token Integrity . . . . . . . . . 51 8.1.4. Address Validation Token Integrity . . . . . . . . . 53
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 52 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 54
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 53 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 55
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 53 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 55
8.5. Successful Path Validation . . . . . . . . . . . . . . . 54 8.5. Successful Path Validation . . . . . . . . . . . . . . . 55
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 54 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 56
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 54 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 56
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 55 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 57
9.2. Initiating Connection Migration . . . . . . . . . . . . . 56 9.2. Initiating Connection Migration . . . . . . . . . . . . . 58
9.3. Responding to Connection Migration . . . . . . . . . . . 56 9.3. Responding to Connection Migration . . . . . . . . . . . 58
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 57 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 59
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 58 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 60
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 58 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 60
9.4. Loss Detection and Congestion Control . . . . . . . . . . 59 9.4. Loss Detection and Congestion Control . . . . . . . . . . 61
9.5. Privacy Implications of Connection Migration . . . . . . 60 9.5. Privacy Implications of Connection Migration . . . . . . 62
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 62 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 64
9.6.1. Communicating a Preferred Address . . . . . . . . . . 62 9.6.1. Communicating a Preferred Address . . . . . . . . . . 64
9.6.2. Responding to Connection Migration . . . . . . . . . 63 9.6.2. Migration to a Preferred Address . . . . . . . . . . 64
9.6.3. Interaction of Client Migration and Preferred 9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 63 Address . . . . . . . . . . . . . . . . . . . . . . . 65
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 64 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 66
10. Connection Termination . . . . . . . . . . . . . . . . . . . 64 10. Connection Termination . . . . . . . . . . . . . . . . . . . 66
10.1. Closing and Draining Connection States . . . . . . . . . 65 10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 67
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 66 10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 67
10.2.1. Liveness Testing . . . . . . . . . . . . . . . . . . 66 10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67
10.2.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67 10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 68
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 67 10.2.1. Closing Connection State . . . . . . . . . . . . . . 69
10.3.1. Immediate Close During the Handshake . . . . . . . . 69 10.2.2. Draining Connection State . . . . . . . . . . . . . 70
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 70 10.2.3. Immediate Close During the Handshake . . . . . . . . 71
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 73 10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 72
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 74 10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 75
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 75 10.3.2. Calculating a Stateless Reset Token . . . . . . . . 76
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 75 10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 77
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 76 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 77
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 76 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 78
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 77 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 78
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 77
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 78
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 79
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 80
13. Packetization and Reliability . . . . . . . . . . . . . . . . 83
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 84
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 84
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 85
13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 86
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 86
13.2.4. Receiver Tracking of ACK Frames . . . . . . . . . . 87
13.2.5. Limiting ACK Ranges . . . . . . . . . . . . . . . . 87
13.2.6. Measuring and Reporting Host Delay . . . . . . . . . 88
13.2.7. ACK Frames and Packet Protection . . . . . . . . . . 88
13.2.8. PADDING Frames Consume Congestion Window . . . . . . 89
13.3. Retransmission of Information . . . . . . . . . . . . . 89
13.4. Explicit Congestion Notification . . . . . . . . . . . . 92
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 92
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 93
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 95
14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 95
14.2. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 96
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 97
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 97
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 98
14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 98
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 98
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 98
14.4.1. PMTU Probes Containing Source Connection ID . . . . 99
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 99
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 100
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 101
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 101
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 102
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 105
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 107
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 109
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 110
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 111
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 113
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 115
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 116
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 117
18.2. Transport Parameter Definitions . . . . . . . . . . . . 117
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 121
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 121
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 122
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 122
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 124
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 125
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 126
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 127
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 127
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 128
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 129
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 131
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 131
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 132
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 133
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 134
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 134
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 135
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 136
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 137
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 138
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 138
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 139
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 140
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 140
20.1. Application Protocol Error Codes . . . . . . . . . . . . 142
21. Security Considerations . . . . . . . . . . . . . . . . . . . 142
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 142
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 143
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 144
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 144
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 144
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 145
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 145
21.8. Explicit Congestion Notification Attacks . . . . . . . . 146
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 146
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 147
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 147
21.12. Overview of Security Properties . . . . . . . . . . . . 147
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 148
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 149
21.12.3. Connection Migration . . . . . . . . . . . . . . . 150
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
22.1. Registration Policies for QUIC Registries . . . . . . . 154
22.1.1. Provisional Registrations . . . . . . . . . . . . . 154
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 155
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 156
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 157
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 157
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 158
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 159
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 161
23.1. Normative References . . . . . . . . . . . . . . . . . . 161
23.2. Informative References . . . . . . . . . . . . . . . . . 162
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 164
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 165
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 166
C.1. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 166
C.2. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 166
C.3. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 168
C.4. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 168
C.5. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 168
C.6. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 169
C.7. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 170
C.8. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 171
C.9. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 171
C.10. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 172
C.11. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 172
C.12. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 173
C.13. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 174
C.14. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 175
C.15. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 175
C.16. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 175
C.17. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 176
C.18. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 177
C.19. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 177
C.20. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 178
C.21. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 179
C.22. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 179
C.23. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 180
C.24. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 180
C.25. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 181
C.26. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 181
C.27. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 182
C.28. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 182
C.29. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 184
C.30. Since draft-hamilton-quic-transport-protocol-01 . . . . . 185
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 186
1. Introduction 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 79
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 79
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 80
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 81
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 82
13. Packetization and Reliability . . . . . . . . . . . . . . . . 86
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 86
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 87
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 87
13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 89
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 89
13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 90
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 91
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 91
13.2.7. PADDING Frames Consume Congestion Window . . . . . . 92
13.3. Retransmission of Information . . . . . . . . . . . . . 92
13.4. Explicit Congestion Notification . . . . . . . . . . . . 95
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 95
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 96
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 99
14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 99
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 100
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 101
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 101
14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 101
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 101
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 102
14.4.1. PMTU Probes Containing Source Connection ID . . . . 102
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 102
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 103
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 104
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 104
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 105
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 108
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 109
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 112
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 113
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 114
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 118
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 119
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 120
18.2. Transport Parameter Definitions . . . . . . . . . . . . 120
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125
19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125
19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 125
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 127
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 128
19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 129
19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 130
19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131
19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 132
19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 134
19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 134
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 135
19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 136
19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 137
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 137
19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 138
19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140
19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141
19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 141
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142
19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 143
20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144
20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 144
20.2. Application Protocol Error Codes . . . . . . . . . . . . 146
21. Security Considerations . . . . . . . . . . . . . . . . . . . 146
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 146
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 147
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 147
21.4. Request Forgery Attacks . . . . . . . . . . . . . . . . 148
21.4.1. Control Options for Endpoints . . . . . . . . . . . 148
21.4.2. Request Forgery with Client Initial Packets . . . . 149
21.4.3. Request Forgery with Preferred Addresses . . . . . . 150
21.4.4. Request Forgery with Spoofed Migration . . . . . . . 151
21.4.5. Generic Request Forgery Countermeasures . . . . . . 151
21.5. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 152
21.6. Stream Fragmentation and Reassembly Attacks . . . . . . 153
21.7. Stream Commitment Attack . . . . . . . . . . . . . . . . 153
21.8. Peer Denial of Service . . . . . . . . . . . . . . . . . 154
21.9. Explicit Congestion Notification Attacks . . . . . . . . 154
21.10. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 154
21.11. Version Downgrade . . . . . . . . . . . . . . . . . . . 155
21.12. Targeted Attacks by Routing . . . . . . . . . . . . . . 155
21.13. Overview of Security Properties . . . . . . . . . . . . 155
21.13.1. Handshake . . . . . . . . . . . . . . . . . . . . . 156
21.13.2. Protected Packets . . . . . . . . . . . . . . . . . 158
21.13.3. Connection Migration . . . . . . . . . . . . . . . 158
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163
22.1. Registration Policies for QUIC Registries . . . . . . . 163
22.1.1. Provisional Registrations . . . . . . . . . . . . . 163
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 164
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 164
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 165
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 165
22.3. QUIC Frame Types Registry . . . . . . . . . . . . . . . 167
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 168
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 170
23.1. Normative References . . . . . . . . . . . . . . . . . . 170
23.2. Informative References . . . . . . . . . . . . . . . . . 171
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 174
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 175
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 176
C.1. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 176
C.2. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 177
C.3. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 177
C.4. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 178
C.5. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 178
C.6. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 178
C.7. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 180
C.8. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 180
C.9. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 181
C.10. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 182
C.11. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 182
C.12. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 183
C.13. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 183
C.14. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 184
C.15. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 185
C.16. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 185
C.17. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 186
C.18. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 187
C.19. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 187
C.20. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 188
C.21. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 188
C.22. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 189
C.23. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 190
C.24. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 191
C.25. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 191
C.26. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 191
C.27. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 192
C.28. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 192
C.29. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 193
C.30. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 195
C.31. Since draft-hamilton-quic-transport-protocol-01 . . . . . 195
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 197
1. Overview
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
* Stream multiplexing * Stream multiplexing
* Stream and connection-level flow control * Stream- and connection-level flow control
* Low-latency connection establishment * Low-latency connection establishment
* Connection migration and resilience to NAT rebinding * Connection migration and resilience to NAT rebinding
* Authenticated and encrypted header and payload * Authenticated and encrypted header and payload
QUIC uses UDP as a substrate to avoid requiring changes to legacy QUIC establishes a connection, which is a stateful interaction
client operating systems and middleboxes. QUIC authenticates all of between a client and server. The primary purpose of a connection is
its headers and encrypts most of the data it exchanges, including its to support the structured exchange of data by an application
signaling, to avoid incurring a dependency on middleboxes. protocol.
Streams are means by which an application protocol exchanges
information. Streams are ordered sequences of bytes. Two types of
stream can be created: bidirectional streams, which allow both
endpoints to send data; and unidirectional streams, which allow a
single endpoint to send. A credit-based scheme is used to limit
stream creation and to bound the amount of data that can be sent.
The QUIC handshake combines negotiation of cryptographic and
transport parameters. The handshake is structured to permit the
exchange of application data as soon as possible. This includes an
option for clients to send data immediately (0-RTT), which might
require prior communication to enable.
QUIC connections are not strictly bound to a single network path.
Connection migration uses connection identifiers to allow connections
to transfer to a new network path.
Frames are used in QUIC to communicate between endpoints. One or
more frames are assembled into packets. QUIC authenticates all
packets and encrypts as much as is practical. QUIC packets are
carried in UDP datagrams ([UDP]) to better facilitate deployment in
existing systems and networks.
Once established, multiple options are provided for connection
termination. Applications can manage a graceful shutdown, endpoints
can negotiate a timeout period, errors can cause immediate connection
teardown, and a stateless mechanism provides for termination of
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:
* 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,
skipping to change at page 9, line 5 skipping to change at page 9, line 44
name, not an acronym. name, not an acronym.
QUIC packet: A complete processable unit of QUIC that can be QUIC packet: A complete processable unit of QUIC that can be
encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram. encapsulated in a single UDP datagram.
Ack-eliciting Packet: A QUIC packet that contains frames other than Ack-eliciting Packet: A QUIC packet that contains frames other than
ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to
send an acknowledgment; see Section 13.2.1. send an acknowledgment; see Section 13.2.1.
Out-of-order packet: A packet that does not increase the largest
received packet number for its packet number space (Section 12.3)
by exactly one. A packet can arrive out of order if it is
delayed, if earlier packets are lost or delayed, or if the sender
intentionally skips a packet number.
Endpoint: An entity that can participate in a QUIC connection by Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server. only two types of endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection. Client: The endpoint that initiates a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint that accepts a QUIC connection.
Address: When used without qualification, the tuple of IP version, Address: When used without qualification, the tuple of IP version,
IP address, UDP protocol, and UDP port number that represents one IP address, and UDP port number that represents one end of a
end of a network path. network path.
Connection ID: An opaque identifier that is used to identify a QUIC Connection ID: An identifier that is used to identify a QUIC
connection at an endpoint. Each endpoint sets a value for its connection at an endpoint. Each endpoint selects one or more
peer to include in packets sent towards the endpoint. Connection IDs for its peer to include in packets sent towards the
endpoint. This value is opaque to the peer.
Stream: A unidirectional or bidirectional channel of ordered bytes Stream: A unidirectional or bidirectional channel of ordered bytes
within a QUIC connection. A QUIC connection can carry multiple within a QUIC connection. A QUIC connection can carry multiple
simultaneous streams. simultaneous streams.
Application: An entity that uses QUIC to send and receive data. Application: An entity that uses QUIC to send and receive data.
1.3. Notational Conventions 1.3. Notational Conventions
Packet and frame diagrams in this document use a bespoke format. The Packet and frame diagrams in this document use a custom format. The
purpose of this format is to summarize, not define, protocol purpose of this format is to summarize, not define, protocol
elements. Prose defines the complete semantics and details of elements. Prose defines the complete semantics and details of
structures. structures.
Complex fields are named and then followed by a list of fields Complex fields are named and then followed by a list of fields
surrounded by a pair of matching braces. Each field in this list is surrounded by a pair of matching braces. Each field in this list is
separated by commas. separated by commas.
Individual fields include length information, plus indications about Individual fields include length information, plus indications about
fixed value, optionality, or repetitions. Individual fields use the fixed value, optionality, or repetitions. Individual fields use the
skipping to change at page 10, line 10 skipping to change at page 10, line 45
x (A): Indicates that x is A bits long x (A): Indicates that x is A bits long
x (i): Indicates that x uses the variable-length encoding in x (i): Indicates that x uses the variable-length encoding in
Section 16 Section 16
x (A..B): Indicates that x can be any length from A to B; A can be x (A..B): Indicates that x can be any length from A to B; A can be
omitted to indicate a minimum of zero bits and B can be omitted to omitted to indicate a minimum of zero bits and B can be omitted to
indicate no set upper limit; values in this format always end on indicate no set upper limit; values in this format always end on
an octet boundary an octet boundary
x (?) = C: Indicates that x has a fixed value of C x (?) = C: Indicates that x has a fixed value of C with the length
described by ?, as above
x (?) = C..D: Indicates that x has a value in the range from C to D, x (?) = C..D: Indicates that x has a value in the range from C to D,
inclusive inclusive, with the length described by ?, as above
[x (E)]: Indicates that x is optional (and has length of E) [x (E)]: Indicates that x is optional (and has length of E)
x (E) ...: Indicates that x is repeated zero or more times (and that x (E) ...: Indicates that x is repeated zero or more times (and that
each instance is length E) each instance is length E)
This document uses network byte order (that is, big endian) values. This document uses network byte order (that is, big endian) values.
Fields are placed starting from the high-order bits of each byte. Fields are placed starting from the high-order bits of each byte.
By convention, individual fields reference a complex field by using By convention, individual fields reference a complex field by using
the name of the complex field. the name of the complex field.
For example: For example:
skipping to change at page 10, line 46 skipping to change at page 11, line 33
[Optional Field (64)], [Optional Field (64)],
Repeated Field (8) ..., Repeated Field (8) ...,
} }
Figure 1: Example Format Figure 1: Example Format
2. Streams 2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. Streams can be unidirectional or abstraction to an application. Streams can be unidirectional or
bidirectional. An alternative view of QUIC unidirectional streams is bidirectional.
a "message" abstraction of practically unlimited length.
Streams can be created by sending data. Other processes associated Streams can be created by sending data. Other processes associated
with stream management - ending, cancelling, and managing flow with stream management - ending, cancelling, and managing flow
control - are all designed to impose minimal overheads. For control - are all designed to impose minimal overheads. For
instance, a single STREAM frame (Section 19.8) can open, carry data instance, a single STREAM frame (Section 19.8) can open, carry data
for, and close a stream. Streams can also be long-lived and can last for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection. the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not interleaved with other streams, and can be cancelled. QUIC does not
skipping to change at page 11, line 44 skipping to change at page 12, line 27
The least significant bit (0x1) of the stream ID identifies the The least significant bit (0x1) of the stream ID identifies the
initiator of the stream. Client-initiated streams have even-numbered initiator of the stream. Client-initiated streams have even-numbered
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 (0x2) of the stream ID distinguishes The second least significant bit (0x2) of the stream ID distinguishes
between bidirectional streams (with the bit set to 0) and between bidirectional streams (with the bit set to 0) and
unidirectional streams (with the bit set to 1). unidirectional streams (with the bit set to 1).
The least significant two 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 |
+======+==================================+ +======+==================================+
| 0x0 | Client-Initiated, Bidirectional | | 0x0 | Client-Initiated, Bidirectional |
+------+----------------------------------+ +------+----------------------------------+
| 0x1 | Server-Initiated, Bidirectional | | 0x1 | Server-Initiated, Bidirectional |
+------+----------------------------------+ +------+----------------------------------+
| 0x2 | Client-Initiated, Unidirectional | | 0x2 | Client-Initiated, Unidirectional |
+------+----------------------------------+ +------+----------------------------------+
| 0x3 | Server-Initiated, Unidirectional | | 0x3 | Server-Initiated, Unidirectional |
+------+----------------------------------+ +------+----------------------------------+
Table 1: Stream ID Types Table 1: Stream ID Types
Within each type, streams are created with numerically increasing The stream space for each type begins at the minimum value (0x0
stream IDs. A stream ID that is used out of order results in all through 0x3 respectively); successive streams of each type are
streams of that type with lower-numbered stream IDs also being created with numerically increasing stream IDs. A stream ID that is
opened. used out of order results in all streams of that type with lower-
numbered stream IDs also being opened.
The first bidirectional stream opened by the client has a stream ID
of 0.
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.
An endpoint uses the Stream ID and Offset fields in STREAM frames to An endpoint uses the Stream ID and Offset fields in STREAM frames to
place data in order. place data in order.
Endpoints MUST be able to deliver stream data to an application as an Endpoints MUST be able to deliver stream data to an application as an
ordered byte-stream. Delivering an ordered byte-stream requires that ordered byte-stream. Delivering an ordered byte-stream requires that
an endpoint buffer any data that is received out of order, up to the an endpoint buffer any data that is received out of order, up to the
skipping to change at page 13, line 20 skipping to change at page 13, line 47
Stream multiplexing can have a significant effect on application Stream multiplexing can have a significant effect on application
performance if resources allocated to streams are correctly performance if resources allocated to streams are correctly
prioritized. prioritized.
QUIC does not provide a mechanism for exchanging prioritization QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information information. Instead, it relies on receiving priority information
from the application that uses QUIC. from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding the streams indicate the relative priority of streams. An implementation uses
to which resources are dedicated, the implementation SHOULD use the information provided by the application to determine how to allocate
information provided by the application. resources to active streams.
2.4. Required Operations on Streams 2.4. Operations on Streams
There are certain operations that an application MUST be able to This document does not define an API for QUIC, but instead defines a
perform when interacting with QUIC streams. This document does not set of functions on streams that application protocols can rely upon.
specify an API, but any implementation of this version of QUIC MUST An application protocol can assume that an implementation of QUIC
expose the ability to perform the operations described in this provides an interface that includes the operations described in this
section on a QUIC stream. section. An implementation designed for use with a specific
application protocol might provide only those operations that are
used by that protocol.
On the sending part of a stream, application protocols need to be On the sending part of a stream, an application protocol can:
able to:
* 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;
* 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
* 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, application protocols need to be On the receiving part of a stream, an application protocol can:
able to:
* read data; and * read data; and
* 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).
Applications also need to be informed of state changes on streams, An application protocol can also request to be informed of state
including when the peer has opened or reset a stream, when a peer changes on streams, including when the peer has opened or reset a
aborts reading on a stream, when new data is available, and when data stream, when a peer aborts reading on a stream, when new data is
can or cannot be written to the stream due to flow control. available, and when data can or cannot be written to the stream due
to flow control.
3. Stream States 3. Stream States
This section describes streams in terms of their send or receive This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on components. Two state machines are described: one for the streams on
which an endpoint transmits data (Section 3.1), and another for which an endpoint transmits data (Section 3.1), and another for
streams on which an endpoint receives data (Section 3.2). streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly. Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part, Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is the use of these state machines is the same whether the stream is
unidirectional or bidirectional. The conditions for opening a stream unidirectional or bidirectional. The conditions for opening a stream
are slightly more complex for a bidirectional stream because the are slightly more complex for a bidirectional stream because the
opening of either the send or receive side causes the stream to open opening of either the send or receive side causes the stream to open
in both directions. in both directions.
An endpoint MUST open streams of the same type in increasing order of These state machines shown in this section are largely informative.
stream ID. This document uses stream states to describe rules for when and how
different types of frames can be sent and the reactions that are
expected when different types of frames are received. Though these
state machines are intended to be useful in implementing QUIC, these
states are not intended to constrain implementations. An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements these
states.
Note: These states are largely informative. This document uses Note: In some cases, a single event or action can cause a transition
stream states to describe rules for when and how different types through multiple states. For instance, sending STREAM with a FIN
of frames can be sent and the reactions that are expected when bit set can cause two state transitions for a sending stream: from
different types of frames are received. Though these state the Ready state to the Send state, and from the Send state to the
machines are intended to be useful in implementing QUIC, these Data Sent state.
states aren't intended to constrain implementations. An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements
these states.
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 18, line 6 skipping to change at page 19, line 6
+-------+ +-------+ +-------+ +-------+
Figure 3: States for Receiving Parts of Streams Figure 3: States for Receiving Parts of Streams
The receiving part of a stream initiated by a peer (types 1 and 3 for The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM, a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that
stream. For bidirectional streams initiated by a peer, receipt of a stream. For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part. The initial state for the stream also creates the receiving part. The initial state for the
receiving part of stream is "Recv". receiving part of a stream is "Recv".
The receiving part of a stream enters the "Recv" state when the The receiving part of a stream enters the "Recv" state when the
sending part of a bidirectional stream initiated by the endpoint sending part of a bidirectional stream initiated by the endpoint
(type 0 for a client, type 1 for a server) enters the "Ready" state. (type 0 for a client, type 1 for a server) enters the "Ready" state.
An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or
STOP_SENDING frame is received from the peer for that stream. STOP_SENDING frame is received from the peer for that stream.
Receiving a MAX_STREAM_DATA frame for an unopened stream indicates Receiving a MAX_STREAM_DATA frame for an unopened stream indicates
that the remote peer has opened the stream and is providing flow that the remote peer has opened the stream and is providing flow
control credit. Receiving a STOP_SENDING frame for an unopened control credit. Receiving a STOP_SENDING frame for an unopened
skipping to change at page 19, line 5 skipping to change at page 20, line 5
STREAM_DATA_BLOCKED frames for the stream can be discarded. STREAM_DATA_BLOCKED frames for the stream can be discarded.
The "Data Recvd" state persists until stream data has been delivered The "Data Recvd" state persists until stream data has been delivered
to the application. Once stream data has been delivered, the stream to the application. Once stream data has been delivered, the stream
enters the "Data Read" state, which is a terminal state. enters the "Data Read" state, which is a terminal state.
Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states
causes the stream to enter the "Reset Recvd" state. This might cause causes the stream to enter the "Reset Recvd" state. This might cause
the delivery of stream data to the application to be interrupted. the delivery of stream data to the application to be interrupted.
It is possible that all stream data is received when a RESET_STREAM It is possible that all stream data has already been received when a
is received (that is, from the "Data Recvd" state). Similarly, it is RESET_STREAM is received (that is, in the "Data Recvd" state).
possible for remaining stream data to arrive after receiving a Similarly, it is possible for remaining stream data to arrive after
RESET_STREAM frame (the "Reset Recvd" state). An implementation is receiving a RESET_STREAM frame (the "Reset Recvd" state). An
free to manage this situation as it chooses. implementation is free to manage this situation as it chooses.
Sending RESET_STREAM means that an endpoint cannot guarantee delivery Sending RESET_STREAM means that an endpoint cannot guarantee delivery
of stream data; however there is no requirement that stream data not of stream data; however there is no requirement that stream data not
be delivered if a RESET_STREAM is received. An implementation MAY be delivered if a RESET_STREAM is received. An implementation MAY
interrupt delivery of stream data, discard any data that was not interrupt delivery of stream data, discard any data that was not
consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM consumed, and signal the receipt of the RESET_STREAM. A RESET_STREAM
signal might be suppressed or withheld if stream data is completely signal might be suppressed or withheld if stream data is completely
received and is buffered to be read by the application. If the received and is buffered to be read by the application. If the
RESET_STREAM is suppressed, the receiving part of the stream remains RESET_STREAM is suppressed, the receiving part of the stream remains
in "Data Recvd". in "Data Recvd".
skipping to change at page 21, line 5 skipping to change at page 22, line 5
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 in HTTP/2 [HTTP2]. This that loosely correspond to the stream states in HTTP/2 [HTTP2]. This
shows that multiple states on sending or receiving parts of streams shows that multiple states on sending or receiving parts of streams
are mapped to the same composite state. Note that this is just one are mapped to the same composite state. Note that this is just one
possibility for such a mapping; this mapping requires that data is possibility for such a mapping; this mapping requires that data is
acknowledged before the transition to a "closed" or "half-closed" acknowledged before the transition to a "closed" or "half-closed"
state. 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 Sent | Recv/Size Known | open | | Ready/Send/Data Sent | Recv/Size Known | open |
+----------------------+----------------------+-----------------+ +----------------------+----------------------+-----------------+
| Ready/Send/Data Sent | Data Recvd/Data Read | half-closed | | Ready/Send/Data Sent | Data Recvd/Data Read | half-closed |
| | | (remote) | | | | (remote) |
+----------------------+----------------------+-----------------+ +----------------------+----------------------+-----------------+
| Ready/Send/Data Sent | Reset Recvd/Reset | half-closed | | Ready/Send/Data Sent | Reset Recvd/Reset | half-closed |
skipping to change at page 22, line 19 skipping to change at page 23, line 19
from the stream, but it is not a guarantee that incoming data will be from the stream, but it is not a guarantee that incoming data will be
ignored. ignored.
STREAM frames received after sending a STOP_SENDING frame are still STREAM frames received after sending a STOP_SENDING frame are still
counted toward connection and stream flow control, even though these counted toward connection and stream flow control, even though these
frames can be discarded upon receipt. frames can be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame if the stream is in the Ready or Send MUST send a RESET_STREAM frame if the stream is in the Ready or Send
state. If the stream is in the Data Sent state and any outstanding state. If the stream is in the "Data Sent" state, an endpoint MAY
data is declared lost, an endpoint SHOULD send a RESET_STREAM frame defer sending the RESET_STREAM frame until the packets containing
in lieu of a retransmission. outstanding data are acknowledged or declared lost. If any
outstanding data is declared lost, the endpoint SHOULD send a
RESET_STREAM frame instead of retransmitting the data.
An endpoint SHOULD copy the error code from the STOP_SENDING frame to An endpoint SHOULD copy the error code from the STOP_SENDING frame to
the RESET_STREAM frame it sends, but MAY use any application error the RESET_STREAM frame it sends, but MAY use any application error
code. The endpoint that sends a STOP_SENDING frame MAY ignore the code. The endpoint that sends a STOP_SENDING frame MAY ignore the
error code carried in any RESET_STREAM frame it receives. error code carried in any RESET_STREAM frame it receives.
If the STOP_SENDING frame is received on a stream that is already in
the "Data Sent" state, an endpoint that wishes to cease
retransmission of previously-sent STREAM frames on that stream MUST
first send a RESET_STREAM frame.
STOP_SENDING SHOULD only be sent for a stream that has not been reset STOP_SENDING SHOULD only be sent for a stream that has not been reset
by the peer. STOP_SENDING is most useful for streams in the "Recv" by the peer. STOP_SENDING is most useful for streams in the "Recv"
or "Size Known" states. or "Size Known" states.
An endpoint is expected to send another STOP_SENDING frame if a An endpoint is expected to send another STOP_SENDING frame if a
packet containing a previous STOP_SENDING is lost. However, once packet containing a previous STOP_SENDING is lost. However, once
either all stream data or a RESET_STREAM frame has been received for either all stream data or a RESET_STREAM frame has been received for
the stream - that is, the stream is in any state other than "Recv" or the stream - that is, the stream is in any state other than "Recv" or
"Size Known" - sending a STOP_SENDING frame is unnecessary. "Size Known" - sending a STOP_SENDING frame is unnecessary.
skipping to change at page 23, line 29 skipping to change at page 24, line 20
Data sent in CRYPTO frames is not flow controlled in the same way as Data sent in CRYPTO frames is not flow controlled in the same way as
stream data. QUIC relies on the cryptographic protocol stream data. QUIC relies on the cryptographic protocol
implementation to avoid excessive buffering of data; see [QUIC-TLS]. implementation to avoid excessive buffering of data; see [QUIC-TLS].
The implementation SHOULD provide an interface to QUIC to tell it The implementation SHOULD provide an interface to QUIC to tell it
about its buffering limits so that there is not excessive buffering about its buffering limits so that there is not excessive buffering
at multiple layers. at multiple layers.
4.1. Data Flow Control 4.1. Data Flow Control
QUIC employs a credit-based flow-control scheme similar to that in QUIC employs a limit-based flow-control scheme where a receiver
HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is advertises the limit of total bytes it is prepared to receive on a
prepared to receive on a given stream and for the entire connection. given stream or for the entire connection. This leads to two levels
This leads to two levels of data flow control in QUIC: of data flow control in QUIC:
* 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 any stream. of data that can be sent on any stream.
* 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.
A receiver sets initial credits for all streams by sending transport Senders MUST NOT send data in excess of either limit.
A receiver sets initial limits for all streams by sending transport
parameters during the handshake (Section 7.4). A receiver sends parameters during the handshake (Section 7.4). A receiver sends
MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to
the sender to advertise additional credit. the sender to advertise larger limits.
A receiver advertises credit for a stream by sending a A receiver can advertise a larger limit for a stream by sending a
MAX_STREAM_DATA frame with the Stream ID field set appropriately. A MAX_STREAM_DATA frame with the corresponding stream ID. A
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
stream. A receiver could use the current offset of data consumed to stream. A receiver could use the current offset of data consumed to
determine the flow control offset to be advertised. A receiver MAY determine the flow control offset to be advertised.
send MAX_STREAM_DATA frames in multiple packets in order to make sure
that the sender receives an update before running out of flow control
credit, even if one of the packets is lost.
A receiver advertises credit for a connection by sending a MAX_DATA A receiver can advertise a larger limit for a connection by sending a
frame, which indicates the maximum of the sum of the absolute byte MAX_DATA frame, which indicates the maximum of the sum of the
offsets of all streams. A receiver maintains a cumulative sum of absolute byte offsets of all streams. A receiver maintains a
bytes received on all streams, which is used to check for flow cumulative sum of bytes received on all streams, which is used to
control violations. A receiver might use a sum of bytes consumed on check for violations of the advertised connection or stream data
all streams to determine the maximum data limit to be advertised. limits. A receiver might use a sum of bytes consumed on all streams
to determine the maximum data limit to be advertised.
A receiver can advertise a larger offset by sending MAX_STREAM_DATA Once a receiver advertises a limit for the connection or a stream, it
or MAX_DATA frames. Once a receiver advertises an offset, it MAY MAY advertise a smaller limit, but this has no effect.
advertise a smaller offset, but this has no effect.
A receiver MUST close the connection with a FLOW_CONTROL_ERROR error A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
(Section 11) if the sender violates the advertised connection or (Section 11) if the sender violates the advertised connection or
stream data limits. stream data limits.
A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do
not increase flow control limits. not increase flow control limits.
If a sender runs out of flow control credit, it will be unable to If a sender has sent data up to the limit, it will be unable to send
send new data and is considered blocked. A sender SHOULD send a new data and is considered blocked. A sender SHOULD send a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to
write but is blocked by flow control limits. If a sender is blocked write but is blocked by flow control limits. If a sender is blocked
for a period longer than the idle timeout (Section 10.2), the for a period longer than the idle timeout (Section 10.1), the
connection might be closed even when data is available for receiver might close the connection even when the sender has data
transmission. To keep the connection from closing, a sender that is that is available for transmission. To keep the connection from
flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED closing, a sender that is flow control limited SHOULD periodically
or DATA_BLOCKED frame when it has no ack-eliciting packets in flight. send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it has no ack-
eliciting packets in flight.
4.2. Flow Credit Increments 4.2. Increasing Flow Control Limits
Implementations decide when and how much credit to advertise in Implementations decide when and how much credit to advertise in
MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few
considerations. considerations.
To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or
MAX_DATA frame multiple times within a round trip or send it early MAX_DATA frame multiple times within a round trip or send it early
enough to allow for recovery from loss of the frame. enough to allow for recovery from loss of the frame.
Control frames contribute to connection overhead. Therefore, Control frames contribute to connection overhead. Therefore,
frequently sending MAX_STREAM_DATA and MAX_DATA frames with small frequently sending MAX_STREAM_DATA and MAX_DATA frames with small
changes is undesirable. On the other hand, if updates are less changes is undesirable. On the other hand, if updates are less
frequent, larger increments to limits are necessary to avoid blocking frequent, larger increments to limits are necessary to avoid blocking
a sender, requiring larger resource commitments at the receiver. a sender, requiring larger resource commitments at the receiver.
There is a trade-off between resource commitment and overhead when There is a trade-off between resource commitment and overhead when
determining how large a limit is advertised. determining how large a limit is advertised.
skipping to change at page 25, line 42 skipping to change at page 26, line 34
how a sender can avoid this congestion. how a sender can avoid this congestion.
4.3. Handling Stream Cancellation 4.3. Handling Stream Cancellation
Endpoints need to eventually agree on the amount of flow control Endpoints need to eventually agree on the amount of flow control
credit that has been consumed, to avoid either exceeding flow control credit that has been consumed, to avoid either exceeding flow control
limits or deadlocking. limits or deadlocking.
On receipt of a RESET_STREAM frame, an endpoint will tear down state On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that for the matching stream and ignore further data arriving on that
stream. Without the offset included in RESET_STREAM, the two stream.
endpoints could disagree on the number of bytes that count towards
connection flow control.
To remedy this issue, a RESET_STREAM frame (Section 19.4) includes
the final size of data sent on the stream. On receiving a
RESET_STREAM frame, a receiver definitively knows how many bytes were
sent on that stream before the RESET_STREAM frame, and the receiver
MUST use the final size of the stream to account for all bytes sent
on the stream in its connection level flow controller.
RESET_STREAM terminates one direction of a stream abruptly. For a RESET_STREAM terminates one direction of a stream abruptly. For a
bidirectional stream, RESET_STREAM has no effect on data flow in the bidirectional stream, RESET_STREAM has no effect on data flow in the
opposite direction. Both endpoints MUST maintain flow control state opposite direction. Both endpoints MUST maintain flow control state
for the stream in the unterminated direction until that direction for the stream in the unterminated direction until that direction
enters a terminal state, or until one of the endpoints sends enters a terminal state, or until one of the endpoints sends
CONNECTION_CLOSE. CONNECTION_CLOSE.
4.4. Stream Final Size 4.4. Stream Final Size
skipping to change at page 26, line 31 skipping to change at page 27, line 16
final size is the sum of the Offset and Length fields of a STREAM final size is the sum of the Offset and Length fields of a STREAM
frame with a FIN flag, noting that these fields might be implicit. frame with a FIN flag, noting that these fields might be implicit.
Alternatively, the Final Size field of a RESET_STREAM frame carries Alternatively, the Final Size field of a RESET_STREAM frame carries
this value. This ensures that all ways that a stream can be closed this value. This ensures that all ways that a stream can be closed
result in the number of bytes on the stream being reliably result in the number of bytes on the stream being reliably
transmitted. This guarantees that both endpoints agree on how much transmitted. This guarantees that both endpoints agree on how much
flow control credit was consumed by the stream. flow control credit was consumed by the stream.
An endpoint will know the final size for a stream when the receiving An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state part of the stream enters the "Size Known" or "Reset Recvd" state
(Section 3). (Section 3). The receiver MUST use the final size of the stream to
account for all bytes sent on the stream in its connection level flow
controller.
An endpoint MUST NOT send data on a stream at or beyond the final An endpoint MUST NOT send data on a stream at or beyond the final
size. size.
Once a final size for a stream is known, it cannot change. If a Once a final size for a stream is known, it cannot change. If a
RESET_STREAM or STREAM frame is received indicating a change in the RESET_STREAM or STREAM frame is received indicating a change in the
final size for the stream, an endpoint SHOULD respond with a final size for the stream, an endpoint SHOULD respond with a
FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat
receipt of data at or beyond the final size as a FINAL_SIZE_ERROR receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
error, even after a stream is closed. Generating these errors is not error, even after a stream is closed. Generating these errors is not
mandatory, but only because requiring that an endpoint generate these mandatory, but only because requiring that an endpoint generate these
errors also means that the endpoint needs to maintain the final size errors also means that the endpoint needs to maintain the final size
state for closed streams, which could mean a significant state state for closed streams, which could mean a significant state
commitment. commitment.
4.5. Controlling Concurrency 4.5. Controlling Concurrency
An endpoint limits the cumulative number of incoming streams a peer An endpoint limits the cumulative number of incoming streams a peer
can open. Only streams with a stream ID less than (max_stream * 4 + can open. Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened; see Table 5. Initial initial_stream_id_for_type) can be opened; see Table 1. Initial
limits are set in the transport parameters (see Section 18.2) and limits are set in the transport parameters; see Section 18.2.
subsequently limits are advertised using MAX_STREAMS frames Subsequent limits are advertised using MAX_STREAMS frames; see
(Section 19.11). Separate limits apply to unidirectional and Section 19.11. Separate limits apply to unidirectional and
bidirectional streams. bidirectional streams.
If a max_streams transport parameter or MAX_STREAMS frame is received If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer; see that cannot be expressed as a variable-length integer; see
Section 16. If either is received, the connection MUST be closed Section 16. If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR; see immediately with a connection error of type FRAME_ENCODING_ERROR; see
Section 10.3. Section 10.2.
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a frame with a stream ID exceeding the limit it has that receives a frame with a stream ID exceeding the limit it has
sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
(Section 11). (Section 11).
Once a receiver advertises a stream limit using the MAX_STREAMS Once a receiver advertises a stream limit using the MAX_STREAMS
frame, advertising a smaller limit has no effect. A receiver MUST frame, advertising a smaller limit has no effect. A receiver MUST
ignore any MAX_STREAMS frame that does not increase the stream limit. ignore any MAX_STREAMS frame that does not increase the stream limit.
skipping to change at page 27, line 42 skipping to change at page 28, line 25
and how many streams to advertise to a peer via MAX_STREAMS to and how many streams to advertise to a peer via MAX_STREAMS to
implementations. Implementations might choose to increase limits as implementations. Implementations might choose to increase limits as
streams close to keep the number of streams available to peers streams close to keep the number of streams available to peers
roughly consistent. roughly consistent.
An endpoint that is unable to open a new stream due to the peer's An endpoint that is unable to open a new stream due to the peer's
limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This
signal is considered useful for debugging. An endpoint MUST NOT wait signal is considered useful for debugging. An endpoint MUST NOT wait
to receive this signal before advertising additional credit, since to receive this signal before advertising additional credit, since
doing so will mean that the peer will be blocked for at least an doing so will mean that the peer will be blocked for at least an
entire round trip, and potentially for longer if the peer chooses to entire round trip, and potentially for longer if the peer chooses not
not send STREAMS_BLOCKED frames. to send STREAMS_BLOCKED frames.
4.6. Flow Control Performance
An endpoint that is unable to ensure that a peer has flow control
credit on the order of the current BDP will have receive throughput
limited by flow control. Lost packets can cause gaps in the receive
buffer, delaying the application from consuming data and freeing up
flow control window.
Sending timely updates of flow control limits can improve
performance. Sending packets only to provide flow control updates
can increase network load and adversely affect performance. Sending
flow control updates along with other frames, such as ACK frames,
reduces the cost of those updates.
5. Connections 5. Connections
QUIC's connection establishment combines version negotiation with the A QUIC connection is shared state between a client and a server.
cryptographic and transport handshakes to reduce connection
establishment latency, as described in Section 7. Once established, Each connection starts with a handshake phase, during which the two
a connection may migrate to a different IP or port at either endpoint endpoints establish a shared secret using the cryptographic handshake
as described in Section 9. Finally, a connection may be terminated protocol [QUIC-TLS] and negotiate the application protocol. The
by either endpoint, as described in Section 10. handshake (Section 7) confirms that both endpoints are willing to
communicate (Section 8.1) and establishes parameters for the
connection (Section 7.4).
An application protocol can use the connection during the handshake
phase with some limitations. 0-RTT allows application data to be
sent by a client before receiving a response from the server.
However, 0-RTT provides no protection against replay attacks; see
Section 9.2 of [QUIC-TLS]. A server can also send application data
to a client before it receives the final cryptographic handshake
messages that allow it to confirm the identity and liveness of the
client. These capabilities allow an application protocol to offer
the option of trading some security guarantees for reduced latency.
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
when forced by a change in a middlebox. Section 9 describes
mitigations for the security and privacy issues associated with
migration.
For connections that are no longer needed or desired, there are
several ways for a client and server to terminate a connection
(Section 10).
5.1. Connection ID 5.1. Connection ID
Each connection possesses a set of connection identifiers, or Each connection possesses a set of connection identifiers, or
connection IDs, each of which can identify the connection. connection IDs, each of which can identify the connection.
Connection IDs are independently selected by endpoints; each endpoint Connection IDs are independently selected by endpoints; each endpoint
selects the connection IDs that its peer uses. selects the connection IDs that its peer uses.
The primary function of a connection ID is to ensure that changes in The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for addressing at lower protocol layers (UDP, IP) do not cause packets
a QUIC connection to be delivered to the wrong endpoint. Each for a QUIC connection to be delivered to the wrong endpoint. Each
endpoint selects connection IDs using an implementation-specific (and endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with perhaps deployment-specific) method that will allow packets with that
that connection ID to be routed back to the endpoint and to be connection ID to be routed back to the endpoint and to be identified
identified by the endpoint upon receipt. by the endpoint upon receipt.
Connection IDs MUST NOT contain any information that can be used by Connection IDs MUST NOT contain any information that can be used by
an external observer (that is, one that does not cooperate with the an external observer (that is, one that does not cooperate with the
issuer) to correlate them with other connection IDs for the same issuer) to correlate them with other connection IDs for the same
connection. As a trivial example, this means the same connection ID connection. As a trivial example, this means the same connection ID
MUST NOT be issued more than once on the same connection. MUST NOT be issued more than once on the same connection.
Packets with long headers include Source Connection ID and Packets with long headers include Source Connection ID and
Destination Connection ID fields. These fields are used to set the Destination Connection ID fields. These fields are used to set the
connection IDs for new connections; see Section 7.2 for details. connection IDs for new connections; see Section 7.2 for details.
skipping to change at page 28, line 41 skipping to change at page 30, line 12
Destination Connection ID and omit the explicit length. The length Destination Connection ID and omit the explicit length. The length
of the Destination Connection ID field is expected to be known to of the Destination Connection ID field is expected to be known to
endpoints. Endpoints using a load balancer that routes based on endpoints. Endpoints using a load balancer that routes based on
connection ID could agree with the load balancer on a fixed length connection ID could agree with the load balancer on a fixed length
for connection IDs, or agree on an encoding scheme. A fixed portion for connection IDs, or agree on an encoding scheme. A fixed portion
could encode an explicit length, which allows the entire connection could encode an explicit length, which allows the entire connection
ID to vary in length and still be used by the load balancer. ID to vary in length and still be used by the load balancer.
A Version Negotiation (Section 17.2.1) packet echoes the connection A Version Negotiation (Section 17.2.1) packet echoes the connection
IDs selected by the client, both to ensure correct routing toward the IDs selected by the client, both to ensure correct routing toward the
client and to allow the client to validate that the packet is in client and to demonstrate that the packet is in response to a packet
response to an Initial packet. sent by the client.
A zero-length connection ID can be used when a connection ID is not A zero-length connection ID can be used when a connection ID is not
needed to route to the correct endpoint. However, multiplexing needed to route to the correct endpoint. However, multiplexing
connections on the same local IP address and port while using zero- connections on the same local IP address and port while using zero-
length connection IDs will cause failures in the presence of peer length connection IDs will cause failures in the presence of peer
connection migration, NAT rebinding, and client port reuse; and connection migration, NAT rebinding, and client port reuse. An
therefore MUST NOT be done unless an endpoint is certain that those endpoint MUST NOT use the same IP address and port for multiple
protocol features are not in use. connections with zero-length connection IDs, unless it is certain
that those protocol features are not in use.
When an endpoint uses a non-zero-length connection ID, it needs to When an endpoint uses a non-zero-length connection ID, it needs to
ensure that the peer has a supply of connection IDs from which to ensure that the peer has a supply of connection IDs from which to
choose for packets sent to the endpoint. These connection IDs are choose for packets sent to the endpoint. These connection IDs are
supplied by the endpoint using the NEW_CONNECTION_ID frame supplied by the endpoint using the NEW_CONNECTION_ID frame
(Section 19.15). (Section 19.15).
5.1.1. Issuing Connection IDs 5.1.1. Issuing Connection IDs
Each Connection ID has an associated sequence number to assist in Each Connection ID has an associated sequence number to assist in
detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer
to the same value. The initial connection ID issued by an endpoint to the same value. The initial connection ID issued by an endpoint
is sent in the Source Connection ID field of the long packet header is sent in the Source Connection ID field of the long packet header
(Section 17.2) during the handshake. The sequence number of the (Section 17.2) during the handshake. The sequence number of the
initial connection ID is 0. If the preferred_address transport initial connection ID is 0. If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID parameter is sent, the sequence number of the supplied connection ID
is 1. is 1.
Additional connection IDs are communicated to the peer using Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on NEW_CONNECTION_ID frames (Section 19.15). The sequence number on
each newly-issued connection ID MUST increase by 1. The connection each newly issued connection ID MUST increase by 1. The connection
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). Connection IDs that are issued and not frame (Section 19.16). Connection IDs that are issued and not
retired are considered active; any active connection ID is valid for retired are considered active; any active connection ID is valid for
skipping to change at page 30, line 17 skipping to change at page 31, line 31
Prior To field. After processing a NEW_CONNECTION_ID frame and Prior To field. After processing a NEW_CONNECTION_ID frame and
adding and retiring active connection IDs, if the number of active adding and retiring active connection IDs, if the number of active
connection IDs exceeds the value advertised in its connection IDs exceeds the value advertised in its
active_connection_id_limit transport parameter, an endpoint MUST active_connection_id_limit transport parameter, an endpoint MUST
close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. close the connection with an error of type CONNECTION_ID_LIMIT_ERROR.
An endpoint SHOULD supply a new connection ID when the peer retires a An endpoint SHOULD supply a new connection ID when the peer retires a
connection ID. If an endpoint provided fewer connection IDs than the connection ID. If an endpoint provided fewer connection IDs than the
peer's active_connection_id_limit, it MAY supply a new connection ID peer's active_connection_id_limit, it MAY supply a new connection ID
when it receives a packet with a previously unused connection ID. An when it receives a packet with a previously unused connection ID. An
endpoint MAY limit the frequency or the total number of connection endpoint MAY limit the total number of connection IDs issued for each
IDs issued for each connection to avoid the risk of running out of connection to avoid the risk of running out of connection IDs; see
connection IDs; see Section 10.4.2. An endpoint MAY also limit the Section 10.3.2. An endpoint MAY also limit the issuance of
issuance of connection IDs to reduce the amount of per-path state it connection IDs to reduce the amount of per-path state it maintains,
maintains, such as path validation status, as its peer might interact such as path validation status, as its peer might interact with it
with it over as many paths as there are issued connection IDs. over as many paths as there are issued connection IDs.
An endpoint that initiates migration and requires non-zero-length An endpoint that initiates migration and requires non-zero-length
connection IDs SHOULD ensure that the pool of connection IDs connection IDs SHOULD ensure that the pool of connection IDs
available to its peer allows the peer to use a new connection ID on available to its peer allows the peer to use a new connection ID on
migration, as the peer will close the connection if the pool is migration, as the peer will be unable to respond if the pool is
exhausted. exhausted.
5.1.2. Consuming and Retiring Connection IDs 5.1.2. Consuming and Retiring Connection IDs
An endpoint can change the connection ID it uses for a peer to An endpoint can change the connection ID it uses for a peer to
another available one at any time during the connection. An endpoint another available one at any time during the connection. An endpoint
consumes connection IDs in response to a migrating peer; see consumes connection IDs in response to a migrating peer; see
Section 9.5 for more. Section 9.5 for more.
An endpoint maintains a set of connection IDs received from its peer, An endpoint maintains a set of connection IDs received from its peer,
skipping to change at page 32, line 8 skipping to change at page 33, line 25
with a connection; see Section 5.1. with a connection; see Section 5.1.
If the Destination Connection ID is zero length and the addressing If the Destination Connection ID is zero length and the addressing
information in the packet matches the addressing information the information in the packet matches the addressing information the
endpoint uses to identify a connection with a zero-length connection endpoint uses to identify a connection with a zero-length connection
ID, QUIC processes the packet as part of that connection. An ID, QUIC processes the packet as part of that connection. An
endpoint can use just destination IP and port or both source and endpoint can use just destination IP and port or both source and
destination addresses for identification, though this makes destination addresses for identification, though this makes
connections fragile as described in Section 5.1. connections fragile as described in Section 5.1.
Endpoints can send a Stateless Reset (Section 10.4) for any packets Endpoints can send a Stateless Reset (Section 10.3) for any packets
that cannot be attributed to an existing connection. A stateless that cannot be attributed to an existing connection. A stateless
reset allows a peer to more quickly identify when a connection reset allows a peer to more quickly identify when a connection
becomes unusable. becomes unusable.
Packets that are matched to an existing connection are discarded if Packets that are matched to an existing connection are discarded if
the packets are inconsistent with the state of that connection. For the packets are inconsistent with the state of that connection. For
example, packets are discarded if they indicate a different protocol example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet version than that of the connection, or if the removal of packet
protection is unsuccessful once the expected keys are available. protection is unsuccessful once the expected keys are available.
Invalid packets without packet protection, such as Initial, Retry, or Invalid packets that lack strong integrity protection, such as
Version Negotiation, MAY be discarded. An endpoint MUST generate a Initial, Retry, or Version Negotiation, MAY be discarded. An
connection error if it commits changes to state before discovering an endpoint MUST generate a connection error if processing the contents
error. of these packets prior to discovering an error resulted in changes to
connection state that cannot be reverted.
5.2.1. Client Packet Handling 5.2.1. Client Packet Handling
Valid packets sent to clients always include a Destination Connection Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects. Clients that choose to ID that matches a value the client selects. Clients that choose to
receive zero-length connection IDs can use the local address and port receive zero-length connection IDs can use the local address and port
to identify a connection. Packets that don't match an existing to identify a connection. Packets that do not match an existing
connection are discarded. connection, based on Destination Connection ID or, if this value is
zero-length, local IP address and port, are discarded.
Due to packet reordering or loss, a client might receive packets for Due to packet reordering or loss, a client might receive packets for
a connection that are encrypted with a key it has not yet computed. a connection that are encrypted with a key it has not yet computed.
The client MAY drop these packets, or MAY buffer them in anticipation The client MAY drop these packets, or MAY buffer them in anticipation
of later packets that allow it to compute the key. of later packets that allow it to compute the key.
If a client receives a packet that has an unsupported version, it If a client receives a packet that has an unsupported version, it
MUST discard that packet. MUST discard that packet.
5.2.2. Server Packet Handling 5.2.2. Server Packet Handling
If a server receives a packet that indicates an unsupported version If a server receives a packet that indicates an unsupported version
but is large enough to initiate a new connection for any one but is large enough to initiate a new connection for any supported
supported version, the server SHOULD send a Version Negotiation version, the server SHOULD send a Version Negotiation packet as
packet as described in Section 6.1. Servers MAY limit the number of described in Section 6.1. A server MAY limit the number of packets
packets that it responds to with a Version Negotiation packet. to which it responds with a Version Negotiation packet. Servers MUST
Servers MUST drop smaller packets that specify unsupported versions. drop smaller packets that specify unsupported versions.
The first packet for an unsupported version can use different The first packet for an unsupported version can use different
semantics and encodings for any version-specific field. In semantics and encodings for any version-specific field. In
particular, different packet protection keys might be used for particular, different packet protection keys might be used for
different versions. Servers that do not support a particular version different versions. Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet. are unlikely to be able to decrypt the payload of the packet or
Servers SHOULD NOT attempt to decode or decrypt a packet from an properly interpret the result. Servers SHOULD respond with a Version
unknown version, but instead send a Version Negotiation packet, Negotiation packet, provided that the datagram is sufficiently long.
provided that the packet is sufficiently long.
Packets with a supported version, or no version field, are matched to Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero- a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port. If the packet length connection IDs - the local address and port. These packets
doesn't match an existing connection, the server continues below. are processed using the selected connection; otherwise, the server
continues below.
If the packet is an Initial packet fully conforming with the If the packet is an Initial packet fully conforming with the
specification, the server proceeds with the handshake (Section 7). specification, the server proceeds with the handshake (Section 7).
This commits the server to the version that the client selected. This commits the server to the version that the client selected.
If a server refuses to accept a new connection, it SHOULD send an If a server refuses to accept a new connection, it SHOULD send an
Initial packet containing a CONNECTION_CLOSE frame with error code Initial packet containing a CONNECTION_CLOSE frame with error code
CONNECTION_REFUSED. CONNECTION_REFUSED.
If the packet is a 0-RTT packet, the server MAY buffer a limited If the packet is a 0-RTT packet, the server MAY buffer a limited
skipping to change at page 34, line 10 skipping to change at page 35, line 32
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 migration is not supported using the indicate migration is not supported 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
connection migration after a client has acted on a preferred_address connection migration after a client has acted on a preferred_address
transport parameter. transport parameter.
Server deployments that use this simple form of load balancing MUST Server deployments that use this simple form of load balancing MUST
avoid the creation of a stateless reset oracle; see Section 21.9. avoid the creation of a stateless reset oracle; see Section 21.10.
5.3. Life of a QUIC Connection
A QUIC connection is a stateful interaction between a client and
server, the primary purpose of which is to support the exchange of
data by an application protocol. Streams (Section 2) are the primary
means by which an application protocol exchanges information.
Each connection starts with a handshake phase, during which client
and server establish a shared secret using the cryptographic
handshake protocol [QUIC-TLS] and negotiate the application protocol.
The handshake (Section 7) confirms that both endpoints are willing to
communicate (Section 8.1) and establishes parameters for the
connection (Section 7.4).
An application protocol can also operate in a limited fashion during
the handshake phase. 0-RTT allows application data to be sent by a
client before receiving any response from the server. However, 0-RTT
lacks certain key security guarantees. In particular, there is no
protection against replay attacks in 0-RTT; see [QUIC-TLS].
Separately, a server can also send application data to a client
before it receives the final cryptographic handshake messages that
allow it to confirm the identity and liveness of the client. These
capabilities allow an application protocol to offer the option to
trade some security guarantees for reduced latency.
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
when forced by a change in a middlebox. Section 9 describes
mitigations for the security and privacy issues associated with
migration.
For connections that are no longer needed or desired, there are
several ways for a client and server to terminate a connection
(Section 10).
5.4. Required Operations on Connections 5.3. Operations on Connections
There are certain operations that an application MUST be able to This document does not define an API for QUIC, but instead defines a
perform when interacting with the QUIC transport. This document does set of functions for QUIC connections that application protocols can
not specify an API, but any implementation of this version of QUIC rely upon. An application protocol can assume that an implementation
MUST expose the ability to perform the operations described in this of QUIC provides an interface that includes the operations described
section on a QUIC connection. in this section. An implementation designed for use with a specific
application protocol might provide only those operations that are
used by that protocol.
When implementing the client role, applications need to be able to: When implementing the client role, an application protocol can:
* open a connection, which begins the exchange described in * open a connection, which begins the exchange described in
Section 7; Section 7;
* enable 0-RTT when available; and * enable Early Data when available; and
* be informed when 0-RTT has been accepted or rejected by a server. * be informed when Early Data has been accepted or rejected by a
server.
When implementing the server role, applications need to be able to: When implementing the server role, an application protocol can:
* 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;
* 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
* 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 enable rejecting Early from the client's resumption ticket and enable rejecting Early
Data based on that information. Data based on that information.
In either role, applications need to be able to: In either role, an application protocol can:
* 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);
* control resource allocation of various types, including flow * control resource allocation of various types, including flow
control and the number of permitted streams of each type; control and the number of permitted streams of each type;
* identify whether the handshake has completed successfully or is * identify whether the handshake has completed successfully or is
still ongoing; still ongoing;
* keep a connection from silently closing, either by generating PING * keep a connection from silently closing, either by generating PING
frames (Section 19.2) or by requesting that the transport send frames (Section 19.2) or by requesting that the transport send
additional frames before the idle timeout expires (Section 10.2); additional frames before the idle timeout expires (Section 10.1);
and and
* immediately close (Section 10.3) the connection. * immediately close (Section 10.2) the connection.
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation allows a server to indicate that it does not
version that is mutually supported. 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
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first UDP datagram they send to
largest of the minimum packet sizes across all versions they support. the largest of the minimum datagram sizes from all versions they
This ensures that the server responds if there is a mutually support. This ensures that the server responds if there is a
supported version. mutually supported version. A server might not send a Version
Negotiation packet if the datagram it receives is smaller than the
minimum size specified in a different version; see Section 14.1.
6.1. Sending Version Negotiation Packets 6.1. Sending Version Negotiation Packets
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet; see server, the server responds with a Version Negotiation packet; see
Section 17.2.1. This includes a list of versions that the server Section 17.2.1. This includes a list of versions that the server
will accept. An endpoint MUST NOT send a Version Negotiation packet will accept. An endpoint MUST NOT send a Version Negotiation packet
in response to receiving a Version Negotiation packet. in response to receiving a Version Negotiation packet.
This system allows a server to process packets with unsupported This system allows a server to process packets with unsupported
skipping to change at page 37, line 10 skipping to change at page 37, line 45
A client that supports only this version of QUIC MUST abandon the A client that supports only this version of QUIC MUST abandon the
current connection attempt if it receives a Version Negotiation current connection attempt if it receives a Version Negotiation
packet, with the following two exceptions. A client MUST discard any packet, with the following two exceptions. A client MUST discard any
Version Negotiation packet if it has received and successfully Version Negotiation packet if it has received and successfully
processed any other packet, including an earlier Version Negotiation processed any other packet, including an earlier Version Negotiation
packet. A client MUST discard a Version Negotiation packet that packet. A client MUST discard a Version Negotiation packet that
lists the QUIC version selected by the client. lists the QUIC version selected by the client.
How to perform version negotiation is left as future work defined by How to perform version negotiation is left as future work defined by
future versions of QUIC. In particular, that future work will ensure future versions of QUIC. In particular, that future work will ensure
robustness against version downgrade attacks; see Section 21.10. robustness against version downgrade attacks; see Section 21.11.
6.2.1. Version Negotiation Between Draft Versions 6.2.1. Version Negotiation Between Draft Versions
[[RFC editor: please remove this section before publication.]] [[RFC editor: please remove this section before publication.]]
When a draft implementation receives a Version Negotiation packet, it When a draft implementation receives a Version Negotiation packet, it
MAY use it to attempt a new connection with one of the versions MAY use it to attempt a new connection with one of the versions
listed in the packet, instead of abandoning the current connection listed in the packet, instead of abandoning the current connection
attempt; see Section 6.2. attempt; see Section 6.2.
The client MUST check that the Destination and Source Connection ID The client MUST check that the Destination and Source Connection ID
fields match the Source and Destination Connection ID fields in a fields match the Source and Destination Connection ID fields in a
packet that the client sent. If this check fails, the packet MUST be packet that the client sent. If this check fails, the packet MUST be
discarded. discarded.
skipping to change at page 38, line 9 skipping to change at page 38, line 42
unsupported versions are ignored to test that a peer correctly unsupported versions are ignored to test that a peer correctly
ignores the value. For instance, an endpoint could include a ignores the value. For instance, an endpoint could include a
reserved version in a Version Negotiation packet; see Section 17.2.1. reserved version in a Version Negotiation packet; see Section 17.2.1.
Endpoints MAY send packets with a reserved version to test that a Endpoints MAY send packets with a reserved version to test that a
peer correctly discards the packet. peer correctly discards the packet.
7. Cryptographic and Transport Handshake 7. Cryptographic and Transport Handshake
QUIC relies on a combined cryptographic and transport handshake to QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency. QUIC uses the CRYPTO minimize connection establishment latency. QUIC uses the CRYPTO
frame Section 19.6 to transmit the cryptographic handshake. Version frame (Section 19.6) to transmit the cryptographic handshake.
0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different Version 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a
QUIC version number could indicate that a different cryptographic different QUIC version number could indicate that a different
handshake protocol is in use. cryptographic handshake protocol is 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:
* 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, - 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 and 1-RTT packets
- 1-RTT keys have forward secrecy
* authenticated values for transport parameters of both endpoints, * authenticated values for transport parameters of both endpoints,
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.4) (see Section 7.4)
* authenticated negotiation of an application protocol (TLS uses * authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
An endpoint can verify support for Explicit Congestion Notification An endpoint verifies support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in Section 13.4.2. (ECN) by observing whether the ACK frames acknowledging the first
packets it sends carry ECN counts, as described in Section 13.4.2.
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
frames that are used to advance the handshake. Exchange of
application data during the handshake is enabled where possible,
shown with a '*'. Once completed, endpoints are able to exchange
application data.
Client Server
Initial (CRYPTO)
0-RTT (*) ---------->
Initial (CRYPTO)
Handshake (CRYPTO)
<---------- 1-RTT (*)
Handshake (CRYPTO)
1-RTT (*) ---------->
<---------- 1-RTT (HANDSHAKE_DONE,*)
1-RTT (*) <=========> 1-RTT (*)
Figure 4: Simplified QUIC Handshake
Endpoints MUST explicitly negotiate an application protocol. This Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
7.1. Example Handshake Flows 7.1. Example Handshake Flows
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
Section 8.1.2. Section 8.1.2.
Once any address validation exchanges are complete, the cryptographic Once any address validation exchanges are complete, the cryptographic
handshake is used to agree on cryptographic keys. The cryptographic handshake is used to agree on cryptographic keys. The cryptographic
handshake is carried in Initial (Section 17.2.2) and Handshake handshake is carried in Initial (Section 17.2.2) and Handshake
(Section 17.2.4) packets. (Section 17.2.4) packets.
Figure 4 provides an overview of the 1-RTT handshake. Each line Figure 5 provides an overview of the 1-RTT handshake. Each line
shows a QUIC packet with the packet type and packet number shown shows a QUIC packet with the packet type and packet number shown
first, followed by the frames that are typically contained in those first, followed by the frames that are typically contained in those
packets. So, for instance the first packet is of type Initial, with packets. So, for instance the first packet is of type Initial, with
packet number 0, and contains a CRYPTO frame carrying the packet number 0, and contains a CRYPTO frame carrying the
ClientHello. ClientHello.
Multiple QUIC packets - even of different packet types - can be Multiple QUIC packets - even of different packet types - can be
coalesced into a single UDP datagram; see Section 12.2. As a result, coalesced into a single UDP datagram; see Section 12.2. As a result,
this handshake may consist of as few as 4 UDP datagrams, or any this handshake may consist of as few as 4 UDP datagrams, or any
number more (subject to limits inherent to the protocol, such as number more (subject to limits inherent to the protocol, such as
skipping to change at page 39, line 45 skipping to change at page 40, line 49
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Initial[1]: ACK[0] Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1-RTT[0]: STREAM[0, "..."], ACK[0] ->
Handshake[1]: ACK[0] Handshake[1]: ACK[0]
<- 1-RTT[1]: STREAM[3, "..."], ACK[0] <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]
Figure 4: Example 1-RTT Handshake Figure 5: Example 1-RTT Handshake
Figure 5 shows an example of a connection with a 0-RTT handshake and Figure 6 shows an example of a connection with a 0-RTT handshake and
a single packet of 0-RTT data. Note that as described in a single packet of 0-RTT data. Note that as described in
Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets, Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets,
and the client sends 1-RTT packets in the same packet number space. and the client sends 1-RTT packets in the same packet number space.
Client Server Client Server
Initial[0]: CRYPTO[CH] Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] -> 0-RTT[0]: STREAM[0, "..."] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0] CRYPTO[EE, FIN] Handshake[0] CRYPTO[EE, FIN]
<- 1-RTT[0]: STREAM[1, "..."] ACK[0] <- 1-RTT[0]: STREAM[1, "..."] ACK[0]
Initial[1]: ACK[0] Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1-RTT[1]: STREAM[0, "..."] ACK[0] ->
Handshake[1]: ACK[0] Handshake[1]: ACK[0]
<- 1-RTT[1]: STREAM[3, "..."], ACK[1] <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]
Figure 5: Example 0-RTT Handshake Figure 6: Example 0-RTT Handshake
7.2. Negotiating Connection IDs 7.2. Negotiating Connection IDs
A connection ID is used to ensure consistent routing of packets, as A connection ID is used to ensure consistent routing of packets, as
described in Section 5.1. The long header contains two connection described in Section 5.1. The long header contains two connection
IDs: the Destination Connection ID is chosen by the recipient of the IDs: the Destination Connection ID is chosen by the recipient of the
packet and is used to provide consistent routing; the Source packet and is used to provide consistent routing; the Source
Connection ID is used to set the Destination Connection ID used by Connection ID is used to set the Destination Connection ID used by
the peer. the peer.
During the handshake, packets with the long header (Section 17.2) are During the handshake, packets with the long header (Section 17.2) are
used to establish the connection IDs in each direction. Each used to establish the connection IDs used by both endpoints. Each
endpoint uses the Source Connection ID field to specify the endpoint uses the Source Connection ID field to specify the
connection ID that is used in the Destination Connection ID field of connection ID that is used in the Destination Connection ID field of
packets being sent to them. Upon receiving a packet, each endpoint packets being sent to them. After processing the first Initial
sets the Destination Connection ID it sends to match the value of the packet, each endpoint sets the Destination Connection ID field in
Source Connection ID that it receives. subsequent packets it sends to the value of the Source Connection ID
field that it received.
When an Initial packet is sent by a client that has not previously When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, the client received an Initial or Retry packet from the server, the client
populates the Destination Connection ID field with an unpredictable populates the Destination Connection ID field with an unpredictable
value. This Destination Connection ID MUST be at least 8 bytes in value. This Destination Connection ID MUST be at least 8 bytes in
length. Until a packet is received from the server, the client MUST length. Until a packet is received from the server, the client MUST
use the same Destination Connection ID value on all packets in this use the same Destination Connection ID value on all packets in this
connection. This Destination Connection ID is used to determine connection.
packet protection keys for Initial packets.
The Destination Connection ID field from the first Initial packet
sent by a client is used to determine packet protection keys for
Initial packets. These keys change after receiving a Retry packet;
see Section 5.2 of [QUIC-TLS].
The client populates the Source Connection ID field with a value of The client populates the Source Connection ID field with a value of
its choosing and sets the Source Connection ID Length field to its choosing and sets the Source Connection ID Length field to
indicate the length. indicate the length.
The first flight of 0-RTT packets use the same Destination Connection The first flight of 0-RTT packets use the same Destination Connection
ID and Source Connection ID values as the client's first Initial ID and Source Connection ID values as the client's first Initial
packet. packet.
Upon first receiving an Initial or Retry packet from the server, the Upon first receiving an Initial or Retry packet from the server, the
skipping to change at page 41, line 25 skipping to change at page 42, line 34
once in response to an Initial packet from the server. Once a client once in response to an Initial packet from the server. Once a client
has received a valid Initial packet from the server, it MUST discard has received a valid Initial packet from the server, it MUST discard
any subsequent packet it receives with a different Source Connection any subsequent packet it receives with a different Source Connection
ID. ID.
A client MUST change the Destination Connection ID it uses for A client MUST change the Destination Connection ID it uses for
sending packets in response to only the first received Initial or sending packets in response to only the first received Initial or
Retry packet. A server MUST set the Destination Connection ID it Retry packet. A server MUST set the Destination Connection ID it
uses for sending packets based on the first received Initial packet. uses for sending packets based on the first received Initial packet.
Any further changes to the Destination Connection ID are only Any further changes to the Destination Connection ID are only
permitted if the values are taken from any received NEW_CONNECTION_ID permitted if the values are taken from NEW_CONNECTION_ID frames; if
frames; if subsequent Initial packets include a different Source subsequent Initial packets include a different Source Connection ID,
Connection ID, they MUST be discarded. This avoids unpredictable they MUST be discarded. This avoids unpredictable outcomes that
outcomes that might otherwise result from stateless processing of might otherwise result from stateless processing of multiple Initial
multiple Initial packets with different Source Connection IDs. packets with different Source Connection IDs.
The Destination Connection ID that an endpoint sends can change over The Destination Connection ID that an endpoint sends can change over
the lifetime of a connection, especially in response to connection the lifetime of a connection, especially in response to connection
migration (Section 9); see Section 5.1.1 for details. migration (Section 9); see Section 5.1.1 for details.
7.3. Authenticating Connection IDs 7.3. Authenticating Connection IDs
The choice each endpoint makes about connection IDs during the The choice each endpoint makes about connection IDs during the
handshake is authenticated by including all values in transport handshake is authenticated by including all values in transport
parameters; see Section 7.4. This ensures that all connection IDs parameters; see Section 7.4. This ensures that all connection IDs
used for the handshake are also authenticated by the cryptographic used for the handshake are also authenticated by the cryptographic
handshake. handshake.
Each endpoint includes the value of the Source Connection ID field Each endpoint includes the value of the Source Connection ID field
from the first Initial packet it sent in the from the first Initial packet it sent in the
initial_source_connection_id transport parameter; see Section 18.2. initial_source_connection_id transport parameter; see Section 18.2.
A server includes the Destination Connection ID field from the first A server includes the Destination Connection ID field from the first
Initial packet it received from the client in the Initial packet it received from the client in the
original_destination_connection_id transport parameter; if the server original_destination_connection_id transport parameter; if the server
sent a Retry packet this refers to the first Initial packet received sent a Retry packet, this refers to the first Initial packet received
before sending the Retry packet. If it sends a Retry packet, a before sending the Retry packet. If it sends a Retry packet, a
server also includes the Source Connection ID field from the Retry server also includes the Source Connection ID field from the Retry
packet in the retry_source_connection_id transport parameter. packet in the retry_source_connection_id transport parameter.
The values provided by a peer for these transport parameters MUST The values provided by a peer for these transport parameters MUST
match the values that an endpoint used in the Destination and Source match the values that an endpoint used in the Destination and Source
Connection ID fields of Initial packets that it sent. Including Connection ID fields of Initial packets that it sent. Including
connection ID values in transport parameters and verifying them connection ID values in transport parameters and verifying them
ensures that that an attacker cannot influence the choice of ensures that that an attacker cannot influence the choice of
connection ID for a successful connection by injecting packets connection ID for a successful connection by injecting packets
skipping to change at page 42, line 34 skipping to change at page 43, line 45
* 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
* 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 6 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 6: Use of Connection IDs in a Handshake Figure 7: Use of Connection IDs in a Handshake
Figure 7 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
... ...
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 with Retry Figure 8: Use of Connection IDs in a Handshake with Retry
In both cases (Figure 6 and Figure 7), the client sets the value of In both cases (Figure 7 and Figure 8), the client sets the value of
the initial_source_connection_id transport parameter to "C1". the initial_source_connection_id transport parameter to "C1".
When the handshake does not include a Retry (Figure 6), the server When the handshake does not include a Retry (Figure 7), the server
sets original_destination_connection_id to "S1" and sets original_destination_connection_id to "S1" and
initial_source_connection_id to "S3". In this case, the server does initial_source_connection_id to "S3". In this case, the server does
not include a retry_source_connection_id transport parameter. not include a retry_source_connection_id transport parameter.
When the handshake includes a Retry (Figure 7), the server sets When the handshake includes a Retry (Figure 8), the server sets
original_destination_connection_id to "S1", original_destination_connection_id to "S1",
retry_source_connection_id to "S2", and initial_source_connection_id retry_source_connection_id to "S2", and initial_source_connection_id
to "S3". to "S3".
Each endpoint validates transport parameters set by the peer. The Each endpoint validates transport parameters set by the peer. The
client confirms that the retry_source_connection_id transport client confirms that the retry_source_connection_id transport
parameter is absent if it did not process a Retry packet. parameter is absent if it did not process a Retry packet.
7.4. Transport Parameters 7.4. Transport Parameters
skipping to change at page 43, line 50 skipping to change at page 45, line 14
Transport parameters are declarations that are made unilaterally by Transport parameters are declarations that are made unilaterally by
each endpoint. Each endpoint can choose values for transport each endpoint. Each endpoint can choose values for transport
parameters independent of the values chosen by its peer. parameters independent of the values chosen by its peer.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. values provided by its peer.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.2. in Section 18.2.
An endpoint MUST treat receipt of a transport parameter with an An endpoint MUST treat receipt of a transport parameter with an
invalid value as a connection error of type invalid value as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
An endpoint MUST NOT send a parameter more than once in a given An endpoint MUST NOT send a parameter more than once in a given
transport parameters extension. An endpoint SHOULD treat receipt of transport parameters extension. An endpoint SHOULD treat receipt of
duplicate transport parameters as a connection error of type duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
Endpoints use transport parameters to authenticate the negotiation of Endpoints use transport parameters to authenticate the negotiation of
connection IDs during the handshake; see Section 7.3. connection IDs during the handshake; see Section 7.3.
Application Layer Protocol Negotiation (ALPN; see [ALPN]) allows
clients to offer multiple application protocols during connection
establishment. The transport parameters that a client includes
during the handshake apply to all application protocols that the
client offers. Application protocols can recommend values for
transport parameters, such as the initial flow control limits.
However, application protocols that set constraints on values for
transport parameters could make it impossible for a client to offer
multiple application protocols if these constraints conflict.
7.4.1. Values of Transport Parameters for 0-RTT 7.4.1. Values of Transport Parameters for 0-RTT
Both endpoints store the value of the server transport parameters Using 0-RTT depends on both client and server using protocol
from a connection and apply them to any 0-RTT packets that are sent parameters that were negotiated from a previous connection. To
in subsequent connections to that peer, except for transport enable 0-RTT, endpoints store the value of the server transport
parameters that are explicitly excluded. Remembered transport parameters from a connection and apply them to any 0-RTT packets that
parameters apply to the new connection until the handshake completes are sent in subsequent connections to that peer. This information is
and the client starts sending 1-RTT packets. Once the handshake stored with any information required by the application protocol or
completes, the client uses the transport parameters established in cryptographic handshake; see Section 4.6 of [QUIC-TLS].
the handshake.
The definition of new transport parameters (Section 7.4.2) MUST Remembered transport parameters apply to the new connection until the
specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A handshake completes and the client starts sending 1-RTT packets.
client need not store a transport parameter it cannot process. Once the handshake completes, the client uses the transport
parameters established in the handshake. Not all transport
parameters are remembered, as some do not apply to future connections
or they have no effect on use of 0-RTT.
The definition of a new transport parameter (Section 7.4.2) MUST
specify whether storing the transport parameter for 0-RTT is
mandatory, optional, or prohibited. A client need not store a
transport parameter it cannot process.
A client MUST NOT use remembered values for the following parameters: A client MUST NOT use remembered values for the following parameters:
ack_delay_exponent, max_ack_delay, initial_source_connection_id, ack_delay_exponent, max_ack_delay, initial_source_connection_id,
original_destination_connection_id, preferred_address, original_destination_connection_id, preferred_address,
retry_source_connection_id, and stateless_reset_token. The client retry_source_connection_id, and stateless_reset_token. The client
MUST use the server's new values in the handshake instead, and absent MUST use the server's new values in the handshake instead; if the
new values from the server, the default value. server does not provide new values, the default value is used.
A client that attempts to send 0-RTT data MUST remember all other A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server. The server can remember transport parameters used by the server. The server can remember
these transport parameters, or store an integrity-protected copy of these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting the values in the ticket and recover the information when accepting
0-RTT data. A server uses the transport parameters in determining 0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data. 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
skipping to change at page 45, line 24 skipping to change at page 47, line 4
* initial_max_stream_data_bidi_local * initial_max_stream_data_bidi_local
* initial_max_stream_data_bidi_remote * initial_max_stream_data_bidi_remote
* initial_max_stream_data_uni * initial_max_stream_data_uni
* initial_max_streams_bidi * initial_max_streams_bidi
* 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 sending of application subset of transport parameters that permit 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 initial_max_streams_bidi and initial_max_data and either initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
initial_max_stream_data_uni. initial_max_stream_data_uni.
A server MAY store and recover the previously sent values of the
max_idle_timeout, max_udp_payload_size, and disable_active_migration
parameters and reject 0-RTT if it selects smaller values. Lowering
the values of these parameters while also accepting 0-RTT data could
degrade the performance of the connection. Specifically, lowering
the max_udp_payload_size could result in dropped packets leading to
worse performance compared to rejecting 0-RTT data outright.
A server MUST either reject 0-RTT data or abort a handshake if the A server MUST either reject 0-RTT data or abort a handshake if the
implied values for transport parameters cannot be supported. implied values for transport parameters cannot be supported.
When sending frames in 0-RTT packets, a client MUST only use When sending frames in 0-RTT packets, a client MUST only use
remembered transport parameters; importantly, it MUST NOT use updated remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets. Updated values of or from frames received in 1-RTT packets. Updated values of
transport parameters from the handshake apply only to 1-RTT packets. transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are parameters apply to all 0-RTT packets even if those values are
skipping to change at page 46, line 25 skipping to change at page 48, line 6
Section 22.2. Section 22.2.
7.5. Cryptographic Message Buffering 7.5. Cryptographic Message Buffering
Implementations need to maintain a buffer of CRYPTO data received out Implementations need to maintain a buffer of CRYPTO data received out
of order. Because there is no flow control of CRYPTO frames, an of order. Because there is no flow control of CRYPTO frames, an
endpoint could potentially force its peer to buffer an unbounded endpoint could potentially force its peer to buffer an unbounded
amount of data. amount of data.
Implementations MUST support buffering at least 4096 bytes of data Implementations MUST support buffering at least 4096 bytes of data
received in out of order CRYPTO frames. Endpoints MAY choose to received in out-of-order CRYPTO frames. Endpoints MAY choose to
allow more data to be buffered during the handshake. A larger limit allow more data to be buffered during the handshake. A larger limit
during the handshake could allow for larger keys or credentials to be during the handshake could allow for larger keys or credentials to be
exchanged. An endpoint's buffer size does not need to remain exchanged. An endpoint's buffer size does not need to remain
constant during the life of the connection. constant during the life of the connection.
Being unable to buffer CRYPTO frames during the handshake can lead to Being unable to buffer CRYPTO frames during the handshake can lead to
a connection failure. If an endpoint's buffer is exceeded during the a connection failure. If an endpoint's buffer is exceeded during the
handshake, it can expand its buffer temporarily to complete the handshake, it can expand its buffer temporarily to complete the
handshake. If an endpoint does not expand its buffer, it MUST close handshake. If an endpoint does not expand its buffer, it MUST close
the connection with a CRYPTO_BUFFER_EXCEEDED error code. the connection with a CRYPTO_BUFFER_EXCEEDED error code.
skipping to change at page 47, line 20 skipping to change at page 48, line 50
8.1. Address Validation During Connection Establishment 8.1. Address Validation During Connection Establishment
Connection establishment implicitly provides address validation for Connection establishment implicitly provides address validation for
both endpoints. In particular, receipt of a packet protected with both endpoints. In particular, receipt of a packet protected with
Handshake keys confirms that the client received the Initial packet Handshake keys confirms that the client received the Initial packet
from the server. Once the server has successfully processed a from the server. Once the server has successfully processed a
Handshake packet from the client, it can consider the client address Handshake packet from the client, it can consider the client address
to have been validated. to have been validated.
Additionally, a server MAY consider the client address validated if
the client uses a connection ID chosen by the server and the
connection ID contains at least 64 bits of entropy.
Prior to validating the client address, servers MUST NOT send more Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have than three times as many bytes as the number of bytes they have
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. For the purposes of can be mounted using spoofed source addresses. For the purposes of
avoiding amplification prior to address validation, servers MUST avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection. This includes datagrams uniquely attributed to a single connection. This includes datagrams
that contain packets that are successfully processed and datagrams that contain packets that are successfully processed and datagrams
that contain packets that are all discarded. that contain packets that are all discarded.
skipping to change at page 48, line 30 skipping to change at page 50, line 11
constructed in a way that allows the server to identify how it was constructed in a way that allows the server to identify how it was
provided to a client. These tokens are carried in the same field, provided to a client. These tokens are carried in the same field,
but require different handling from servers. but require different handling from servers.
8.1.2. Address Validation using Retry Packets 8.1.2. Address Validation using Retry Packets
Upon receiving the client's Initial packet, the server can request Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (Section 17.2.5) address validation by sending a Retry packet (Section 17.2.5)
containing a token. This token MUST be repeated by the client in all containing a token. This token MUST be repeated by the client in all
Initial packets it sends for that connection after it receives the Initial packets it sends for that connection after it receives the
Retry packet. In response to processing an Initial containing a Retry packet.
token, a server can either abort the connection or permit it to
proceed. In response to processing an Initial containing a token that was
provided in a Retry packet, a server cannot send another Retry
packet; it can only refuse the connection or permit it to proceed.
As long as it is not possible for an attacker to generate a valid As long as it is not possible for an attacker to generate a valid
token for its own address (see Section 8.1.4) and the client is able token for its own address (see Section 8.1.4) and the client is able
to return that token, it proves to the server that it received the to return that token, it proves to the server that it received the
token. token.
A server can also use a Retry packet to defer the state and A server can also use a Retry packet to defer the state and
processing costs of connection establishment. Requiring the server processing costs of connection establishment. Requiring the server
to provide a different connection ID, along with the to provide a different connection ID, along with the
original_destination_connection_id transport parameter defined in original_destination_connection_id transport parameter defined in
skipping to change at page 49, line 5 skipping to change at page 50, line 37
it cooperates with, received the original Initial packet from the it cooperates with, received the original Initial packet from the
client. Providing a different connection ID also grants a server client. Providing a different connection ID also grants a server
some control over how subsequent packets are routed. This can be some control over how subsequent packets are routed. This can be
used to direct connections to a different server instance. used to direct connections to a different server instance.
If a server receives a client Initial that can be unprotected but If a server receives a client Initial that can be unprotected but
contains an invalid Retry token, it knows the client will not accept contains an invalid Retry token, it knows the client will not accept
another Retry token. The server can discard such a packet and allow another Retry token. The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client. Instead, the impose a significant latency penalty on the client. Instead, the
server SHOULD immediately close (Section 10.3) the connection with an server SHOULD immediately close (Section 10.2) the connection with an
INVALID_TOKEN error. Note that a server has not established any INVALID_TOKEN error. Note that a server has not established any
state for the connection at this point and so does not enter the state for the connection at this point and so does not enter the
closing period. closing period.
A flow showing the use of a Retry packet is shown in Figure 8. A flow showing the use of a Retry packet is shown in Figure 9.
Client Server Client Server
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 8: 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
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. The client includes this token in Initial future connections. In a future connection, the client includes this
packets to provide address validation in a future connection. The token in Initial packets to provide address validation. The client
client MUST include the token in all Initial packets it sends, unless MUST include the token in all Initial packets it sends, unless a
a Retry replaces the token with a newer one. The client MUST NOT use Retry replaces the token with a newer one. The client MUST NOT use
the token provided in a Retry for future connections. Servers MAY the token provided in a Retry for future connections. Servers MAY
discard any Initial packet that does not carry the expected token. discard any Initial packet that does not carry the expected token.
Unlike the token that is created for a Retry packet, which is used Unlike the token that is created for a Retry packet, which is used
immediately, the token sent in the NEW_TOKEN frame might be used immediately, the token sent in the NEW_TOKEN frame might be used
after some period of time has passed. Thus, a token SHOULD have an after some period of time has passed. Thus, a token SHOULD have an
expiration time, which could be either an explicit expiration time or expiration time, which could be either an explicit expiration time or
an issued timestamp that can be used to dynamically calculate the an issued timestamp that can be used to dynamically calculate the
expiration time. A server can store the expiration time or include expiration time. A server can store the expiration time or include
it in an encrypted form in the token. it in an encrypted form in the token.
skipping to change at page 51, line 37 skipping to change at page 53, line 27
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.
Clients MAY use tokens obtained on one connection for any connection Clients MAY use tokens obtained on one connection for any connection
attempt using the same version. When selecting a token to use, attempt using the same version. When selecting a token to use,
clients do not need to consider other properties of the connection clients do not need to consider other properties of the connection
that is being attempted, including the choice of possible application that is being attempted, including the choice of possible application
protocols, session tickets, or other connection properties. protocols, session tickets, or other connection properties.
Attackers could replay tokens to use servers as amplifiers in DDoS
attacks. To protect against such attacks, servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to
be valid for longer, but SHOULD NOT be accepted multiple times in a
short period. Servers are encouraged to allow tokens to be used only
once, if possible.
8.1.4. Address Validation Token Integrity 8.1.4. Address Validation Token Integrity
An address validation token MUST be difficult to guess. Including a An address validation token MUST be difficult to guess. Including a
large enough random value in the token would be sufficient, but this large enough random value in the token would be sufficient, but this
depends on the server remembering the value it sends to clients. depends on the server remembering the value it sends to clients.
A token-based scheme allows the server to offload any state A token-based scheme allows the server to offload any state
associated with validation to the client. For this design to work, associated with validation to the client. For this design to work,
the token MUST be covered by integrity protection against the token MUST be covered by integrity protection against
modification or falsification by clients. Without integrity modification or falsification by clients. Without integrity
skipping to change at page 52, line 28 skipping to change at page 54, line 14
Tokens sent in NEW_TOKEN frames MUST include information that allows Tokens sent in NEW_TOKEN frames MUST include information that allows
the server to verify that the client IP address has not changed from the server to verify that the client IP address has not changed from
when the token was issued. Servers can use tokens from NEW_TOKEN in when the token was issued. Servers can use tokens from NEW_TOKEN in
deciding not to send a Retry packet, even if the client address has deciding not to send a Retry packet, even if the client address has
changed. If the client IP address has changed, the server MUST changed. If the client IP address has changed, the server MUST
adhere to the anti-amplification limits found in Section 8.1. Note adhere to the anti-amplification limits found in Section 8.1. Note
that in the presence of NAT, this requirement might be insufficient that in the presence of NAT, this requirement might be insufficient
to protect other hosts that share the NAT from amplification attack. to protect other hosts that share the NAT from amplification attack.
Servers MUST ensure that replay of tokens is prevented or limited. Attackers could replay tokens to use servers as amplifiers in DDoS
For instance, servers might limit the time over which a token is attacks. To protect against such attacks, servers MUST ensure that
accepted. Tokens provided in NEW_TOKEN frames might need to allow replay of tokens is prevented or limited. Servers SHOULD ensure that
longer validity periods. Tokens MAY include additional information tokens sent in Retry packets are only accepted for a short time.
about clients to further narrow applicability or reuse. Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to
be valid for longer, but SHOULD NOT be accepted multiple times in a
short period. Servers are encouraged to allow tokens to be used only
once, if possible; tokens MAY include additional information about
clients to further narrow applicability or reuse.
8.2. Path Validation 8.2. Path Validation
Path validation is used during connection migration (see Section 9 Path validation is used during connection migration (see Section 9)
and Section 9.6) by the migrating endpoint to verify reachability of by the migrating endpoint to verify reachability of a peer from a new
a peer from a new local address. In path validation, endpoints test local address. In path validation, endpoints test reachability
reachability between a specific local address and a specific peer between a specific local address and a specific peer address, where
address, where an address is the two-tuple of IP address and port. an address is the two-tuple of IP address and port.
Path validation tests that packets (PATH_CHALLENGE) can be both sent Path validation tests that packets sent on a path to a peer are
to and received (PATH_RESPONSE) from a peer on the path. received by that peer. Path validation is used to ensure that
Importantly, it validates that the packets received from the packets received from a migrating peer do not carry a spoofed source
migrating endpoint do not carry a spoofed source address. address.
Path validation does not validate that a peer can send in the return
direction. The peer performs independent validation of the return
path.
Path validation can be used at any time by either endpoint. For Path validation can be used at any time by either endpoint. For
instance, an endpoint might check that a peer is still in possession instance, an endpoint might check that a peer is still in possession
of its address after a period of quiescence. of its address after a period of quiescence.
Path validation is not designed as a NAT traversal mechanism. Though Path validation is not designed as a NAT traversal mechanism. Though
the mechanism described here might be effective for the creation of the mechanism described here might be effective for the creation of
NAT bindings that support NAT traversal, the expectation is that one NAT bindings that support NAT traversal, the expectation is that one
or other peer is able to receive packets without first having sent a or other peer is able to receive packets without first having sent a
packet on that path. Effective NAT traversal needs additional packet on that path. Effective NAT traversal needs additional
synchronization mechanisms that are not provided here. synchronization mechanisms that are not provided here.
An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that An endpoint MAY include PATH_CHALLENGE and PATH_RESPONSE frames that
are used for path validation with other frames. In particular, an are used for path validation with other frames. In particular, an
endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum
discovery, or an endpoint may bundle a PATH_RESPONSE with its own Transfer Unit (PMTU) discovery (see Section 14.2.1), or an endpoint
PATH_CHALLENGE. can include a PATH_RESPONSE with its own PATH_CHALLENGE.
When probing a new path, an endpoint might want to ensure that its When probing a new path, an endpoint might want to ensure that its
peer has an unused connection ID available for responses. The peer has an unused connection ID available for responses. The
endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the
same packet. This ensures that an unused connection ID will be same packet. This ensures that an unused connection ID will be
available to the peer when sending a response. available to the peer when sending a response.
8.3. Initiating Path Validation 8.3. Initiating Path Validation
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing a random payload on the path to be validated. containing an unpredictable payload on the path to be validated.
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
packet loss. However, an endpoint SHOULD NOT send multiple packet loss. However, an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT
send a PATH_CHALLENGE more frequently than it would an Initial send a PATH_CHALLENGE more frequently than it would an Initial
packet, ensuring that connection migration is no more load on a new packet, ensuring that connection migration is no more load on a new
path than establishing a new connection. path than establishing a new connection.
The endpoint MUST use unpredictable data in every PATH_CHALLENGE The endpoint MUST use unpredictable data in every PATH_CHALLENGE
frame so that it can associate the peer's response with the frame so that it can associate the peer's response with the
corresponding PATH_CHALLENGE. corresponding PATH_CHALLENGE.
8.4. Path Validation Responses 8.4. Path Validation Responses
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by
immediately by echoing the data contained in the PATH_CHALLENGE frame echoing the data contained in the PATH_CHALLENGE frame in a
in a PATH_RESPONSE frame. PATH_RESPONSE frame. A PATH_RESPONSE frame does not need to be sent
on the network path where the PATH_CHALLENGE was received; a
PATH_RESPONSE can be sent on any network path. An endpoint MUST NOT
delay transmission of a packet containing a PATH_RESPONSE frame
unless constrained by congestion control.
An endpoint MUST NOT send more than one PATH_RESPONSE frame in An endpoint MUST NOT send more than one PATH_RESPONSE frame in
response to one PATH_CHALLENGE frame; see Section 13.3. The peer is response to one PATH_CHALLENGE frame; see Section 13.3. The peer is
expected to send more PATH_CHALLENGE frames as necessary to evoke expected to send more PATH_CHALLENGE frames as necessary to evoke
additional PATH_RESPONSE frames. additional PATH_RESPONSE frames.
8.5. Successful Path Validation 8.5. Successful Path Validation
A new address is considered valid when a PATH_RESPONSE frame is Path validation succeeds when a PATH_RESPONSE frame is received that
received that contains the data that was sent in a previous contains the data that was sent in a previous PATH_CHALLENGE frame.
PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing This validates the path on which the PATH_CHALLENGE was sent.
a PATH_CHALLENGE frame is not adequate validation, since the
acknowledgment can be spoofed by a malicious peer.
Note that receipt on a different local address does not result in Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
path validation failure, as it might be a result of a forwarded frame is not adequate validation, since the acknowledgment can be
packet (see Section 9.3.3) or misrouting. It is possible that a spoofed by a malicious peer.
valid PATH_RESPONSE might be received in the future.
8.6. Failed Path Validation 8.6. Failed Path Validation
Path validation only fails when the endpoint attempting to validate Path validation only fails when the endpoint attempting to validate
the path abandons its attempt to validate the path. the path abandons its attempt to validate the path.
Endpoints SHOULD abandon path validation based on a timer. When Endpoints SHOULD abandon path validation based on a timer. When
setting this timer, implementations are cautioned that the new path setting this timer, implementations are cautioned that the new path
could have a longer round-trip time than the original. A value of could have a longer round-trip time than the original. A value of
three times the larger of the current Probe Timeout (PTO) or the three times the larger of the current Probe Timeout (PTO) or the
initial timeout (that is, 2*kInitialRtt) as defined in initial timeout (that is, 2*kInitialRtt) as defined in
[QUIC-RECOVERY] is RECOMMENDED. That is: [QUIC-RECOVERY] is RECOMMENDED. That is:
validation_timeout = max(3*PTO, 6*kInitialRtt) validation_timeout = max(3*PTO, 6*kInitialRtt)
This timeout allows for multiple PTOs to expire prior to failing path
validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE
frame does not cause path validation failure.
Note that the endpoint might receive packets containing other frames Note that the endpoint might receive packets containing other frames
on the new path, but a PATH_RESPONSE frame with appropriate data is on the new path, but a PATH_RESPONSE frame with appropriate data is
required for path validation to succeed. required for path validation to succeed.
When an endpoint abandons path validation, it determines that the When an endpoint abandons path validation, it determines that the
path is unusable. This does not necessarily imply a failure of the path is unusable. This does not necessarily imply a failure of the
connection - endpoints can continue sending packets over other paths connection - endpoints can continue sending packets over other paths
as appropriate. If no paths are available, an endpoint can wait for as appropriate. If no paths are available, an endpoint can wait for
a new path to become available or close the connection. a new path to become available or close the connection.
skipping to change at page 55, line 45 skipping to change at page 57, line 40
addresses, except as described in Section 9.6. Clients are addresses, except as described in Section 9.6. Clients are
responsible for initiating all migrations. Servers do not send non- responsible for initiating all migrations. Servers do not send non-
probing packets (see Section 9.1) toward a client address until they probing packets (see Section 9.1) toward a client address until they
see a non-probing packet from that address. If a client receives see a non-probing packet from that address. If a client receives
packets from an unknown server address, the client MUST discard these packets from an unknown server address, the client MUST discard these
packets. packets.
9.1. Probing a New Path 9.1. Probing a New Path
An endpoint MAY probe for peer reachability from a new local address An endpoint MAY probe for peer reachability from a new local address
using path validation Section 8.2 prior to migrating the connection using path validation (Section 8.2) prior to migrating the connection
to the new local address. Failure of path validation simply means to the new local address. Failure of path validation simply means
that the new path is not usable for this connection. Failure to that the new path is not usable for this connection. Failure to
validate a path does not cause the connection to end unless there are validate a path does not cause the connection to end unless there are
no valid alternative paths available. no valid alternative paths available.
An endpoint uses a new connection ID for probes sent from a new local An endpoint uses a new connection ID for probes sent from a new local
address; see Section 9.5 for further discussion. An endpoint that address; see Section 9.5 for further discussion. An endpoint that
uses a new local address needs to ensure that at least one new uses a new local address needs to ensure that at least one new
connection ID is available at the peer. That can be achieved by connection ID is available at the peer. That can be achieved by
including a NEW_CONNECTION_ID frame in the probe. including a NEW_CONNECTION_ID frame in the probe.
Receiving a PATH_CHALLENGE frame from a peer indicates that the peer Receiving a PATH_CHALLENGE frame from a peer indicates that the peer
is probing for reachability on a path. An endpoint sends a is probing for reachability on a path. An endpoint sends a
PATH_RESPONSE in response as per Section 8.2. PATH_RESPONSE frame in response, as per Section 8.2.
PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames
are "probing frames", and all other frames are "non-probing frames". are "probing frames", and all other frames are "non-probing frames".
A packet containing only probing frames is a "probing packet", and a A packet containing only probing frames is a "probing packet", and a
packet containing any other frame is a "non-probing packet". packet containing any other frame is a "non-probing packet".
9.2. Initiating Connection Migration 9.2. Initiating Connection Migration
An endpoint can migrate a connection to a new local address by An endpoint can migrate a connection to a new local address by
sending packets containing non-probing frames from that address. sending packets containing non-probing frames from that address.
Each endpoint validates its peer's address during connection Each endpoint validates its peer's address during connection
establishment. Therefore, a migrating endpoint can send to its peer establishment. Therefore, a migrating endpoint can send to its peer
knowing that the peer is willing to receive at the peer's current knowing that the peer is willing to receive at the peer's current
address. Thus an endpoint can migrate to a new local address without address. Thus an endpoint can migrate to a new local address without
first validating the peer's address. first validating the peer's address.
When migrating, the new path might not support the endpoint's current When migrating, the new path might not support the endpoint's current
sending rate. Therefore, the endpoint resets its congestion sending rate. Therefore, the endpoint resets its congestion
controller, as described in Section 9.4. controller and RTT estimate, as described in Section 9.4.
The new path might not have the same ECN capability. Therefore, the The new path might not have the same ECN capability. Therefore, the
endpoint verifies ECN capability as described in Section 13.4. endpoint verifies ECN capability as described in Section 13.4.
Receiving acknowledgments for data sent on the new path serves as To establish reachability on the new path, an endpoint initiates path
proof of the peer's reachability from the new address. Note that validation (Section 8.2) on the new path. An endpoint MAY defer path
since acknowledgments may be received on any path, return validation until after a peer sends the next non-probing frame to its
reachability on the new path is not established. To establish return new address.
reachability on the new path, an endpoint MAY concurrently initiate
path validation Section 8.2 on the new path or it MAY choose to wait Path validation is necessary to verify reachability of a peer on a
for the peer to send the next non-probing frame to its new address. new network path. Acknowledgments cannot be used for path validation
as they contain insufficient entropy and might be spoofed. No method
is provided to establish return reachability, as endpoints
independently determine reachability on each direction of a path.
9.3. Responding to Connection Migration 9.3. Responding to Connection Migration
Receiving a packet from a new peer address containing a non-probing Receiving a packet from a new peer address containing a non-probing
frame indicates that the peer has migrated to that address. frame indicates that the peer has migrated to that address.
In response to such a packet, an endpoint MUST start sending In response to such a packet, an endpoint MUST start sending
subsequent packets to the new peer address and MUST initiate path subsequent packets to the new peer address and MUST initiate path
validation (Section 8.2) to verify the peer's ownership of the validation (Section 8.2) to verify the peer's ownership of the
unvalidated address. unvalidated address.
skipping to change at page 58, line 5 skipping to change at page 59, line 48
address. Until a peer's address is deemed valid, an endpoint MUST address. Until a peer's address is deemed valid, an endpoint MUST
limit the rate at which it sends data to this address. The endpoint limit the rate at which it sends data to this address. The endpoint
MUST NOT send more than a minimum congestion window's worth of data MUST NOT send more than a minimum congestion window's worth of data
per estimated round-trip time (kMinimumWindow, as defined in per estimated round-trip time (kMinimumWindow, as defined in
[QUIC-RECOVERY]). In the absence of this limit, an endpoint risks [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks
being used for a denial of service attack against an unsuspecting being used for a denial of service attack against an unsuspecting
victim. Note that since the endpoint will not have any round-trip victim. Note that since the endpoint will not have any round-trip
time measurements to this address, the estimate SHOULD be the default time measurements to this address, the estimate SHOULD be the default
initial value; see [QUIC-RECOVERY]. initial value; see [QUIC-RECOVERY].
If an endpoint skips validation of a peer address as described in If an endpoint skips validation of a peer address as described above,
Section 9.3, it does not need to limit its sending rate. it does not need to limit its sending rate.
9.3.2. On-Path Address Spoofing 9.3.2. On-Path Address Spoofing
An on-path attacker could cause a spurious connection migration by An on-path attacker could cause a spurious connection migration by
copying and forwarding a packet with a spoofed address such that it copying and forwarding a packet with a spoofed address such that it
arrives before the original packet. The packet with the spoofed arrives before the original packet. The packet with the spoofed
address will be seen to come from a migrating connection, and the address will be seen to come from a migrating connection, and the
original packet will be seen as a duplicate and dropped. After a original packet will be seen as a duplicate and dropped. After a
spurious migration, validation of the source address will fail spurious migration, validation of the source address will fail
because the entity at the source address does not have the necessary because the entity at the source address does not have the necessary
cryptographic keys to read or respond to the PATH_CHALLENGE frame cryptographic keys to read or respond to the PATH_CHALLENGE frame
that is sent to it even if it wanted to. that is sent to it even if it wanted to.
To protect the connection from failing due to such a spurious To protect the connection from failing due to such a spurious
migration, an endpoint MUST revert to using the last validated peer migration, an endpoint MUST revert to using the last validated peer
address when validation of a new peer address fails. address when validation of a new peer address fails. Additionally,
receipt of packets with higher packet numbers from the legitimate
peer address will trigger another connection migration. This will
cause the validation of the address of the spurious migration to be
abandoned, thus containing migrations initiated by the attacker
injecting a single packet.
If an endpoint has no state about the last validated peer address, it If an endpoint has no state about the last validated peer address, it
MUST close the connection silently by discarding all connection MUST close the connection silently by discarding all connection
state. This results in new packets on the connection being handled state. This results in new packets on the connection being handled
generically. For instance, an endpoint MAY send a stateless reset in generically. For instance, an endpoint MAY send a stateless reset in
response to any further incoming packets. response to any further incoming packets.
Note that receipt of packets with higher packet numbers from the
legitimate peer address will trigger another connection migration.
This will cause the validation of the address of the spurious
migration to be abandoned.
9.3.3. Off-Path Packet Forwarding 9.3.3. Off-Path Packet Forwarding
An off-path attacker that can observe packets might forward copies of An off-path attacker that can observe packets might forward copies of
genuine packets to endpoints. If the copied packet arrives before genuine packets to endpoints. If the copied packet arrives before
the genuine packet, this will appear as a NAT rebinding. Any genuine the genuine packet, this will appear as a NAT rebinding. Any genuine
packet will be discarded as a duplicate. If the attacker is able to packet will be discarded as a duplicate. If the attacker is able to
continue forwarding packets, it might be able to cause migration to a continue forwarding packets, it might be able to cause migration to a
path via the attacker. This places the attacker on path, giving it path via the attacker. This places the attacker on path, giving it
the ability to observe or drop all subsequent packets. the ability to observe or drop all subsequent packets.
Unlike the attack described in Section 9.3.2, the attacker can ensure This style of attack relies on the attacker using a path that has
that the new path is successfully validated. approximately the same characteristics as the direct path between
endpoints. The attack is more reliable if relatively few packets are
This style of attack relies on the attacker using a path that is sent or if packet loss coincides with the attempted attack.
approximately as fast as the direct path between endpoints. The
attack is more reliable if relatively few packets are sent or if
packet loss coincides with the attempted attack.
A non-probing packet received on the original path that increases the A non-probing packet received on the original path that increases the
maximum received packet number will cause the endpoint to move back maximum received packet number will cause the endpoint to move back
to that path. Eliciting packets on this path increases the to that path. Eliciting packets on this path increases the
likelihood that the attack is unsuccessful. Therefore, mitigation of likelihood that the attack is unsuccessful. Therefore, mitigation of
this attack relies on triggering the exchange of packets. this attack relies on triggering the exchange of packets.
In response to an apparent migration, endpoints MUST validate the In response to an apparent migration, endpoints MUST validate the
previously active path using a PATH_CHALLENGE frame. This induces previously active path using a PATH_CHALLENGE frame. This induces
the sending of new packets on that path. If the path is no longer the sending of new packets on that path. If the path is no longer
skipping to change at page 60, line 7 skipping to change at page 61, line 39
indicate an intentional migration rather than an attack. indicate an intentional migration rather than an attack.
9.4. Loss Detection and Congestion Control 9.4. Loss Detection and Congestion Control
The capacity available on the new path might not be the same as the The capacity available on the new path might not be the same as the
old path. Packets sent on the old path MUST NOT contribute to old path. Packets sent on the old path MUST NOT contribute to
congestion control or RTT estimation for the new path. congestion control or RTT estimation for the new path.
On confirming a peer's ownership of its new address, an endpoint MUST On confirming a peer's ownership of its new address, an endpoint MUST
immediately reset the congestion controller and round-trip time immediately reset the congestion controller and round-trip time
estimator for the new path to initial values (see Sections A.3 and estimator for the new path to initial values (see Appendices A.3 and
B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send B.3 in [QUIC-RECOVERY]) unless the only change in the peer's address
rate or round-trip time estimate is valid for the new path. For is its port number. Because port-only changes are commonly the
instance, an endpoint might infer that a change in only the client's result of NAT rebinding or other middlebox activity, the endpoint MAY
port number is indicative of a NAT rebinding, meaning that the new instead retain its congestion control state and round-trip estimate
path is likely to have similar bandwidth and round-trip time. in those cases instead of reverting to initial values. In cases
However, this determination will be imperfect. If the determination where congestion control state retained from an old path is used on a
is incorrect, the congestion controller and the RTT estimator are new path with substantially different characteristics, a sender may
expected to adapt to the new path. Generally, implementations are transmit too aggressively until the congestion controller and the RTT
advised to be cautious when using previous values on a new path. estimator have adapted. Generally, implementations are advised to be
cautious when using previous values on a new path.
There may be apparent reordering at the receiver when an endpoint There may be apparent reordering at the receiver when an endpoint
sends data and probes from/to multiple addresses during the migration sends data and probes from/to multiple addresses during the migration
period, since the two resulting paths may have different round-trip period, since the two resulting paths may have different round-trip
times. A receiver of packets on multiple paths will still send ACK times. A receiver of packets on multiple paths will still send ACK
frames covering all received packets. frames covering all received packets.
While multiple paths might be used during connection migration, a While multiple paths might be used during connection migration, a
single congestion control context and a single loss recovery context single congestion control context and a single loss recovery context
(as described in [QUIC-RECOVERY]) may be adequate. For instance, an (as described in [QUIC-RECOVERY]) may be adequate. For instance, an
skipping to change at page 60, line 43 skipping to change at page 62, line 30
controller to reduce its sending rate. An endpoint might set a controller to reduce its sending rate. An endpoint might set a
separate timer when a PATH_CHALLENGE is sent, which is cancelled if separate timer when a PATH_CHALLENGE is sent, which is cancelled if
the corresponding PATH_RESPONSE is received. If the timer fires the corresponding PATH_RESPONSE is received. If the timer fires
before the PATH_RESPONSE is received, the endpoint might send a new before the PATH_RESPONSE is received, the endpoint might send a new
PATH_CHALLENGE, and restart the timer for a longer period of time. PATH_CHALLENGE, and restart the timer for a longer period of time.
This timer SHOULD be set as described in Section 6.2.1 of This timer SHOULD be set as described in Section 6.2.1 of
[QUIC-RECOVERY] and MUST NOT be more aggressive. [QUIC-RECOVERY] and MUST NOT be more aggressive.
9.5. Privacy Implications of Connection Migration 9.5. Privacy Implications of Connection Migration
Using a stable connection ID on multiple network paths allows a Using a stable connection ID on multiple network paths would allow a
passive observer to correlate activity between those paths. An passive observer to correlate activity between those paths. An
endpoint that moves between networks might not wish to have their endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses, connection IDs are used when sending from different local addresses,
as discussed in Section 5.1. For this to be effective endpoints need as discussed in Section 5.1. For this to be effective, endpoints
to ensure that connection IDs they provide cannot be linked by any need to ensure that connection IDs they provide cannot be linked by
other entity. any other entity.
At any time, endpoints MAY change the Destination Connection ID they At any time, endpoints MAY change the Destination Connection ID they
send to a value that has not been used on another path. transmit with to a value that has not been used on another path.
An endpoint MUST NOT reuse a connection ID when sending from more An endpoint MUST NOT reuse a connection ID when sending from more
than one local address, for example when initiating connection than one local address, for example when initiating connection
migration as described in Section 9.2 or when probing a new network migration as described in Section 9.2 or when probing a new network
path as described in Section 9.1. path as described in Section 9.1.
Similarly, an endpoint MUST NOT reuse a connection ID when sending to Similarly, an endpoint MUST NOT reuse a connection ID when sending to
more than one destination address. Due to network changes outside more than one destination address. Due to network changes outside
the control of its peer, an endpoint might receive packets from a new the control of its peer, an endpoint might receive packets from a new
source address with the same destination connection ID, in which case source address with the same destination connection ID, in which case
skipping to change at page 61, line 38 skipping to change at page 63, line 23
each new network path eliminates the use of the connection ID for each new network path eliminates the use of the connection ID for
linking packets from the same connection across different network linking packets from the same connection across different network
paths. Header protection ensures that packet numbers cannot be used paths. Header protection ensures that packet numbers cannot be used
to correlate activity. This does not prevent other properties of to correlate activity. This does not prevent other properties of
packets, such as timing and size, from being used to correlate packets, such as timing and size, from being used to correlate
activity. activity.
An endpoint SHOULD NOT initiate migration with a peer that has An endpoint SHOULD NOT initiate migration with a peer that has
requested a zero-length connection ID, because traffic over the new requested a zero-length connection ID, because traffic over the new
path might be trivially linkable to traffic over the old one. If the path might be trivially linkable to traffic over the old one. If the
server is able to route packets with a zero-length connection ID to server is able to associate packets with a zero-length connection ID
the right connection, it means that the server is using other to the right connection, it means that the server is using other
information to demultiplex packets. For example, a server might information to demultiplex packets. For example, a server might
provide a unique address to every client, for instance using HTTP provide a unique address to every client, for instance using HTTP
alternative services [ALTSVC]. Information that might allow correct alternative services [ALTSVC]. Information that might allow correct
routing of packets across multiple network paths will also allow routing of packets across multiple network paths will also allow
activity on those paths to be linked by entities other than the peer. activity on those paths to be linked by entities other than the peer.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
are exercised even for clients that don't experience NAT rebindings are exercised even for clients that do not experience NAT rebindings
or genuine migrations. Changing port number can cause a peer to or genuine migrations. Changing port number can cause a peer to
reset its congestion state (see Section 9.4), so the port SHOULD only reset its congestion state (see Section 9.4), so the port SHOULD only
be changed infrequently. be changed infrequently.
An endpoint that exhausts available connection IDs cannot probe new An endpoint that exhausts available connection IDs cannot probe new
paths or initiate migration, nor can it respond to probes or attempts paths or initiate migration, nor can it respond to probes or attempts
by its peer to migrate. To ensure that migration is possible and by its peer to migrate. To ensure that migration is possible and
packets sent on different paths cannot be correlated, endpoints packets sent on different paths cannot be correlated, endpoints
SHOULD provide new connection IDs before peers migrate; see SHOULD provide new connection IDs before peers migrate; see
Section 5.1.1. If a peer might have exhausted available connection Section 5.1.1. If a peer might have exhausted available connection
skipping to change at page 62, line 34 skipping to change at page 64, line 15
9.6. Server's Preferred Address 9.6. Server's Preferred Address
QUIC allows servers to accept connections on one IP address and QUIC allows servers to accept connections on one IP address and
attempt to transfer these connections to a more preferred address attempt to transfer these connections to a more preferred address
shortly after the handshake. This is particularly useful when shortly after the handshake. This is particularly useful when
clients initially connect to an address shared by multiple servers clients initially connect to an address shared by multiple servers
but would prefer to use a unicast address to ensure connection but would prefer to use a unicast address to ensure connection
stability. This section describes the protocol for migrating a stability. This section describes the protocol for migrating a
connection to a preferred server address. connection to a preferred server address.
Migrating a connection to a new server address mid-connection is left Migrating a connection to a new server address mid-connection is not
for future work. If a client receives packets from a new server supported by the version of QUIC specified in this document. If a
address not indicated by the preferred_address transport parameter, client receives packets from a new server address when the client has
the client SHOULD discard these packets. not initiated a migration to that address, the client SHOULD discard
these packets.
9.6.1. Communicating a Preferred Address 9.6.1. Communicating a Preferred Address
A server conveys a preferred address by including the A server conveys a preferred address by including the
preferred_address transport parameter in the TLS handshake. preferred_address transport parameter in the TLS handshake.
Servers MAY communicate a preferred address of each address family Servers MAY communicate a preferred address of each address family
(IPv4 and IPv6) to allow clients to pick the one most suited to their (IPv4 and IPv6) to allow clients to pick the one most suited to their
network attachment. network attachment.
Once the handshake is confirmed, the client SHOULD select one of the Once the handshake is confirmed, the client SHOULD select one of the
two server's preferred addresses and initiate path validation (see two addresses provided by the server and initiate path validation
Section 8.2) of that address using any previously unused active (see Section 8.2). A client constructs packets using any previously
connection ID, taken from either the preferred_address transport unused active connection ID, taken from either the preferred_address
parameter or a NEW_CONNECTION_ID frame. transport parameter or a NEW_CONNECTION_ID frame.
If path validation succeeds, the client SHOULD immediately begin As soon as path validation succeeds, the client SHOULD begin sending
sending all future packets to the new server address using the new all future packets to the new server address using the new connection
connection ID and discontinue use of the old server address. If path ID and discontinue use of the old server address. If path validation
validation fails, the client MUST continue sending all future packets fails, the client MUST continue sending all future packets to the
to the server's original IP address. server's original IP address.
9.6.2. Responding to Connection Migration 9.6.2. Migration to a Preferred Address
A client that migrates to a preferred address MUST validate the
address it chooses before migrating; see Section 21.4.3.
A server might receive a packet addressed to its preferred IP address A server might receive a packet addressed to its preferred IP address
at any time after it accepts a connection. If this packet contains a at any time after it accepts a connection. If this packet contains a
PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per PATH_CHALLENGE frame, the server sends a packet containing a
Section 8.2. The server MUST send other non-probing frames from its PATH_RESPONSE frame as per Section 8.2. The server MUST send non-
original address until it receives a non-probing packet from the probing packets from its original address until it receives a non-
client at its preferred address and until the server has validated probing packet from the client at its preferred address and until the
the new path. server has validated the new path.
The server MUST probe on the path toward the client from its The server MUST probe on the path toward the client from its
preferred address. This helps to guard against spurious migration preferred address. This helps to guard against spurious migration
initiated by an attacker. initiated by an attacker.
Once the server has completed its path validation and has received a Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address. It SHOULD drop packets exclusively from its preferred IP address. It SHOULD drop packets
for this connection received on the old IP address, but MAY continue for this connection received on the old IP address, but MAY continue
skipping to change at page 64, line 5 skipping to change at page 65, line 43
SHOULD perform path validation to both the original and preferred SHOULD perform path validation to both the original and preferred
server address from the client's new address concurrently. server address from the client's new address concurrently.
If path validation of the server's preferred address succeeds, the If path validation of the server's preferred address succeeds, the
client MUST abandon validation of the original address and migrate to client MUST abandon validation of the original address and migrate to
using the server's preferred address. If path validation of the using the server's preferred address. If path validation of the
server's preferred address fails but validation of the server's server's preferred address fails but validation of the server's
original address succeeds, the client MAY migrate to its new address original address succeeds, the client MAY migrate to its new address
and continue sending to the server's original address. and continue sending to the server's original address.
If the connection to the server's preferred address is not from the If packets received at the server's preferred address have a
same client address, the server MUST protect against potential different source address than observed from the client during the
attacks as described in Section 9.3.1 and Section 9.3.2. In addition handshake, the server MUST protect against potential attacks as
to intentional simultaneous migration, this might also occur because described in Section 9.3.1 and Section 9.3.2. In addition to
the client's access network used a different NAT binding for the intentional simultaneous migration, this might also occur because the
server's preferred address. client's access network used a different NAT binding for the server's
preferred address.
Servers SHOULD initiate path validation to the client's new address Servers SHOULD initiate path validation to the client's new address
upon receiving a probe packet from a different address. Servers MUST upon receiving a probe packet from a different address. Servers MUST
NOT send more than a minimum congestion window's worth of non-probing NOT send more than a minimum congestion window's worth of non-probing
packets to the new address before path validation is complete. packets to the new address before path validation is complete.
A client that migrates to a new address SHOULD use a preferred A client that migrates to a new address SHOULD use a preferred
address from the same address family for the server. address from the same address family for the server.
The connection ID provided in the preferred_address transport The connection ID provided in the preferred_address transport
skipping to change at page 64, line 34 skipping to change at page 66, line 27
on any path. on any path.
9.7. Use of IPv6 Flow-Label and Migration 9.7. Use of IPv6 Flow-Label and Migration
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
in compliance with [RFC6437], unless the local API does not allow in compliance with [RFC6437], unless the local API does not allow
setting IPv6 flow labels. setting IPv6 flow labels.
The IPv6 flow label SHOULD be a pseudo-random function of the source The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the and destination addresses, source and destination UDP ports, and the
destination CID. The flow label generation MUST be designed to Destination Connection ID field. The flow label generation MUST be
minimize the chances of linkability with a previously used flow designed to minimize the chances of linkability with a previously
label, as this would enable correlating activity on multiple paths; used flow label, as this would enable correlating activity on
see Section 9.5. multiple paths; see Section 9.5.
A possible implementation is to compute the flow label as a A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses, cryptographic hash function of the source and destination addresses,
source and destination UDP ports, destination CID, and a local source and destination UDP ports, Destination Connection ID field,
secret. and a local secret.
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:
* idle timeout (Section 10.2) * idle timeout (Section 10.1)
* immediate close (Section 10.3) * immediate close (Section 10.2)
* stateless reset (Section 10.4)
* 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. Closing and Draining Connection States 10.1. Idle Timeout
The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for at least three
times the current Probe Timeout (PTO) interval as defined in
[QUIC-RECOVERY].
An endpoint enters a closing period after initiating an immediate
close; Section 10.3. While closing, an endpoint MUST NOT send
packets unless they contain a CONNECTION_CLOSE frame; see
Section 10.3 for details. An endpoint retains only enough
information to generate a packet containing a CONNECTION_CLOSE frame
and to identify packets as belonging to the connection. The
endpoint's selected connection ID and the QUIC version are sufficient
information to identify packets for a closing connection; an endpoint
can discard all other connection state. An endpoint MAY retain
packet protection keys for incoming packets to allow it to read and
process a CONNECTION_CLOSE frame.
The draining state is entered once an endpoint receives a signal that
its peer is closing or draining. While otherwise identical to the
closing state, an endpoint in the draining state MUST NOT send any
packets. Retaining packet protection keys is unnecessary once a
connection is in the draining state.
An endpoint MAY transition from the closing period to the draining
period if it receives a CONNECTION_CLOSE frame or stateless reset,
both of which indicate that the peer is also closing or draining.
The draining period SHOULD end when the closing period would have
ended. In other words, the endpoint can use the same end time, but
cease retransmission of the closing packet.
Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to generate
an unnecessary stateless reset. Endpoints that have some alternative
means to ensure that late-arriving packets on the connection do not
induce a response, such as those that are able to close the UDP
socket, MAY use an abbreviated draining period which can allow for
faster resource recovery. Servers that retain an open socket for
accepting new connections SHOULD NOT exit the closing or draining
period early.
Once the closing or draining period has ended, an endpoint SHOULD
discard all connection state. This results in new packets on the
connection being handled generically. For instance, an endpoint MAY
send a stateless reset in response to any further incoming packets.
The draining and closing periods do not apply when a stateless reset
(Section 10.4) is sent.
An endpoint is not expected to handle key updates when it is closing
or draining. A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact.
While in the closing period, an endpoint could receive packets from a
new source address, indicating a connection migration; Section 9. An
endpoint in the closing state MUST strictly limit the number of
packets it sends to this new address until the address is validated;
see Section 8.2. A server in the closing state MAY instead choose to
discard packets received from a new source address.
10.2. Idle Timeout
If a max_idle_timeout is specified by either peer in its transport If a max_idle_timeout is specified by either peer in its transport
parameters (Section 18.2), the connection is silently closed and its parameters (Section 18.2), the connection is silently closed and its
state is discarded when it remains idle for longer than the minimum state is discarded when it remains idle for longer than the minimum
of both peers max_idle_timeout values and three times the current of both peers max_idle_timeout values.
Probe Timeout (PTO).
Each endpoint advertises a max_idle_timeout, but the effective value Each endpoint advertises a max_idle_timeout, but the effective value
at an endpoint is computed as the minimum of the two advertised at an endpoint is computed as the minimum of the two advertised
values. By announcing a max_idle_timeout, an endpoint commits to values. By announcing a max_idle_timeout, an endpoint commits to
initiating an immediate close (Section 10.3) if it abandons the initiating an immediate close (Section 10.2) if it abandons the
connection prior to the effective value. connection prior to the effective value.
An endpoint restarts its idle timer when a packet from its peer is An endpoint restarts its idle timer when a packet from its peer is
received and processed successfully. An endpoint also restarts its received and processed successfully. An endpoint also restarts its
idle timer when sending an ack-eliciting packet if no other ack- idle timer when sending an ack-eliciting packet if no other ack-
eliciting packets have been sent since last receiving and processing eliciting packets have been sent since last receiving and processing
a packet. Restarting this timer when sending a packet ensures that a packet. Restarting this timer when sending a packet ensures that
connections are not closed after new activity is initiated. connections are not closed after new activity is initiated.
10.2.1. Liveness Testing To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the
current Probe Timeout (PTO). This allows for multiple PTOs to expire
prior to idle timeout, ensuring the idle timeout does not expire as a
result of a single packet loss.
10.1.1. Liveness Testing
An endpoint that sends packets close to the effective timeout risks An endpoint that sends packets close to the effective timeout risks
having them be discarded at the peer, since the peer might enter its having them be discarded at the peer, since the idle timeout period
draining state before these packets arrive. might have expired at the peer before these packets arrive.
An endpoint can send a PING or another ack-eliciting frame to test An endpoint can send a PING or another ack-eliciting frame to test
the connection for liveness if the peer could time out soon, such as the connection for liveness if the peer could time out soon, such as
within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially
useful if any available application data cannot be safely retried. useful if any available application data cannot be safely retried.
Note that the application determines what data is safe to retry. Note that the application determines what data is safe to retry.
10.2.2. Deferring Idle Timeout 10.1.2. Deferring Idle Timeout
An endpoint might need to send ack-eliciting packets to avoid an idle An endpoint might need to send ack-eliciting packets to avoid an idle
timeout if it is expecting response data, but does not have or is timeout if it is expecting response data, but does not have or is
unable to send application data. unable to send application data.
An implementation of QUIC might provide applications with an option An implementation of QUIC might provide applications with an option
to defer an idle timeout. This facility could be used when the to defer an idle timeout. This facility could be used when the
application wishes to avoid losing state that has been associated application wishes to avoid losing state that has been associated
with an open connection, but does not expect to exchange application with an open connection, but does not expect to exchange application
data for some time. With this option, an endpoint could send a PING data for some time. With this option, an endpoint could send a PING
frame periodically to defer an idle timeout; see Section 19.2. frame (Section 19.2) periodically, which will cause the peer to
restart its idle timeout period. Sending a packet containing a PING
frame restarts the idle timeout for this endpoint also if this is the
first ack-eliciting packet sent since receiving a packet. Sending a
PING frame causes the peer to respond with an acknowledgment, which
also restarts the idle timeout for the endpoint.
Application protocols that use QUIC SHOULD provide guidance on when Application protocols that use QUIC SHOULD provide guidance on when
deferring an idle timeout is appropriate. Unnecessary sending of deferring an idle timeout is appropriate. Unnecessary sending of
PING frames could have a detrimental effect on performance. PING frames could have a detrimental effect on performance.
A connection will time out if no packets are sent or received for a A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout period longer than the time negotiated using the max_idle_timeout
transport parameter; see Section 10. However, state in middleboxes transport parameter; see Section 10. However, state in middleboxes
might time out earlier than that. Though REQ-5 in [RFC4787] might time out earlier than that. Though REQ-5 in [RFC4787]
recommends a 2 minute timeout interval, experience shows that sending recommends a 2 minute timeout interval, experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the majority packets every 30 seconds is necessary to prevent the majority of
of middleboxes from losing state for UDP flows. middleboxes from losing state for UDP flows [GATEWAY].
10.3. Immediate Close 10.2. Immediate Close
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
terminate the connection immediately. A CONNECTION_CLOSE frame terminate the connection immediately. A CONNECTION_CLOSE frame
causes all streams to immediately become closed; open streams can be causes all streams to immediately become closed; open streams can be
assumed to be implicitly reset. assumed to be implicitly reset.
After sending a CONNECTION_CLOSE frame, an endpoint immediately After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state. enters the closing state; see Section 10.2.1. After receiving a
CONNECTION_CLOSE frame, endpoints enter the draining state; see
Section 10.2.2.
During the closing period, an endpoint that sends a CONNECTION_CLOSE An immediate close can be used after an application protocol has
frame SHOULD respond to any incoming packet that can be decrypted arranged to close a connection. This might be after the application
with another packet containing a CONNECTION_CLOSE frame. Such an protocol negotiates a graceful shutdown. The application protocol
endpoint SHOULD limit the number of packets it generates containing a can exchange messages that are needed for both application endpoints
CONNECTION_CLOSE frame. For instance, an endpoint could wait for a to agree that the connection can be closed, after which the
application requests that QUIC close the connection. When QUIC
consequently closes the connection, a CONNECTION_CLOSE frame with an
application-supplied error code will be used to signal closure to the
peer.
The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for at least three
times the current Probe Timeout (PTO) interval as defined in
[QUIC-RECOVERY].
Disposing of connection state prior to exiting the closing or
draining state could cause could result in an endpoint generating a
stateless reset unnecessarily when it receives a late-arriving
packet. Endpoints that have some alternative means to ensure that
late-arriving packets do not induce a response, such as those that
are able to close the UDP socket, MAY end these states earlier to
allow for faster resource recovery. Servers that retain an open
socket for accepting new connections SHOULD NOT end the closing or
draining states early.
Once its closing or draining state ends, an endpoint SHOULD discard
all connection state. The endpoint MAY send a stateless reset in
response to any further incoming packets belonging to this
connection.
10.2.1. Closing Connection State
An endpoint enters the closing state after initiating an immediate
close.
In the closing state, an endpoint retains only enough information to
generate a packet containing a CONNECTION_CLOSE frame and to identify
packets as belonging to the connection. An endpoint in the closing
state sends a packet containing a CONNECTION_CLOSE frame in response
to any incoming packet that it attributes to the connection.
An endpoint SHOULD limit the rate at which it generates packets in
the closing state. For instance, an endpoint could wait for a
progressively increasing number of received packets or amount of time progressively increasing number of received packets or amount of time
before responding to a received packet. before responding to received packets.
An endpoint is allowed to drop the packet protection keys when An endpoint's selected connection ID and the QUIC version are
entering the closing period (Section 10.1) and send a packet sufficient information to identify packets for a closing connection;
containing a CONNECTION_CLOSE in response to any UDP datagram that is the endpoint MAY discard all other connection state. An endpoint
received. However, an endpoint without the packet protection keys that is closing is not required to process any received frame. An
cannot identify and discard invalid packets. To avoid creating an endpoint MAY retain packet protection keys for incoming packets to
unwitting amplification attack, such endpoints MUST reduce the allow it to read and process a CONNECTION_CLOSE frame.
frequency with which it sends packets containing a CONNECTION_CLOSE
frame. To minimize the state that an endpoint maintains for a
closing connection, endpoints MAY send the exact same packet.
Note: Allowing retransmission of a closing packet contradicts other An endpoint MAY drop packet protection keys when entering the closing
advice in this document that recommends the creation of new packet state and send a packet containing a CONNECTION_CLOSE frame in
numbers for every packet. Sending new packet numbers is primarily response to any UDP datagram that is received. However, an endpoint
of advantage to loss recovery and congestion control, which are that discards packet protection keys cannot identify and discard
not expected to be relevant for a closed connection. invalid packets. To avoid being used for an amplication attack, such
Retransmitting the final packet requires less state. endpoints MUST limit the cumulative size of packets it sends to three
times the cumulative size of the packets that are received and
attributed to the connection. To minimize the state that an endpoint
maintains for a closing connection, endpoints MAY send the exact same
packet in response to any received packet.
New packets from unverified addresses could be used to create an Note: Allowing retransmission of a closing packet is an exception to
amplification attack; see Section 8. To avoid this, endpoints MUST the requirement that a new packet number be used for each packet
either limit transmission of CONNECTION_CLOSE frames to validated in Section 12.3. Sending new packet numbers is primarily of
addresses or drop packets without response if the response would be advantage to loss recovery and congestion control, which are not
more than three times larger than the received packet. expected to be relevant for a closed connection. Retransmitting
the final packet requires less state.
After receiving a CONNECTION_CLOSE frame, endpoints enter the While in the closing state, an endpoint could receive packets from a
draining state. An endpoint that receives a CONNECTION_CLOSE frame new source address, possibly indicating a connection migration; see
MAY send a single packet containing a CONNECTION_CLOSE frame before Section 9. An endpoint in the closing state MUST either discard
entering the draining state, using a CONNECTION_CLOSE frame and a packets received from an unvalidated address or limit the cumulative
NO_ERROR code if appropriate. An endpoint MUST NOT send further size of packets it sends to an unvalidated address to three times the
packets, which could result in a constant exchange of size of packets it receives from that address.
CONNECTION_CLOSE frames until the closing period on either peer
ended.
An immediate close can be used after an application protocol has An endpoint is not expected to handle key updates when it is closing
arranged to close a connection. This might be after the application (Section 6 of [QUIC-TLS]). A key update might prevent the endpoint
protocols negotiates a graceful shutdown. The application protocol from moving from the closing state to the draining state, as the
exchanges whatever messages that are needed to cause both endpoints endpoint will not be able to process subsequently received packets,
to agree to close the connection, after which the application but it otherwise has no impact.
requests that the connection be closed. The application protocol can
use a CONNECTION_CLOSE frame with an appropriate error code to signal
closure.
10.3.1. Immediate Close During the Handshake 10.2.2. Draining Connection State
The draining state is entered once an endpoint receives a
CONNECTION_CLOSE frame, which indicates that its peer is closing or
draining. While otherwise identical to the closing state, an
endpoint in the draining state MUST NOT send any packets. Retaining
packet protection keys is unnecessary once a connection is in the
draining state.
An endpoint that receives a CONNECTION_CLOSE frame MAY send a single
packet containing a CONNECTION_CLOSE frame before entering the
draining state, using a NO_ERROR code if appropriate. An endpoint
MUST NOT send further packets. Doing so could result in a constant
exchange of CONNECTION_CLOSE frames until one of the endpoints exits
the closing state.
An endpoint MAY enter the draining state from the closing state if it
receives a CONNECTION_CLOSE frame, which indicates that the peer is
also closing or draining. In this case, the draining state SHOULD
end when the closing state would have ended. In other words, the
endpoint uses the same end time, but ceases transmission of any
packets on this connection.
10.2.3. Immediate Close During the Handshake
When sending CONNECTION_CLOSE, the goal is to ensure that the peer When sending CONNECTION_CLOSE, the goal is to ensure that the peer
will process the frame. Generally, this means sending the frame in a will process the frame. Generally, this means sending the frame in a
packet with the highest level of packet protection to avoid the 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:
* 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.
* A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be * A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured of the server has accepted 0-RTT and so sending a 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.
* 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 CONNECTION_CLOSE process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE
in both Handshake and 1-RTT packets. A server SHOULD also send in both Handshake and 1-RTT packets. A server SHOULD also send
CONNECTION_CLOSE in an Initial packet. CONNECTION_CLOSE in an Initial 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
skipping to change at page 69, line 48 skipping to change at page 71, line 48
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
state might be revealed. Endpoints MUST clear the value of the state might be revealed. Endpoints MUST clear the value of the
Reason Phrase field and SHOULD use the APPLICATION_ERROR code when Reason Phrase field and SHOULD use the APPLICATION_ERROR code when
converting to a CONNECTION_CLOSE of type 0x1c. converting to a CONNECTION_CLOSE of type 0x1c.
CONNECTION_CLOSE frames sent in multiple packet types can be CONNECTION_CLOSE frames sent in multiple packet types can be
coalesced into a single UDP datagram; see Section 12.2. coalesced into a single UDP datagram; see Section 12.2.
An endpoint might send a CONNECTION_CLOSE frame in an Initial packet An endpoint can send a CONNECTION_CLOSE frame in an Initial packet.
or in response to unauthenticated information received in Initial or This might be in response to unauthenticated information received in
Handshake packets. Such an immediate close might expose legitimate Initial or Handshake packets. Such an immediate close might expose
connections to a denial of service. QUIC does not include defensive legitimate connections to a denial of service. QUIC does not include
measures for on-path attacks during the handshake; see Section 21.1. defensive measures for on-path attacks during the handshake; see
Section 21.1. However, at the cost of reducing feedback about errors
However, at the cost of reducing feedback about errors for legitimate for legitimate peers, some forms of denial of service can be made
peers, some forms of denial of service can be made more difficult for more difficult for an attacker if endpoints discard illegal packets
an attacker if endpoints discard illegal packets rather than rather than terminating a connection with CONNECTION_CLOSE. For this
terminating a connection with CONNECTION_CLOSE. For this reason, reason, endpoints MAY discard packets rather than immediately close
endpoints MAY discard packets rather than immediately close if errors if errors are detected in packets that lack authentication.
are detected in packets that lack authentication.
An endpoint that has not established state, such as a server that An endpoint that has not established state, such as a server that
detects an error in an Initial packet, does not enter the closing detects an error in an Initial packet, does not enter the closing
state. An endpoint that has no state for the connection does not state. An endpoint that has no state for the connection does not
enter a closing or draining period on sending a CONNECTION_CLOSE enter a closing or draining period on sending a CONNECTION_CLOSE
frame. frame.
10.4. Stateless Reset 10.3. Stateless Reset
A stateless reset is provided as an option of last resort for an A stateless reset is provided as an option of last resort for an
endpoint that does not have access to the state of a connection. A endpoint that does not have access to the state of a connection. A
crash or outage might result in peers continuing to send data to an crash or outage might result in peers continuing to send data to an
endpoint that is unable to properly continue the connection. An endpoint that is unable to properly continue the connection. An
endpoint MAY send a stateless reset in response to receiving a packet endpoint MAY send a stateless reset in response to receiving a packet
that it cannot associate with an active connection. that it cannot associate with an active connection.
A stateless reset is not appropriate for signaling error conditions. A stateless reset is not appropriate for signaling error conditions.
An endpoint that wishes to communicate a fatal connection error MUST An endpoint that wishes to communicate a fatal connection error MUST
use a CONNECTION_CLOSE frame if it has sufficient state to do so. use a CONNECTION_CLOSE frame if it has sufficient state to do so.
To support this process, a token is sent by endpoints. The token is To support this process, a token is sent by endpoints. The token is
carried in the Stateless Reset Token field of a NEW_CONNECTION_ID carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
frame. Servers can also specify a stateless_reset_token transport frame. Servers can also specify a stateless_reset_token transport
parameter during the handshake that applies to the connection ID that parameter during the handshake that applies to the connection ID that
it selected during the handshake; clients cannot use this transport it selected during the handshake; clients cannot use this transport
parameter because their transport parameters don't have parameter because their transport parameters do not have
confidentiality protection. These tokens are protected by confidentiality protection. These tokens are protected by
encryption, so only client and server know their value. Tokens are encryption, so only client and server know their value. Tokens are
invalidated when their associated connection ID is retired via a invalidated when their associated connection ID is retired via a
RETIRE_CONNECTION_ID frame (Section 19.16). RETIRE_CONNECTION_ID frame (Section 19.16).
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: packet in the following layout:
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 9: Stateless Reset Packet Figure 10: Stateless Reset Packet
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet 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 that are set to and an arbitrary number of bytes following it are set to values that
unpredictable values. The last 16 bytes of the datagram contain a SHOULD be indistinguishable from random. The last 16 bytes of the
Stateless Reset Token. datagram contain a Stateless Reset Token.
To entities other than its intended recipient, a stateless reset will To entities other than its intended recipient, a stateless reset will
appear to be a packet with a short header. For the stateless reset appear to be a packet with a short header. For the stateless reset
to appear as a valid QUIC packet, the Unpredictable Bits field needs to appear as a valid QUIC packet, the Unpredictable Bits field needs
to include at least 38 bits of data (or 5 bytes, less the two fixed to include at least 38 bits of data (or 5 bytes, less the two fixed
bits). bits).
A minimum size of 21 bytes does not guarantee that a stateless reset The resulting minimum size of 21 bytes does not guarantee that a
is difficult to distinguish from other packets if the recipient stateless reset is difficult to distinguish from other packets if the
requires the use of a connection ID. To prevent a resulting recipient requires the use of a connection ID. To achieve that end,
stateless reset from being trivially distinguishable from a valid the endpoint SHOULD pad all packets it sends to at least 22 bytes
packet, all packets sent by an endpoint SHOULD be padded to at least longer than the minimum connection ID that it might request the peer
22 bytes longer than the minimum connection ID that the endpoint to include in packets that the peer sends. This ensures that any
might use. An endpoint that sends a stateless reset in response to a stateless reset sent by the peer is indistinguishable from a valid
packet that is 43 bytes or less in length SHOULD send a stateless packet sent to the endpoint. An endpoint that sends a stateless
reset that is one byte shorter than the packet it responds to. reset in response to a packet that is 43 bytes or shorter SHOULD send
a stateless reset that is one byte shorter than the packet it
responds to.
These values assume that the Stateless Reset Token is the same length These values assume that the Stateless Reset Token is the same length
as the minimum expansion of the packet protection AEAD. Additional as the minimum expansion of the packet protection AEAD. Additional
unpredictable bytes are necessary if the endpoint could have unpredictable bytes are necessary if the endpoint could have
negotiated a packet protection scheme with a larger minimum negotiated a packet protection scheme with a larger minimum
expansion. expansion.
An endpoint MUST NOT send a stateless reset that is three times or An endpoint MUST NOT send a stateless reset that is three times or
more larger than the packet it receives to avoid being used for more larger than the packet it receives to avoid being used for
amplification. Section 10.4.3 describes additional limits on amplification. Section 10.3.3 describes additional limits on
stateless reset size. stateless reset size.
Endpoints MUST discard packets that are too small to be valid QUIC Endpoints MUST discard packets that are too small to be valid QUIC
packets. With the set of AEAD functions defined in [QUIC-TLS], packets. With the set of AEAD functions defined in [QUIC-TLS],
packets that are smaller than 21 bytes are never valid. packets that are smaller than 21 bytes are never valid.
Endpoints MUST send stateless reset packets formatted as a packet Endpoints MUST send stateless reset packets formatted as a packet
with a short header. However, endpoints MUST treat any packet ending with a short header. However, endpoints MUST treat any packet ending
in a valid stateless reset token as a stateless reset, as other QUIC in a valid stateless reset token as a stateless reset, as other QUIC
versions might allow the use of a long header. versions might allow the use of a long header.
skipping to change at page 72, line 27 skipping to change at page 74, line 27
Connection ID will therefore differ from the value used in previous Connection ID will therefore differ from the value used in previous
packets. A random Destination Connection ID makes the connection ID packets. A random Destination Connection ID makes the connection ID
appear to be the result of moving to a new connection ID that was appear to be the result of moving to a new connection ID that was
provided using a NEW_CONNECTION_ID frame (Section 19.15). provided using a NEW_CONNECTION_ID frame (Section 19.15).
Using a randomized connection ID results in two problems: Using a randomized connection ID results in two problems:
* 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.4.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.
* 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 reuse this design, or use a portion of the aware of this and either reuse this design, or use a portion of the
packet other than the last 16 bytes for carrying data. packet other than the last 16 bytes for carrying data.
10.4.1. Detecting a Stateless Reset 10.3.1. Detecting a Stateless Reset
An endpoint detects a potential stateless reset using the trailing 16 An endpoint detects a potential stateless reset using the trailing 16
bytes of the UDP datagram. An endpoint remembers all Stateless Reset bytes of the UDP datagram. An endpoint remembers all Stateless Reset
Tokens associated with the connection IDs and remote addresses for Tokens associated with the connection IDs and remote addresses for
datagrams it has recently sent. This includes Stateless Reset Tokens datagrams it has recently sent. This includes Stateless Reset Tokens
from NEW_CONNECTION_ID frames and the server's transport parameters from NEW_CONNECTION_ID frames and the server's transport parameters
but excludes Stateless Reset Tokens associated with connection IDs but excludes Stateless Reset Tokens associated with connection IDs
that are either unused or retired. The endpoint identifies a that are either unused or retired. The endpoint identifies a
received datagram as a stateless reset by comparing the last 16 bytes received datagram as a stateless reset by comparing the last 16 bytes
of the datagram with all Stateless Reset Tokens associated with the of the datagram with all Stateless Reset Tokens associated with the
skipping to change at page 74, line 5 skipping to change at page 76, line 5
transformation is defined as a cryptographically-secure pseudo-random transformation is defined as a cryptographically-secure pseudo-random
function using a secret key (e.g., block cipher, HMAC [RFC2104]). An function using a secret key (e.g., block cipher, HMAC [RFC2104]). An
endpoint is not expected to protect information about whether a endpoint is not expected to protect information about whether a
packet was successfully decrypted, or the number of valid Stateless packet was successfully decrypted, or the number of valid Stateless
Reset Tokens. Reset Tokens.
If the last 16 bytes of the datagram are identical in value to a If the last 16 bytes of the datagram are identical in value to a
Stateless Reset Token, the endpoint MUST enter the draining period Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection. and not send any further packets on this connection.
10.4.2. Calculating a Stateless Reset Token 10.3.2. Calculating a Stateless Reset Token
The stateless reset token MUST be difficult to guess. In order to The stateless reset token MUST be difficult to guess. In order to
create a Stateless Reset Token, an endpoint could randomly generate create a Stateless Reset Token, an endpoint could randomly generate
[RFC4086] a secret for every connection that it creates. However, ([RFC4086]) a secret for every connection that it creates. However,
this presents a coordination problem when there are multiple this presents a coordination problem when there are multiple
instances in a cluster or a storage problem for an endpoint that instances in a cluster or a storage problem for an endpoint that
might lose state. Stateless reset specifically exists to handle the might lose state. Stateless reset specifically exists to handle the
case where state is lost, so this approach is suboptimal. case where state is lost, so this approach is suboptimal.
A single static key can be used across all connections to the same A single static key can be used across all connections to the same
endpoint by generating the proof using a second iteration of a endpoint by generating the proof using a second iteration of a
preimage-resistant function that takes a static key and the preimage-resistant function that takes a static key and the
connection ID chosen by the endpoint (see Section 5.1) as input. An connection ID chosen by the endpoint (see Section 5.1) as input. An
endpoint could use HMAC [RFC2104] (for example, HMAC(static_key, endpoint could use HMAC [RFC2104] (for example, HMAC(static_key,
skipping to change at page 74, line 44 skipping to change at page 76, line 44
without state. In addition, it cannot provide a zero-length without state. In addition, it cannot provide a zero-length
connection ID. connection ID.
Revealing the Stateless Reset Token allows any entity to terminate Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection. connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key; see Section 21.9. A connection ID from a connection same static key; see Section 21.10. A connection ID from a
that is reset by revealing the Stateless Reset Token MUST NOT be connection that is reset by revealing the Stateless Reset Token MUST
reused for new connections at nodes that share a static key. NOT be reused for new connections at nodes that share a static key.
The same Stateless Reset Token MUST NOT be used for multiple The same Stateless Reset Token MUST NOT be used for multiple
connection IDs. Endpoints are not required to compare new values connection IDs. Endpoints are not required to compare new values
against all previous values, but a duplicate value MAY be treated as against all previous values, but a duplicate value MAY be treated as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.3.3. Looping
The design of a Stateless Reset is such that without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
lead to an infinite exchange. lead to an infinite exchange.
An endpoint MUST ensure that every Stateless Reset that it sends is An endpoint MUST ensure that every Stateless Reset that it sends is
smaller than the packet which triggered it, unless it maintains state smaller than the packet that triggered it, unless it maintains state
sufficient to prevent looping. In the event of a loop, this results sufficient to prevent looping. In the event of a loop, this results
in packets eventually being too small to trigger a response. in packets eventually being too small to trigger a response.
An endpoint can remember the number of Stateless Reset packets that An endpoint can remember the number of Stateless Reset packets that
it has sent and stop generating new Stateless Reset packets once a it has sent and stop generating new Stateless Reset packets once a
limit is reached. Using separate limits for different remote limit is reached. Using separate limits for different remote
addresses will ensure that Stateless Reset packets can be used to addresses will ensure that Stateless Reset packets can be used to
close connections when other peers or connections have exhausted close connections when other peers or connections have exhausted
limits. limits.
skipping to change at page 76, line 5 skipping to change at page 78, line 5
The most appropriate error code (Section 20) SHOULD be included in The most appropriate error code (Section 20) SHOULD be included in
the frame that signals the error. Where this specification the frame that signals the error. Where this specification
identifies error conditions, it also identifies the error code that identifies error conditions, it also identifies the error code that
is used; though these are worded as requirements, different is used; though these are worded as requirements, different
implementation strategies might lead to different errors being implementation strategies might lead to different errors being
reported. In particular, an endpoint MAY use any applicable error reported. In particular, an endpoint MAY use any applicable error
code when it detects an error condition; a generic error code (such code when it detects an error condition; a generic error code (such
as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
of specific error codes. of specific error codes.
A stateless reset (Section 10.4) is not suitable for any error that A stateless reset (Section 10.3) is not suitable for any error that
can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A
stateless reset MUST NOT be used by an endpoint that has the state stateless reset MUST NOT be used by an endpoint that has the state
necessary to send a frame on the connection. necessary to send a frame on the connection.
11.1. Connection Errors 11.1. Connection Errors
Errors that result in the connection being unusable, such as an Errors that result in the connection being unusable, such as an
obvious violation of protocol semantics or corruption of state that obvious violation of protocol semantics or corruption of state that
affects an entire connection, MUST be signaled using a affects an entire connection, MUST be signaled using a
CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the
connection in this manner even if the error only affects a single connection in this manner even if the error only affects a single
stream. stream.
Application protocols can signal application-specific protocol errors Application-specific protocol errors are signaled using the
using the application-specific variant of the CONNECTION_CLOSE frame. CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are
Errors that are specific to the transport, including all those specific to the transport, including all those described in this
described in this document, are carried in the QUIC-specific variant document, are carried in the CONNECTION_CLOSE frame with a frame type
of the CONNECTION_CLOSE frame. of 0x1c.
A CONNECTION_CLOSE frame could be sent in a packet that is lost. An A CONNECTION_CLOSE frame could be sent in a packet that is lost. An
endpoint SHOULD be prepared to retransmit a packet containing a endpoint SHOULD be prepared to retransmit a packet containing a
CONNECTION_CLOSE frame if it receives more packets on a terminated CONNECTION_CLOSE frame if it receives more packets on a terminated
connection. Limiting the number of retransmissions and the time over connection. Limiting the number of retransmissions and the time over
which this final packet is sent limits the effort expended on which this final packet is sent limits the effort expended on
terminated connections. terminated connections.
An endpoint that chooses not to retransmit packets containing a An endpoint that chooses not to retransmit packets containing a
CONNECTION_CLOSE frame risks a peer missing the first such packet. CONNECTION_CLOSE frame risks a peer missing the first such packet.
The only mechanism available to an endpoint that continues to receive The only mechanism available to an endpoint that continues to receive
data for a terminated connection is to use the stateless reset data for a terminated connection is to use the stateless reset
process (Section 10.4). process (Section 10.3).
11.2. Stream Errors 11.2. Stream Errors
If an application-level error affects a single stream, but otherwise If an application-level error affects a single stream, but otherwise
leaves the connection in a recoverable state, the endpoint can send a leaves the connection in a recoverable state, the endpoint can send a
RESET_STREAM frame (Section 19.4) with an appropriate error code to RESET_STREAM frame (Section 19.4) with an appropriate error code to
terminate just the affected stream. terminate just the affected stream.
Resetting a stream without the involvement of the application Resetting a stream without the involvement of the application
protocol could cause the application protocol to enter an protocol could cause the application protocol to enter an
skipping to change at page 77, line 30 skipping to change at page 79, line 30
(Section 17.2.4), and Retry (Section 17.2.5). Version negotiation (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation
uses a version-independent packet with a long header; see uses a version-independent packet with a long header; see
Section 17.2.1. Section 17.2.1.
Packets with the short header are designed for minimal overhead and Packets with the short header are designed for minimal overhead and
are used after a connection is established and 1-RTT keys are are used after a connection is established and 1-RTT keys are
available; see Section 17.3. available; see Section 17.3.
12.1. Protected Packets 12.1. Protected Packets
All QUIC packets except Version Negotiation packets use authenticated QUIC packets have different levels of cryptographic protection based
encryption with additional data (AEAD) [RFC5116] to provide on the type of packet. Details of packet protection are found in
confidentiality and integrity protection. Retry packets use AEAD to [QUIC-TLS]; this section includes an overview of the protections that
provide integrity protection. Details of packet protection are found are provided.
in [QUIC-TLS]; this section includes an overview of the process.
Initial packets are protected using keys that are statically derived. Version Negotiation packets have no cryptographic protection; see
This packet protection is not effective confidentiality protection. [QUIC-INVARIANTS].
Initial protection only exists to ensure that the sender of the
packet is on the network path. Any entity that receives the Initial Retry packets use an authenticated encryption with associated data
packet from a client can recover the keys necessary to remove packet function (AEAD; [AEAD]) to protect against accidental modification.
protection or to generate packets that will be successfully
authenticated. Initial packets use an AEAD, the keys for which are derived using a
value that is visible on the wire. Initial packets therefore do not
have effective confidentiality protection. Initial protection exists
to ensure that the sender of the packet is on the network path. Any
entity that receives an Initial packet from a client can recover the
keys that will allow them to both read the contents of the packet and
generate Initial packets that will be successfully authenticated at
either endpoint.
All other packets are protected with keys derived from the All other packets are protected with keys derived from the
cryptographic handshake. The type of the packet from the long header cryptographic handshake. The cryptographic handshake ensures that
or key phase from the short header are used to identify which only the communicating endpoints receive the corresponding keys for
encryption keys are used. Packets protected with 0-RTT and 1-RTT Handshake, 0-RTT, and 1-RTT packets. Packets protected with 0-RTT
keys are expected to have confidentiality and data origin and 1-RTT keys have strong confidentiality and integrity protection.
authentication; the cryptographic handshake ensures that only the
communicating endpoints receive the corresponding keys.
The packet number field contains a packet number, which has The Packet Number field that appears in some packet types has
additional confidentiality protection that is applied after packet alternative confidentiality protection that is applied as part of
protection is applied; see [QUIC-TLS] for details. The underlying header protection; see Section 5.4 of [QUIC-TLS] for details. The
packet number increases with each packet sent in a given packet underlying packet number increases with each packet sent in a given
number space; see Section 12.3 for details. packet number space; see Section 12.3 for details.
12.2. Coalescing Packets 12.2. Coalescing Packets
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake
(Section 17.2.4) packets contain a Length field, which determines the (Section 17.2.4) packets contain a Length field that determines the
end of the packet. The length includes both the Packet Number and end of the packet. The length includes both the Packet Number and
Payload fields, both of which are confidentiality protected and Payload fields, both of which are confidentiality protected and
initially of unknown length. The length of the Payload field is initially of unknown length. The length of the Payload field is
learned once header protection is removed. learned once header protection is removed.
Using the Length field, a sender can coalesce multiple QUIC packets Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram. This can reduce the number of UDP datagrams into one UDP datagram. This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and start sending needed to complete the cryptographic handshake and start sending
data. This can also be used to construct PMTU probes; see data. This can also be used to construct PMTU probes; see
Section 14.4.1. Receivers MUST be able to process coalesced packets. Section 14.4.1. Receivers MUST be able to process coalesced packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it
more likely the receiver will be able to process all the packets in a more likely the receiver will be able to process all the packets in a
single pass. A packet with a short header does not include a length, single pass. A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram. An so it can only be the last packet included in a UDP datagram. An
endpoint SHOULD NOT coalesce multiple packets at the same encryption endpoint SHOULD include multiple frames in a single packet if they
level. are to be sent at the same encryption level, instead of coalescing
multiple packets at the same encryption level.
Senders MUST NOT coalesce QUIC packets for different connections into Receivers MAY route based on the information in the first packet
a single UDP datagram. Receivers SHOULD ignore any subsequent contained in a UDP datagram. Senders MUST NOT coalesce QUIC packets
packets with a different Destination Connection ID than the first with different connection IDs into a single UDP datagram. Receivers
packet in the datagram. SHOULD ignore any subsequent packets with a different Destination
Connection ID than the first packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. The receiver of coalesced QUIC packets MUST separate and complete. The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge individually process each QUIC packet and separately acknowledge
them, as if they were received as the payload of different UDP them, as if they were received as the payload of different UDP
datagrams. For example, if decryption fails (because the keys are datagrams. For example, if decryption fails (because the keys are
not available or any other reason), the receiver MAY either discard not available or any other reason), the receiver MAY either discard
or buffer the packet for later processing and MUST attempt to process or buffer the packet for later processing and MUST attempt to process
the remaining packets. the remaining packets.
skipping to change at page 79, line 36 skipping to change at page 81, line 45
packets do not include a packet number. packets do not include a packet number.
Packet numbers are divided into 3 spaces in QUIC: Packet numbers are divided into 3 spaces in QUIC:
* Initial space: All Initial packets (Section 17.2.2) are in this * Initial space: All Initial packets (Section 17.2.2) are in this
space. space.
* Handshake space: All Handshake packets (Section 17.2.4) are in * Handshake space: All Handshake packets (Section 17.2.4) are in
this space. this space.
* Application data space: All 0-RTT and 1-RTT encrypted packets * Application data space: All 0-RTT (Section 17.2.3) and 1-RTT
(Section 12.1) are in this space. (Section 17.3) encrypted packets are in this space.
As described in [QUIC-TLS], each packet type uses different As described in [QUIC-TLS], each packet type uses different
protection keys. protection keys.
Conceptually, a packet number space is the context in which a packet Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged. Initial packets can only be sent can be processed and acknowledged. Initial packets can only be sent
with Initial packet protection keys and acknowledged in packets which with Initial packet protection keys and acknowledged in packets that
are also Initial packets. Similarly, Handshake packets are sent at are also Initial packets. Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in the Handshake encryption level and can only be acknowledged in
Handshake packets. Handshake packets.
This enforces cryptographic separation between the data sent in the This enforces cryptographic separation between the data sent in the
different packet number spaces. Packet numbers in each space start different packet number spaces. Packet numbers in each space start
at packet number 0. Subsequent packets sent in the same packet at packet number 0. Subsequent packets sent in the same packet
number space MUST increase the packet number by at least one. number space MUST increase the packet number by at least one.
0-RTT and 1-RTT data exist in the same packet number space to make 0-RTT and 1-RTT data exist in the same packet number space to make
loss recovery algorithms easier to implement between the two packet loss recovery algorithms easier to implement between the two packet
types. types.
A QUIC endpoint MUST NOT reuse a packet number within the same packet A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection. If the packet number for sending number space in one connection. If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without reaches 2^62 - 1, the sender MUST close the connection without
sending a CONNECTION_CLOSE frame or any further packets; an endpoint sending a CONNECTION_CLOSE frame or any further packets; an endpoint
MAY send a Stateless Reset (Section 10.4) in response to further MAY send a Stateless Reset (Section 10.3) in response to further
packets that it receives. packets that it receives.
A receiver MUST discard a newly unprotected packet unless it is A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet certain that it has not processed another packet with the same packet
number from the same packet number space. Duplicate suppression MUST number from the same packet number space. Duplicate suppression MUST
happen after removing packet protection for the reasons described in happen after removing packet protection for the reasons described in
Section 9.3 of [QUIC-TLS]. Section 9.3 of [QUIC-TLS].
Endpoints that track all individual packets for the purposes of Endpoints that track all individual packets for the purposes of
detecting duplicates are at risk of accumulating excessive state. detecting duplicates are at risk of accumulating excessive state.
The data required for detecting duplicates can be limited by The data required for detecting duplicates can be limited by
maintaining a minimum packet number below which all packets are maintaining a minimum packet number below which all packets are
immediately dropped. Any minimum needs to account for large immediately dropped. Any minimum needs to account for large
variations in round trip time, which includes the possibility that a variations in round trip time, which includes the possibility that a
peer might probe network paths with a much larger round trip times; peer might probe network paths with much larger round trip times; see
see Section 9. Section 9.
Packet number encoding at a sender and decoding at a receiver are Packet number encoding at a sender and decoding at a receiver are
described in Section 17.1. described in Section 17.1.
12.4. Frames and Frame Types 12.4. Frames and Frame Types
The payload of QUIC packets, after removing packet protection, The payload of QUIC packets, after removing packet protection,
consists of a sequence of complete frames, as shown in Figure 10. consists of a sequence of complete frames, as shown in Figure 11.
Version Negotiation, Stateless Reset, and Retry packets do not Version Negotiation, Stateless Reset, and Retry packets do not
contain frames. contain frames.
Packet Payload { Packet Payload {
Frame (..) ..., Frame (8..) ...,
} }
Figure 10: QUIC Payload Figure 11: QUIC Payload
The payload of a packet that contains frames MUST contain at least The payload of a packet that contains frames MUST contain at least
one frame, and MAY contain multiple frames and multiple frame types. one frame, and MAY contain multiple frames and multiple frame types.
Frames always fit within a single QUIC packet and cannot span Frames always fit within a single QUIC packet and cannot span
multiple packets. multiple packets.
Each frame begins with a Frame Type, indicating its type, followed by Each frame begins with a Frame Type, indicating its type, followed by
additional type-dependent fields: additional type-dependent fields:
Frame { Frame {
Frame Type (i), Frame Type (i),
Type-Dependent Fields (..), Type-Dependent Fields (..),
} }
Figure 11: Generic Frame Layout Figure 12: Generic Frame Layout
The frame types defined in this specification are listed in Table 3. The frame types defined in this specification are listed in Table 3.
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. These frames are explained in more detail in Section 19. frame. These frames are explained in more detail in Section 19.
+-------------+----------------------+---------------+---------+ +=============+======================+===============+======+======+
| Type Value | Frame Type Name | Definition | Packets | | Type Value | Frame Type Name | Definition | Pkts | Spec |
+=============+======================+===============+=========+ +=============+======================+===============+======+======+
| 0x00 | PADDING | Section 19.1 | IH01 | | 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 | | 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 | | 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 | | 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 | | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | P |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+------+------+
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 | P |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+------+------+
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 | |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+------+------+
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+------+------+
Table 3: Frame Types Table 3: Frame Types
The "Packets" column in Table 3 does not form part of the IANA The "Pkts" column in Table 3 lists the types of packets that each
registry; see Section 22.3. This column lists the types of packets frame type could appear in, indicated by the following characters:
that each frame type could appear in, indicated by the following
characters:
I: Initial (Section 17.2.2) I: Initial (Section 17.2.2)
H: Handshake (Section 17.2.4) H: Handshake (Section 17.2.4)
0: 0-RTT (Section 17.2.3) 0: 0-RTT (Section 17.2.3)
1: 1-RTT (Section 17.3) 1: 1-RTT (Section 17.3)
ih: A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial
or Handshake packets. or Handshake packets.
Section 4 of [QUIC-TLS] provides more detail about these Section 4 of [QUIC-TLS] provides more detail about these
restrictions. Note that all frames can appear in 1-RTT packets. restrictions. Note that all frames can appear in 1-RTT packets. An
endpoint MUST treat receipt of a frame in a packet type that is not
permitted as a connection error of type PROTOCOL_VIOLATION.
The "Spec" column in Table 3 summarizes any special rules governing
the processing or generation of the frame type, as indicated by the
following characters:
N: Packets containing only frames with this marking are not ack-
eliciting; see Section 13.2.
C: Packets containing only frames with this marking do not count
toward bytes in flight for congestion control purposes; see
[QUIC-RECOVERY].
P: Packets containing only frames with this marking can be used to
probe new network paths during connection migration; see
Section 9.1.
F: The content of frames with this marking are flow controlled; see
Section 4.
The "Pkts" and "Spec" columns in Table 3 do not form part of the IANA
registry; see Section 22.3.
An endpoint MUST treat the receipt of a frame of unknown type as a An endpoint MUST treat the receipt of a frame of unknown type as a
connection error of type FRAME_ENCODING_ERROR. connection error of type FRAME_ENCODING_ERROR.
All QUIC frames are idempotent in this version of QUIC. That is, a All QUIC frames are idempotent in this version of QUIC. That is, a
valid frame does not cause undesirable side effects or errors when valid frame does not cause undesirable side effects or errors when
received more than once. received more than once.
The Frame Type field uses a variable length integer encoding (see The Frame Type field uses a variable-length integer encoding (see
Section 16) with one exception. To ensure simple and efficient Section 16) with one exception. To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest implementations of frame parsing, a frame type MUST use the shortest
possible encoding. For frame types defined in this document, this possible encoding. For frame types defined in this document, this
means a single-byte encoding, even though it is possible to encode means a single-byte encoding, even though it is possible to encode
these values as a two-, four- or eight-byte variable length integer. these values as a two-, four- or eight-byte variable-length integer.
For instance, though 0x4001 is a legitimate two-byte encoding for a For instance, though 0x4001 is a legitimate two-byte encoding for a
variable-length integer with a value of 1, PING frames are always variable-length integer with a value of 1, PING frames are always
encoded as a single byte with the value 0x01. This rule applies to encoded as a single byte with the value 0x01. This rule applies to
all current and future QUIC frame types. An endpoint MAY treat the all current and future QUIC frame types. An endpoint MAY treat the
receipt of a frame type that uses a longer encoding than necessary as receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
A sender bundles one or more frames in a QUIC packet; see A sender sends one or more frames in a QUIC packet; see Section 12.4.
Section 12.4.
A sender can minimize per-packet bandwidth and computational costs by A sender can minimize per-packet bandwidth and computational costs by
including as many frames as possible in each QUIC packet. A sender including as many frames as possible in each QUIC packet. A sender
MAY wait for a short period of time to collect multiple frames before MAY wait for a short period of time to collect multiple frames before
sending a packet that is not maximally packed, to avoid sending out sending a packet that is not maximally packed, to avoid sending out
large numbers of small packets. An implementation MAY use knowledge large numbers of small packets. An implementation MAY use knowledge
about application sending behavior or heuristics to determine whether about application sending behavior or heuristics to determine whether
and for how long to wait. This waiting period is an implementation and for how long to wait. This waiting period is an implementation
decision, and an implementation should be careful to delay decision, and an implementation should be careful to delay
conservatively, since any delay is likely to increase application- conservatively, since any delay is likely to increase application-
skipping to change at page 84, line 49 skipping to change at page 87, line 21
is able to detect the condition. is able to detect the condition.
13.2. Generating Acknowledgements 13.2. Generating Acknowledgements
Endpoints acknowledge all packets they receive and process. However, Endpoints acknowledge all packets they receive and process. However,
only ack-eliciting packets cause an ACK frame to be sent within the only ack-eliciting packets cause an ACK frame to be sent within the
maximum ack delay. Packets that are not ack-eliciting are only maximum ack delay. Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons. acknowledged when an ACK frame is sent for other reasons.
When sending a packet for any reason, an endpoint SHOULD attempt to When sending a packet for any reason, an endpoint SHOULD attempt to
bundle an ACK frame if one has not been sent recently. Doing so include an ACK frame if one has not been sent recently. Doing so
helps with timely loss detection at the peer. helps with timely loss detection at the peer.
In general, frequent feedback from a receiver improves loss and In general, frequent feedback from a receiver improves loss and
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 ack packets MUST be acknowledged at least once within the maximum delay
delay. An endpoint communicates its maximum delay using the an endpoint communicated using the max_ack_delay transport parameter;
max_ack_delay transport parameter; see Section 18.2. max_ack_delay see Section 18.2. max_ack_delay declares an explicit contract: an
declares an explicit contract: an endpoint promises to never endpoint promises to never intentionally delay acknowledgments of an
intentionally delay acknowledgments of an ack-eliciting packet by ack-eliciting packet by more than the indicated value. If it does,
more than the indicated value. If it does, any excess accrues to the any excess accrues to the RTT estimate and could result in spurious
RTT estimate and could result in spurious or delayed retransmissions or delayed retransmissions from the peer. A sender uses the
from the peer. For Initial and Handshake packets, a max_ack_delay of receiver's max_ack_delay value in determining timeouts for timer-
0 is used. The sender uses the receiver's max_ack_delay value in based retransmission, as detailed in Section 6.2 of [QUIC-RECOVERY].
determining timeouts for timer-based retransmission, as detailed in
Section 6.2 of [QUIC-RECOVERY]. An endpoint MUST acknowledge all ack-eliciting Initial and Handshake
packets immediately and all ack-eliciting 0-RTT and 1-RTT packets
within its advertised max_ack_delay, with the following exception.
Prior to handshake confirmation, an endpoint might not have packet
protection keys for decrypting Handshake, 0-RTT, or 1-RTT packets
when they are received. It might therefore buffer them and
acknowledge them when the requisite keys become available.
Since packets containing only ACK frames are not congestion Since packets containing only ACK frames are not congestion
controlled, an endpoint MUST NOT send more than one such packet in controlled, an endpoint MUST NOT send more than one such packet in
response to receiving an ack-eliciting packet. response to receiving an ack-eliciting packet.
An endpoint MUST NOT send a non-ack-eliciting packet in response to a An endpoint MUST NOT send a non-ack-eliciting packet in response to a
non-ack-eliciting packet, even if there are packet gaps which precede non-ack-eliciting packet, even if there are packet gaps that precede
the received packet. This avoids an infinite feedback loop of the received packet. This avoids an infinite feedback loop of
acknowledgements, which could prevent the connection from ever acknowledgements, which could prevent the connection from ever
becoming idle. Non-ack-eliciting packets are eventually acknowledged becoming idle. Non-ack-eliciting packets are eventually acknowledged
when the endpoint sends an ACK frame in response to other events. when the endpoint sends an ACK frame in response to other events.
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet generate and send an ACK frame without delay when it receives an ack-
that is out of order. The endpoint SHOULD NOT continue sending ACK eliciting packet either:
frames immediately unless more ack-eliciting packets are received out
of order. If every subsequent ack-eliciting packet arrives out of * when the received packet has a packet number less than another
order, then an ACK frame SHOULD be sent immediately for every ack-eliciting packet that has been received, or
received ack-eliciting packet.
* when the packet has a packet number larger than the highest-
numbered ack-eliciting packet that has been received and there are
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 guidance offered above. However, an receivers that do not follow the guidance offered above. However, an
implementer should only deviate from these requirements after careful implementation should only deviate from these requirements after
consideration of the performance implications of doing so. careful consideration of the performance implications of a change,
for connections made by the endpoint and for other users of the
network.
An endpoint that is only sending ACK frames will not receive An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames. An endpoint SHOULD included in packets with ack-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ack-eliciting send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge. When only non-ack-eliciting packets need to packets to acknowledge. When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames. has been received to include an ACK frame with outgoing frames.
A receiver MUST NOT send an ack-eliciting frame in all packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgements.
13.2.2. Acknowledgement Frequency 13.2.2. Acknowledgement Frequency
A receiver determines how frequently to send acknowledgements in A receiver determines how frequently to send acknowledgements in
response to ack-eliciting packets. This determination involves a response to ack-eliciting packets. This determination involves a
tradeoff. trade-off.
Endpoints rely on timely acknowledgment to detect loss; see Section 6 Endpoints rely on timely acknowledgment to detect loss; see Section 6
of [QUIC-RECOVERY]. Window-based congestion controllers, such as the of [QUIC-RECOVERY]. Window-based congestion controllers, such as the
one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to
manage their congestion window. In both cases, delaying manage their congestion window. In both cases, delaying
acknowledgments can adversely affect performance. acknowledgments can adversely affect performance.
On the other hand, reducing the frequency of packets that carry only On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at acknowledgements reduces packet transmission and processing cost at
both endpoints. It can also improve connection throughput on both endpoints. It can improve connection throughput on severely
severely asymmetric links; see Section 3 of [RFC3449]. asymmetric links and reduce the volume of acknowledgment traffic
using return path capacity; see Section 3 of [RFC3449].
A receiver SHOULD send an ACK frame after receiving at least two ack- A receiver SHOULD send an ACK frame after receiving at least two ack-
eliciting packets. This recommendation is general in nature and eliciting packets. This recommendation is general in nature and
consistent with recommendations for TCP endpoint behavior [RFC5681]. consistent with recommendations for TCP endpoint behavior [RFC5681].
Knowledge of network conditions, knowledge of the peer's congestion Knowledge of network conditions, knowledge of the peer's congestion
controller, or further research and experimentation might suggest controller, or further research and experimentation might suggest
alternative acknowledgment strategies with better performance alternative acknowledgment strategies with better performance
characteristics. characteristics.
A receiver MAY process multiple available packets before determining A receiver MAY process multiple available packets before determining
whether to send an ACK frame in response. whether to send an ACK frame in response.
13.2.3. Managing ACK Ranges 13.2.3. Managing ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets When an ACK frame is sent, one or more ranges of acknowledged packets
are included. Including older packets reduces the chance of spurious are included. Including acknowledgements for older packets reduces
retransmits caused by losing previously sent ACK frames, at the cost the chance of spurious retransmissions caused by losing previously
of larger ACK frames. sent ACK frames, at the cost of larger ACK frames.
ACK frames SHOULD always acknowledge the most recently received ACK frames SHOULD always acknowledge the most recently received
packets, and the more out-of-order the packets are, the more packets, and the more out-of-order the packets are, the more
important it is to send an updated ACK frame quickly, to prevent the important it is to send an updated ACK frame quickly, to prevent the
peer from declaring a packet as lost and spuriously retransmitting peer from declaring a packet as lost and spuriously retransmitting
the frames it contains. An ACK frame is expected to fit within a the frames it contains. An ACK frame is expected to fit within a
single QUIC packet. If it does not, then older ranges (those with single QUIC packet. If it does not, then older ranges (those with
the smallest packet numbers) are omitted. the smallest packet numbers) are omitted.
Section 13.2.4 and Section 13.2.5 describe an exemplary approach for
determining what packets to acknowledge in each ACK frame. Though
the goal of these algorithms is to generate an acknowledgment for
every packet that is processed, it is still possible for
acknowledgments to be lost. A sender cannot expect to receive an
acknowledgment for every packet that the receiver processes.
13.2.4. Receiver Tracking of ACK Frames
When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved. When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent
ACK frame.
In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering. In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames
containing them could be lost. In this case, the loss recovery
algorithm could cause spurious retransmits, but the sender will
continue making forward progress.
13.2.5. Limiting ACK Ranges
A receiver limits the number of ACK Ranges (Section 19.3.1) it A receiver limits the number of ACK Ranges (Section 19.3.1) it
remembers and sends in ACK frames, both to limit the size of ACK remembers and sends in ACK frames, both to limit the size of ACK
frames and to avoid resource exhaustion. After receiving frames and to avoid resource exhaustion. After receiving
acknowledgments for an ACK frame, the receiver SHOULD stop tracking acknowledgments for an ACK frame, the receiver SHOULD stop tracking
those acknowledged ACK Ranges. those acknowledged ACK Ranges. Senders can expect acknowledgements
for most packets, but QUIC does not guarantee receipt of an
acknowledgment for every packet that the receiver processes.
It is possible that retaining many ACK Ranges could cause an ACK It is possible that retaining many ACK Ranges could cause an ACK
frame to become too large. A receiver can discard unacknowledged ACK frame to become too large. A receiver can discard unacknowledged ACK
Ranges to limit ACK frame size, at the cost of increased Ranges to limit ACK frame size, at the cost of increased
retransmissions from the sender. This is necessary if an ACK frame retransmissions from the sender. This is necessary if an ACK frame
would be too large to fit in a packet, however receivers MAY also would be too large to fit in a packet. Receivers MAY also limit ACK
limit ACK frame size further to preserve space for other frames. frame size further to preserve space for other frames or to limit the
capacity that acknowledgments consume.
A receiver MUST retain an ACK Range unless it can ensure that it will A receiver MUST retain an ACK Range unless it can ensure that it will
not subsequently accept packets with numbers in that range. not subsequently accept packets with numbers in that range.
Maintaining a minimum packet number that increases as ranges are Maintaining a minimum packet number that increases as ranges are
discarded is one way to achieve this with minimal state. discarded is one way to achieve this with minimal state.
Receivers can discard all ACK Ranges, but they MUST retain the Receivers can discard all ACK Ranges, but they MUST retain the
largest packet number that has been successfully processed as that is largest packet number that has been successfully processed as that is
used to recover packet numbers from subsequent packets; see used to recover packet numbers from subsequent packets; see
Section 17.1. Section 17.1.
A receiver SHOULD include an ACK Range containing the largest A receiver SHOULD include an ACK Range containing the largest
received packet number in every ACK frame. The Largest Acknowledged received packet number in every ACK frame. The Largest Acknowledged
field is used in ECN validation at a sender and including a lower field is used in ECN validation at a sender and including a lower
value than what was included in a previous ACK frame could cause ECN value than what was included in a previous ACK frame could cause ECN
to be unnecessarily disabled; see Section 13.4.2. to be unnecessarily disabled; see Section 13.4.2.
Section 13.2.4 describes an exemplary approach for determining what
packets to acknowledge in each ACK frame. Though the goal of this
algorithm is to generate an acknowledgment for every packet that is
processed, it is still possible for acknowledgments to be lost.
13.2.4. Limiting Ranges by Tracking ACK Frames
When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved. When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent
ACK frame.
A receiver that sends only non-ack-eliciting packets, such as ACK A receiver that sends only non-ack-eliciting packets, such as ACK
frames, might not receive an acknowledgement for a long period of frames, might not receive an acknowledgement for a long period of
time. This could cause the receiver to maintain state for a large time. This could cause the receiver to maintain state for a large
number of ACK frames for a long period of time, and ACK frames it number of ACK frames for a long period of time, and ACK frames it
sends could be unnecessarily large. In such a case, a receiver could sends could be unnecessarily large. In such a case, a receiver could
bundle a PING or other small ack-eliciting frame occasionally, such send a PING or other small ack-eliciting frame occasionally, such as
as once per round trip, to elicit an ACK from the peer. once per round trip, to elicit an ACK from the peer.
A receiver MUST NOT bundle an ack-eliciting frame with all packets In cases without ACK frame loss, this algorithm allows for a minimum
that would otherwise be non-ack-eliciting, to avoid an infinite of 1 RTT of reordering. In cases with ACK frame loss and reordering,
feedback loop of acknowledgements. this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames
containing them could be lost. In this case, the loss recovery
algorithm could cause spurious retransmissions, but the sender will
continue making forward progress.
13.2.6. Measuring and Reporting Host Delay 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between the An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the time the packet with the largest packet number is received and the
time an acknowledgment is sent. The endpoint encodes this delay in time an acknowledgment is sent. The endpoint encodes this
the Ack Delay field of an ACK frame; see Section 19.3. This allows acknowledgement delay in the ACK Delay field of an ACK frame; see
the receiver of the ACK to adjust for any intentional delays, which Section 19.3. This allows the receiver of the ACK frame to adjust
is important for getting a better estimate of the path RTT when for any intentional delays, which is important for getting a better
acknowledgments are delayed. A packet might be held in the OS kernel estimate of the path RTT when acknowledgments are delayed.
or elsewhere on the host before being processed. An endpoint MUST
NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame.
13.2.7. ACK Frames and Packet Protection A packet might be held in the OS kernel or elsewhere on the host
before being processed. An endpoint MUST NOT include delays that it
does not control when populating the ACK Delay field in an ACK frame.
However, endpoints SHOULD include buffering delays caused by
unavailability of decryption keys, since these delays can be large
and are likely to be non-repeating.
When the measured acknowledgement delay is larger than its
max_ack_delay, an endpoint SHOULD report the measured delay. This
information is especially useful during the handshake when delays
might be large; see Section 13.2.1.
13.2.6. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed; see Section 12.1. For number space as the packet being acknowledged; see Section 12.1. For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
the server cryptographic handshake messages are delayed or lost. the server cryptographic handshake messages are delayed or lost.
Note that the same limitation applies to other data sent by the Note that the same limitation applies to other data sent by the
server protected by the 1-RTT keys. server protected by the 1-RTT keys.
13.2.8. PADDING Frames Consume Congestion Window 13.2.7. PADDING Frames Consume Congestion Window
Packets containing PADDING frames are considered to be in flight for Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Packets containing only congestion control purposes [QUIC-RECOVERY]. Packets containing only
PADDING frames therefore consume congestion window but do not PADDING frames therefore consume congestion window but do not
generate acknowledgments that will open the congestion window. To generate acknowledgments that will open the congestion window. To
avoid a deadlock, a sender SHOULD ensure that other frames are sent avoid a deadlock, a sender SHOULD ensure that other frames are sent
periodically in addition to PADDING frames to elicit acknowledgments periodically in addition to PADDING frames to elicit acknowledgments
from the receiver. from the receiver.
13.3. Retransmission of Information 13.3. Retransmission of Information
skipping to change at page 89, line 46 skipping to change at page 92, line 39
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.
* 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.
* ACK frames carry the most recent set of acknowledgements and the * ACK frames carry the most recent set of acknowledgements and the
Ack Delay from the largest acknowledged packet, as described in acknowledgement delay from the largest acknowledged packet, as
Section 13.2.1. Delaying the transmission of packets containing described in Section 13.2.1. Delaying the transmission of packets
ACK frames or sending old ACK frames can cause the peer to containing ACK frames or resending old ACK frames can cause the
generate an inflated RTT sample or unnecessarily disable ECN. peer to generate an inflated RTT sample or unnecessarily disable
ECN.
* 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.
* 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
skipping to change at page 90, line 27 skipping to change at page 93, line 20
* 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, but as described in Section 10. detected, but as described in Section 10.
* 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. MAX_DATA frames to be sent; see Section 4.2.
* 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" state. enters a "Size Known" state.
* 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
skipping to change at page 91, line 46 skipping to change at page 94, line 40
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
payload size due to change in packet number length, connection ID payload size due to change in packet number length, connection ID
length, and path MTU. A receiver MUST accept packets containing an length, and path MTU. A receiver MUST accept packets containing an
outdated frame, such as a MAX_DATA frame carrying a smaller maximum outdated frame, such as a MAX_DATA frame carrying a smaller maximum
data than one found in an older packet. data than one found in an older packet.
A sender SHOULD avoid retransmitting information from packets once
they are acknowledged. This includes packets that are acknowledged
after being declared lost, which can happen in the presence of
network reordering. Doing so requires senders to retain information
about packets after they are declared lost. A sender can discard
this information after a period of time elapses that adequately
allows for reordering, such as a PTO (Section 6.2 of
[QUIC-RECOVERY]), or on other events, such as reaching a memory
limit.
Upon detecting losses, a sender MUST take appropriate congestion Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY]. are described in [QUIC-RECOVERY].
13.4. Explicit Congestion Notification 13.4. Explicit Congestion Notification
QUIC endpoints can use Explicit Congestion Notification (ECN) QUIC endpoints can use Explicit Congestion Notification (ECN)
[RFC3168] to detect and respond to network congestion. ECN allows a [RFC3168] to detect and respond to network congestion. ECN allows a
network node to indicate congestion in the network by setting a network node to indicate congestion in the network by setting a
codepoint in the IP header of a packet instead of dropping it. codepoint in the IP header of a packet instead of dropping it.
Endpoints react to congestion by reducing their sending rate in Endpoints react to congestion by reducing their sending rate in
response, as described in [QUIC-RECOVERY]. response, as described in [QUIC-RECOVERY].
Note that supporting ECN requires being able to set and read the ECN
codepoints in the IP headers of datagrams carrying QUIC packets. On
platforms where this is not possible, QUIC cannot support ECN.
To use ECN, QUIC endpoints first determine whether a path supports To use ECN, QUIC endpoints first determine whether a path supports
ECN marking and the peer is able to access the ECN codepoint in the ECN marking and the peer is able to access the ECN codepoint in the
IP header. A network path does not support ECN if ECN marked packets IP header. A network path does not support ECN if ECN marked packets
get dropped or ECN markings are rewritten on the path. An endpoint get dropped or ECN markings are rewritten on the path. An endpoint
validates the use of ECN on the path, both during connection validates the use of ECN on the path, both during connection
establishment and when migrating to a new path (Section 9). establishment and when migrating to a new path (Section 9).
13.4.1. ECN Counts 13.4.1. ECN Counts
On receiving a QUIC packet with an ECT or CE codepoint, an ECN- On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames; see count, and includes these counts in subsequent ACK frames; see
Section 13.2 and Section 19.3. Note that this requires being able to Section 13.2 and Section 19.3.
read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms.
An IP packet that results in no QUIC packets being processed does not An IP packet that results in no QUIC packets being processed does not
increase ECN counts. A QUIC packet detected by a receiver as a increase ECN counts. A QUIC packet detected by a receiver as a
duplicate does not affect the receiver's local ECN codepoint counts; duplicate does not affect the receiver's local ECN codepoint counts;
see Section 21.8 for relevant security concerns. see Section 21.9 for relevant security concerns.
If an endpoint receives a QUIC packet without an ECT or CE codepoint If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per Section 13.2 with an ACK in the IP packet header, it responds per Section 13.2 with an ACK
frame without increasing any ECN counts. If an endpoint does not frame without increasing any ECN counts. If an endpoint does not
implement ECN support or does not have access to received ECN implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts. codepoints, it does not increase ECN counts.
Coalesced packets (see Section 12.2) mean that several packets can Coalesced packets (see Section 12.2) mean that several packets can
share the same IP header. The ECN counts for the ECN codepoint share the same IP header. The ECN counts for the ECN codepoint
received in the associated IP header are incremented once for each received in the associated IP header are incremented once for each
QUIC packet, not per enclosing IP packet or UDP datagram. QUIC packet, not per enclosing IP packet or UDP datagram.
Each packet number space maintains separate acknowledgement state and Each packet number space maintains separate acknowledgement state and
separate ECN counts. For example, if one each of an Initial, 0-RTT, separate ECN counts. For example, if one each of an Initial, 0-RTT,
Handshake, and 1-RTT QUIC packet are coalesced, the corresponding Handshake, and 1-RTT QUIC packet are coalesced, the corresponding
counts for the Initial and Handshake packet number space will be counts for the Initial and Handshake packet number space will be
incremented by one and the counts for the 1-RTT packet number space incremented by one and the counts for the application data packet
will be increased by two. number space will be increased by two.
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 with ECN markings. To provide robust connectivity in drop packets with ECN markings. To provide robust connectivity in
the presence of such devices, each endpoint independently validates the presence of such devices, each endpoint independently validates
ECN counts and disables ECN if errors are detected. ECN counts and disables ECN if the path is not showing consistent
support for ECN.
Endpoints validate ECN for packets sent on each network path Endpoints validate ECN for packets sent on each network path
independently. An endpoint thus validates ECN on new connection independently. An endpoint thus validates ECN on new connection
establishment, when switching to a new server preferred address, and establishment, when switching to a server's preferred address, and on
on active connection migration to a new path. Appendix B describes active connection migration to a new path. Appendix B describes one
one possible algorithm for testing paths for ECN support. possible algorithm for testing paths for ECN support.
Even if an endpoint does not use ECN markings on packets it Even if an endpoint does not use ECN markings on packets it
transmits, the endpoint MUST provide feedback about ECN markings transmits, the endpoint MUST provide feedback about ECN markings
received from the peer if they are accessible. Failing to report ECN received from the peer if they are accessible. Failing to report ECN
counts will cause the peer to disable ECN marking. counts will cause the peer to disable ECN marking.
13.4.2.1. Sending ECN Markings 13.4.2.1. Sending ECN Markings
To start ECN validation, an endpoint SHOULD do the following when To start ECN validation, an endpoint SHOULD do the following when
sending packets on a new path to a peer: sending packets on a new path to a peer:
* Set the ECT(0) codepoint in the IP header of early outgoing * Set the ECT(0) codepoint in the IP header of early outgoing
packets sent on a new path to the peer [RFC8311]. packets sent on a new path to the peer ([RFC8311]).
* If all packets that were sent with the ECT(0) codepoint are * If all packets that were sent with the ECT(0) codepoint are
eventually deemed lost [QUIC-RECOVERY], validation is deemed to eventually deemed lost (Section 6 of [QUIC-RECOVERY]), validation
have failed. is deemed to have failed.
To reduce the chances of misinterpreting congestive loss as packets To reduce the chances of misinterpreting congestive loss as packets
dropped by a faulty network element, an endpoint could set the ECT(0) dropped by a faulty network element, an endpoint could set the ECT(0)
codepoint for only the first ten outgoing packets on a path, or for a codepoint for only the first ten outgoing packets on a path, or for a
period of three RTTs, whichever occurs first. period of three RTTs, whichever occurs first.
Other methods of probing paths for ECN support are possible, as are Other methods of probing paths for ECN support are possible, as are
different marking strategies. Implementations MAY use other methods different marking strategies. Implementations MAY use other methods
defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) defined in RFCs; see [RFC8311]. Implementations that use the ECT(1)
codepoint need to perform ECN validation using ECT(1) counts. codepoint need to perform ECN validation using ECT(1) counts.
13.4.2.2. Receiving ACK Frames 13.4.2.2. Receiving ACK Frames
An endpoint that sets ECT(0) or ECT(1) codepoints on packets it Erroneous application of ECN marks in the network can result in
transmits MUST use the following steps on receiving an ACK frame to degraded connection performance. An endpoint that receives an ACK
validate ECN. frame with ECN counts therefore validates the counts before using
them. It performs this validation by comparing newly received counts
* If this ACK frame newly acknowledges a packet that the endpoint against those from the last successfully processed ACK frame. Any
sent with either ECT(0) or ECT(1) codepoints set, and if no ECN increase in ECN counts is validated based on the markings that were
feedback is present in the ACK frame, validation fails. This step applied to packets that are newly acknowledged in the ACK frame.
protects against both a network element that zeroes out ECN bits
and a peer that is unable to access ECN markings, since the peer
could respond without ECN feedback in these cases.
* For validation to succeed, the total increase in ECT(0), ECT(1),
and CE counts MUST be no smaller than the total number of QUIC
packets sent with an ECT codepoint that are newly acknowledged in
this ACK frame. This step detects any network remarking from
ECT(0), ECT(1), or CE codepoints to Not-ECT.
* Any increase in either ECT(0) or ECT(1) counts, plus any increase If an ACK frame newly acknowledges a packet that the endpoint sent
in the CE count, MUST be no smaller than the number of packets with either ECT(0) or ECT(1) codepoints set, ECN validation fails if
sent with the corresponding ECT codepoint that are newly ECN counts are not present in the ACK frame. This check detects a
acknowledged in this ACK frame. This step detects any erroneous network element that zeroes out ECN bits or a peer that is unable to
network remarking from ECT(0) to ECT(1) (or vice versa). access ECN markings.
Processing ECN counts out of order can result in validation failure. ECN validation fails if the sum of the increase in ECT(0) and ECN-CE
An endpoint SHOULD NOT perform this validation if this ACK frame does counts is less than the number of newly acknowledged packets that
not advance the largest packet number acknowledged in this were originally sent with an ECT(0) marking. Similarly, ECN
connection. validation fails if the sum of the increases to ECT(1) and ECN-CE
counts is less than the number of newly acknowledged packets sent
with an ECT(1) marking. These checks can detect removal of ECN
markings in the network.
An endpoint could miss acknowledgements for a packet when ACK frames An endpoint could miss acknowledgements for a packet when ACK frames
are lost. It is therefore possible for the total increase in ECT(0), are lost. It is therefore possible for the total increase in ECT(0),
ECT(1), and CE counts to be greater than the number of packets ECT(1), and ECN-CE counts to be greater than the number of packets
acknowledged in an ACK frame. When this happens, and if validation acknowledged in an ACK frame. This is why counts are permitted to be
succeeds, the local reference counts MUST be increased to match the larger than might be accounted for by newly acknowledged packets.
counts in the ACK frame.
ECN validation MAY fail if the total count for an ECT(0) or ECT(1)
marking exceeds the total number of packets sent with the
corresponding marking. In particular, an endpoint that never applies
a particular marking can fail validation when a non-zero count for
the corresponding marking is received. This check can detect when
packets are marked ECT(0) or ECT(1) in the network.
Processing ECN counts out of order can result in validation failure.
An endpoint SHOULD skip ECN validation on an ACK frame that does not
increase the largest acknowledged packet number.
13.4.2.3. Validation Outcomes 13.4.2.3. Validation Outcomes
If validation fails, then the endpoint stops sending ECN markings in If validation fails, then the endpoint stops sending ECN markings in
subsequent IP packets with the expectation that either the network subsequent IP packets with the expectation that either the network
path or the peer does not support ECN. path or the peer does not support ECN.
Upon successful validation, an endpoint can continue to set ECT Upon successful validation, an endpoint can continue to set ECT
codepoints in subsequent packets with the expectation that the path codepoints in subsequent packets with the expectation that the path
is ECN-capable. Network routing and path elements can change mid- is ECN-capable. Network routing and path elements can change mid-
skipping to change at page 95, line 11 skipping to change at page 98, line 20
Even if validation fails, an endpoint MAY revalidate ECN on the same Even if validation fails, an endpoint MAY revalidate ECN on the same
path at any later time in the connection. path at any later time in the connection.
14. Packet Size 14. Packet Size
The QUIC packet size includes the QUIC header and protected payload, The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP headers. but not the UDP or IP headers.
QUIC depends upon a minimum IP packet size of at least 1280 bytes. QUIC depends upon a minimum IP packet size of at least 1280 bytes.
This is the IPv6 minimum size [RFC8200] and is also supported by most This is the IPv6 minimum size ([IPv6]) and is also supported by most
modern IPv4 networks. Assuming the minimum IP header size, this modern IPv4 networks. Assuming the minimum IP header size, this
results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252
bytes for IPv4. bytes for IPv4.
The QUIC maximum packet size is the largest size of QUIC packet that The QUIC maximum packet size is the largest size of QUIC packet that
can be sent across a network path using a single packet. Any maximum can be sent across a network path using a single packet. Any maximum
packet size larger than 1200 bytes can be discovered using Path packet size larger than 1200 bytes can be discovered using Path
Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see
Section 14.3). 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 packet (Section 18.2) might act as an additional limit on the maximum packet
size. A sender can avoid exceeding this limit, once the value is size. A sender can avoid exceeding this limit, once the value is
known. However, prior to learning the value of the transport known. However, prior to learning the value of the transport
parameter, endpoints risk datagrams being lost if they send packets parameter, endpoints risk datagrams being lost if they send packets
larger than the smallest allowed maximum packet size of 1200 bytes. larger than the smallest allowed maximum packet size of 1200 bytes.
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4
[IPv4], the DF bit MUST be set to prevent fragmentation on the path. ([IPv4]), the DF bit MUST be set to prevent fragmentation on the
path.
14.1. Initial Packet Size 14.1. Initial Packet Size
A client MUST expand the payload of all UDP datagrams carrying A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum packet size Initial packets to at least the smallest allowed maximum packet size
(1200 bytes) by adding PADDING frames to the Initial packet or by (1200 bytes) by adding PADDING frames to the Initial packet or by
coalescing the Initial packet; see Section 12.2. Sending a UDP coalescing the Initial packet; see Section 12.2. Sending a UDP
datagram of this size ensures that the network path from the client datagram of this size ensures that the network path from the client
to the server supports a reasonable Path Maximum Transmission Unit to the server supports a reasonable Path Maximum Transmission Unit
(PMTU). This also helps reduce the amplitude of amplification (PMTU). This also helps reduce the amplitude of amplification
skipping to change at page 96, line 9 skipping to change at page 99, line 25
address; see Section 8. address; see Section 8.
Datagrams containing Initial packets MAY exceed 1200 bytes if the Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the network path and peer both support the size client believes that the network path and peer both support the size
that it chooses. that it chooses.
A server MUST discard an Initial packet that is carried in a UDP A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is less than the smallest allowed datagram with a payload that is less than the smallest allowed
maximum packet size of 1200 bytes. A server MAY also immediately maximum packet size of 1200 bytes. A server MAY also immediately
close the connection by sending a CONNECTION_CLOSE frame with an close the connection by sending a CONNECTION_CLOSE frame with an
error code of PROTOCOL_VIOLATION; see Section 10.3.1. error code of PROTOCOL_VIOLATION; see Section 10.2.3.
The server MUST also limit the number of bytes it sends before The server MUST also limit the number of bytes it sends before
validating the address of the client; see Section 8. validating the address of the client; see Section 8.
14.2. Path Maximum Transmission Unit (PMTU) 14.2. Path Maximum Transmission Unit
The Path Maximum Transmission Unit (PMTU) is the maximum size of the The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP packet including the IP header, UDP header, and UDP entire IP packet including the IP header, UDP header, and UDP
payload. The UDP payload includes the QUIC packet header, protected payload. The UDP payload includes the QUIC packet header, protected
payload, and any authentication fields. The PMTU can depend on path payload, and any authentication fields. The PMTU can depend on path
characteristics, and can therefore change over time. The largest UDP characteristics, and can therefore change over time. The largest UDP
payload an endpoint sends at any given time is referred to as the payload an endpoint sends at any given time is referred to as the
endpoint's maximum packet size. endpoint's maximum packet size.
An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD
(Section 14.2.1) to determine whether the path to a destination will (Section 14.2.1) to determine whether the path to a destination will
support a desired maximum packet size without fragmentation. In the support a desired maximum packet size without fragmentation. In the
absence of these mechanisms, QUIC endpoints SHOULD NOT send IP absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
packets larger than the smallest allowed maximum packet size. packets larger than the smallest allowed maximum packet size.
Both DPLPMTUD and PMTUD send IP packets that are larger than the Both DPLPMTUD and PMTUD send IP packets that are larger than the
current maximum packet size. We refer to these as PMTU probes. All current maximum packet size, referred to as PMTU probes. All QUIC
QUIC packets that are not sent in a PMTU probe SHOULD be sized to fit packets that are not sent in a PMTU probe SHOULD be sized to fit
within the maximum packet size to avoid the packet being fragmented within the maximum packet size to avoid the packet being fragmented
or dropped [RFC8085]. or dropped ([RFC8085]).
If a QUIC endpoint determines that the PMTU between any pair of local If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below the smallest allowed maximum and remote IP addresses has fallen below the smallest allowed maximum
packet size of 1200 bytes, it MUST immediately cease sending QUIC packet size of 1200 bytes, it MUST immediately cease sending QUIC
packets, except for those in PMTU probes or those containing packets, except for those in PMTU probes or those containing
CONNECTION_CLOSE frames, on the affected path. An endpoint MAY CONNECTION_CLOSE frames, on the affected path. An endpoint MAY
terminate the connection if an alternative path cannot be found. terminate the connection if an alternative path cannot be found.
Each pair of local and remote addresses could have a different PMTU. Each pair of local and remote addresses could have a different PMTU.
QUIC implementations that implement any kind of PMTU discovery QUIC implementations that implement any kind of PMTU discovery
skipping to change at page 97, line 32 skipping to change at page 100, line 48
The size of the quoted packet can actually be smaller, or the The size of the quoted packet can actually be smaller, or the
information unintelligible, as described in Section 1.1 of information unintelligible, as described in Section 1.1 of
[DPLPMTUD]. [DPLPMTUD].
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from off-path injection as specified in [RFC8201] and Section 5.2 of from off-path injection as specified in [RFC8201] and Section 5.2 of
[RFC8085]. This validation SHOULD use the quoted packet supplied in [RFC8085]. This validation SHOULD use the quoted packet supplied in
the payload of an ICMP message to associate the message with a the payload of an ICMP message to associate the message with a
corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]). corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]).
ICMP message validation MUST include matching IP addresses and UDP ICMP message validation MUST include matching IP addresses and UDP
ports [RFC8085] and, when possible, connection IDs to an active QUIC ports ([RFC8085]) and, when possible, connection IDs to an active
session. The endpoint SHOULD ignore all ICMP messages that fail QUIC session. The endpoint SHOULD ignore all ICMP messages that fail
validation. validation.
An endpoint MUST NOT increase PMTU based on ICMP messages; see An endpoint MUST NOT increase PMTU based on ICMP messages; see
Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum
packet size in response to ICMP messages MAY be provisional until packet size in response to ICMP messages MAY be provisional until
QUIC's loss detection algorithm determines that the quoted packet has QUIC's loss detection algorithm determines that the quoted packet has
actually been lost. actually been lost.
14.3. Datagram Packetization Layer PMTU Discovery 14.3. Datagram Packetization Layer PMTU Discovery
skipping to change at page 98, line 10 skipping to change at page 101, line 28
Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1 Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1
of [DPLPMTUD]) to be consistent with the minimum QUIC packet size. of [DPLPMTUD]) to be consistent with the minimum QUIC packet size.
The MIN_PLPMTU is the same as the BASE_PMTU. The MIN_PLPMTU is the same as the BASE_PMTU.
QUIC endpoints implementing DPLPMTUD maintain a maximum packet size QUIC endpoints implementing DPLPMTUD maintain a maximum packet size
(DPLPMTUD MPS) for each combination of local and remote IP addresses. (DPLPMTUD MPS) for each combination of local and remote IP addresses.
14.3.1. DPLPMTUD and Initial Connectivity 14.3.1. DPLPMTUD and Initial Connectivity
From the perspective of DPLPMTUD, QUIC transport is an acknowledged From the perspective of DPLPMTUD, QUIC is an acknowledged
packetization layer (PL). A sender can therefore enter the DPLPMTUD packetization layer (PL). A sender can therefore enter the DPLPMTUD
BASE state when the QUIC connection handshake has been completed. BASE state when the QUIC connection handshake has been completed.
14.3.2. Validating the QUIC Path with DPLPMTUD 14.3.2. Validating the QUIC Path with DPLPMTUD
QUIC provides an acknowledged PL, therefore a sender does not QUIC provides an acknowledged PL, therefore a sender does not
implement the DPLPMTUD CONFIRMATION_TIMER while in the implement the DPLPMTUD CONFIRMATION_TIMER while in the
SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD]. SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD].
14.3.3. Handling of ICMP Messages by DPLPMTUD 14.3.3. Handling of ICMP Messages by DPLPMTUD
skipping to change at page 99, line 39 skipping to change at page 103, line 5
current use for packets of that type. 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 to this Other versions of QUIC might have different properties from this
version. The properties of QUIC that are guaranteed to be consistent version. The properties of QUIC that are guaranteed to be consistent
across all versions of the protocol are described in across all versions of the protocol are described in
[QUIC-INVARIANTS]. [QUIC-INVARIANTS].
Version 0x00000001 of QUIC uses TLS as a cryptographic handshake Version 0x00000001 of QUIC uses TLS as a cryptographic handshake
protocol, as described in [QUIC-TLS]. protocol, as described in [QUIC-TLS].
Versions with the most significant 16 bits of the version number Versions with the most significant 16 bits of the version number
cleared are reserved for use in future IETF consensus documents. cleared are reserved for use in future IETF consensus documents.
skipping to change at page 100, line 26 skipping to change at page 103, line 37
[[RFC editor: please remove the remainder of this section before [[RFC editor: please remove the remainder of this section before
publication.]] publication.]]
The version number for the final version of this specification The version number for the final version of this specification
(0x00000001), is reserved for the version of the protocol that is (0x00000001), is reserved for the version of the protocol that is
published as an RFC. published as an RFC.
Version numbers used to identify IETF drafts are created by adding Version numbers used to identify IETF drafts are created by adding
the draft number to 0xff000000. For example, draft-ietf-quic- the draft number to 0xff000000. For example, draft-ietf-quic-
transport-13 would be identified as 0xff00000D. transport-13 would be identified as 0xff00000d.
Implementors are encouraged to register version numbers of QUIC that Implementors are encouraged to register version numbers of QUIC that
they are using for private experimentation on the GitHub wiki at they are using for private experimentation on the GitHub wiki at
https://github.com/quicwg/base-drafts/wiki/QUIC-Versions. https://github.com/quicwg/base-drafts/wiki/QUIC-Versions.
16. Variable-Length Integer Encoding 16. Variable-Length Integer Encoding
QUIC packets and frames commonly use a variable-length encoding for QUIC packets and frames commonly use a variable-length encoding for
non-negative integer values. This encoding ensures that smaller non-negative integer values. This encoding ensures that smaller
integer values need fewer bytes to encode. integer values need fewer bytes to encode.
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 summarizes encode 6, 14, 30, or 62 bit values respectively. Table 4 summarizes
the encoding properties. the encoding properties.
+------+--------+-------------+-----------------------+ +======+========+=============+=======================+
| 2Bit | Length | Usable Bits | Range | | 2Bit | 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
For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in
hexadecimal) decodes to the decimal value 151288809941952652; the hexadecimal) decodes to the decimal value 151288809941952652; the
four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte
sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37
(as does the two byte sequence 40 25). (as does the two byte sequence 40 25).
Error codes (Section 20) and versions (Section 15) are described Versions (Section 15) and error codes (Section 20) are described
using integers, but do not use this encoding. using integers, but do not use this encoding.
17. Packet Formats 17. Packet Formats
All numeric values are encoded in network byte order (that is, big- All numeric values are encoded in network byte order (that is, big-
endian) and all field sizes are in bits. Hexadecimal notation is endian) and all field sizes are in bits. Hexadecimal notation is
used for describing the value of fields. used for describing the value of fields.
17.1. Packet Number Encoding and Decoding 17.1. Packet Number Encoding and Decoding
Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3).
When present in long or short packet headers, they are encoded in 1 When present in long or short packet headers, they are encoded in 1
to 4 bytes. The number of bits required to represent the packet to 4 bytes. The number of bits required to represent the packet
number is reduced by including the least significant bits of the number is reduced by including only the least significant bits of the
packet number. packet number.
The encoded packet number is protected as described in Section 5.4 of The encoded packet number is protected as described in Section 5.4 of
[QUIC-TLS]. [QUIC-TLS].
The sender MUST use a packet number size able to represent more than Prior to receiving an acknowledgement for a packet number space, the
full packet number MUST be included.
After an acknowledgement is received for a packet number space, the
sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest twice as large a range than the difference between the largest
acknowledged packet and packet number being sent. A peer receiving acknowledged packet and packet number being sent. A peer receiving
the packet will then correctly decode the packet number, unless the the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher- packet is delayed in transit such that it arrives after many higher-
numbered packets have been received. An endpoint SHOULD use a large numbered packets have been received. An endpoint SHOULD use a large
enough packet number encoding to allow the packet number to be enough packet number encoding to allow the packet number to be
recovered even if the packet arrives after packets that are sent recovered even if the packet arrives after packets that are sent
afterwards. afterwards.
As a result, the size of the packet number encoding is at least one As a result, the size of the packet number encoding is at least one
skipping to change at page 103, line 16 skipping to change at page 106, line 16
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
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),
} }
Figure 12: 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 103, line 40 skipping to change at page 106, line 40
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. version and MUST be discarded.
Long Packet Type: The next two bits (those with a mask of 0x30) of Long Packet Type: The next two bits (those with a mask of 0x30) of
byte 0 contain a packet type. Packet types are listed in Table 5. byte 0 contain a packet type. Packet types are listed in Table 5.
Type-Specific Bits: The lower four bits (those with a mask of 0x0f) Type-Specific Bits: The lower four bits (those with a mask of 0x0f)
of byte 0 are type-specific. of byte 0 are type-specific.
Version: The QUIC Version is a 32-bit field that follows the first Version: The QUIC Version is a 32-bit field that follows the first
byte. This field indicates which version of QUIC is in use and byte. This field indicates the version of QUIC that is in use and
determines how the rest of the protocol fields are interpreted. determines how the rest of the protocol fields are interpreted.
Destination Connection ID Length: The byte following the version Destination Connection ID Length: The byte following the version
contains the length in bytes of the Destination Connection ID contains the length in bytes of the Destination Connection ID
field that follows it. This length is encoded as an 8-bit field that follows it. This length is encoded as an 8-bit
unsigned integer. In QUIC version 1, this value MUST NOT exceed unsigned integer. In QUIC version 1, this value MUST NOT exceed
20. Endpoints that receive a version 1 long header with a value 20. Endpoints that receive a version 1 long header with a value
larger than 20 MUST drop the packet. Servers SHOULD be able to larger than 20 MUST drop the packet. In order to properly form a
read longer connection IDs from other QUIC versions in order to Version Negotiation packet, servers SHOULD be able to read longer
properly form a version negotiation packet. connection IDs from other QUIC versions.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the Destination Connection ID Length field and is between follows the Destination Connection ID Length field, which
0 and 20 bytes in length. Section 7.2 describes the use of this indicates the length of this field. Section 7.2 describes the use
field in more detail. of this field in more detail.
Source Connection ID Length: The byte following the Destination Source Connection ID Length: The byte following the Destination
Connection ID contains the length in bytes of the Source Connection ID contains the length in bytes of the Source
Connection ID field that follows it. This length is encoded as a Connection ID field that follows it. This length is encoded as a
8-bit unsigned integer. In QUIC version 1, this value MUST NOT 8-bit unsigned integer. In QUIC version 1, this value MUST NOT
exceed 20 bytes. Endpoints that receive a version 1 long header exceed 20 bytes. Endpoints that receive a version 1 long header
with a value larger than 20 MUST drop the packet. Servers SHOULD with a value larger than 20 MUST drop the packet. In order to
be able to read longer connection IDs from other QUIC versions in properly form a Version Negotiation packet, servers SHOULD be able
order to properly form a version negotiation packet. to read longer connection IDs from other QUIC versions.
Source Connection ID: The Source Connection ID field follows the Source Connection ID: The Source Connection ID field follows the
Source Connection ID Length field and is between 0 and 20 bytes in Source Connection ID Length field, which indicates the length of
length. 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.
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 |
+======+===========+================+ +======+===========+================+
| 0x0 | Initial | Section 17.2.2 | | 0x0 | Initial | Section 17.2.2 |
+------+-----------+----------------+ +------+-----------+----------------+
| 0x1 | 0-RTT | Section 17.2.3 | | 0x1 | 0-RTT | Section 17.2.3 |
+------+-----------+----------------+ +------+-----------+----------------+
| 0x2 | Handshake | Section 17.2.4 | | 0x2 | Handshake | Section 17.2.4 |
+------+-----------+----------------+ +------+-----------+----------------+
| 0x3 | Retry | Section 17.2.5 | | 0x3 | Retry | Section 17.2.5 |
+------+-----------+----------------+ +------+-----------+----------------+
Table 5: Long Header Packet Types Table 5: Long Header Packet Types
The header form bit, connection ID lengths byte, Destination and The header form bit, Destination and Source Connection ID lengths,
Source Connection ID fields, and Version fields of a long header Destination and Source Connection ID fields, and Version fields of a
packet are version-independent. The other fields in the first byte long header packet are version-independent. The other fields in the
are version-specific. See [QUIC-INVARIANTS] for details on how first byte are version-specific. See [QUIC-INVARIANTS] for details
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
version and packet type. While type-specific semantics for this version and packet type. While type-specific semantics for this
version are described in the following sections, several long-header version are described in the following sections, several long-header
packets in this version of QUIC contain these additional fields: packets in this version of QUIC contain these additional fields:
Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are
reserved across multiple packet types. These bits are protected reserved across multiple packet types. These bits are protected
using header protection; see Section 5.4 of [QUIC-TLS]. The value using header protection; see Section 5.4 of [QUIC-TLS]. The value
included prior to protection MUST be set to 0. An endpoint MUST included prior to protection MUST be set to 0. An endpoint MUST
treat receipt of a packet that has a non-zero value for these treat receipt of a packet that has a non-zero value for these bits
bits, after removing both packet and header protection, as a after removing both packet and header protection as a connection
connection error of type PROTOCOL_VIOLATION. Discarding such a error of type PROTOCOL_VIOLATION. Discarding such a packet after
packet after only removing header protection can expose the only removing header protection can expose the endpoint to
endpoint to attacks; see Section 9.3 of [QUIC-TLS]. attacks; see Section 9.3 of [QUIC-TLS].
Packet Number Length: In packet types which contain a Packet Number Packet Number Length: In packet types that contain a Packet Number
field, the least significant two bits (those with a mask of 0x03) field, the least significant two bits (those with a mask of 0x03)
of byte 0 contain the length of the packet number, encoded as an of byte 0 contain the length of the packet number, encoded as an
unsigned, two-bit integer that is one less than the length of the unsigned, two-bit integer that is one less than the length of the
packet number field in bytes. That is, the length of the packet packet number field in bytes. That is, the length of the packet
number field is the value of this field, plus one. These bits are number field is the value of this field, plus one. These bits are
protected using header protection; see Section 5.4 of [QUIC-TLS]. protected using header protection; see Section 5.4 of [QUIC-TLS].
Length: The length of the remainder of the packet (that is, the Length: The length of the remainder of the packet (that is, the
Packet Number and Payload fields) in bytes, encoded as a variable- Packet Number and Payload fields) in bytes, encoded as a variable-
length integer (Section 16). length integer (Section 16).
Packet Number: The packet number field is 1 to 4 bytes long. The Packet Number: The packet number field is 1 to 4 bytes long. The
packet number has confidentiality protection separate from packet packet number is protected using header protection; see
protection, as described in Section 5.4 of [QUIC-TLS]. The length Section 5.4 of [QUIC-TLS]. The length of the packet number field
of the packet number field is encoded in the Packet Number Length is encoded in the Packet Number Length bits of byte 0; see above.
bits of byte 0; see above.
17.2.1. Version Negotiation Packet 17.2.1. Version Negotiation Packet
A Version Negotiation packet is inherently not version-specific. A Version Negotiation packet is inherently not version-specific.
Upon receipt by a client, it will be identified as a Version Upon receipt by a client, it will be identified as a Version
Negotiation packet based on the Version field having a value of 0. Negotiation packet based on the Version field having a value of 0.
The Version Negotiation packet is a response to a client packet that The Version Negotiation packet is a response to a client packet that
contains a version that is not supported by the server, and is only contains a version that is not supported by the server, and is only
sent by servers. sent by servers.
skipping to change at page 106, line 15 skipping to change at page 109, line 4
Version Negotiation Packet { Version Negotiation Packet {
Header Form (1) = 1, Header Form (1) = 1,
Unused (7), Unused (7),
Version (32) = 0, Version (32) = 0,
Destination Connection ID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..2040), Destination Connection ID (0..2040),
Source Connection ID Length (8), Source Connection ID Length (8),
Source Connection ID (0..2040), Source Connection ID (0..2040),
Supported Version (32) ..., Supported Version (32) ...,
} }
Figure 14: Version Negotiation Packet
Figure 13: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field. Servers SHOULD set the Clients MUST ignore the value of this field. Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field. Negotiation packets appear to have the Fixed Bit field.
The Version field of a Version Negotiation packet MUST be set to The Version field of a Version Negotiation packet MUST be set to
0x00000000. 0x00000000.
The server MUST include the value from the Source Connection ID field The server MUST include the value from the Source Connection ID field
skipping to change at page 106, line 40 skipping to change at page 109, line 28
randomly selected by a client. Echoing both connection IDs gives randomly selected by a client. Echoing both connection IDs gives
clients some assurance that the server received the packet and that clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an off-path the Version Negotiation packet was not generated by an off-path
attacker. attacker.
As future versions of QUIC may support Connection IDs larger than the As future versions of QUIC may support Connection IDs larger than the
version 1 limit, Version Negotiation packets could carry Connection version 1 limit, Version Negotiation packets could carry Connection
IDs that are longer than 20 bytes. IDs that are longer than 20 bytes.
The remainder of the Version Negotiation packet is a list of 32-bit The remainder of the Version Negotiation packet is a list of 32-bit
versions which the server supports. versions that the server supports.
A Version Negotiation packet cannot be explicitly acknowledged in an A Version Negotiation packet is not acknowledged. It is only sent in
ACK frame by a client. Receiving another Initial packet implicitly response to a packet that indicates an unsupported version; see
acknowledges a Version Negotiation packet. Section 5.2.2.
The Version Negotiation packet does not include the Packet Number and The Version Negotiation packet does not include the Packet Number and
Length fields present in other packets that use the long header form. Length fields present in other packets that use the long header form.
Consequently, a Version Negotiation packet consumes an entire UDP Consequently, a Version Negotiation packet consumes an entire UDP
datagram. datagram.
A server MUST NOT send more than one Version Negotiation packet in A server MUST NOT send more than one Version Negotiation packet in
response to a single UDP datagram. response to a single UDP datagram.
See Section 6 for a description of the version negotiation process. See Section 6 for a description of the version negotiation process.
skipping to change at page 107, line 31 skipping to change at page 110, line 23
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),
Token Length (i), Token Length (i),
Token (..), Token (..),
Length (i), Length (i),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (..), Packet Payload (..),
} }
Figure 14: Initial Packet Figure 15: Initial Packet
The Initial packet contains a long header as well as the Length and The Initial packet contains a long header as well as the Length and
Packet Number fields. The first byte contains the Reserved and Packet Number fields; see Section 17.2. The first byte contains the
Packet Number Length bits. Between the Source Connection ID and Reserved and Packet Number Length bits; see also Section 17.2.
Length fields, there are two additional fields specific to the Between the Source Connection ID and Length fields, there are two
Initial packet. additional fields specific to the Initial packet.
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
Token field, in bytes. This value is zero if no token is present. Token field, in bytes. This value is zero if no token is present.
Initial packets sent by the server MUST set the Token Length field Initial packets sent by the server MUST set the Token Length field
to zero; clients that receive an Initial packet with a non-zero to zero; clients that receive an Initial packet with a non-zero
Token Length field MUST either discard the packet or generate a Token Length field MUST either discard the packet or generate a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
Token: The value of the token that was previously provided in a Token: The value of the token that was previously provided in a
Retry packet or NEW_TOKEN frame. Retry packet or NEW_TOKEN frame; see Section 8.1.
Packet Payload: The payload of the packet. Packet Payload: The payload of the packet.
In order to prevent tampering by version-unaware middleboxes, Initial In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys packets are protected with connection- and version-specific keys
(Initial keys) as described in [QUIC-TLS]. This protection does not (Initial keys) as described in [QUIC-TLS]. This protection does not
provide confidentiality or integrity against on-path attackers, but provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers. provides some level of protection against off-path attackers.
The client and server use the Initial packet type for any packet that The client and server use the Initial packet type for any packet that
skipping to change at page 108, line 48 skipping to change at page 111, line 42
the first flight of Initial packets. the first flight of Initial packets.
17.2.2.1. Abandoning Initial Packets 17.2.2.1. Abandoning Initial Packets
A client stops both sending and processing Initial packets when it A client stops both sending and processing Initial packets when it
sends its first Handshake packet. A server stops sending and sends its first Handshake packet. A server stops sending and
processing Initial packets when it receives its first Handshake processing Initial packets when it receives its first Handshake
packet. Though packets might still be in flight or awaiting packet. Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged acknowledgment, no further Initial packets need to be exchanged
beyond this point. Initial packet protection keys are discarded (see beyond this point. Initial packet protection keys are discarded (see
Section 4.11.1 of [QUIC-TLS]) along with any loss recovery and Section 4.9.1 of [QUIC-TLS]) along with any loss recovery and
congestion control state; see Section 6.4 of [QUIC-RECOVERY]. congestion control state; see Section 6.4 of [QUIC-RECOVERY].
Any data in CRYPTO frames is discarded - and no longer retransmitted Any data in CRYPTO frames is discarded - and no longer retransmitted
- when Initial keys are discarded. - when Initial keys are discarded.
17.2.3. 0-RTT 17.2.3. 0-RTT
A 0-RTT packet uses long headers with a type value of 0x1, followed A 0-RTT packet uses long headers with a type value of 0x1, followed
by the Length and Packet Number fields. The first byte contains the by the Length and Packet Number fields; see Section 17.2. The first
Reserved and Packet Number Length bits. It is used to carry "early" byte contains the Reserved and Packet Number Length bits; see
data from the client to the server as part of the first flight, prior Section 17.2. A 0-RTT packet is used to carry "early" data from the
to handshake completion. As part of the TLS handshake, the server client to the server as part of the first flight, prior to handshake
can accept or reject this early data. completion. As part of the TLS handshake, the server can accept or
reject this early data.
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its
limitations. limitations.
0-RTT Packet { 0-RTT Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 1, Long Packet Type (2) = 1,
Reserved Bits (2), Reserved Bits (2),
Packet Number Length (2), Packet Number Length (2),
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 (..), Packet Payload (..),
} }
Figure 15: 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
A client MUST NOT reset the packet number it uses for 0-RTT packets, described in Section 17.2.5.3, reusing packet numbers could
since the keys used to protect 0-RTT packets will not change as a compromise packet protection.
result of responding to a Retry packet. Sending packets with the
same packet number in that case is likely to compromise the packet
protection for all 0-RTT packets because the same key and nonce could
be used to protect different content.
A client only receives acknowledgments for its 0-RTT packets once the A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete. Consequently, a server might expect 0-RTT handshake is complete, as defined Section 4.1.1 of [QUIC-TLS].
packets to start with a packet number of 0. Therefore, in
determining the length of the packet number encoding for 0-RTT
packets, a client MUST assume that all packets up to the current
packet number are in flight, starting from a packet number of 0.
Thus, 0-RTT packets could need to use a longer packet number
encoding.
A client MUST NOT send 0-RTT packets once it starts processing 1-RTT A client MUST NOT send 0-RTT packets once it starts processing 1-RTT
packets from the server. This means that 0-RTT packets cannot packets from the server. This means that 0-RTT packets cannot
contain any response to frames from 1-RTT packets. For instance, a contain any response to frames from 1-RTT packets. For instance, a
client cannot send an ACK frame in a 0-RTT packet, because that can client cannot send an ACK frame in a 0-RTT packet, because that can
only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT
packet MUST be carried in a 1-RTT packet. packet MUST be carried in a 1-RTT packet.
A server SHOULD treat a violation of remembered limits as a A server SHOULD treat a violation of remembered limits
connection error of an appropriate type (for instance, a (Section 7.4.1) as a connection error of an appropriate type (for
FLOW_CONTROL_ERROR for exceeding stream data limits). instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).
17.2.4. Handshake Packet 17.2.4. Handshake Packet
A Handshake packet uses long headers with a type value of 0x2, A Handshake packet uses long headers with a type value of 0x2,
followed by the Length and Packet Number fields. The first byte followed by the Length and Packet Number fields; see Section 17.2.
contains the Reserved and Packet Number Length bits. It is used to The first byte contains the Reserved and Packet Number Length bits;
carry acknowledgments and cryptographic handshake messages from the see Section 17.2. It is used to carry cryptographic handshake
server and client. messages and acknowledgments from the server and client.
Handshake Packet { Handshake Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 2, Long Packet Type (2) = 2,
Reserved Bits (2), Reserved Bits (2),
Packet Number Length (2), Packet Number Length (2),
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 (..), Packet Payload (..),
} }
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 111, line 43 skipping to change at page 114, line 38
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 (shown in Figure 17) does not contain any protected A Retry packet (shown in Figure 18) does not contain any protected
fields. The value in the Unused field is selected randomly by the fields. The value in the Unused field is set to an arbitrary value
server. In addition to the fields from the long header, it contains by the server; a client MUST ignore these bits. In addition to the
these additional fields: fields from the long 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: See the Retry Packet Integrity section of Retry Integrity Tag: See the Retry Packet Integrity section of
[QUIC-TLS]. [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
skipping to change at page 112, line 37 skipping to change at page 115, line 34
packet in response to a single UDP datagram. packet in response to a single UDP datagram.
17.2.5.2. Handling a Retry Packet 17.2.5.2. Handling a Retry Packet
A client MUST accept and process at most one Retry packet for each A client MUST accept and process at most one Retry packet for each
connection attempt. After the client has received and processed an connection attempt. After the client has received and processed an
Initial or Retry packet from the server, it MUST discard any Initial or Retry packet from the server, it MUST discard any
subsequent Retry packets that it receives. subsequent Retry packets that it receives.
Clients MUST discard Retry packets that have a Retry Integrity Tag Clients MUST discard Retry packets that have a Retry Integrity Tag
that cannot be validated, see the Retry Packet Integrity section of that cannot be validated; see the Retry Packet Integrity section of
[QUIC-TLS]. This diminishes an off-path attacker's ability to inject [QUIC-TLS]. This diminishes an off-path attacker's ability to inject
a Retry packet and protects against accidental corruption of Retry a Retry packet and protects against accidental corruption of Retry
packets. A client MUST discard a Retry packet with a zero-length packets. A client MUST discard a Retry packet with a zero-length
Retry Token field. Retry Token field.
The client responds to a Retry packet with an Initial packet that The client responds to a Retry packet with an Initial packet that
includes the provided Retry Token to continue connection includes the provided Retry Token to continue connection
establishment. establishment.
A client sets the Destination Connection ID field of this Initial A client sets the Destination Connection ID field of this Initial
skipping to change at page 113, line 19 skipping to change at page 116, line 10
Token field to the token provided in the Retry. The client MUST NOT Token field to the token provided in the Retry. The client MUST NOT
change the Source Connection ID because the server could include the change the Source Connection ID because the server could include the
connection ID as part of its token validation logic; see connection ID as part of its token validation logic; see
Section 8.1.4. Section 8.1.4.
A Retry packet does not include a packet number and cannot be A Retry packet does not include a packet number and cannot be
explicitly acknowledged by a client. explicitly acknowledged by a client.
17.2.5.3. Continuing a Handshake After Retry 17.2.5.3. Continuing a Handshake After Retry
The next Initial packet from the client uses the connection ID and Subsequent Initial packets from the client include the connection ID
token values from the Retry packet; see Section 7.2. Aside from and token values from the Retry packet. The client copies the Source
this, the Initial packet sent by the client is subject to the same Connection ID field from the Retry packet to the Destination
Connection ID field and uses this value until an Initial packet with
an updated value is received; see Section 7.2. The value of the
Token field is copied to all subsequent Initial packets; see
Section 8.1.2.
Other than updating the Destination Connection ID and Token fields,
the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet. A client MUST use the same restrictions as the first Initial packet. A client MUST use the same
cryptographic handshake message it includes in this packet. A server cryptographic handshake message it included in this packet. A server
MAY treat a packet that contains a different cryptographic handshake MAY treat a packet that contains a different cryptographic handshake
message as a connection error or discard it. message as a connection error or discard it.
A client MAY attempt 0-RTT after receiving a Retry packet by sending A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server. A client 0-RTT packets to the connection ID provided by the server. A client
MUST NOT change the cryptographic handshake message it sends in MUST NOT change the cryptographic handshake message it sends in
response to receiving a Retry. response to receiving a Retry.
A client MUST NOT reset the packet number for any packet number space A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet; Section 17.2.3 contains more after processing a Retry packet. In particular, 0-RTT packets
information on this. contain confidential information that will most likely be
retransmitted on receiving a Retry packet. The keys used to protect
these new 0-RTT packets will not change as a result of responding to
a Retry packet. However, the data sent in these packets could be
different than what was sent earlier. Sending these new packets with
the same packet number is likely to compromise the packet protection
for those packets because the same key and nonce could be used to
protect different content. A server MAY abort the connection if it
detects that the client reset the packet number.
A server acknowledges the use of a Retry packet for a connection A server acknowledges the use of a Retry packet for a connection
using the retry_source_connection_id transport parameter; see using the retry_source_connection_id transport parameter; see
Section 18.2. If the server sends a Retry packet, it also Section 18.2. If the server sends a Retry packet, it also
subsequently includes the value of the Source Connection ID field subsequently includes the value of the Source Connection ID field
from the Retry packet in its retry_source_connection_id transport from the Retry packet in its retry_source_connection_id transport
parameter. parameter.
If the client received and processed a Retry packet, it MUST validate If the client received and processed a Retry packet, it MUST validate
that the retry_source_connection_id transport parameter is present that the retry_source_connection_id transport parameter is present
and correct; otherwise, it MUST validate that the transport parameter and correct; otherwise, it MUST validate that the transport parameter
is absent. A client MUST treat a failed validation as a connection is absent. A client MUST treat a failed validation as a connection
error of type PROTOCOL_VIOLATION. error of type PROTOCOL_VIOLATION.
17.3. Short Header Packets 17.3. Short Header Packets
This version of QUIC defines a single packet type which uses the This version of QUIC defines a single packet type that uses the short
short packet header. packet header.
Short Header Packet { Short Header Packet {
Header Form (1) = 0, Header Form (1) = 0,
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 (..), Packet Payload (..),
} }
Figure 18: Short Header Packet Format Figure 19: Short Header Packet Format
The short header can be used after the version and 1-RTT keys are The short header can be used after the version and 1-RTT keys are
negotiated. Packets that use the short header contain the following negotiated. Packets that use the short header contain the following
fields: 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
skipping to change at page 116, line 12 skipping to change at page 119, line 22
spin bit independently, this ensures that the spin bit signal is spin bit independently, this ensures that the spin bit signal is
disabled on approximately one in eight network paths. disabled on approximately one in eight network paths.
When the spin bit is disabled, endpoints MAY set the spin bit to any When the spin bit is disabled, endpoints MAY set the spin bit to any
value, and MUST ignore any incoming value. It is RECOMMENDED that value, and MUST ignore any incoming value. It is RECOMMENDED that
endpoints set the spin bit to a random value either chosen endpoints set the spin bit to a random value either chosen
independently for each packet or chosen independently for each independently for each packet or chosen independently for each
connection ID. connection ID.
If the spin bit is enabled for the connection, the endpoint maintains If the spin bit is enabled for the connection, the endpoint maintains
a spin value and sets the spin bit in the short header to the a spin value for each network path and sets the spin bit in the short
currently stored value when a packet with a short header is sent out. header to the currently stored value when a packet with a short
The spin value is initialized to 0 in the endpoint at connection header is sent on that path. The spin value is initialized to 0 in
start. Each endpoint also remembers the highest packet number seen the endpoint for each network path. Each endpoint also remembers the
from its peer on the connection. highest packet number seen from its peer on each path.
When a server receives a short header packet that increments the When a server receives a short header packet that increases the
highest packet number seen by the server from the client, it sets the highest packet number seen by the server from the client on a given
spin value to be equal to the spin bit in the received packet. network path, it sets the spin value for that path to be equal to the
spin bit in the received packet.
When a client receives a short header packet that increments the When a client receives a short header packet that increases the
highest packet number seen by the client from the server, it sets the highest packet number seen by the client from the server on a given
spin value to the inverse of the spin bit in the received packet. network path, it sets the spin value for that path to the inverse of
the spin bit in the received packet.
An endpoint resets its spin value to zero when sending the first An endpoint resets the spin value for a network path to zero when
packet of a given connection with a new connection ID. This reduces changing the connection ID being used on that network path.
the risk that transient spin bit state can be used to link flows
across connection migration or ID change.
With this mechanism, the server reflects the spin value received, With this mechanism, the server reflects the spin value received,
while the client 'spins' it after one RTT. On-path observers can while the client 'spins' it after one RTT. On-path observers can
measure the time between two spin bit toggle events to estimate the measure the time between two spin bit toggle events to estimate the
end-to-end RTT of a connection. end-to-end RTT of a connection.
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 19: Figure 20:
Transport Parameters { Transport Parameters {
Transport Parameter (..) ..., Transport Parameter (..) ...,
} }
Figure 19: 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 20: 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 20: 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. Transport Parameter Value field.
QUIC encodes transport parameters into a sequence of bytes, which are 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
integer values of N are reserved to exercise the requirement that integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored. These transport parameters unknown transport parameters be ignored. These transport parameters
have no semantics, and may carry arbitrary values. have no semantics, and may carry arbitrary values.
18.2. Transport Parameter Definitions 18.2. Transport Parameter Definitions
skipping to change at page 117, line 45 skipping to change at page 121, line 6
otherwise stated. otherwise stated.
The following transport parameters are defined: The following transport parameters are defined:
original_destination_connection_id (0x00): The value of the original_destination_connection_id (0x00): The value of the
Destination Connection ID field from the first Initial packet sent Destination Connection ID field from the first Initial packet sent
by the client; see Section 7.3. This transport parameter is only by the client; see Section 7.3. This transport parameter is only
sent by a server. sent by a server.
max_idle_timeout (0x01): The max idle timeout is a value in max_idle_timeout (0x01): The max idle timeout is a value in
milliseconds that is encoded as an integer; see (Section 10.2). milliseconds that is encoded as an integer; see (Section 10.1).
Idle timeout is disabled when both endpoints omit this transport Idle timeout is disabled when both endpoints omit this transport
parameter or specify a value of 0. parameter or specify a value of 0.
stateless_reset_token (0x02): A stateless reset token is used in stateless_reset_token (0x02): A stateless reset token is used in
verifying a stateless reset; see Section 10.4. This parameter is verifying a stateless reset; see Section 10.3. This parameter is
a sequence of 16 bytes. This transport parameter MUST NOT be sent a sequence of 16 bytes. This transport parameter MUST NOT be sent
by a client, but MAY be sent by a server. A server that does not by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset send this transport parameter cannot use stateless reset
(Section 10.4) for the connection ID negotiated during the (Section 10.3) for the connection ID negotiated during the
handshake. handshake.
max_udp_payload_size (0x03): The maximum UDP payload size parameter max_udp_payload_size (0x03): The maximum UDP payload size parameter
is an integer value that limits the size of UDP payloads that the is an integer value that limits the size of UDP payloads that the
endpoint is willing to receive. UDP packets with payloads larger endpoint is willing to receive. UDP datagrams with payloads
than this limit are not likely to be processed by the receiver. larger than this limit are not likely to be processed by the
receiver.
The default for this parameter is the maximum permitted UDP The default for this parameter is the maximum permitted UDP
payload of 65527. Values below 1200 are invalid. payload of 65527. Values below 1200 are invalid.
This limit does act as an additional constraint on datagram size This limit does act as an additional constraint on datagram size
in the same way as the path MTU, but it is a property of the in the same way as the path MTU, but it is a property of the
endpoint and not the path; see Section 14. It is expected that endpoint and not the path; see Section 14. It is expected that
this is the space an endpoint dedicates to holding incoming this is the space an endpoint dedicates to holding incoming
packets. packets.
skipping to change at page 119, line 24 skipping to change at page 122, line 34
(Section 19.11) of the corresponding type with the same value. (Section 19.11) of the corresponding type with the same value.
initial_max_streams_uni (0x09): The initial maximum unidirectional initial_max_streams_uni (0x09): The initial maximum unidirectional
streams parameter is an integer value that contains the initial streams parameter is an integer value that contains the initial
maximum number of unidirectional streams the peer may initiate. maximum number of unidirectional streams the peer may initiate.
If this parameter is absent or zero, the peer cannot open If this parameter is absent or zero, the peer cannot open
unidirectional streams until a MAX_STREAMS frame is sent. Setting unidirectional streams until a MAX_STREAMS frame is sent. Setting
this parameter is equivalent to sending a MAX_STREAMS this parameter is equivalent to sending a MAX_STREAMS
(Section 19.11) of the corresponding type with the same value. (Section 19.11) of the corresponding type with the same value.
ack_delay_exponent (0x0a): The ACK delay exponent is an integer ack_delay_exponent (0x0a): The acknowledgement delay exponent is an
value indicating an exponent used to decode the ACK Delay field in integer value indicating an exponent used to decode the ACK Delay
the ACK frame (Section 19.3). If this value is absent, a default field in the ACK frame (Section 19.3). If this value is absent, a
value of 3 is assumed (indicating a multiplier of 8). Values default value of 3 is assumed (indicating a multiplier of 8).
above 20 are invalid. Values above 20 are invalid.
max_ack_delay (0x0b): The maximum ACK delay is an integer value max_ack_delay (0x0b): The maximum acknowledgement delay is an
indicating the maximum amount of time in milliseconds by which the integer value indicating the maximum amount of time in
endpoint will delay sending acknowledgments. This value SHOULD milliseconds by which the endpoint will delay sending
include the receiver's expected delays in alarms firing. For acknowledgments. This value SHOULD include the receiver's
example, if a receiver sets a timer for 5ms and alarms commonly expected delays in alarms firing. For example, if a receiver sets
fire up to 1ms late, then it should send a max_ack_delay of 6ms. a timer for 5ms and alarms commonly fire up to 1ms late, then it
If this value is absent, a default of 25 milliseconds is assumed. should send a max_ack_delay of 6ms. If this value is absent, a
Values of 2^14 or greater are invalid. default of 25 milliseconds is assumed. Values of 2^14 or greater
are invalid.
disable_active_migration (0x0c): The disable active migration disable_active_migration (0x0c): The disable active migration
transport parameter is included if the endpoint does not support transport parameter is included if the endpoint does not support
active connection migration (Section 9) on the address being used active connection migration (Section 9) on the address being used
during the handshake. When a peer sets this transport parameter, during the handshake. When a peer sets this transport parameter,
an endpoint MUST NOT use a new local address when sending to the an endpoint MUST NOT use a new local address when sending to the
address that the peer used during the handshake. This transport address that the peer used during the handshake. This transport
parameter does not prohibit connection migration after a client parameter does not prohibit connection migration after a client
has acted on a preferred_address transport parameter. This has acted on a preferred_address transport parameter. This
parameter is a zero-length value. parameter is a zero-length value.
preferred_address (0x0d): The server's preferred address is used to preferred_address (0x0d): The server's preferred address is used to
effect a change in server address at the end of the handshake, as effect a change in server address at the end of the handshake, as
described in Section 9.6. The format of this transport parameter described in Section 9.6. This transport parameter is only sent
is shown in Figure 21. This transport parameter is only sent by a by a server. Servers MAY choose to only send a preferred address
server. Servers MAY choose to only send a preferred address of of one address family by sending an all-zero address and port
one address family by sending an all-zero address and port
(0.0.0.0:0 or ::.0) for the other family. IP addresses are (0.0.0.0:0 or ::.0) for the other family. IP addresses are
encoded in network byte order. encoded in network byte order.
The preferred_address transport parameter contains an address and
port for both IP version 4 and 6. The four-byte IPv4 Address
field 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 field. After address and port pairs, a Connection ID Length
field describes the length of the following Connection ID field.
Finally, a 16-byte Stateless Reset Token field includes the
stateless reset token associated with the connection ID. The
format of this transport parameter is shown in Figure 22.
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 bundled with 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
fields of a NEW_CONNECTION_ID frame (Section 19.15). A server fields of a NEW_CONNECTION_ID frame (Section 19.15). A server
that chooses a zero-length connection ID MUST NOT provide a that chooses a zero-length connection ID MUST NOT provide a
preferred address. Similarly, a server MUST NOT include a zero- preferred address. Similarly, a server MUST NOT include a zero-
length connection ID in this transport parameter. A client MUST length connection ID in this transport parameter. A client MUST
treat violation of these requirements as a connection error of treat violation of these requirements as a connection error of
type TRANSPORT_PARAMETER_ERROR. type TRANSPORT_PARAMETER_ERROR.
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),
CID Length (8), Connection ID Length (8),
Connection ID (..), Connection ID (..),
Stateless Reset Token (128), Stateless Reset Token (128),
} }
Figure 21: Preferred Address format Figure 22: Preferred Address format
active_connection_id_limit (0x0e): The active connection ID limit is active_connection_id_limit (0x0e): The active connection ID limit is
an integer value specifying the maximum number of connection IDs an integer value specifying the maximum number of connection IDs
from the peer that an endpoint is willing to store. This value from the peer that an endpoint is willing to store. This value
includes the connection ID received during the handshake, that includes the connection ID received during the handshake, that
received in the preferred_address transport parameter, and those received in the preferred_address transport parameter, and those
received in NEW_CONNECTION_ID frames. The value of the received in 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 121, line 45 skipping to change at page 125, line 11
retry_source_connection_id, or stateless_reset_token. A server MUST retry_source_connection_id, or stateless_reset_token. A server MUST
treat receipt of any of these transport parameters as a connection treat receipt of any of these transport parameters as a connection
error of type TRANSPORT_PARAMETER_ERROR. error of type TRANSPORT_PARAMETER_ERROR.
19. Frame Types and Formats 19. Frame Types and Formats
As described in Section 12.4, packets contain one or more frames. As described in Section 12.4, packets contain one or more frames.
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 Frame 19.1. PADDING Frames
The 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 client packet to the minimum required size, or to increase an initial client packet to the minimum required size, or to
provide protection against traffic analysis for protected packets. provide protection against traffic analysis for protected packets.
As shown in Figure 22, a PADDING frame has no content. That is, a PADDING frames are formatted as shown in Figure 23, which shows that
PADDING frame consists of the single byte that identifies the frame PADDING frames have no content. That is, a PADDING frame consists of
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 22: PADDING Frame Format Figure 23: PADDING Frame Format
19.2. PING Frame 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. As shown in are still alive or to check reachability to the peer.
Figure 23 a PING frame contains no content.
PING frames are formatted as shown in Figure 24, which shows that
PING frames have no content.
PING Frame { PING Frame {
Type (i) = 0x01, Type (i) = 0x01,
} }
Figure 23: 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.2.2. from timing out; see Section 10.1.2.
19.3. ACK Frames 19.3. ACK Frames
Receivers send ACK frames (types 0x02 and 0x03) to inform senders of Receivers send ACK frames (types 0x02 and 0x03) to inform senders of
packets they have received and processed. The ACK frame contains one packets they have received and processed. The ACK frame contains one
or more ACK Ranges. ACK Ranges identify acknowledged packets. If or more ACK Ranges. ACK Ranges identify acknowledged packets. If
the frame type is 0x03, ACK frames also contain the sum of QUIC the frame type is 0x03, ACK frames also contain the sum of QUIC
packets with associated ECN marks received on the connection up until packets with associated ECN marks received on the connection up until
this point. QUIC implementations MUST properly handle both types this point. QUIC implementations MUST properly handle both types
and, if they have enabled ECN for packets they send, they SHOULD use and, if they have enabled ECN for packets they send, they SHOULD use
the information in the ECN section to manage their congestion state. the information in the ECN section to manage their congestion state.
QUIC acknowledgements are irrevocable. Once acknowledged, a packet QUIC acknowledgements are irrevocable. Once acknowledged, a packet
remains acknowledged, even if it does not appear in a future ACK remains acknowledged, even if it does not appear in a future ACK
frame. This is unlike TCP SACKs ([RFC2018]). frame. This is unlike reneging for TCP SACKs ([RFC2018]).
Packets from different packet number spaces can be identified using Packets from different packet number spaces can be identified using
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.
An ACK frame is shown in Figure 24. 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 24: 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 representing the time delta in ACK Delay: A variable-length integer encoding the acknowledgement
microseconds between when this ACK was sent and when the largest delay in microseconds; see Section 13.2.5. It is decoded by
acknowledged packet, as indicated in the Largest Acknowledged multiplying the value in the field by 2 to the power of the
field, was received by this peer. The value of the ACK Delay ack_delay_exponent transport parameter sent by the sender of the
field is scaled by multiplying the encoded value by 2 to the power ACK frame; see Section 18.2. Compared to simply expressing the
of the value of the ack_delay_exponent transport parameter set by delay as an integer, this encoding allows for a larger range of
the sender of the ACK frame; see Section 18.2. Scaling in this values within the same number of bytes, at the cost of lower
fashion allows for a larger range of values with a shorter resolution.
encoding at the cost of lower resolution. Because the receiver
doesn't use the ACK Delay for Initial and Handshake packets, a
sender SHOULD send a value of 0.
ACK Range Count: A variable-length integer specifying the number of ACK Range Count: A variable-length integer specifying the number of
Gap and ACK Range fields in the frame. Gap and ACK Range fields in the frame.
First ACK Range: A variable-length integer indicating the number of First ACK Range: A variable-length integer indicating the number of
contiguous packets preceding the Largest Acknowledged that are contiguous packets preceding the Largest Acknowledged that are
being acknowledged. The First ACK Range is encoded as an ACK being acknowledged. The First ACK Range is encoded as an ACK
Range; see Section 19.3.1 starting from the Largest Acknowledged. Range; see Section 19.3.1 starting from the Largest Acknowledged.
That is, the smallest packet acknowledged in the range is That is, the smallest packet acknowledged in the range is
determined by subtracting the First ACK Range value from the determined by subtracting the First ACK Range value from the
Largest Acknowledged. Largest Acknowledged.
ACK Ranges: Contains additional ranges of packets which are ACK Ranges: Contains additional ranges of packets that are
alternately not acknowledged (Gap) and acknowledged (ACK Range); alternately not acknowledged (Gap) and acknowledged (ACK Range);
see Section 19.3.1. see Section 19.3.1.
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 values in Each ACK Range consists of alternating Gap and ACK Range values in
descending packet number order. ACK Ranges can be repeated. The descending packet number order. ACK Ranges can be repeated. The
number of Gap and ACK Range values is determined by the ACK Range number of Gap and ACK Range values is determined by the ACK Range
Count field; one of each value is present for each value in the ACK Count field; one of each value is present for each value in the ACK
Range Count field. Range Count field.
ACK Ranges are structured as shown in Figure 25. 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 25: 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 125, line 41 skipping to change at page 128, line 50
If any computed packet number is negative, an endpoint MUST generate If any computed packet number is negative, an endpoint MUST generate
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 (that is, type 0x03) to The ACK frame uses the least significant bit (that is, type 0x03) to
indicate ECN feedback and report receipt of QUIC packets with indicate ECN feedback and report receipt of QUIC packets with
associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP
header. ECN Counts are only present when the ACK frame type is 0x03. header. ECN Counts are only present when the ACK frame type is 0x03.
ECN Counts are only parsed when the ACK frame type is 0x03. There When present, there are 3 ECN counts, as shown in Figure 27.
are 3 ECN counts, as shown in Figure 26.
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 26: 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.
CE Count: A variable-length integer representing the total number of CE Count: A variable-length integer representing the total number of
packets received with the CE codepoint in the packet number space packets received with the CE codepoint in the packet number space
of the ACK frame. of the ACK frame.
ECN counts are maintained separately for each packet number space. ECN counts are maintained separately for each packet number space.
19.4. RESET_STREAM Frame 19.4. RESET_STREAM Frames
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
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.
The RESET_STREAM frame is shown in Figure 27. 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 27: 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.1) containing the application protocol error code (see Section 20.2)
which indicates why the stream is being closed. that indicates why the stream is being closed.
Final Size: A variable-length integer indicating the final size of Final Size: A variable-length integer indicating the final size of
the stream by the RESET_STREAM sender, in unit of bytes. the stream by the RESET_STREAM sender, in unit of bytes; see
Section 4.4.
19.5. STOP_SENDING Frame 19.5. STOP_SENDING Frames
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at 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.1. Receiving a STOP_SENDING frame for a Known states; see Section 3.1. 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.
The STOP_SENDING frame is shown in Figure 28. 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 28: 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.1. the stream; see Section 20.2.
19.6. CRYPTO Frame 19.6. CRYPTO Frames
The 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.
The CRYPTO frame is shown in Figure 29. 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 29: 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 128, line 39 skipping to change at page 132, line 5
The largest offset delivered on a stream - the sum of the offset and The largest offset delivered on a stream - the sum of the offset and
data length - cannot exceed 2^62-1. Receipt of a frame that exceeds data length - cannot exceed 2^62-1. Receipt of a frame that exceeds
this limit MUST be treated as a connection error of type this limit MUST be treated as a connection error of type
FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED.
Unlike STREAM frames, which include a Stream ID indicating to which Unlike STREAM frames, which include a Stream ID indicating to which
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 Frame 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.
The NEW_TOKEN frame is shown in Figure 30. 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 30: 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 may use with a future Initial Token: An opaque blob that the client may use with a future Initial
packet. The token MUST NOT be empty. An endpoint MUST treat packet. The token MUST NOT be empty. An endpoint MUST treat
receipt of a NEW_TOKEN frame with an empty Token field as a receipt of a NEW_TOKEN frame with an empty Token field as a
connection error of type FRAME_ENCODING_ERROR. connection error of type FRAME_ENCODING_ERROR.
skipping to change at page 129, line 29 skipping to change at page 132, line 44
duplicate values, which might be used to link connection attempts; duplicate values, which might be used to link connection attempts;
see Section 8.1.3. see Section 8.1.3.
Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt
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
STREAM frame takes the form 0b00001XXX (or the set of values from STREAM frame Type field takes the form 0b00001XXX (or the set of
0x08 to 0x0f). The value of the three low-order bits of the frame values from 0x08 to 0x0f). The three low-order bits of the frame
type determines the fields that are present in the frame. type determine the fields that are present in the frame:
* 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).
* 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
skipping to change at page 130, line 10 skipping to change at page 133, line 26
* The FIN bit (0x01) of the frame type is set only on frames that * The FIN bit (0x01) of the frame type is set only on frames that
contain the final size of the stream. Setting this bit indicates contain the final size of the stream. Setting this bit indicates
that the frame marks the end of the stream. that the frame marks the end of the stream.
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.
The STREAM frames are shown in Figure 31. 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 31: 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 131, line 5 skipping to change at page 134, line 17
When a Stream Data field has a length of 0, the offset in the STREAM When a Stream Data field has a length of 0, the offset in the STREAM
frame is the offset of the next byte that would be sent. frame is the offset of the next byte that would be sent.
The first byte in the stream has an offset of 0. The largest offset The first byte in the stream has an offset of 0. The largest offset
delivered on a stream - the sum of the offset and data length - delivered on a stream - the sum of the offset and data length -
cannot exceed 2^62-1, as it is not possible to provide flow control cannot exceed 2^62-1, as it is not possible to provide flow control
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 Frame 19.9. MAX_DATA Frames
The 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.
The MAX_DATA frame is shown in Figure 32. 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 32: MAX_DATA Frame Format Figure 33: MAX_DATA Frame Format
MAX_DATA frames contain the following fields: 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 largest received offsets on all streams - including streams in the largest received offsets on all streams - including streams in
terminal states - MUST NOT exceed the value advertised by a receiver. terminal states - MUST NOT exceed the value advertised by a receiver.
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
error if it receives more data than the maximum data value that it error if it receives more data than the maximum data value that it
has sent, unless this is a result of a change in the initial limits; has sent. This includes violations of remembered limits in Early
see Section 7.4.1. Data; see Section 7.4.1.
19.10. MAX_STREAM_DATA Frame 19.10. MAX_STREAM_DATA Frames
The MAX_STREAM_DATA frame (type=0x11) is used in flow control to A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform
inform a peer of the maximum amount of data that can be sent on a a peer of the maximum amount of data that can be sent on a stream.
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.1. Receiving a MAX_STREAM_DATA frame for a locally- see Section 3.1. 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.
The MAX_STREAM_DATA frame is shown in Figure 33. 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 33: 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 stream that is affected encoded as a Stream ID: The stream ID of the stream that is affected 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 132, line 33 skipping to change at page 135, line 42
largest received offset of data that is sent or received on the largest received offset of data that is sent or received on the
stream. Loss or reordering can mean that the largest received offset stream. Loss or reordering can mean that the largest received offset
on a stream can be greater than the total size of data received on on a stream can be greater than the total size of data received on
that stream. Receiving STREAM frames might not increase the largest that stream. Receiving STREAM frames might not increase the largest
received offset. received offset.
The data sent on a stream MUST NOT exceed the largest maximum stream The data sent on a stream MUST NOT exceed the largest maximum stream
data value advertised by the receiver. An endpoint MUST terminate a data value advertised by the receiver. An endpoint MUST terminate a
connection with a FLOW_CONTROL_ERROR error if it receives more data connection with a FLOW_CONTROL_ERROR error if it receives more data
than the largest maximum stream data that it has sent for the than the largest maximum stream data that it has sent for the
affected stream, unless this is a result of a change in the initial affected stream. This includes violations of remembered limits in
limits; see Section 7.4.1. Early Data; see Section 7.4.1.
19.11. MAX_STREAMS Frames 19.11. MAX_STREAMS Frames
The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the A MAX_STREAMS frame (type=0x12 or 0x13) inform 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.
The MAX_STREAMS frames are shown in Figure 34; 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 34: MAX_STREAMS Frame Format Figure 35: MAX_STREAMS Frame Format
MAX_STREAMS frames contain the following fields: 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 FRAME_ENCODING_ERROR. as a FRAME_ENCODING_ERROR.
Loss or reordering can cause a MAX_STREAMS frame to be received which Loss or reordering can cause a MAX_STREAMS frame to be received that
states a lower stream limit than an endpoint has previously received. state a lower stream limit than an endpoint has previously received.
MAX_STREAMS frames which do not increase the stream limit MUST be MAX_STREAMS frames that do not increase the stream limit MUST be
ignored. ignored.
An endpoint MUST NOT open more streams than permitted by the current An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer. For instance, a server that receives a stream limit set by its peer. For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7, unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15. An endpoint MUST terminate a connection and 11, but not stream 15. An endpoint MUST terminate a connection
with a STREAM_LIMIT_ERROR error if a peer opens more streams than was with a STREAM_LIMIT_ERROR error if a peer opens more streams than was
permitted. permitted. This includes violations of remembered limits in Early
Data; see Section 7.4.1.
Note that these frames (and the corresponding transport parameters) Note that these frames (and the corresponding transport parameters)
do not describe the number of streams that can be opened do not describe the number of streams that can be opened
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 Frame 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 due to connection-level flow control; to send data, but is unable to do so due to connection-level flow
see Section 4. DATA_BLOCKED frames can be used as input to tuning of control; see Section 4. DATA_BLOCKED frames can be used as input to
flow control algorithms; see Section 4.2. tuning of flow control algorithms; see Section 4.2.
The DATA_BLOCKED frame is shown in Figure 35. 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 35: DATA_BLOCKED Frame Format Figure 36: DATA_BLOCKED Frame Format
DATA_BLOCKED frames contain the following fields: 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 Frame 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 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.
The STREAM_DATA_BLOCKED frame is shown in Figure 36. 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 36: 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 which is Stream ID: A variable-length integer indicating the stream that is
flow control blocked. 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
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
it wishes to open a stream, but is unable to due to the maximum it wishes to open a stream, but is unable to 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 indicates stream limit, and a STREAMS_BLOCKED frame of type 0x17 is used to
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.
The STREAMS_BLOCKED frames are shown in Figure 37. 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 37: STREAMS_BLOCKED Frame Format Figure 38: STREAMS_BLOCKED Frame Format
STREAMS_BLOCKED frames contain the following fields: 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 STREAM_LIMIT_ERROR or a stream ID MUST be treated as a STREAM_LIMIT_ERROR or a
FRAME_ENCODING_ERROR. FRAME_ENCODING_ERROR.
19.15. NEW_CONNECTION_ID Frame 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.
The NEW_CONNECTION_ID frame is shown in Figure 38. 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 38: 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. See Section 5.1.1. by the sender, encoded as a variable-length integer; see
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.
Length: An 8-bit unsigned integer containing the length of the Length: An 8-bit unsigned integer containing the length of the
connection ID. Values less than 1 and greater than 20 are invalid connection ID. Values less than 1 and greater than 20 are invalid
and MUST be treated as a connection error of type and MUST be treated as a connection error of type
FRAME_ENCODING_ERROR. FRAME_ENCODING_ERROR.
Connection ID: A connection ID of the specified length. Connection ID: A connection ID of the specified length.
Stateless Reset Token: A 128-bit value that will be used for a Stateless Reset Token: A 128-bit value that will be used for a
stateless reset when the associated connection ID is used; see stateless reset when the associated connection ID is used; see
Section 10.4. Section 10.3.
An endpoint MUST NOT send this frame if it currently requires that An endpoint MUST NOT send this frame if it currently requires that
its peer send packets with a zero-length Destination Connection ID. its peer send packets with a zero-length Destination Connection ID.
Changing the length of a connection ID to or from zero-length makes Changing the length of a connection ID to or from zero-length makes
it difficult to identify when the value of the connection ID changed. it difficult to identify when the value of the connection ID changed.
An endpoint that is sending packets with a zero-length Destination An endpoint that is sending packets with a zero-length Destination
Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
Transmission errors, timeouts and retransmissions might cause the Transmission errors, timeouts and retransmissions might cause the
same NEW_CONNECTION_ID frame to be received multiple times. Receipt same NEW_CONNECTION_ID frame to be received multiple times. Receipt
of the same frame multiple times MUST NOT be treated as a connection of the same frame multiple times MUST NOT be treated as a connection
error. A receiver can use the sequence number supplied in the error. A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to identify new connection IDs from old ones. NEW_CONNECTION_ID frame to handle receiving the same
NEW_CONNECTION_ID frame multiple times.
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
previously issued connection ID with a different Stateless Reset previously issued connection ID with a different Stateless Reset
Token or a different sequence number, or if a sequence number is used Token or a different sequence number, or if a sequence number is used
for different connection IDs, the endpoint MAY treat that receipt as for different connection IDs, the endpoint MAY treat that receipt as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
The Retire Prior To field counts connection IDs established during The Retire Prior To field counts connection IDs established during
connection setup and the preferred_address transport parameter; see connection setup and the preferred_address transport parameter; see
Section 5.1.2. The Retire Prior To field MUST be less than or equal Section 5.1.2. The Retire Prior To field MUST be less than or equal
skipping to change at page 136, line 43 skipping to change at page 140, line 11
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver in subsequent NEW_CONNECTION_ID frames have no effect. A receiver
MUST ignore any Retire Prior To fields that do not increase the MUST ignore any Retire Prior To fields that do not increase the
largest received Retire Prior To value. largest received Retire Prior To value.
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence An endpoint that receives a NEW_CONNECTION_ID frame with a sequence
number smaller than the Retire Prior To field of a previously number smaller than the Retire Prior To field of a previously
received NEW_CONNECTION_ID frame MUST send a corresponding received NEW_CONNECTION_ID frame MUST send a corresponding
RETIRE_CONNECTION_ID frame that retires the newly received connection RETIRE_CONNECTION_ID frame that retires the newly received connection
ID, unless it has already done so for that sequence number. ID, unless it has already done so for that sequence number.
19.16. RETIRE_CONNECTION_ID Frame 19.16. RETIRE_CONNECTION_ID Frames
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
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 may include the connection ID provided during the by its peer. This may include 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.
The RETIRE_CONNECTION_ID frame is shown in Figure 39. 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 39: RETIRE_CONNECTION_ID Frame Format Figure 40: RETIRE_CONNECTION_ID Frame Format
RETIRE_CONNECTION_ID frames contain the following fields: 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.
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
NOT refer to the Destination Connection ID field of the packet in NOT refer to the Destination Connection ID field of the packet in
which the frame is contained. The peer MAY treat this as a which the frame is contained. The peer MAY treat this as a
connection error of type FRAME_ENCODING_ERROR. connection error of type PROTOCOL_VIOLATION.
An endpoint cannot send this frame if it was provided with a zero- An endpoint cannot send this frame if it was provided with a zero-
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 Frame 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.
The PATH_CHALLENGE frame is shown in Figure 40. 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 40: PATH_CHALLENGE Frame Format Figure 41: PATH_CHALLENGE Frame Format
PATH_CHALLENGE frames contain the following fields: PATH_CHALLENGE frames contain the following field:
Data: This 8-byte field contains arbitrary data. Data: This 8-byte field contains arbitrary data.
A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that
sufficient to ensure that it is easier to receive the packet than it it is easier to receive the packet than it is to guess the value
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. (Section 19.18) containing the same Data.
19.18. PATH_RESPONSE Frame 19.18. PATH_RESPONSE Frames
The 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. Its format, shown in Figure 41 is identical to PATH_CHALLENGE frame.
the PATH_CHALLENGE frame (Section 19.17).
PATH_RESPONSE frames are formatted as shown in Figure 42, which is
identical to the PATH_CHALLENGE frame (Section 19.17).
PATH_RESPONSE Frame { PATH_RESPONSE Frame {
Type (i) = 0x1b, Type (i) = 0x1b,
Data (64), Data (64),
} }
Figure 41: 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 with a frame type of 0x1c is used to signal errors CONNECTION_CLOSE with a frame 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 haven't 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.
The CONNECTION_CLOSE frames are shown in Figure 42. 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 42: 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 error code which indicates the Error Code: A variable-length integer error code that indicates the
reason for closing this connection. A CONNECTION_CLOSE frame of reason for closing this connection. A CONNECTION_CLOSE frame of
type 0x1c uses codes from the space defined in Section 20. A type 0x1c uses codes from the space defined in Section 20.1. A
CONNECTION_CLOSE frame of type 0x1d uses codes from the CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see Section 20.1. application protocol error code space; 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
that triggered the error. A value of 0 (equivalent to the mention that triggered the error. A value of 0 (equivalent to the mention
of the PADDING frame) is used when the frame type is unknown. The of the PADDING frame) is used when the frame type is unknown. The
application-specific variant of CONNECTION_CLOSE (type 0x1d) does application-specific variant of CONNECTION_CLOSE (type 0x1d) does
not include this field. not include this field.
Reason Phrase Length: A variable-length integer specifying the Reason Phrase Length: A variable-length integer specifying the
length of the reason phrase in bytes. Because a CONNECTION_CLOSE length of the reason phrase in bytes. Because a CONNECTION_CLOSE
frame cannot be split between packets, any limits on packet size frame cannot be split between packets, any limits on packet size
will also limit the space available for a reason phrase. will also limit the space available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses to not was closed. This can be zero length if the sender chooses not to
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
The application-specific variant of CONNECTION_CLOSE (type 0x1d) can The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
only be sent using 0-RTT or 1-RTT packets; see Section 4 of only be sent using 0-RTT or 1-RTT packets; see Section 4 of
[QUIC-TLS]. When an application wishes to abandon a connection [QUIC-TLS]. When an application wishes to abandon a connection
during the handshake, an endpoint can send a CONNECTION_CLOSE frame during the handshake, an endpoint can send a CONNECTION_CLOSE frame
(type 0x1c) with an error code of APPLICATION_ERROR in an Initial or (type 0x1c) with an error code of APPLICATION_ERROR in an Initial or
a Handshake packet. a Handshake packet.
19.20. HANDSHAKE_DONE frame 19.20. HANDSHAKE_DONE Frames
The server uses the 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. As shown in Figure 43, confirmation of the handshake to the client.
a HANDSHAKE_DONE frame has no content.
HANDSHAKE_DONE frames are formatted as shown in Figure 44, which
shows that HANDSHAKE_DONE frames have no content.
HANDSHAKE_DONE Frame { HANDSHAKE_DONE Frame {
Type (i) = 0x1e, Type (i) = 0x1e,
} }
Figure 43: 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
successfully process a packet. This allows for efficient encoding of successfully process a packet. This allows for efficient encoding of
frames, but it means that an endpoint cannot send a frame of a type frames, but it means that an endpoint cannot send a frame of a type
that is unknown to its peer. that is unknown to its peer.
An extension to QUIC that wishes to use a new type of frame MUST An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame. An first ensure that a peer is able to understand the frame. An
endpoint can use a transport parameter to signal its willingness to endpoint can use a transport parameter to signal its willingness to
receive one or more extension frame types with the one transport receive extension frame types. One transport parameter can indicate
parameter. support for one or more extension frame types.
Extensions that modify or replace core protocol functionality Extensions that modify or replace core protocol functionality
(including frame types) will be difficult to combine with other (including frame types) will be difficult to combine with other
extensions which modify or replace the same functionality unless the extensions that modify or replace the same functionality unless the
behavior of the combination is explicitly defined. Such extensions behavior of the combination is explicitly defined. Such extensions
SHOULD define their interaction with previously-defined extensions SHOULD define their interaction with previously-defined extensions
modifying the same protocol components. modifying the same protocol components.
Extension frames MUST be congestion controlled and MUST cause an ACK Extension frames MUST be congestion controlled and MUST cause an ACK
frame to be sent. The exception is extension frames that replace or frame to be sent. The exception is extension frames that replace or
supplement the ACK frame. Extension frames are not included in flow supplement the ACK frame. Extension frames are not included in flow
control unless specified in the extension. control unless specified in the extension.
An IANA registry is used to manage the assignment of frame types; see An IANA registry is used to manage the assignment of frame types; see
Section 22.3. Section 22.3.
20. Transport Error Codes 20. Error Codes
QUIC error codes are 62-bit unsigned integers. QUIC transport error codes and application error codes are 62-bit
unsigned integers.
20.1. Transport Error Codes
This section lists the defined QUIC transport error codes that may be This section lists the defined QUIC transport error codes that may be
used in a CONNECTION_CLOSE frame. These errors apply to the entire used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors
connection. apply to the entire connection.
NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to
signal that the connection is being closed abruptly in the absence signal that the connection is being closed abruptly in the absence
of any error. of any error.
INTERNAL_ERROR (0x1): The endpoint encountered an internal error and INTERNAL_ERROR (0x1): The endpoint encountered an internal error and
cannot continue with the connection. cannot continue with the connection.
CONNECTION_REFUSED (0x2): The server refused to accept a new CONNECTION_REFUSED (0x2): The server refused to accept a new
connection. connection.
skipping to change at page 141, line 40 skipping to change at page 145, line 17
TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport
parameters that were badly formatted, included an invalid value, parameters that were badly formatted, included an invalid value,
was absent even though it is mandatory, was present though it is was absent even though it is mandatory, was present though it is
forbidden, or is otherwise in error. forbidden, or is otherwise in error.
CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs CONNECTION_ID_LIMIT_ERROR (0x9): The number of connection IDs
provided by the peer exceeds the advertised provided by the peer exceeds the advertised
active_connection_id_limit. active_connection_id_limit.
PROTOCOL_VIOLATION (0xA): An endpoint detected an error with PROTOCOL_VIOLATION (0xa): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
INVALID_TOKEN (0xB): A server received a Retry Token in a client INVALID_TOKEN (0xb): A server received a client Initial that
Initial that is invalid. contained an invalid Token field.
APPLICATION_ERROR (0xC): The application or application protocol APPLICATION_ERROR (0xc): The application or application protocol
caused the connection to be closed. caused the connection to be closed.
CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in CRYPTO_BUFFER_EXCEEDED (0xd): An endpoint has received more data in
CRYPTO frames than it can buffer. CRYPTO frames than it can buffer.
AEAD_LIMIT_REACHED (0xe): An endpoint has reached the
confidentiality or integrity limit for the AEAD algorithm used by
the given connection.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.4 for details of registering new error codes. See Section 22.4 for details of registering new error codes.
In defining these error codes, several principles are applied. Error In defining these error codes, several principles are applied. Error
conditions that might require specific action on the part of a conditions that might require specific action on the part of a
recipient are given unique codes. Errors that represent common recipient are given unique codes. Errors that represent common
conditions are given specific codes. Absent either of these conditions are given specific codes. Absent either of these
conditions, error codes are used to identify a general function of conditions, error codes are used to identify a general function of
the stack, like flow control or transport parameter handling. the stack, like flow control or transport parameter handling.
Finally, generic errors are provided for conditions where Finally, generic errors are provided for conditions where
implementations are unable or unwilling to use more specific codes. implementations are unable or unwilling to use more specific codes.
20.1. Application Protocol Error Codes 20.2. Application Protocol Error Codes
Application protocol error codes are 62-bit unsigned integers, but The management of application error codes is left to application
the management of application error codes is left to application
protocols. Application protocol error codes are used for the protocols. Application protocol error codes are used for the
RESET_STREAM frame (Section 19.4), the STOP_SENDING frame RESET_STREAM frame (Section 19.4), the STOP_SENDING frame
(Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d
(Section 19.19). (Section 19.19).
21. Security Considerations 21. Security Considerations
21.1. Handshake Denial of Service 21.1. Handshake Denial of Service
As an encrypted and authenticated transport QUIC provides a range of As an encrypted and authenticated transport QUIC provides a range of
protections against denial of service. Once the cryptographic protections against denial of service. Once the cryptographic
handshake is complete, QUIC endpoints discard most packets that are handshake is complete, QUIC endpoints discard most packets that are
not authenticated, greatly limiting the ability of an attacker to not authenticated, greatly limiting the ability of an attacker to
interfere with existing connections. interfere with existing connections.
Once a connection is established QUIC endpoints might accept some Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see Section 14.2.1), but the use of unauthenticated ICMP packets (see Section 14.2.1), but the use of
these packets is extremely limited. The only other type of packet these packets is extremely limited. The only other type of packet
that an endpoint might accept is a stateless reset (Section 10.4) that an endpoint might accept is a stateless reset (Section 10.3),
which relies on the token being kept secret until it is used. which relies on the token being kept secret until it is used.
During the creation of a connection, QUIC only provides protection During the creation of a connection, QUIC only provides protection
against attack from off the network path. All QUIC packets contain against attack from off the network path. All QUIC packets contain
proof that the recipient saw a preceding packet from its peer. proof that the recipient saw a preceding packet from its peer.
Addresses cannot change during the handshake, so endpoints can Addresses cannot change during the handshake, so endpoints can
discard packets that are received on a different network path. discard packets that are received on a different network path.
The Source and Destination Connection ID fields are the primary means The Source and Destination Connection ID fields are the primary means
skipping to change at page 144, line 12 skipping to change at page 147, line 50
Servers SHOULD provide mitigations for this attack by limiting the Servers SHOULD provide mitigations for this attack by limiting the
usage and lifetime of address validation tokens; see Section 8.1.3. usage and lifetime of address validation tokens; see Section 8.1.3.
21.3. Optimistic ACK Attack 21.3. Optimistic ACK Attack
An endpoint that acknowledges packets it has not received might cause An endpoint that acknowledges packets it has not received might cause
a congestion controller to permit sending at rates beyond what the a congestion controller to permit sending at rates beyond what the
network supports. An endpoint MAY skip packet numbers when sending network supports. An endpoint MAY skip packet numbers when sending
packets to detect this behavior. An endpoint can then immediately packets to detect this behavior. An endpoint can then immediately
close the connection with a connection error of type close the connection with a connection error of type
PROTOCOL_VIOLATION; see Section 10.3. PROTOCOL_VIOLATION; see Section 10.2.
21.4. Slowloris Attacks 21.4. Request Forgery Attacks
The attacks commonly known as Slowloris [SLOWLORIS] try to keep many A request forgery attack occurs where an endpoint causes its peer to
connections to the target endpoint open and hold them open as long as issue a request towards a victim, with the request controlled by the
possible. These attacks can be executed against a QUIC endpoint by endpoint. Request forgery attacks aim to provide an attacker with
generating the minimum amount of activity necessary to avoid being access to capabilities of its peer that might otherwise be
closed for inactivity. This might involve sending small amounts of unavailable to the attacker. For a networking protocol, a request
data, gradually opening flow control windows in order to control the forgery attack is often used to exploit any implicit authorization
sender rate, or manufacturing ACK frames that simulate a high loss conferred on the peer by the victim due to the peer's location in the
rate. network.
For request forgery to be effective, an attacker needs to be able to
influence what packets the peer sends and where these packets are
sent. If an attacker can target a vulnerable service with a
controlled payload, that service might perform actions that are
attributed to the attacker's peer, but decided by the attacker.
For example, cross-site request forgery [CSRF] exploits on the Web
cause a client to issue requests that include authorization cookies
[COOKIE], allowing one site access to information and actions that
are intended to be restricted to a different site.
As QUIC runs over UDP, the primary attack modality of concern is one
where an attacker can select the address to which its peer sends UDP
datagrams and can control some of the unprotected content of those
packets. As much of the data sent by QUIC endpoints is protected,
this includes control over ciphertext. An attack is successful if an
attacker can cause a peer to send a UDP datagram to a host that will
perform some action based on content in the datagram.
This section discusses ways in which QUIC might be used for request
forgery attacks.
This section also describes limited countermeasures that can be
implemented by QUIC endpoints. These mitigations can be employed
unilaterally by a QUIC implementation or deployment, without
potential targets for request forgery attacks taking action. However
these countermeasures could be insufficient if UDP-based services do
not properly authorize requests.
21.4.1. Control Options for Endpoints
QUIC offers some opportunities for an attacker to influence or
control where its peer sends UDP datagrams:
* initial connection establishment (Section 7), where a server is
able to choose where a client sends datagrams, for example by
populating DNS records;
* preferred addresses (Section 9.6), where a server is able to
choose where a client sends datagrams; and
* spoofed connection migrations (Section 9.3.1), where a client is
able to use source address spoofing to select where a server sends
subsequent datagrams.
In all three cases, the attacker can cause its peer to send datagrams
to a victim that might not understand QUIC. That is, these packets
are sent by the peer prior to address validation; see Section 8.
Outside of the encrypted portion of packets, QUIC offers an endpoint
several options for controlling the content of UDP datagrams that its
peer sends. The Destination Connection ID field offers direct
control over bytes that appear early in packets sent by the peer; see
Section 5.1. The Token field in Initial packets offers a server
control over other bytes of Initial packets; see Section 17.2.2.
There are no measures in this version of QUIC to prevent indirect
control over the encrypted portions of packets. It is necessary to
assume that endpoints are able to control the contents of frames that
a peer sends, especially those frames that convey application data,
such as STREAM frames. Though this depends to some degree on details
of the application protocol, some control is possible in many
protocol usage contexts. As the attacker has access to packet
protection keys, they are likely to be capable of predicting how a
peer will encrypt future packets. Successful control over datagram
content then only requires that the attacker be able to predict the
packet number and placement of frames in packets with some amount of
reliability.
This section assumes that limiting control over datagram content is
not feasible. The focus of the mitigations in subsequent sections is
on limiting the ways in which datagrams that are sent prior to
address validation can be used for request forgery.
21.4.2. Request Forgery with Client Initial Packets
An attacker acting as a server can choose the IP address and port on
which it advertises its availability, so Initial packets from clients
are assumed to be available for use in this sort of attack. The
address validation implicit in the handshake ensures that - for a new
connection - a client will not send other types of packet to a
destination that does not understand QUIC or is not willing to accept
a QUIC connection.
Initial packet protection (Section 5.2 of [QUIC-TLS]) makes it
difficult for servers to control the content of Initial packets sent
by clients. A client choosing an unpredictable Destination
Connection ID ensures that servers are unable to control any of the
encrypted portion of Initial packets from clients.
However, the Token field is open to server control and does allow a
server to use clients to mount request forgery attacks. Use of
tokens provided with the NEW_TOKEN frame (Section 8.1.3) offers the
only option for request forgery during connection establishment.
Clients however are not obligated to use the NEW_TOKEN frame.
Request forgery attacks that rely on the Token field can be avoided
if clients send an empty Token field when the server address has
changed from when the NEW_TOKEN frame was received.
Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN
frame from one server address in an Initial packet that is sent to a
different server address. As strict equality might reduce the
utility of this mechanism, clients MAY employ heuristics that result
in different server addresses being treated as equivalent, such as
treating addresses with a shared prefix of sufficient length as being
functionally equivalent (for instance, /24 in IPv4 or /56 in IPv6).
In addition, clients SHOULD treat a preferred address that is
successfully validated as equivalent to the address on which the
connection was made; see Section 9.6.
Sending a Retry packet (Section 17.2.5) offers a server the option to
change the Token field. After sending a Retry, the server can also
control the Destination Connection ID field of subsequent Initial
packets from the client. This also might allow indirect control over
the encrypted content of Initial packets. However, the exchange of a
Retry packet validates the server's address, thereby preventing the
use of subsequent Initial packets for request forgery.
21.4.3. Request Forgery with Preferred Addresses
Servers can specify a preferred address, which clients then migrate
to after confirming the handshake; see Section 9.6. The Destination
Connection ID field of packets that the client sends to a preferred
address can be used for request forgery.
A client MUST NOT send non-probing frames to a preferred address
prior to validating that address; see Section 8. This greatly
reduces the options that a server has to control the encrypted
portion of datagrams.
This document does not offer any additional countermeasures that are
specific to use of preferred addresses and can be implemented by
endpoints. The generic measures described in Section 21.4.5 could be
used as further mitigation.
21.4.4. Request Forgery with Spoofed Migration
Clients are able to present a spoofed source address as part of an
apparent connection migration to cause a server to send datagrams to
that address.
The Destination Connection ID field in any packets that a server
subsequently sends to this spoofed address can be used for request
forgery. A client might also be able to influence the ciphertext.
A server that only sends probing packets (Section 9.1) to an address
prior to address validation provides an attacker with only limited
control over the encrypted portion of datagrams. However,
particularly for NAT rebinding, this can adversely affect
performance. If the server sends frames carrying application data,
an attacker might be able to control most of the content of
datagrams.
This document does not offer specific countermeasures that can be
implemented by endpoints aside from the generic measures described in
Section 21.4.5. However, countermeasures for address spoofing at the
network level, in particular ingress filtering [BCP38], are
especially effective against attacks that use spoofing and originate
from an external network.
21.4.5. Generic Request Forgery Countermeasures
The most effective defense against request forgery attacks is to
modify vulnerable services to use strong authentication. However,
this is not always something that is within the control of a QUIC
deployment. This section outlines some others steps that QUIC
endpoints could take unilaterally. These additional steps are all
discretionary as, depending on circumstances, they could interfere
with or prevent legitimate uses.
Services offered over loopback interfaces (that is, the IPv6 address
::1 or the IPv4 address 127.0.0.1) often lack proper authentication.
Endpoints MAY prevent connection attempts or migration to a loopback
address. Endpoints SHOULD NOT allow connections or migration to a
loopback address if the same service was previously available at a
different interface or if the address was provided by a service at a
non-loopback address. Endpoints that depend on these capabilities
could offer an option to disable these protections.
Similarly, endpoints could regard a change in address to link-local
address [RFC4291] or an address in a private use range [RFC1918] from
a global, unique-local [RFC4193], or non-private address as a
potential attempt at request forgery. Endpoints could refuse to use
these addresses entirely, but that carries a significant risk of
interfering with legitimate uses. Endpoints SHOULD NOT refuse to use
an address unless they have specific knowledge about the network
indicating that sending datagrams to unvalidated addresses in a given
range is not safe.
Endpoints MAY choose to reduce the risk of request forgery by not
including values from NEW_TOKEN frames in Initial packets or by only
sending probing frames in packets prior to completing address
validation. Note that this does not prevent an attacker from using
the Destination Connection ID field for an attack.
Endpoints are not expected to have specific information about the
location of servers that could be vulnerable targets of a request
forgery attack. However, it might be possible over time to identify
specific UDP ports that are common targets of attacks or particular
patterns in datagrams that are used for attacks. Endpoints MAY
choose to avoid sending datagrams to these ports or not send
datagrams that match these patterns prior to validating the
destination address. Endpoints MAY retire connection IDs containing
patterns known to be problematic without using them.
Note: Modifying endpoints to apply these protections is more
efficient than deploying network-based protections, as endpoints
do not need to perform any additional processing when sending to
an address that has been validated.
21.5. Slowloris Attacks
The attacks commonly known as Slowloris ([SLOWLORIS]) try to keep
many connections to the target endpoint open and hold them open as
long as possible. These attacks can be executed against a QUIC
endpoint by generating the minimum amount of activity necessary to
avoid being closed for inactivity. This might involve sending small
amounts of data, gradually opening flow control windows in order to
control the sender rate, or manufacturing ACK frames that simulate a
high loss rate.
QUIC deployments SHOULD provide mitigations for the Slowloris QUIC deployments SHOULD provide mitigations for the Slowloris
attacks, such as increasing the maximum number of clients the server attacks, such as increasing the maximum number of clients the server
will allow, limiting the number of connections a single IP address is will allow, limiting the number of connections a single IP address is
allowed to make, imposing restrictions on the minimum transfer speed allowed to make, imposing restrictions on the minimum transfer speed
a connection is allowed to have, and restricting the length of time a connection is allowed to have, and restricting the length of time
an endpoint is allowed to stay connected. an endpoint is allowed to stay connected.
21.5. Stream Fragmentation and Reassembly Attacks 21.6. Stream Fragmentation and Reassembly Attacks
An adversarial sender might intentionally send fragments of stream An adversarial sender might intentionally send fragments of stream
data in order to cause disproportionate receive buffer memory data in an attempt to cause disproportionate receive buffer memory
commitment and/or creation of a large and inefficient data structure. commitment and/or creation of a large and inefficient data structure.
An adversarial receiver might intentionally not acknowledge packets An adversarial receiver might intentionally not acknowledge packets
containing stream data in order to force the sender to store the containing stream data in an attempt to force the sender to store the
unacknowledged stream data for retransmission. unacknowledged stream data for retransmission.
The attack on receivers is mitigated if flow control windows The attack on receivers is mitigated if flow control windows
correspond to available memory. However, some receivers will over- correspond to available memory. However, some receivers will over-
commit memory and advertise flow control offsets in the aggregate commit memory and advertise flow control offsets in the aggregate
that exceed actual available memory. The over-commitment strategy that exceed actual available memory. The over-commitment strategy
can lead to better performance when endpoints are well behaved, but can lead to better performance when endpoints are well behaved, but
renders endpoints vulnerable to the stream fragmentation attack. renders endpoints vulnerable to the stream fragmentation attack.
QUIC deployments SHOULD provide mitigations against stream QUIC deployments SHOULD provide mitigations against stream
fragmentation attacks. Mitigations could consist of avoiding over- fragmentation attacks. Mitigations could consist of avoiding over-
committing memory, limiting the size of tracking data structures, committing memory, limiting the size of tracking data structures,
delaying reassembly of STREAM frames, implementing heuristics based delaying reassembly of STREAM frames, implementing heuristics based
on the age and duration of reassembly holes, or some combination. on the age and duration of reassembly holes, or some combination.
21.6. Stream Commitment Attack 21.7. Stream Commitment Attack
An adversarial endpoint can open lots of streams, exhausting state on An adversarial endpoint can open a large number of streams,
an endpoint. The adversarial endpoint could repeat the process on a exhausting state on an endpoint. The adversarial endpoint could
large number of connections, in a manner similar to SYN flooding repeat the process on a large number of connections, in a manner
attacks in TCP. similar to SYN flooding attacks in TCP.
Normally, clients will open streams sequentially, as explained in Normally, clients will open streams sequentially, as explained in
Section 2.1. However, when several streams are initiated at short Section 2.1. However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence. On receiving a higher- streams to be received out of sequence. On receiving a higher-
numbered stream ID, a receiver is required to open all intervening numbered stream ID, a receiver is required to open all intervening
streams of the same type; see Section 3.2. Thus, on a new streams of the same type; see Section 3.2. Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client- connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams. initiated bidirectional streams.
The number of active streams is limited by the The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in Section 4.5. If chosen judiciously, parameters, as explained in Section 4.5. If chosen judiciously,
these limits mitigate the effect of the stream commitment attack. these limits mitigate the effect of the stream commitment attack.
However, setting the limit too low could affect performance when However, setting the limit too low could affect performance when
applications expect to open large number of streams. applications expect to open large number of streams.
21.7. Peer Denial of Service 21.8. Peer Denial of Service
QUIC and TLS both contain frames or messages that have legitimate QUIC and TLS both contain frames or messages that have legitimate
uses in some contexts, but that can be abused to cause a peer to uses in some contexts, but that can be abused to cause a peer to
expend processing resources without having any observable impact on expend processing resources without having any observable impact on
the state of the connection. the state of the connection.
Messages can also be used to change and revert state in small or Messages can also be used to change and revert state in small or
inconsequential ways, such as by sending small increments to flow inconsequential ways, such as by sending small increments to flow
control limits. control limits.
If processing costs are disproportionately large in comparison to If processing costs are disproportionately large in comparison to
bandwidth consumption or effect on state, then this could allow a bandwidth consumption or effect on state, then this could allow a
malicious peer to exhaust processing capacity. malicious peer to exhaust processing capacity.
While there are legitimate uses for all messages, implementations While there are legitimate uses for all messages, implementations
SHOULD track cost of processing relative to progress and treat SHOULD track cost of processing relative to progress and treat
excessive quantities of any non-productive packets as indicative of excessive quantities of any non-productive packets as indicative of
an attack. Endpoints MAY respond to this condition with a connection an attack. Endpoints MAY respond to this condition with a connection
error, or by dropping packets. error, or by dropping packets.
21.8. Explicit Congestion Notification Attacks 21.9. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate. [RFC3168] discusses the IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN codepoints to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this duplicate packet against the original to be successful in this
attack. Therefore, QUIC endpoints ignore the ECN codepoint field on attack. Therefore, QUIC endpoints ignore the ECN codepoint field on
an IP packet unless at least one QUIC packet in that IP packet is an IP packet unless at least one QUIC packet in that IP packet is
successfully processed; see Section 13.4. successfully processed; see Section 13.4.
21.9. Stateless Reset Oracle 21.10. Stateless Reset Oracle
Stateless resets create a possible denial of service attack analogous Stateless resets create a possible denial of service attack analogous
to a TCP reset injection. This attack is possible if an attacker is to a TCP reset injection. This attack is possible if an attacker is
able to cause a stateless reset token to be generated for a able to cause a stateless reset token to be generated for a
connection with a selected connection ID. An attacker that can cause connection with a selected connection ID. An attacker that can cause
this token to be generated can reset an active connection with the this token to be generated can reset an active connection with the
same connection ID. same connection ID.
If a packet can be routed to different instances that share a static If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker key, for example by changing an IP address or port, then an attacker
can cause the server to send a stateless reset. To defend against can cause the server to send a stateless reset. To defend against
this style of denial service, endpoints that share a static key for this style of denial of service, endpoints that share a static key
stateless reset (see Section 10.4.2) MUST be arranged so that packets for stateless reset (see Section 10.3.2) MUST be arranged so that
with a given connection ID always arrive at an instance that has packets with a given connection ID always arrive at an instance that
connection state, unless that connection is no longer active. has connection state, unless that connection is no longer active.
In the case of a cluster that uses dynamic load balancing, it's More generally, servers MUST NOT generate a stateless reset if a
possible that a change in load balancer configuration could happen connection with the corresponding connection ID could be active on
while an active instance retains connection state; even if an any endpoint using the same static key.
In the case of a cluster that uses dynamic load balancing, it is
possible that a change in load balancer configuration could occur
while an active instance retains connection state. Even if an
instance retains connection state, the change in routing and instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being resulting stateless reset will result in the connection being
terminated. If there is no chance in the packet being routed to the terminated. If there is no chance of the packet being routed to the
correct instance, it is better to send a stateless reset than wait correct instance, it is better to send a stateless reset than wait
for connections to time out. However, this is acceptable only if the for the connection to time out. However, this is acceptable only if
routing cannot be influenced by an attacker. the routing cannot be influenced by an attacker.
21.10. Version Downgrade 21.11. Version Downgrade
This document defines QUIC Version Negotiation packets in Section 6, This document defines QUIC Version Negotiation packets in Section 6
which can be used to negotiate the QUIC version used between two that can be used to negotiate the QUIC version used between two
endpoints. However, this document does not specify how this endpoints. However, this document does not specify how this
negotiation will be performed between this version and subsequent negotiation will be performed between this version and subsequent
future versions. In particular, Version Negotiation packets do not future versions. In particular, Version Negotiation packets do not
contain any mechanism to prevent version downgrade attacks. Future contain any mechanism to prevent version downgrade attacks. Future
versions of QUIC that use Version Negotiation packets MUST define a versions of QUIC that use Version Negotiation packets MUST define a
mechanism that is robust against version downgrade attacks. mechanism that is robust against version downgrade attacks.
21.11. Targeted Attacks by Routing 21.12. Targeted Attacks by Routing
Deployments should limit the ability of an attacker to target a new Deployments should limit the ability of an attacker to target a new
connection to a particular server instance. This means that client- connection to a particular server instance. This means that client-
controlled fields, such as the initial Destination Connection ID used controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions. Ideally, routing decisions are made independently routing decisions. Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to of client-selected values; a Source Connection ID can be selected to
route later packets to the same server. route later packets to the same server.
21.12. Overview of Security Properties 21.13. Overview of Security Properties
A complete security analysis of QUIC is outside the scope of this A complete security analysis of QUIC is outside the scope of this
document. This section provides an informal description of the document. This section provides an informal description of the
desired security properties as an aid to implementors and to help desired security properties as an aid to implementors and to help
guide protocol analysis. guide protocol analysis.
QUIC assumes the threat model described in [SEC-CONS] and provides QUIC assumes the threat model described in [SEC-CONS] and provides
protections against many of the attacks that arise from that model. protections against many of the attacks that arise from that model.
For this purpose, attacks are divided into passive and active For this purpose, attacks are divided into passive and active
skipping to change at page 147, line 48 skipping to change at page 156, line 17
the network, while active attackers also have the capability to write the network, while active attackers also have the capability to write
packets into the network. However, a passive attack may involve an packets into the network. However, a passive attack may involve an
attacker with the ability to cause a routing change or other attacker with the ability to cause a routing change or other
modification in the path taken by packets that comprise a connection. modification in the path taken by packets that comprise a connection.
Attackers are additionally categorized as either on-path attackers or Attackers are additionally categorized as either on-path attackers or
off-path attackers; see Section 3.5 of [SEC-CONS]. An on-path off-path attackers; see Section 3.5 of [SEC-CONS]. An on-path
attacker can read, modify, or remove any packet it observes such that attacker can read, modify, or remove any packet it observes such that
it no longer reaches its destination, while an off-path attacker it no longer reaches its destination, while an off-path attacker
observes the packets, but cannot prevent the original packet from observes the packets, but cannot prevent the original packet from
reaching its intended destination. An off-path attacker can also reaching its intended destination. Both types of attackers can also
transmit arbitrary packets. transmit arbitrary packets.
Properties of the handshake, protected packets, and connection Properties of the handshake, protected packets, and connection
migration are considered separately. migration are considered separately.
21.12.1. Handshake 21.13.1. Handshake
The QUIC handshake incorporates the TLS 1.3 handshake and inherits The QUIC handshake incorporates the TLS 1.3 handshake and inherits
the cryptographic properties described in Appendix E.1 of [TLS13]. the cryptographic properties described in Appendix E.1 of [TLS13].
Many of the security properties of QUIC depend on the TLS handshake Many of the security properties of QUIC depend on the TLS handshake
providing these properties. Any attack on the TLS handshake could providing these properties. Any attack on the TLS handshake could
affect QUIC. affect QUIC.
Any attack on the TLS handshake that compromises the secrecy or Any attack on the TLS handshake that compromises the secrecy or
uniqueness of session keys affects other security guarantees provided uniqueness of session keys affects other security guarantees provided
by QUIC that depends on these keys. For instance, migration by QUIC that depends on these keys. For instance, migration
skipping to change at page 148, line 27 skipping to change at page 156, line 45
both for the negotiation of keys using the TLS handshake and for QUIC both for the negotiation of keys using the TLS handshake and for QUIC
packet protection, to avoid linkability across network paths. packet protection, to avoid linkability across network paths.
An attack on the integrity of the TLS handshake might allow an An attack on the integrity of the TLS handshake might allow an
attacker to affect the selection of application protocol or QUIC attacker to affect the selection of application protocol or QUIC
version. version.
In addition to the properties provided by TLS, the QUIC handshake In addition to the properties provided by TLS, the QUIC handshake
provides some defense against DoS attacks on the handshake. provides some defense against DoS attacks on the handshake.
21.12.1.1. Anti-Amplification 21.13.1.1. Anti-Amplification
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 is either on-path or off-path. for which an attacker can observe packets.
Prior to validation, endpoints are limited in what they are able to Prior to validation, endpoints are limited in what they are able to
send. During the handshake, a server cannot send more than three send. During the handshake, a server cannot send more than three
times the data it receives; clients that initiate new connections or times the data it receives; clients that initiate new connections or
migrate to a new network path are limited. migrate to a new network path are limited.
21.12.1.2. Server-Side DoS 21.13.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 which 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
will allow new connection establishment without incurring this cost. will allow new connection establishment without incurring this cost.
21.12.1.3. On-Path Handshake Termination 21.13.1.3. On-Path Handshake Termination
An on-path or off-path attacker can force a handshake to fail by An on-path or off-path attacker can force a handshake to fail by
replacing or racing Initial packets. Once valid Initial packets have replacing or racing Initial packets. Once valid Initial packets have
been exchanged, subsequent Handshake packets are protected with the been exchanged, subsequent Handshake packets are protected with the
handshake keys and an on-path attacker cannot force handshake failure handshake keys and an on-path attacker cannot force handshake failure
other than by dropping packets to cause endpoints to abandon the other than by dropping packets to cause endpoints to abandon the
attempt. attempt.
An on-path attacker can also replace the addresses of packets on An on-path attacker can also replace the addresses of packets on
either side and therefore cause the client or server to have an either side and therefore cause the client or server to have an
incorrect view of the remote addresses. Such an attack is incorrect view of the remote addresses. Such an attack is
indistinguishable from the functions performed by a NAT. indistinguishable from the functions performed by a NAT.
21.12.1.4. Parameter Negotiation 21.13.1.4. Parameter Negotiation
The entire handshake is cryptographically protected, with the Initial The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key later packets being encrypted with keys derived from the TLS key
exchange. Further, parameter negotiation is folded into the TLS exchange. Further, parameter negotiation is folded into the TLS
transcript and thus provides the same integrity guarantees as transcript and thus provides the same integrity guarantees as
ordinary TLS negotiation. An attacker can observe the client's ordinary TLS negotiation. An attacker can observe the client's
transport parameters (as long as it knows the version-specific keys) transport parameters (as long as it knows the version-specific salt)
but cannot observe the server's transport parameters and cannot but cannot observe the server's transport parameters and cannot
influence parameter negotiation. influence parameter negotiation.
Connection IDs are unencrypted but integrity protected in all Connection IDs are unencrypted but integrity protected in all
packets. packets.
This version of QUIC does not incorporate a version negotiation This version of QUIC does not incorporate a version negotiation
mechanism; implementations of incompatible versions will simply fail mechanism; implementations of incompatible versions will simply fail
to establish a connection. to establish a connection.
21.12.2. Protected Packets 21.13.2. Protected Packets
Packet protection (Section 12.1) provides authentication and Packet protection (Section 12.1) provides authentication and
encryption of all packets except Version Negotiation packets, though encryption of all packets except Version Negotiation packets, though
Initial and Retry packets have limited encryption and authentication Initial and Retry packets have limited encryption and authentication
based on version-specific keys; see [QUIC-TLS] for more details. based on version-specific inputs; see [QUIC-TLS] for more details.
This section considers passive and active attacks against protected This section considers passive and active attacks against protected
packets. packets.
Both on-path and off-path attackers can mount a passive attack in Both on-path and off-path attackers can mount a passive attack in
which they save observed packets for an offline attack against packet which they save observed packets for an offline attack against packet
protection at a future time; this is true for any observer of any protection at a future time; this is true for any observer of any
packet on any network. packet on any network.
A blind attacker, one who injects packets without being able to A blind attacker, one who injects packets without being able to
observe valid packets for a connection, is unlikely to be successful, observe valid packets for a connection, is unlikely to be successful,
since packet protection ensures that valid packets are only generated since packet protection ensures that valid packets are only generated
by endpoints which possess the key material established during the by endpoints that possess the key material established during the
handshake; see Section 7 and Section 21.12.1. Similarly, any active handshake; see Section 7 and Section 21.13.1. Similarly, any active
attacker that observes packets and attempts to insert new data or attacker that observes packets and attempts to insert new data or
modify existing data in those packets should not be able to generate modify existing data in those packets should not be able to generate
packets deemed valid by the receiving endpoint. packets deemed valid by the receiving endpoint.
A spoofing attack, in which an active attacker rewrites unprotected A spoofing attack, in which an active attacker rewrites unprotected
parts of a packet that it forwards or injects, such as the source or parts of a packet that it forwards or injects, such as the source or
destination address, is only effective if the attacker can forward destination address, is only effective if the attacker can forward
packets to the original endpoint. Packet protection ensures that the packets to the original endpoint. Packet protection ensures that the
packet payloads can only be processed by the endpoints that completed packet payloads can only be processed by the endpoints that completed
the handshake, and invalid packets are ignored by those endpoints. the handshake, and invalid packets are ignored by those endpoints.
An attacker can also modify the boundaries between packets and UDP An attacker can also modify the boundaries between packets and UDP
datagrams, causing multiple packets to be coalesced into a single datagrams, causing multiple packets to be coalesced into a single
datagram, or splitting coalesced packets into multiple datagrams. datagram, or splitting coalesced packets into multiple datagrams.
Aside from datagrams containing Initial packets, which require Aside from datagrams containing Initial packets, which require
padding, modification of how packets are arranged in datagrams has no padding, modification of how packets are arranged in datagrams has no
functional effect on a connection, although it might change some functional effect on a connection, although it might change some
performance characteristics. performance characteristics.
21.12.3. Connection Migration 21.13.3. Connection Migration
Connection Migration (Section 9) provides endpoints with the ability Connection Migration (Section 9) provides endpoints with the ability
to transition between IP addresses and ports on multiple paths, using to transition between IP addresses and ports on multiple paths, using
one path at a time for transmission and receipt of non-probing one path at a time for transmission and receipt of non-probing
frames. Path validation (Section 8.2) establishes that a peer is frames. Path validation (Section 8.2) establishes that a peer is
both willing and able to receive packets sent on a particular path. both willing and able to receive packets sent on a particular path.
This helps reduce the effects of address spoofing by limiting the This helps reduce the effects of address spoofing by limiting the
number of packets sent to a spoofed address. number of packets sent to a spoofed address.
This section describes the intended security properties of connection This section describes the intended security properties of connection
migration when under various types of DoS attacks. migration when under various types of DoS attacks.
21.12.3.1. On-Path Active Attacks 21.13.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:
* Inspect packets * Inspect packets
skipping to change at page 152, line 5 skipping to change at page 160, line 19
3. An on-path attacker cannot prevent a client from migrating to a 3. An on-path attacker cannot prevent a client from migrating to a
path for which the attacker is not on-path. path for which the attacker is not on-path.
4. An on-path attacker can reduce the throughput of a connection by 4. An on-path attacker can reduce the throughput of a connection by
delaying packets or dropping them. delaying packets or dropping them.
5. An on-path attacker cannot cause an endpoint to accept a packet 5. An on-path attacker cannot cause an endpoint to accept a packet
for which it has modified an authenticated portion of that for which it has modified an authenticated portion of that
packet. packet.
21.12.3.2. Off-Path Active Attacks 21.13.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 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 sent between the client and the server. It is also able to send
copies of those packets to either endpoint. copies of those packets to either endpoint.
An off-path attacker can: An off-path attacker can:
* Inspect packets * Inspect packets
skipping to change at page 153, line 25 skipping to change at page 161, line 44
5. An off-path attacker can become a limited on-path attacker during 5. An off-path attacker can become a limited on-path attacker during
migration to a new path for which it is also an off-path migration to a new path for which it is also an off-path
attacker. attacker.
6. An off-path attacker can become a limited on-path attacker by 6. An off-path attacker can become a limited on-path attacker by
affecting shared NAT state such that it sends packets to the affecting shared NAT state such that it sends packets to the
server from the same IP address and port that the client server from the same IP address and port that the client
originally used. originally used.
21.12.3.3. Limited On-Path Active Attacks 21.13.3.3. Limited On-Path Active Attacks
A limited on-path attacker is an off-path attacker that has offered A limited on-path attacker is an off-path attacker that has offered
improved routing of packets by duplicating and forwarding original improved routing of packets by duplicating and forwarding original
packets between the server and the client, causing those packets to packets between the server and the client, causing those packets to
arrive before the original copies such that the original packets are arrive before the original copies such that the original packets are
dropped by the destination endpoint. dropped by the destination endpoint.
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
skipping to change at page 157, line 8 skipping to change at page 165, line 24
This process also applies to requests to change a provisional This process also applies to requests to change a provisional
registration into a permanent registration, except that the goal is registration into a permanent registration, except that the goal is
not to determine whether there is no use of the codepoint, but to not to determine whether there is no use of the codepoint, but to
determine that the registration is an accurate representation of any determine that the registration is an accurate representation of any
deployed usage. deployed usage.
22.1.4. Permanent Registrations 22.1.4. Permanent Registrations
Permanent registrations in QUIC registries use the Specification Permanent registrations in QUIC registries use the Specification
Required policy [RFC8126], unless otherwise specified. The Required policy ([RFC8126]), unless otherwise specified. The
designated expert(s) verify that a specification exists and is designated expert(s) verify that a specification exists and is
readily accessible. Expert(s) are encouraged to be biased towards readily accessible. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or actively harmful (not merely aesthetically displeasing, or
architecturally dubious). The creation of a registry MAY specify architecturally dubious). The creation of a registry MAY specify
additional constraints on permanent registrations. additional constraints on permanent registrations.
The creation of a registries MAY identify a range of codepoints where The creation of a registry MAY identify a range of codepoints where
registrations are governed by a different registration policy. For registrations are governed by a different registration policy. For
instance, the registries for 62-bit codepoints in this document have instance, the registries for 62-bit codepoints in this document have
stricter policies for codepoints in the range from 0 to 63. stricter policies for codepoints in the range from 0 to 63.
Any stricter requirements for permanent registrations do not prevent Any stricter requirements for permanent registrations do not prevent
provisional registrations for affected codepoints. For instance, a provisional registrations for affected codepoints. For instance, a
provisional registration for a frame type Section 22.3 of 61 could be provisional registration for a frame type (Section 22.3) of 61 could
requested. be requested.
All registrations made by Standards Track publications MUST be All registrations made by Standards Track publications MUST be
permanent. permanent.
All registrations in this document are assigned a permanent status All registrations in this document are assigned a permanent status
and list as contact both the IESG (ietf@ietf.org) and the QUIC and list as contact the IETF (quic@ietf.org).
working group (quic@ietf.org (mailto:quic@ietf.org)).
22.2. QUIC Transport Parameter Registry 22.2. QUIC Transport Parameter Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" IANA [SHALL add/has added] a registry for "QUIC Transport Parameters"
under a "QUIC" heading. under a "QUIC" heading.
The "QUIC Transport Parameters" registry governs a 62-bit space. The "QUIC Transport Parameters" registry governs a 62-bit space.
This registry follows the registration policy from Section 22.1. This registry follows the registration policy from Section 22.1.
Permanent registrations in this registry are assigned using the Permanent registrations in this registry are assigned using the
Specification Required policy [RFC8126]. Specification Required policy ([RFC8126]).
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following fields: 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 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
skipping to change at page 158, line 49 skipping to change at page 167, line 49
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x10 | retry_source_connection_id | Section 18.2 | | 0x10 | retry_source_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Entries Table 6: Initial QUIC Transport Parameters Entries
Additionally, each value of the format "31 * N + 27" for integer Additionally, each value of the format "31 * N + 27" for integer
values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be
assigned by IANA. assigned by IANA.
22.3. QUIC Frame Type Registry 22.3. QUIC Frame Types Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC" heading. "QUIC" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This The "QUIC Frame Types" registry governs a 62-bit space. This
registry follows the registration policy from Section 22.1. registry follows the registration policy from Section 22.1.
Permanent registrations in this registry are assigned using the Permanent registrations in this registry are assigned using the
Specification Required policy [RFC8126], except for values between Specification Required policy ([RFC8126]), except for values between
0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
Standards Action or IESG Approval as defined in Section 4.9 and 4.10 Standards Action or IESG Approval as defined in Section 4.9 and 4.10
of [RFC8126]. of [RFC8126].
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following fields: in this registry MUST include the following field:
Frame Name: A short mnemonic for the frame type. Frame Name: A short mnemonic for the frame type.
In addition to the advice in Section 22.1, specifications for new In addition to the advice in Section 22.1, specifications for new
permanent registrations SHOULD describe the means by which an permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of endpoint might determine that it can send the identified type of
frame. An accompanying transport parameter registration is expected frame. An accompanying transport parameter registration is expected
for most registrations; see Section 22.2. Specifications for for most registrations; see Section 22.2. Specifications for
permanent registrations also needs to describe the format and permanent registrations also need to describe the format and assigned
assigned semantics of any fields in the frame. semantics of any fields in the frame.
The initial contents of this registry are tabulated in Table 3. The initial contents of this registry are tabulated in Table 3. Note
that the registry does not include the "Pkts" and "Spec" columns from
Table 3.
22.4. QUIC Transport Error Codes Registry 22.4. QUIC Transport Error Codes Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Error IANA [SHALL add/has added] a registry for "QUIC Transport Error
Codes" under a "QUIC" heading. Codes" under a "QUIC" heading.
The "QUIC Transport Error Codes" registry governs a 62-bit space. The "QUIC Transport Error Codes" registry governs a 62-bit space.
This space is split into three spaces that are governed by different This space is split into three regions that are governed by different
policies. Permanent registrations in this registry are assigned policies. Permanent registrations in this registry are assigned
using the Specification Required policy [RFC8126], except for values using the Specification Required policy ([RFC8126]), except for
between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned values between 0x00 and 0x3f (in hexadecimal; inclusive), which are
using Standards Action or IESG Approval as defined in Section 4.9 and assigned using Standards Action or IESG Approval as defined in
4.10 of [RFC8126]. Section 4.9 and 4.10 of [RFC8126].
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following fields: 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 | Error | Description | Specification | |Value | Error | Description | Specification |
+======+===========================+================+===============+ +======+===========================+================+===============+
| 0x0 | NO_ERROR | No error | Section 20 | | 0x0 | NO_ERROR | No error | Section 20 |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x1 | INTERNAL_ERROR | Implementation | Section 20 | | 0x1 | INTERNAL_ERROR | Implementation | Section 20 |
| | | error | | | | | error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x2 | CONNECTION_REFUSED_ERROR |Server refuses a| Section 20 | | 0x2 | CONNECTION_REFUSED |Server refuses a| Section 20 |
| | | connection | | | | | connection | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 |
| | | error | | | | | error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 | | 0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 |
| | | opened | | | | | opened | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 |
| | | in invalid | | | | | in invalid | |
skipping to change at page 160, line 40 skipping to change at page 169, line 40
| | | error | | | | | error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 |
| | | transport | | | | | transport | |
| | | parameters | | | | | parameters | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 | | 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 |
| | | connection IDs | | | | | connection IDs | |
| | | received | | | | | received | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xA | PROTOCOL_VIOLATION |Generic protocol| Section 20 | | 0xa | PROTOCOL_VIOLATION |Generic protocol| Section 20 |
| | | violation | | | | | violation | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xB | INVALID_TOKEN | Invalid Token | Section 20 | | 0xb | INVALID_TOKEN | Invalid Token | Section 20 |
| | | Received | | | | | Received | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xC | APPLICATION_ERROR | Application | Section 20 | | 0xc | APPLICATION_ERROR | Application | Section 20 |
| | | error | | | | | error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | | 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 |
| | | buffer | | | | | buffer | |
| | | overflowed | | | | | overflowed | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and [DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", Work in Progress, Internet-Draft, Datagram Transports", Work in Progress, Internet-Draft,
draft-ietf-tsvwg-datagram-plpmtud-21, 12 May 2020, draft-ietf-tsvwg-datagram-plpmtud-22, June 10, 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
datagram-plpmtud-21.txt>. datagram-plpmtud-22.txt>.
[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/info/rfc791>.
[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", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-29, 10 June 2020, draft-ietf-quic-recovery-30, September 10, 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-29>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-30>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", Work in Progress, Layer Security (TLS) to Secure QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-tls-29, 10 June 2020, Internet-Draft, draft-ietf-quic-tls-30, September 10,
<https://tools.ietf.org/html/draft-ietf-quic-tls-29>. 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-30>.
[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery",
RFC 1191, DOI 10.17487/RFC1191, November 1990, RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/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/info/rfc2119>.
skipping to change at page 162, line 10 skipping to change at page 171, line 10
[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/info/rfc3629>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] 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/info/rfc4086>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[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/info/rfc6437>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/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
skipping to change at page 162, line 46 skipping to change at page 171, line 42
[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/info/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/info/rfc8446>.
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
23.2. Informative References 23.2. Informative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/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/info/rfc7838>.
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2267, DOI 10.17487/RFC2267, January
1998, <https://www.rfc-editor.org/info/rfc2267>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses
for cross-site request forgery",
DOI 10.1145/1455770.1455782, Proceedings of the 15th ACM
conference on Computer and communications security -
CCS '08, 2008, <https://doi.org/10.1145/1455770.1455782>.
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2 Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2, 2013, <https://goo.gl/dMVtFi>.
[GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An experimental study of home
gateway characteristics", DOI 10.1145/1879141.1879174,
Proceedings of the 10th annual conference on Internet
measurement - IMC '10, 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/info/rfc7540>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-09, 10 June 2020, <https://tools.ietf.org/html/ invariants-10, September 10, 2020,
draft-ietf-quic-invariants-09>. <https://tools.ietf.org/html/draft-ietf-quic-invariants-
10>.
[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, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-06, 6 January 2020, draft-ietf-quic-manageability-07, July 8, 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
manageability-06.txt>. manageability-07.txt>.
[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/info/rfc1812>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/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/info/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/info/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/info/rfc3449>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/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/info/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/info/rfc4787>.
skipping to change at page 164, line 24 skipping to change at page 174, line 24
[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/info/rfc5869>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] 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/info/rfc7301>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [SEC-CONS] 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/info/rfc3552>.
[SLOWLORIS] [SLOWLORIS]
RSnake Hansen, R., "Welcome to Slowloris...", June 2009, RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
<https://web.archive.org/web/20150315054838/ <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
[STD] Bradner, S., "The Internet Standards Process -- Revision [STD] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
Appendix A. Sample Packet Number Decoding Algorithm Appendix A. Sample Packet Number Decoding Algorithm
The pseudo-code in Figure 44 shows how an implementation can decode The pseudo-code in Figure 45 shows how an implementation can decode
packet numbers after header protection has been removed. packet numbers after header protection has been removed.
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
// //
// This means we can't just strip the trailing bits from // This means we cannot just strip the trailing bits from
// expected_pn and add the truncated_pn because that might // expected_pn and add the truncated_pn because that might
// yield a value outside the window. // yield a value outside the window.
// //
// The following code calculates a candidate value and // The following code calculates a candidate value and
// makes sure it's within the packet number window. // makes sure it's within the packet number window.
// 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 44: Sample Packet Number Decoding Algorithm Figure 45: Sample Packet Number Decoding Algorithm
Appendix B. Sample ECN Validation Algorithm Appendix B. 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
periodically reassess a path that was determined to not support ECN. periodically reassess a path that was determined to not support ECN.
This section describes one method for testing new paths. This This section describes one method for testing new paths. This
algorithm is intended to show how a path might be tested for ECN algorithm is intended to show how a path might be tested for ECN
skipping to change at page 166, line 36 skipping to change at page 176, line 36
marked packets are discarded by the path, the short duration of the marked packets are discarded by the path, the short duration of the
testing period limits the number of losses incurred. testing period limits the number of losses incurred.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-28 C.1. Since draft-ietf-quic-transport-29
* Require the same connection ID on coalesced packets (#3800, #3930)
* Allow caching of packets that can't be decrypted, by allowing the
reported acknowledgment delay to exceed max_ack_delay prior to
confirming the handshake (#3821, #3980, #4035, #3874)
* Allow connection ID to be used for address validation (#3834,
#3924)
* Required protocol operations are no longer directed at
implementations, but are features provided to application
protocols (#3838, #3935)
* Narrow requirements for reset of congestion state on path change
(#3842, #3945)
* Add a three times amplification limit for sending of
CONNECTION_CLOSE with reduced state (#3845, #3864)
* Change error code for invalid RETIRE_CONNECTION_ID frames (#3860,
#3861)
* Recommend retention of state for lost packets to allow for late
arrival and avoid unnecessary retransmission (#3956, #3957)
* Allow a server to reject connections if a client reuses packet
numbers after Retry (#3989, #3990)
* Limit recommendation for immediate acknowledgment to when ack-
eliciting packets are reordered (#4001, #4000)
C.2. Since draft-ietf-quic-transport-28
* Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED * Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED
(#3709, #3690, #3694) (#3709, #3690, #3694)
* Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs * Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs
(#3703, #3691) (#3703, #3691)
* Integrate QUIC-specific language from draft-ietf-tsvwg-datagram- * Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-
plpmtud (#3695, #3702) plpmtud (#3695, #3702)
* disable_active_migration does not apply to the addresses offered * disable_active_migration does not apply to the addresses offered
in server_preferred_address (#3608, #3670) in server_preferred_address (#3608, #3670)
C.2. Since draft-ietf-quic-transport-27 C.3. Since draft-ietf-quic-transport-27
* Allowed CONNECTION_CLOSE in any packet number space, with a * Allowed CONNECTION_CLOSE in any packet number space, with a
requirement to use a new transport-level error for application- requirement to use a new transport-level error for application-
specific errors in Initial and Handshake packets (#3430, #3435, specific errors in Initial and Handshake packets (#3430, #3435,
#3440) #3440)
* Clearer requirements for address validation (#2125, #3327) * Clearer requirements for address validation (#2125, #3327)
* Security analysis of handshake and migration (#2143, #2387, #2925) * Security analysis of handshake and migration (#2143, #2387, #2925)
* The entire payload of a datagram is used when counting bytes for * The entire payload of a datagram is used when counting bytes for
skipping to change at page 168, line 5 skipping to change at page 178, line 34
* Clarified that largest acknowledged needs to be saved, but not * Clarified that largest acknowledged needs to be saved, but not
necessarily signaled in all cases (#3541, #3581) necessarily signaled in all cases (#3541, #3581)
* Addressed linkability risk with the use of preferred_address * Addressed linkability risk with the use of preferred_address
(#3559, #3563) (#3559, #3563)
* Added authentication of handshake connection IDs (#3439, #3499) * Added authentication of handshake connection IDs (#3439, #3499)
* Opening a stream in the wrong direction is an error (#3527) * Opening a stream in the wrong direction is an error (#3527)
C.3. Since draft-ietf-quic-transport-26 C.4. Since draft-ietf-quic-transport-26
* Change format of transport parameters to use varints (#3294, * Change format of transport parameters to use varints (#3294,
#3169) #3169)
C.4. Since draft-ietf-quic-transport-25 C.5. Since draft-ietf-quic-transport-25
* Define the use of CONNECTION_CLOSE prior to establishing * Define the use of CONNECTION_CLOSE prior to establishing
connection state (#3269, #3297, #3292) connection state (#3269, #3297, #3292)
* Allow use of address validation tokens after client address * Allow use of address validation tokens after client address
changes (#3307, #3308) changes (#3307, #3308)
* Define the timer for address validation (#2910, #3339) * Define the timer for address validation (#2910, #3339)
C.5. Since draft-ietf-quic-transport-24 C.6. Since draft-ietf-quic-transport-24
* Added HANDSHAKE_DONE to signal handshake confirmation (#2863, * Added HANDSHAKE_DONE to signal handshake confirmation (#2863,
#3142, #3145) #3142, #3145)
* Add integrity check to Retry packets (#3014, #3274, #3120) * Add integrity check to Retry packets (#3014, #3274, #3120)
* Specify handling of reordered NEW_CONNECTION_ID frames (#3194, * Specify handling of reordered NEW_CONNECTION_ID frames (#3194,
#3202) #3202)
* Require checking of sequence numbers in RETIRE_CONNECTION_ID * Require checking of sequence numbers in RETIRE_CONNECTION_ID
skipping to change at page 169, line 25 skipping to change at page 180, line 5
* Idle timeout is symmetric (#2602, #3099) * Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280) * Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries * Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170) (#3109, #3020, #3102, #3170)
* Packets on one path must not adjust values for a different path * Packets on one path must not adjust values for a different path
(#2909, #3139) (#2909, #3139)
C.6. Since draft-ietf-quic-transport-23 C.7. Since draft-ietf-quic-transport-23
* Allow ClientHello to span multiple packets (#2928, #3045) * Allow ClientHello to span multiple packets (#2928, #3045)
* Client Initial size constraints apply to UDP datagram payload * Client Initial size constraints apply to UDP datagram payload
(#3053, #3051) (#3053, #3051)
* Stateless reset changes (#2152, #2993) * Stateless reset changes (#2152, #2993)
- tokens need to be compared in constant time - tokens need to be compared in constant time
skipping to change at page 170, line 4 skipping to change at page 180, line 33
* A new connection ID is necessary when responding to migration * A new connection ID is necessary when responding to migration
(#2778, #2969) (#2778, #2969)
* Stronger requirements for connection ID retirement (#3046, #3096) * Stronger requirements for connection ID retirement (#3046, #3096)
* NEW_TOKEN cannot be empty (#2978, #2977) * NEW_TOKEN cannot be empty (#2978, #2977)
* PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
* CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) * CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
* Frame encoding error conditions updated (#3027, #3042) * Frame encoding error conditions updated (#3027, #3042)
* Non-ack-eliciting packets cannot be sent in response to non-ack- * Non-ack-eliciting packets cannot be sent in response to non-ack-
eliciting packets (#3100, #3104) eliciting packets (#3100, #3104)
* Servers have to change connection IDs in Retry (#2837, #3147) * Servers have to change connection IDs in Retry (#2837, #3147)
C.7. Since draft-ietf-quic-transport-22 C.8. Since draft-ietf-quic-transport-22
* Rules for preventing correlation by connection ID tightened * Rules for preventing correlation by connection ID tightened
(#2084, #2929) (#2084, #2929)
* Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, * Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688) #2541, #2688)
* Discourage regressions of largest acknowledged in ACK (#2205, * Discourage regressions of largest acknowledged in ACK (#2205,
#2752) #2752)
skipping to change at page 171, line 19 skipping to change at page 181, line 48
#2840, #2841) #2840, #2841)
* Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
* Cryptographic handshake needs to provide server transport * Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921) parameter encryption (#2920, #2921)
* Moved ACK generation guidance from recovery draft to transport * Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916). draft (#1860, #2916).
C.8. Since draft-ietf-quic-transport-21 C.9. Since draft-ietf-quic-transport-21
* Connection ID lengths are now one octet, but limited in version 1 * Connection ID lengths are now one octet, but limited in version 1
to 20 octets of length (#2736, #2749) to 20 octets of length (#2736, #2749)
C.9. Since draft-ietf-quic-transport-20 C.10. Since draft-ietf-quic-transport-20
* Error codes are encoded as variable-length integers (#2672, #2680) * Error codes are encoded as variable-length integers (#2672, #2680)
* NEW_CONNECTION_ID includes a request to retire old connection IDs * NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769) (#2645, #2769)
* Tighter rules for generating and explicitly eliciting ACK frames * Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794) (#2546, #2794)
* Recommend having only one packet per encryption level in a * Recommend having only one packet per encryption level in a
skipping to change at page 172, line 20 skipping to change at page 182, line 49
* PATH_RESPONSE no longer needs to be received on the validated path * PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
* PATH_RESPONSE frames are not stored and retransmitted (#2724, * PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
* Document hack for enabling routing of ICMP when doing PMTU probing * Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
C.10. Since draft-ietf-quic-transport-19 C.11. Since draft-ietf-quic-transport-19
* Refine discussion of 0-RTT transport parameters (#2467, #2464) * Refine discussion of 0-RTT transport parameters (#2467, #2464)
* Fewer transport parameters need to be remembered for 0-RTT (#2624, * Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
* Spin bit text incorporated (#2564) * Spin bit text incorporated (#2564)
* Close the connection when maximum stream ID in MAX_STREAMS exceeds * Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62 - 1 (#2499, #2487)
* New connection ID required for intentional migration (#2414, * New connection ID required for intentional migration (#2414,
#2413) #2413)
skipping to change at page 172, line 47 skipping to change at page 183, line 27
* The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
* Initial packets from clients need to be padded to 1200 unless a * Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
* CRYPTO frames can be discarded if too much data is buffered * CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
* Stateless reset uses a short header packet (#2599, #2600) * Stateless reset uses a short header packet (#2599, #2600)
C.11. Since draft-ietf-quic-transport-18 C.12. Since draft-ietf-quic-transport-18
* Removed version negotiation; version negotiation, including * Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
* Added discussion of the use of IPv6 flow labels (#2348, #2399) * Added discussion of the use of IPv6 flow labels (#2348, #2399)
* A connection ID can't be retired in a packet that uses that * A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
* Idle timeout transport parameter is in milliseconds (from seconds) * Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
* Endpoints are required to use new connection IDs when they use new * Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414) network paths (#2413, #2414)
* Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
C.12. Since draft-ietf-quic-transport-17 C.13. Since draft-ietf-quic-transport-17
* Stream-related errors now use STREAM_STATE_ERROR (#2305) * Stream-related errors now use STREAM_STATE_ERROR (#2305)
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* Expanded conditions for ignoring ICMP packet too big messages * Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
* Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, * Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 174, line 10 skipping to change at page 184, line 37
#2301) #2301)
* Allow server preferred address for both IPv4 and IPv6 (#2122, * Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
* Corrected requirements for migration to a preferred address * Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
* ACK of non-existent packet is illegal (#2298, #2302) * ACK of non-existent packet is illegal (#2298, #2302)
C.13. Since draft-ietf-quic-transport-16 C.14. Since draft-ietf-quic-transport-16
* Stream limits are defined as counts, not maximums (#1850, #1906) * Stream limits are defined as counts, not maximums (#1850, #1906)
* Require amplification attack defense after closing (#1905, #1911) * Require amplification attack defense after closing (#1905, #1911)
* Remove reservation of application error code 0 for STOPPING * Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
* Renumbered frames (#1945) * Renumbered frames (#1945)
skipping to change at page 175, line 4 skipping to change at page 185, line 32
* Allow STOP_SENDING to open a remote bidirectional stream (#1797, * Allow STOP_SENDING to open a remote bidirectional stream (#1797,
#2013) #2013)
* Added mitigation for off-path migration attacks (#1278, #1749, * Added mitigation for off-path migration attacks (#1278, #1749,
#2033) #2033)
* Don't let the PMTU to drop below 1280 (#2063, #2069) * Don't let the PMTU to drop below 1280 (#2063, #2069)
* Require peers to replace retired connection IDs (#2085) * Require peers to replace retired connection IDs (#2085)
* Servers are required to ignore Version Negotiation packets (#2088) * Servers are required to ignore Version Negotiation packets (#2088)
* Tokens are repeated in all Initial packets (#2089) * Tokens are repeated in all Initial packets (#2089)
* Clarified how PING frames are sent after loss (#2094) * Clarified how PING frames are sent after loss (#2094)
* Initial keys are discarded once Handshake are available (#1951, * Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
* ICMP PTB validation clarifications (#2161, #2109, #2108) * ICMP PTB validation clarifications (#2161, #2109, #2108)
C.14. Since draft-ietf-quic-transport-15 C.15. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
C.15. Since draft-ietf-quic-transport-14 C.16. Since draft-ietf-quic-transport-14
* Merge ACK and ACK_ECN (#1778, #1801) * Merge ACK and ACK_ECN (#1778, #1801)
* Explicitly communicate max_ack_delay (#981, #1781) * Explicitly communicate max_ack_delay (#981, #1781)
* Validate original connection ID after Retry packets (#1710, #1486, * Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
* Idle timeout is optional and has no specified maximum (#1765) * Idle timeout is optional and has no specified maximum (#1765)
* Update connection ID handling; add RETIRE_CONNECTION_ID type * Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
* Include a Token in all Initial packets (#1649, #1794) * Include a Token in all Initial packets (#1649, #1794)
* Prevent handshake deadlock (#1764, #1824) * Prevent handshake deadlock (#1764, #1824)
C.16. Since draft-ietf-quic-transport-13 C.17. Since draft-ietf-quic-transport-13
* Streams open when higher-numbered streams of the same type open * Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
* Split initial stream flow control limit into 3 transport * Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
* All flow control transport parameters are optional (#1610) * All flow control transport parameters are optional (#1610)
* Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) * Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 176, line 28 skipping to change at page 187, line 7
* Permit 0-RTT after receiving Version Negotiation or Retry (#1507, * Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
* Permit Retry in response to 0-RTT (#1547, #1552) * Permit Retry in response to 0-RTT (#1547, #1552)
* Looser verification of ECN counters to account for ACK loss * Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
* Remove frame type field from APPLICATION_CLOSE (#1508, #1528) * Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
C.17. Since draft-ietf-quic-transport-12 C.18. Since draft-ietf-quic-transport-12
* Changes to integration of the TLS handshake (#829, #1018, #1094, * Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
- The cryptographic handshake uses CRYPTO frames, not stream 0 - The cryptographic handshake uses CRYPTO frames, not stream 0
- QUIC packet protection is used in place of TLS record - QUIC packet protection is used in place of TLS record
protection protection
- Separate QUIC packet number spaces are used for the handshake - Separate QUIC packet number spaces are used for the handshake
skipping to change at page 177, line 23 skipping to change at page 187, line 50
* Fixed sampling method for packet number encryption; the length * Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
* Stateless Reset is now symmetric and subject to size constraints * Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
* Added frame type extension mechanism (#58, #1473) * Added frame type extension mechanism (#58, #1473)
C.18. Since draft-ietf-quic-transport-11 C.19. Since draft-ietf-quic-transport-11
* Enable server to transition connections to a preferred address * Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
* Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, * Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
* Packet numbers use a variable-length encoding (#989, #1334) * Packet numbers use a variable-length encoding (#989, #1334)
* STREAM frames can now be empty (#1350) * STREAM frames can now be empty (#1350)
C.19. Since draft-ietf-quic-transport-10 C.20. Since draft-ietf-quic-transport-10
* Swap payload length and packed number fields in long header * Swap payload length and packed number fields in long header
(#1294) (#1294)
* Clarified that CONNECTION_CLOSE is allowed in Handshake packet * Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 178, line 4 skipping to change at page 188, line 31
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
* A more complete connection migration (#1249) * A more complete connection migration (#1249)
* Refine opportunistic ACK defense text (#305, #1030, #1185) * Refine opportunistic ACK defense text (#305, #1030, #1185)
* A Stateless Reset Token isn't mandatory (#818, #1191) * A Stateless Reset Token isn't mandatory (#818, #1191)
* Removed implicit stream opening (#896, #1193) * Removed implicit stream opening (#896, #1193)
* An empty STREAM frame can be used to open a stream without sending * An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
* Define stream counts in transport parameters rather than a maximum * Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
* STOP_SENDING is now prohibited before streams are used (#1050) * STOP_SENDING is now prohibited before streams are used (#1050)
* Recommend including ACK in Retry packets and allow PADDING (#1067, * Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
* Endpoints now become closing after an idle timeout (#1178, #1179) * Endpoints now become closing after an idle timeout (#1178, #1179)
* Remove implication that Version Negotiation is sent when a packet * Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
C.20. Since draft-ietf-quic-transport-09 C.21. Since draft-ietf-quic-transport-09
* Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with * Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
* A server can now only send 3 packets without validating the client * A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
* Delivery order of stream data is no longer strongly specified * Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 179, line 5 skipping to change at page 189, line 29
* Improved retransmission rules for all frame types: information is * Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
* Added an error code for server busy signals (#1137) * Added an error code for server busy signals (#1137)
* Endpoints now set the connection ID that their peer uses. * Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
C.21. Since draft-ietf-quic-transport-08 C.22. Since draft-ietf-quic-transport-08
* Clarified requirements for BLOCKED usage (#65, #924) * Clarified requirements for BLOCKED usage (#65, #924)
* BLOCKED frame now includes reason for blocking (#452, #924, #927, * BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
* GAP limitation in ACK Frame (#613) * GAP limitation in ACK Frame (#613)
* Improved PMTUD description (#614, #1036) * Improved PMTUD description (#614, #1036)
skipping to change at page 179, line 28 skipping to change at page 190, line 5
* Reserved versions don't need to be generated deterministically * Reserved versions don't need to be generated deterministically
(#831, #931) (#831, #931)
* You don't always need the draining period (#871) * You don't always need the draining period (#871)
* Stateless reset clarified as version-specific (#930, #986) * Stateless reset clarified as version-specific (#930, #986)
* initial_max_stream_id_x transport parameters are optional (#970, * initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
* Ack Delay assumes a default value during the handshake (#1007, * ACK delay assumes a default value during the handshake (#1007,
#1009) #1009)
* Removed transport parameters from NewSessionTicket (#1015) * Removed transport parameters from NewSessionTicket (#1015)
C.22. Since draft-ietf-quic-transport-07 C.23. Since draft-ietf-quic-transport-07
* The long header now has version before packet number (#926, #939) * The long header now has version before packet number (#926, #939)
* Rename and consolidate packet types (#846, #822, #847) * Rename and consolidate packet types (#846, #822, #847)
* Packet types are assigned new codepoints and the Connection ID * Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
* Removed type for Version Negotiation and use Version 0 (#963, * Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 180, line 28 skipping to change at page 191, line 5
* Address validation for connection migration (#161, #732, #878) * Address validation for connection migration (#161, #732, #878)
* Clearly defined retransmission rules for BLOCKED (#452, #65, #924) * Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
* negotiated_version is sent in server transport parameters (#710, * negotiated_version is sent in server transport parameters (#710,
#959) #959)
* Increased the range over which packet numbers are randomized * Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
C.23. Since draft-ietf-quic-transport-06 C.24. Since draft-ietf-quic-transport-06
* Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) * Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
* Split error code space between application and transport (#485) * Split error code space between application and transport (#485)
* Stateless reset token moved to end (#820) * Stateless reset token moved to end (#820)
* 1-RTT-protected long header types removed (#848) * 1-RTT-protected long header types removed (#848)
* No acknowledgments during draining period (#852) * No acknowledgments during draining period (#852)
* Remove "application close" as a separate close type (#854) * Remove "application close" as a separate close type (#854)
* Remove timestamps from the ACK frame (#841) * Remove timestamps from the ACK frame (#841)
* Require transport parameters to only appear once (#792) * Require transport parameters to only appear once (#792)
C.24. Since draft-ietf-quic-transport-05 C.25. Since draft-ietf-quic-transport-05
* Stateless token is server-only (#726) * Stateless token is server-only (#726)
* Refactor section on connection termination (#733, #748, #328, * Refactor section on connection termination (#733, #748, #328,
#177) #177)
* Limit size of Version Negotiation packet (#585) * Limit size of Version Negotiation packet (#585)
* Clarify when and what to ack (#736) * Clarify when and what to ack (#736)
* Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED * Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
* Clarify Keep-alive requirements (#729) * Clarify Keep-alive requirements (#729)
C.25. Since draft-ietf-quic-transport-04 C.26. Since draft-ietf-quic-transport-04
* Introduce STOP_SENDING frame, RESET_STREAM only resets in one * Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
* Removed GOAWAY; application protocols are responsible for graceful * Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
* Reduced the number of error codes (#96, #177, #184, #211) * Reduced the number of error codes (#96, #177, #184, #211)
* Version validation fields can't move or change (#121) * Version validation fields can't move or change (#121)
skipping to change at page 181, line 47 skipping to change at page 192, line 24
* Increased the maximum length of the Largest Acknowledged field in * Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
* truncate_connection_id is renamed to omit_connection_id (#659) * truncate_connection_id is renamed to omit_connection_id (#659)
* CONNECTION_CLOSE terminates the connection like TCP RST (#330, * CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.26. Since draft-ietf-quic-transport-03 C.27. Since draft-ietf-quic-transport-03
* Change STREAM and RESET_STREAM layout * Change STREAM and RESET_STREAM layout
* Add MAX_STREAM_ID settings * Add MAX_STREAM_ID settings
C.27. Since draft-ietf-quic-transport-02 C.28. Since draft-ietf-quic-transport-02
* The size of the initial packet payload has a fixed minimum (#267, * The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
* Define when Version Negotiation packets are ignored (#284, #294, * Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
* The 64-bit FNV-1a algorithm is used for integrity protection of * The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 182, line 51 skipping to change at page 193, line 27
linkability (#232, #491, #496) linkability (#232, #491, #496)
* Transport parameters for 0-RTT are retained from a previous * Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
- A client in 0-RTT no longer required to reset excess streams - A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
* Expanded security considerations (#440, #444, #445, #448) * Expanded security considerations (#440, #444, #445, #448)
C.28. Since draft-ietf-quic-transport-01 C.29. Since draft-ietf-quic-transport-01
* Defined short and long packet headers (#40, #148, #361) * Defined short and long packet headers (#40, #148, #361)
* Defined a versioning scheme and stable fields (#51, #361) * Defined a versioning scheme and stable fields (#51, #361)
* Define reserved version values for "greasing" negotiation (#112, * Define reserved version values for "greasing" negotiation (#112,
#278) #278)
* The initial packet number is randomized (#35, #283) * The initial packet number is randomized (#35, #283)
* Narrow the packet number encoding range requirement (#67, #286, * Narrow the packet number encoding range requirement (#67, #286,
skipping to change at page 184, line 49 skipping to change at page 195, line 25
* Remove error code and reason phrase from GOAWAY (#352, #355) * Remove error code and reason phrase from GOAWAY (#352, #355)
* GOAWAY includes a final stream number for both directions (#347) * GOAWAY includes a final stream number for both directions (#347)
* Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
* Defined priority as the responsibility of the application protocol * Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.29. Since draft-ietf-quic-transport-00 C.30. Since draft-ietf-quic-transport-00
* Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag * Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
* Defined versioning * Defined versioning
* Reworked description of packet and frame layout * Reworked description of packet and frame layout
* Error code space is divided into regions for each component * Error code space is divided into regions for each component
* Use big endian for all numeric values * Use big endian for all numeric values
C.30. Since draft-hamilton-quic-transport-protocol-01 C.31. Since draft-hamilton-quic-transport-protocol-01
* Adopted as base for draft-ietf-quic-tls * Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list * Updated authors/editors list
* Added IANA Considerations section * Added IANA Considerations section
* Moved Contributors and Acknowledgments to appendices * Moved Contributors and Acknowledgments to appendices
Contributors Contributors
 End of changes. 542 change blocks. 
1426 lines changed or deleted 1941 lines changed or added

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